At last, there is an .aastory large enough to be rejected by the current c64 build conversion process! Is that the last word on the subject?
I may be looking in the wrong place but the Dialog docs as they stand are silent on the question of whether or not inline graphics (like that map) should be supported on c64:
Interpreters are supposed to restrict this vast space of possibilities to a manageable set of supported file formats. The current version of the Å-machine web interpreter, for instance, only embeds graphics in png or jpeg format. Other backends (Z-machine, debugger) just print the alt-text.
“Other backends” notably omitting the one other target…
Early in the project I hoped to be able to include a C64 version of TIB in the comp. But the game grew until it wouldn’t fit on a standard floppy disk anymore, and I didn’t have time to add disk-swapping functionality to the C64 interpreter.
Now, after the comp, I might find the time. The first step to get the game running on a C64 would be to add support for multi-disk games, and make sure that everything works. But it would be annoying to have to swap disks all the time, so the next step would be to rearrange the data so all the frequently-used bits are on one disk. I believe this is within reach for TIB if I can only generate slightly tighter bytecode, and I already have some ideas for how to do that.
Meanwhile, I’m beginning to warm to the idea of supporting arbitrary DOS devices, which would allow other kinds of disk drives to be used—but they would potentially be much slower than the current fastloader. One stumbling block, however, is that the built-in kernal drivers tend to disable interrupts, which would interfere with the code for displaying the status bar.
I don’t rule out graphics for the C64 interpreter, but the pictures would have to be in a custom format. The
aastory file format is designed to support post-compilation editing of resource data, so it would be possible to make a tool for replacing or converting bundled images. But this is more of a long-term goal.
Beyond the basic “interpreter on side 1, game on side 2” and to the extent that I get a vote or an advisory voice or whatever, I would recommend/ask/push for “single larger volumes” over complex simultaneous .d64 spanning.
Ozmoo’s support for multiple simultaneous 1541 drives is nobly intended but on physical hardware is something I would basically never want to deal with. (The saving grace is that, yes, a contemporary Ultimate-class device offers two full 1541 emulations. Other than that, ugh.)
I would consider all of these superior to multiple spanned volumes:
- d71/d81 support with required true drive emulation
- d81/DNP support without TDE (the slower but sd2iec-friendly solution)
- Spans .d64s but with mandatory load-to-REU
- Easyflash-compatible .crt
My target machine for C64 images is a stock breadbin with a single 1541 (and no REU), and it matters a lot to me to be able to write the resulting images to a physical floppy, to support retrogaming friends. But being able to write to a .d81 and take advantage of a REU would be attractive, for convenience on devices such as the The C64 (of which I have one on my desk as I’m typing this).
I’d eventually love to be able to do 80-column mode from .d71s on the C128 (of which I have one in the next room), but that’s a bigger ask. (Starting with C128 Å-machine support.)
You seem to know your way around what Dialog is doing, but just to clarify: REU support is already baked in (and recommended since it enables UNDO) so I would be shocked if anything changed on that front if-and-when more hardware is supported.