ST wakestate enforcer

[troed]

Quite some time ago, the master of the ST hardware, @ijor, mentioned that by poking at the GLUE testpin it would be possible to change wakestate on an ST while booting up. I implemented this as a "wakestate nudger" since my need was to be able to quickly get into the four different wakestates when testing new tricks: https://blog.troed.se/projects/atari-st ... te-nudger/

However, it could be interesting for the demo scene to make a different use of this. Instead of being able to easily jump between wakestates, the ability to _lock_ a machine to a specific one. This is a bit similar to what's known as "VSP safe" compo machines in the C64 scenes, where there are hardware differences that mean some computers will crash when a demo uses the VSP scrolling trick.

On the ST, wakestate 2 differs four cycles* from the other wakestates which means there's plenty of fullscreen/sync scroll demos out there that have issues in that wakestate. More an issue with ancient code than modern to be fair, since the left border opening in WS2 and on STE happened to be the same.

In wakestate 3 (some of the time) and wakestate 1 the "4 pixel Shifter scroll", both LJBK's version and mine, fails and cannot be used fully.

I'm thus speculating that having compo machines locked to WS4 might be the most compatible for the ST demoscene, also allowing demo coders full use of the Shifter scroll trick.

@ijor - I'm picturing a shim circuit inbetween the GLUE socket and the GLUE. How advanced to you think it'll need to be to synchronize the GLUE with the 8MHz clock and the three cycle delay needed for WS4?

/Troed

*) Well, not really, but the effect is that left border openings need to be performed 4 cycles earlier as seen from the CPU ...

[ijor]

However, it could be interesting for the demo scene to make a different use of this. Instead of being able to easily jump between wakestates, the ability to _lock_ a machine to a specific one. This is a bit similar to what's known as "VSP safe" compo machines in the C64 scenes, where there are hardware differences that mean some computers will crash when a demo uses the VSP scrolling trick.
...
I'm thus speculating that having compo machines locked to WS4 might be the most compatible for the ST demoscene, also allowing demo coders full use of the Shifter scroll trick.

@ijor - I'm picturing a shim circuit inbetween the GLUE socket and the GLUE. How advanced to you think it'll need to be to synchronize the GLUE with the 8MHz clock and the three cycle delay needed for WS4?

It is, of course, possible, but not sure it's as simple as you might think, especially if you want something that would use only the signals available at GLUE.

Controlling the TEST (and possibly, also RESET) signal to change GLUE timing is almost trivial. But to actually configure a specific wakesate you need to measure the current one, in the first place. The wakestate is a relation between GLUE and MMU internal timings, You can't force a specific wakestate just on GLUE, without considering MMU current timing. And you can't measure the current wakestate during RESET, at least not without bringing some other signals to the circuit. Otherwise, to detect the current wakestate you'll need to wait until a RAM (or SHIFTER) transaction.

Either way, while it wouldn't be terribly complicated, it might be too much to implement this just with discrete logic. It might require a small CPLD, or perhaps at least a GAL chip.

In wakestate 3 (some of the time) and wakestate 4 the "4 pixel Shifter scroll", both LJBK's version and mine, fails and cannot be used fully.
I'm thus speculating that having compo machines locked to WS4 might be the most compatible for the ST demoscene, also allowing demo coders full use of the Shifter scroll trick.

There is a typo there? You want a fixed WS4 that doesn't work with the Shifter scroller?

Not that it matters too much for this purpose. It wouldn't change too much to use a different wakestate. As a matter of fact, it's perfectly possible to make this user adjustable with jumpers.