hurminator wrote: ↑Sun May 19, 2024 3:19 pmThe only major thing I don’t like is the name d64… it should be d41. Anyway, too late to change that.
Honestly, for me, 41 is kind of non-sequitur since I could access 60 kilobytes of RAM in machine language, through tricks that are supported by .D64 images too.
Many games (including my SpaceZoom game) was actually bigger than 41KB.
It loaded to the RAM behind the BASIC, since poking to the ROM there will write to the RAM underneath the ROM. Once it SYS’d into the machine language, I could poke address 1 to turn off the ROM. The computer would not crash with the C64 BASIC ROM turned off, since my game didn’t relay on that ROM. So you could load a program all the way to the VIC-II address (53248 or $D000)
While you could only have 38911 bytes for BASIC, you could load software much larger than 41 kilobytes contiguous; they simply loaded into the RAM behind the BASIC ROM.
Generally, addresses ~2048 through ~53247 ($0800 thru $CFFF) is a contiguous RAM block if you turn off the BASIC ROM.
It was safe to load from the 1541 even with the BASIC ROM turned on, just that the RAM loaded was inaccessible until you SYS’d into machine language which then pokes address $0001 to turn off the BASIC ROM in order to use the already-ready-loaded-game-software RAM underneath the ROM.
In other words, writing to the ROM wrote to the RAM underneath it, when you did your LOAD “GIANT-VIDEO-GAME”,8 which could safely load from $0800 thru $CFFF (a whopping 52 kilobytes contiguous RAM). You just couldn’t access RAM at the flashing cursor prompt, only after you ran the game that called a SYS command (and that the game turned off the BASIC ROM).
My game was so big (even with RLE compression) that loading my game went beyond 38911 contiguous bytes, so the “41” is a non-sequitur to me…
I never understood the meaning of 41 when it came to Commodore 64s which truly did have almost 64KB of RAM, because you had two memories at the same addresses, meaning you had 16 bits of data (8 bits of ROM and 8 bits of RAM) at every memory location from address $A000-$BFFF (Basic ROM) and from $E000-$FFFF (Kernel ROM, but watch out for the last two bytes which are reset NMI address vector for RUNSTOP+RESTORE, IRRC).
How read/writes operated depended on what you POKE’d to address 1 (the assembly language version of a POKE is usually “STA” or one of its opcode variants)
Mind you, 41KB decimal kilobytes (41 * 1000) is more like 40KiB binary kilobytes (40 * 1024)
But we in practice had access to 60KB of RAM in machine language — the language of games.
Yes, if you do it at BASIC, turning off the ROM will crash your computer at the flashing cursor READY. prompt.
But it does not crash if you’re already running a machine language game that didn’t depend on either ROM.
Voila, 60 kilobytes of easy usable RAM. The last 4 kilobytes was a tricky matter (VIC-II, SID, etc)
So, essentially, any game — in machine language, I truly had nigh nearly 64 kilobytes of RAM to play with, not 41.
There are small exceptions (the impossible-to-access RAM underneath the VIC-II and SID I never bothered with. And I don’t know what tricks were invented to access the final remainder of RAM. In practice, it’s generally easy for a machine language / assembly app to access the 16K of RAM underneath ROM, and the 4K RAM window between $C000-$CFFF).
The address range above BASIC ROM was popular for third party machine language utilities, so if you’ve seen “SYS 49152” software, you should know that points to that convenient tiny window of memory above the BASIC ROM (which you could turn off) and before the VIC-II chip (which you couldn’t turn off). Once you do that, the 4KB memory window is usably contiguous to machine language all the way down to address $0002, throwing out everything that the ROM uses. You could even relocate the screen memory to the RAM running underneath kernel ROM (instead of the usual $0400 memory start for character buffer memory).
So theoretically you can have machine language contiguous from $0002 through $CFFF, but in practice we did not do that, most kept the screen buffer at $0400 and left contents of addresses $0000-$03FF untouched (except address 1 to temporarily turn off ROM).
So in practice beyond the first ~41K, a machine language app could easily access 20K more memory safely (as long as the ROM’s were re-enabled before going back to BASIC), so you had more than 60K of usable RAM for your 100% machine language / assembly language game. And since .D64 could safely contain software that loads to the RAM underneath ROM, you in practice could have files on a .D64 that could load to almost any address in the Commodore 64 memory — even to the RAM underneath the Kernel ROM (Although that’s much harder than software that loads at $0800 but keeps loading all the way to the VIC-II chip at address $CFFF — final contiguous RAM address 53247 — as the file on .D64 can successfully load into a contiguous 52 kilobytes ($0800 thru $CFFF), and it could load additional files that loaded into other parts (an additional 8 kilobytes), so .D64 images and .T64 images can load files into more than 60,000 address locations on a Commodore 64. It’s just that you could only do 38911 address locations with BASIC software instead of assembly-language games. Many large games used the RAM behind Kernel ROM as a work area, such as decompression buffers etc. So 52KB (well, KiB) contiguous + 8KB contiguous, for a total of 60KB (well, KiB) of easily accessible game RAM.
