(*) : More technical details: C64 and C128 have memory that can be accessed directly (unbanked), and memory that requires some extra steps to access (banked). This new feature means Ozmoo, throughout a playing session, looks for virtual memory blocks in unbanked RAM that arenât used a lot, blocks in banked RAM that are, and let them trade places. 10-20 moves into the game, parser, main game loop etc should all be in unbanked RAM. For modern games, and complex games, this can make a big difference in performance.
Iâm having issues with the image loader, it shows the image and the flickering, but it never seems to finish loading. Pressing keys do nothing, except ESC which clears the screen but then nothing happens.
Due to reasons, the C64 disk drive is one of the slowest disk drives of the 80s. Program load typically happens at about 400 bytes/s. Your program is probably around 40 KB, so it can be expected to take around 100 seconds to load.
C64 users who werenât fans of long loading times would typically use a fastload cartridge, which would increase loading speed to something like 4000-6000 bytes/s.
When using VICE, there are other options as well:
Use the command line flag -autostart-warp instead of --autostart-delay-random
Enable warp speed manually during loading (On my version of VICE for Windows, I press Alt-W to enable/disable warp speed)
Enter the config menu for drive 8 in Vice (Preferences => Settings => Peripheral Devices => Drive => Drive 8 ), disable True Drive Emulation and enable Virtual Device. Save settings. This speeds up all disk operations a lot, so loading parts of the game during play gets much faster too.
ESC key is mapped to the run/stop key. This is normally a way to abort a program load, which is what happens here. I have now disabled the key in the loader.
The help text is wrong. We changed the way colours are specified, and missed updating this. It should be âbgâ instead of â0â, and âfgâ instead of 1. I have updated Ozmoo.
I wonât make a new release of Ozmoo just yet, but you can get the latest source from Github. The version is now set to 15.6.
Actually I was about to mention restart not working, but it is just the same issue: it simply takes a loooooong time to reload the story file.
BTW, I am going to experiment with using sprites to draw the status-line background, as I would like a certain color combination that isnât normally possible
Ha! i filed a âbugâ for the exact same thing 2 weeks ago (the restart seemed to hang and crash). frederik enlightened me as above and i turned on the fake disk drive noise in VICE so now i know that itâs not a crash but the emulated 1541 still flailing away.
Due to reasons, the C64 disk drive is one of the slowest disk drives of the 80s. Program load typically happens at about 400 bytes/s. Your program is probably around 40 KB, so it can be expected to take around 100 seconds to load.
C64 users who werenât fans of long loading times would typically use a fastload cartridge, which would increase loading speed to something like 4000-6000 bytes/s.
Something that would be an absolutely wonderful improvement to some future version of Ozmoo would be to first patch the bug in the C64âs data transfer routines that a fastload cartridge patches, then continue loading, using the faster transfer speed for all future disk access. A lot of later games back in the day, and new games now, did this by default.
For the initial loading, any fastload cartridge will work fine, as will a disk turbo program if you donât have a cart.
There is no bug in the C64âs data transfer routines. At one point, a chip that should have handled data transfers turned out to be faulty, there was no time to fix the chip, so a much slower solution was implemented in software. Itâs painfully slow, but it works reliably.
Since the disk drive is in fact a computer in its own right, itâs possible to run programs on it. This is what fast loaders do - install a program on the drive that transfers data faster, possibly also speeding up the rotation of the disk, and they run a program on the computer side that can receive the data at this rate.
100% of those fastloaders can speed up file loads. Maybe 20% of them can speed up file saves. Maybe 1% of them can speed up raw block reads. What Ozmoo needs, if anything, is a fastloader that can speed up raw block reads. We havenât found code that does this. We donât know how to write it. We havenât found anyone who knows how to write it. No one has suggested they could write it, or made a pull/merge request that would add this.
Itâs possible that we could copy code from Infocomâs interpreters (havenât checked), but one absolutely vital point of Ozmoo is that it contains no code of legally questionable origin, so weâre not going to copy code from Infocomâs interpreters.
The best solution is currently JiffyDOS. This requires changing or adding a ROM chip in the C64, and one in the drive. If you have SD2IEC, it has all the drive needs built-in, but you still have to modify your C64. Ozmoo works well with JiffyDOS, as does most software.
Tip: To get Z-code games to work and look just like if Infocom had released them on C64, you can use d64toinf.zip at Index: if-archive/infocom/tools (may require DOSBox to run?).
A feature request: support hires mode (â.hirâ files) for the image loader. I hacked this in myself for my own game, but it would be nice to have it generally available.
The format is very similar to Koala paint, it just lacks the 1000 bytes for the color memory and the extra byte at the end for the border color.
With a bit of hacking of the build script, I made my game show the title image while it is being decrunched. The downside is that I lost 9K for virtual memory (should be fixable, but a bit more work than I wanted to do right now).
Yes, thatâs easily fixable, but it means more disk access is required to populate virtual memory during gameplay. That doesnât seem like a good deal for the player.
That zip should be unpacked over a fresh copy of Ozmoo 15.5 code. The main new files are âasm/fast-core.asmâ which has the C64 side of things, and âasm/fast-limbo.asmâ which has the code loaded to the 1541 drive.
The document âfast_protocol.mdâ describes the protocol used to communicate between the C64 and the drive (all the gory details). I designed it to be as robust as possible, e.g. the C64 can leave interrupts enabled.
Raw receiving speed (from drive to C64) is around 2500 bytes per second (about 6x the normal rate). But the improvement to performance is only around 2x the normal speed (testing with -p:0 build option).
I have only tested this code in VICE, not on real hardware. I played my own game last night to completion, and tested a bit of adventure_punyform today, with no issues, but I have seen it muck up (unfortunately not in a reproducable way). I am thinking how to stress test the codeâŚ
The âmake.rbâ script just forces the fast loader on, adding proper options for it is left as an exercise for the reader
