Project: HDMI/DVI out for STFM

[exxos]

Nah, my crappy scope doesn't have a big enough buffer to capture that much... and I doubt my eyeballs would be up for manually counting them either.

ah, was thinking more counting in the FPGA, you could output binary count to some spare IO pins.. Then check bits with scope.

I think the glue only has access to D0 and D1.

ah yes, you are right.

I mean the whole thing sounds fairly ridiculous to me, but the evidence is right in front of my eyes... maybe the behaviour is part of TOS and not the ASICs at all?

Either something TOS is doing , or the shifter then. Though troed did mention something screwy about the registers if you tried to write to just 1 8 bit chunk instead of the 16bit chunk at once. Not sure if thats a possible issue with your setup or not..

Maybe you could try TOS1.00 and see what happens ? Maybe Atari were plotting extra video modes in TOS or the shifter during its production.. I guess we need someone to look at the TOS sources to see if anything is going on with other bits or not.

[Smonson]

ah, was thinking more counting in the FPGA, you could output binary count to some spare IO pins.. Then check bits with scope.

That's a good idea, although now I probably won't bother since it's working for normal video (...I will confirm that also for 50Hz tonight).

Either something TOS is doing , or the shifter then. Though troed did mention something screwy about the registers if you tried to write to just 1 8 bit chunk instead of the 16bit chunk at once. Not sure if thats a possible issue with your setup or not..

Maybe you could try TOS1.00 and see what happens ? Maybe Atari were plotting extra video modes in TOS or the shifter during its production.. I guess we need someone to look at the TOS sources to see if anything is going on with other bits or not.

I found the disassembled TOS in the ST Internals book... but it's not OCRed so there's no easy way to search for specific addresses. Is there a better copy out there? I also found a copy of the TOS 2.06 source but it's probably quite different from 1.04, which is the version I have in the machine.

One idea, maybe it's comparing the value read back from the video mode register with the copy in RAM in order to check if the video mode has been changed, and then automatically resetting the machine. That would seem to explain most of that behaviour.

[IngoQ]

I found the disassembled TOS in the ST Internals book... but it's not OCRed so there's no easy way to search for specific addresses.

If the quality of the scan is sufficient, I can OCR it for you.

[Smonson]

If the quality of the scan is sufficient, I can OCR it for you.

It isn't great, but if you want to try you can find it on page 275 of the book here: http://dev-docs.atariforge.org/files/At ... ernals.pdf

Tonight's obligatory progress shot (excuse the green):

20171106_213729.jpg (162.46 KiB) Viewed 5788 times

[troed]

I found the disassembled TOS in the ST Internals book... but it's not OCRed so there's no easy way to search for specific addresses. Is there a better copy out there? I also found a copy of the TOS 2.06 source but it's probably quite different from 1.04, which is the version I have in the machine.

One idea, maybe it's comparing the value read back from the video mode register with the copy in RAM in order to check if the video mode has been changed, and then automatically resetting the machine. That would seem to explain most of that behaviour.

Any TOS source will do when it comes to checking what you guess. There is a monitor detect interrupt which will by default reset an ST when it notices mono mode pin - it will also reset the machine if you switch video mode between low/medium and high.

It's not implausible that you could end up triggering this.

[Smonson]

Any TOS source will do when it comes to checking what you guess. There is a monitor detect interrupt which will by default reset an ST when it notices mono mode pin - it will also reset the machine if you switch video mode between low/medium and high.

It's not implausible that you could end up triggering this.

Yes, It seems very likely. But my motivation for confirming it is gone now that the problem is resolved. I don't have any development tools on the Atari - or any software at all apart from a collection of game disks on an SD card. So I can't easily examine the contents of the ROMs. Wait until I get a hard drive (and a monitor of course)

[Smonson]

How it fits:

20171107_210215.jpg (231.63 KiB) Viewed 5788 times

20171107_210513.jpg (172.6 KiB) Viewed 5788 times

I may have said a small apology to the gods when I started cutting.

[guus.assmann]

Great job, thanks for this !

As the shifter often is quite picy regarding timing, it is also a party stopper for some speedups in the system.
Maybe with this "shifter replacement" it is also possible to get the Ram and Rom to work at double speed?
The MMU generaly can handle higher speeds.
And for the CPU it's not a problem to replace it with a 16Mhz version.

Just a (hopefull) thought.

BR/
Guus

[Smonson]

Great job, thanks for this !

As the shifter often is quite picy regarding timing, it is also a party stopper for some speedups in the system.
Maybe with this "shifter replacement" it is also possible to get the Ram and Rom to work at double speed?
The MMU generaly can handle higher speeds.
And for the CPU it's not a problem to replace it with a 16Mhz version.

Thanks Guus!

If you wanted to go up to 32MHz, I think the main limitation would be the signal integrity between this board and the main board. The oscillator on the FPGA is already 32MHz (the logic internal to the FPGA can handle more than 1GHz - the DVI/HDMI clock for example is 320MHz currently) and it's supplying the 16MHz clock to the rest of the system through the shifter socket. Since the MMU and GLU aren't configurable you'd be limited to the same screen modes but at 100, 120 or 144.4 Hz! 100 or 120Hz might be OK using a fairly modern LCD TV.

You could do it with this board, no hardware changes are needed unless there's an analogue reason. There's an unused PLL in there so you don't need to limit the clock speed to powers of 2 either.

[Smonson]

Update: colour

iball.png (620.46 KiB) Viewed 5788 times