Update.
(This will be quite brief as I haven't been taking notes as I've gone along).
Jeremy
(This will be quite brief as I haven't been taking notes as I've gone along).
- I decided to assume sideways RAM is generally available and rather than cut features out to fit into available main memory, just use as many sideways RAM banks as necessary.
- Introduced defined targets for the build process. Each machine configuration is a specific build target. For example, Model B - 7C00 is a target where HIMEM is assumed to be $7C00, limiting the game to running in MODE 7. Model B - 3000 is a target, also for the Model B, but assuming HIMEM is $3000, leaving space for MODE 0 etc. In the latter case main memory is much more limited so more sideways RAM banks are required.
- This entailed a significant reworking of the build process.
- Added code to the interpreter to allow Event and Status tables to exist in sideways RAM as well as the Conditions and Actions they referenced. This was necessary because for some targets, even Planet of Death requires sideways RAM. Compare and contrast the Dunshalt Donut on the Master 128 and Electron - 3000 builds to see the performance impact here (although some of this is Electron related).
- Added support for the Master RAM Board Electron option (actually trivial to do) although I have no means to test such a build myself.
- Moved the assembly, linking and disk imaging process from a bash script to the C# code simply because I find that easier to manage. Typically building for all 11 targets takes < 6 seconds, which seems fast enough.
- Prompted by comments elsewhere, I added code to report Actions which print a message then either move the player or describe the location without an intervening PAUSE, KEY or BEEP opcode to give the player time to read the temporary message. There were quite a few instances of this in the Dunshalt Donut and one or two elsewhere. These have had a delay of similar duration to delays elsewhere in the game added.
- Added code to automatically decide which object types need to be moved to sideways RAM based on available main memory, an approximate/assumed size for the interpreter (which can vary by target) and whether moving the object type will degrade performance. So, typically text goes first, then conditions and actions, leaving events and statuses to the end.
- Added a loader to each build. This incorporates a screen to map sideways RAM banks to the (up to) 4 logical slots the interpreter supports. Also includes a documentation viewer for information about the game and build.
- Moved the pre-game screens I added to each game to the documentation in the loader to avoid adding quite a lot of text to each game.
- As a result of this, the loader is built for each target/game as part of the game build process.
- Minor improvements and bug fixes in the interpreter.
Jeremy
Statistics: Posted by EdwardianDuck — Sat Apr 26, 2025 2:28 pm