Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
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 »

keli wrote: Fri Nov 03, 2017 7:19 am
Smonson wrote: Fri Nov 03, 2017 6:12 am
  • Then TOS writes the appropriate video mode value directly into the shifter's video mode register without caching it in a RAM variable
The value is in fact cached in RAM at 0x00044C (sshiftmd system variable).
Smonson wrote: Fri Nov 03, 2017 6:12 am
  • Some interrupt handler or handlers reads the shifter's video mode register directly and writes video parameters into the GLU according to what it sees there
The GLUE shadows the low two bits of the video mode register automatically. The OS does not need to update these separately (a shame really, since having them at separate addresses could probably be useful to get exotic graphic modes.)
Hmm, in that case I guess only hardware issues on the Atari side could cause this behaviour. I'll prioritise re-installing the original shifter and the stripboard prototype to see if I can recreate the machine's original working behaviour.

Thanks for the info, Keli!
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 »

Small update... Restoring the real shifter into the socket reveals that under normal operation, there are only reads from the shifter registers, no writes. I can also reproduce that behaviour with my FPGA board by never attempting to drive the shifter bus - that also makes the frame rate steady.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Project: HDMI/DVI out for STFM

Post by rpineau »

No writes !!! .. but .. but .. the palette registers !!
or did you mean no read, only writes ?
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
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 »

I should have been more clear, sorry about that: there are probably a few writes at bootup, but from frame to frame, during normal operation there are only reads.
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 »

Which seems to suggest that the machine could be constantly rebooting.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Project: HDMI/DVI out for STFM

Post by rpineau »

Ok, makes more sense. Palette registers are probably written once early in the boot and unless you reboot nothing writes to them (unless you use some software than changes the color in the palette but this is not part of the boot :) ).
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
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 »

Interesting results here tonight. I can make the whole thing display perfectly stable monochrome video by assigning the bus driver to always drive in the direction 5v -> 3.3v, so the FPGA only receives data, and never writes to the bus.

I can also make perfectly stable video (of a blank screen) by holding the machine in RESET.

If I enable the bus driver and always return all zeroes to the bus for every address, the ST continues reading and writing to/from the shifter with unstable video frames generated. There are also no disk reads.

If I do the same as above but always return all ones to the bus for every address, the ST stops resetting, I get continuous reads from the shifter at 71.2Hz (there are probably a couple of writes at startup that aren't visible on the scope), and Hsync and Vsync look good on the scope, but the FPGA doesn't synchronise to it (which means frames are not exactly 112224 clock cycles in length). I can tell the machine is running code OK though, because I can see floppy disk reads proceeding as normal on the HxC LCD panel.

If I return all ones for every address except that I return 0x0002 for address 16 (video mode), then I get the unstable, crashing ST back.

If I return all zeroes for every address except that I return 0xffff for address 16, then I got the stable, running ST again.

Same as above but if I return binary 1111111111111110 for address 16. Stable machine, slightly weird video.

So the behaviour of the machine is highly dependent on what it reads from the 'unused' bits in the shifter's video mode register.

That's progress I suppose!
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 »

Actually, I coudn't walk away from this chair without some closure, so I implemented the verilog to respond back whatever is written into those registers. In this case, I actually see usable video frames. :yay:

Such a relief. I think it's safe to call the hardware part sufficiently tested. I need to do a new revision of the board to fix all my errata, and then I'll work on the software side.
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 11:16 am
So the behaviour of the machine is highly dependent on what it reads from the 'unused' bits in the shifter's video mode register.
Wow, sounds like a "undocumented feature".. No other bits should do anything according to the docs. But maybe if there is a shadow register in ram for the glue that the glue is going nuts for some reason.

Could you count the number of sync pulses per frame to see if that gives any clues ?
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 11:42 am
Smonson wrote: Sun Nov 05, 2017 11:16 am
So the behaviour of the machine is highly dependent on what it reads from the 'unused' bits in the shifter's video mode register.
Wow, sounds like a "undocumented feature".. No other bits should do anything according to the docs. But maybe if there is a shadow register in ram for the glue that the glue is going nuts for some reason.

Could you count the number of sync pulses per frame to see if that gives any clues ?
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.

I think the glue only has access to D0 and D1 - not sure if it's possible for any of those extra bits to affect the glue. 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?
Post Reply

Return to “FPGA DEVELOPMENT”