exxos's Atari, Amiga & retro forum

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!

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.

No writes !!! .. but .. but .. the palette registers !!
or did you mean no read, only writes ?

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.

Which seems to suggest that the machine could be constantly rebooting.

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 ).

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!

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.

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.

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 ?

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?