last thing for the night:
pulled all cpu changes to support aix into a branch and testing that through the full windows install cycle. needed one fix (which actually improves gxemul dyntrans).
will try pulling that one change into the aix branch and see if windows works in there with that.
Replying to @prozacchiwawa@functional.cafe
there are hacks i should address better in the code to support aix, but they're mostly in device code. i think i want all the cpu changes.
Replying to @prozacchiwawa@functional.cafe
likely the biggest one is to decide whether to implement some kind of simulated pipeline timing for the s3. technically you could stuff a bunch of the same command in the queue and watch the queue level rise in the register, watching the ready for command bit turn off and then back on each time, but there's likely better middle ground that can be found.
Replying to @prozacchiwawa@functional.cafe
something that caught my attention recently regarding this is:
i now loop the machine object over a much smaller number of instructions (small enough that it should be good for implementing these quick moving effects).
one thing i could do is have a simple state machine in the s3 that can remember how many commands are in the pipe and whether the queue busy bit should be observed as being unset and run it when the user writes or reads 9ae8 one step for every n instructions or until it reaches a quiet state.
that'd allow the cpu to observe all possible state changes of the s3 pipeline (like if you were implementing some kind of detailed self test), have it respect macroscopic time passing (since you could observe more or less simulation time between reads affecting it) but not need the timer tick to become a lot more frequent.
Replying to @prozacchiwawa@functional.cafe
by making the test branch and isolating the broken stuff, i also figured out a fix.
windows actually runs in the aix branch.