Boot strapping into modex

OK, so we had a productive weekend, I pulled in all our random libraries that I have written over the years and got a title screen up.

The mouse code was not as bad as I thought and we have rudimentary mouse support there with software drawn cursor.

One thing I did fix was, since we are running a 100 hz timer (100 ticks per second), and we take over IRQ 8 (the clock), DOS does not update the time (we are not calling the original IRQ. We want the least code running in the clock tick as possible, which means absolutely we are NOT going to call whatever else is chained to the clock interrupt). We do have a total number of ticks since the game started, so we can take those ticks, convert them to seconds and add that to the current wall clock when we exit the game, and voila, correct clock time when the game exits (nice)!

So were running a ModeX of 360x240. This gives us 3 pages on a 256kb adapter, page 0 and 1 for double buffering and page 2 for tile maps (or that is the plan).

ModeX is a blessing and a curse. One of the downsides is you can only do byte sized transfers (no move double word (four bytes at a time) or move word (two bytes at a time) because of the latches, whereas in ModeY (chunky pixel mode) you can do multi byte width moves. There is always a trade off.

Right now the software mouse icons are in base ram and ideally I need to get them out into the page 2 vram so I can just do vram to vram copies, and make the mouse back buffer to be and even size of modulo 4 + 4 then I can just latch and copy 3 extra pixels from any mouse modulo 4 position and not worry about spending clocks on IO port access.

Which would mean say, for 24 x 24 tiles, we could have a max of 150 tiles, so taking a row for mouse icons, no map could use more than 135 tiles.

Perhaps we don't double buffer and have page 1 for all sprites… That makes a bit more sense maybe... time to do some testing and trial and error.

I also chucked it onto my real hardware (99% of the time I just use DOSBox-X for testing), and ran into some sound bugs in my Gus PNP and AWE32 drivers which I spent a few hours fixing. (Yay old bugs from 30 years ago!.)