Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Project: HDMI/DVI out for STFM

Post by exxos »

Smonson wrote: Sun Nov 05, 2017 12:26 pm 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.

Smonson wrote: Sun Nov 05, 2017 12:26 pm I think the glue only has access to D0 and D1.
ah yes, you are right.
Smonson wrote: Sun Nov 05, 2017 12:26 pm 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

exxos wrote: Sun Nov 05, 2017 12:42 pm 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).
exxos wrote: Sun Nov 05, 2017 12:42 pm 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.
User avatar
IngoQ
Site Admin
Site Admin
Posts: 1066
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Project: HDMI/DVI out for STFM

Post by IngoQ »

Smonson wrote: Mon Nov 06, 2017 1:54 am 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.
Ingo :geek:

| Atari 1040STE@32MHz | Amiga 1200 (ACA1220) | Atari 800XL (U1MB, SIDE2) | Atari 130XL (Sophia DVI) | C64 (1541 Ultimate II, Rev3 RFMod Replacement) | TI 99/4A (F18A, 32k, FlashROM 99) | Sinclair ZX Spectrum 128 (Stereo, DivMMC) | Amstrad CPC664 (512k, M4 Wifi) | ... |
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

IngoQ wrote: Mon Nov 06, 2017 9:07 am 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
20171106_213729.jpg (162.46 KiB) Viewed 4565 times
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Mon Nov 06, 2017 1:54 am 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.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Mon Nov 06, 2017 11:51 am
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) :)
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

How it fits:
20171107_210215.jpg
20171107_210215.jpg (231.63 KiB) Viewed 4565 times
20171107_210513.jpg
20171107_210513.jpg (172.6 KiB) Viewed 4565 times
I may have said a small apology to the gods when I started cutting.
guus.assmann
Posts: 94
Joined: Sat Sep 23, 2017 8:52 pm
Location: Ede Netherlands

Project: HDMI/DVI out for STFM

Post by 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
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

guus.assmann wrote: Tue Nov 07, 2017 11:15 am 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.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

Update: colour
iball.png
iball.png (620.46 KiB) Viewed 4565 times
Post Reply

Return to “FPGA DEVELOPMENT”