ST wakestate enforcer
Posted: 04 Aug 2024 15:31
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 ...
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 ...