prozacchiwawa

the style of the Mibo.Raylib examples is to use Capitalized properties on structs and javascript style camel case, but the ocaml style i learned is snake case.

i'm not sure which way to steer my brain

i also aside loaded up my old gcc ppc pecoff wrapper, cause i haven't looked at it in ages. last i left it, it was compiling some typical C but the compiler side support for setjmp and longjmp wasn't working and i switched away from it. maybe now having the one big thing i was focused on put away i can make another go at it.

man i haven't written f# in ages.

my work is all in rust and i've been very focused on gxemul for the past couple years.

it's fun to forget about ownership and memory for a while and focus on just making something neat (even if it uses raylib, which needs one to remember that memory and ownership exist to a degree).

@gloriouscow for some reason yellow was always on sale even if I needed to refill black

by making the test branch and isolating the broken stuff, i also figured out a fix.

windows actually runs in the aix branch.

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.

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.

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.

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.