Fake JiffyDOS issues

maybe with Hydro's permission, Include basic 7.80. I would also take out all the tape routines from ram. maybe fix baud rates higher for modem?

Thinking about it, one thing I would definitely upgrade in my “dream ROMset” is the machine language monitor. I am firmly of the opinion that an MLM which can neither assemble nor disassemble code in memory is pretty useless.

I haven’t followed up on this thread the way I meant to. My apologies.

I definitely would include BASIC 7.80. Including that one is as much of a no-brainer as including JiffyDOS, I think.

Another idea I had is to actually test the VDC RAM size at boot and configure things appropriately. That would allow one ROM image to support both 16K and 64K VDC setups, so installing a 64K-VDC board such as the Chip Level Designs one or the currently produced clone of it would be more useful.

VDC8x2, I like the idea of ditching the tape nonsense, though I would feel differently if there were no option to switch back to a stock ROM (I think JiffyDOS had the right idea there). I also like the idea of improved RS232 speeds and reliability, and in fact a friend of mine who goes by the handle AgentFriday has come up with a way for a stock C64 to do 38-kilobit-per-second serial communications, in bursts while the VIC-II is not active. I’ve seen it in action and it is awesome. I believe he wrote a blog article about it some time ago, probably on commodoreserver.com if that helps anyone track it down.

Hydrophilic, wow, that’s quite a number of ideas! I think we can break them down into three categories: (1) selecting any or no boot device at boot time, (2) adding useful features and functions to the Kernal, and (3) adding useful features and functions to BASIC.

One at a time, then. (1) I think I’d make it so it does what it does now, unless you held down Shift (skip autoboot altogether) or Alt (bring up a boot menu listing the available devices, like what you get on a Mac if you hold Option during boot). At first I thought the idea to select the screen as a boot device was kind of nifty, but then I realized you’d need a full-blown machine language monitor with the ability to save your work before it would be any practical use. At that point it’d be just as simple to implement the idea I mentioned several posts ago for an improved MLM and have an option in the boot menu to enter it directly, presumably after you selected one of the boot-device options so you’d have something to work with.

(2) and (3) are good in theory and I can even see the exact requirements I’d want for the specific features you suggest, but it breaks compatibility in a fairly severe way (at least, the BASIC extensions would). I suppose we could piggyback on the JiffyDOS wedge and prefix all additional commands with one of the less-used funny characters, or maybe use a digraph (!!COMMAND or the like). The idea to allocate a device number to the REU seems like something Commodore should have done in the first place, and we even have the cassette device number we’ve just rendered unusable… of course, that also would introduce severe compatibility bugs. Maybe we could use device number 6 (it seems unlikely in these paperless times that anyone would have more than two printers hooked up at once, and unit address 7 is already in use by the network controller on the Flyer cloud storage device), or perhaps 30 instead (being all the way at the far end of the available range, there shouldn’t be many things already using it)?

Does anyone else have any widely applicable Kernal or BASIC extensions they’d want to see in their dream ROMset?

Buzbard, are there any differences between the 128 and 128D JiffyDOS ROMs that are actually needed for them to work in a given machine? If not, it’d likely be simplest to just base this project on the 128D JiffyDOS ROM and ignore the flat-128 one entirely.