Cartridge vs Disk - Loading

Supporter (16)

25-08-2021, 19:24

I'm developing a game in C (using Fusion-C) and trying to make sure that I understand how the MSX handles running a program from a disk versus from a cartridge ROM. This may be an obvious question but my experience with programming is a bit more high-level than C and I'm finding myself having to go back and re-learn some concepts, so I ask for your patience and understanding.

I know that when a program is loaded from a disk (or cassette, but I'm not using the cassette for this project), the program itself needs to be loaded into the system RAM before it can run-- the Z80's program counter can't address the disk or cassette directly. Does this also hold true for programs running on cartridge ROM, or can cartridge ROM be addressed by the program counter just like if it were system RAM but without consuming system RAM?

The reason I ask is because if the program doesn't need to be loaded into RAM when running from ROM, I believe that it frees up a considerable amount of memory for the program to use versus loading it from disk (which would be further undercut by MSX-DOS also needing to consume memory). This also leads me to wonder if most of the commercially-produced MSX software ran on cartridges for performance reasons rather than copyright protection.

I also have a question about loading a C program from disk in parts, but if running from cartridge frees up more memory, I would rather just use DSK2ROM and not have to worry about partitioning my game code.

Por geijoenr

Champion (305)

25-08-2021, 19:41

Running from ROM is the same as running from RAM from the CPU perspective. Plugging a ROM cartridge of 32k is equivalent to adding 32k of read only memory to the computer so yes, you save RAM.

But keep in mind that the CPU can only see 64K at a time, so you need to switch slots and pages to access the RAM. This is a basic topic you can find information about in the wiki.

Por CodeIndigo

Supporter (16)

25-08-2021, 21:15

Okay, I've reviewed some information in the wiki. Again, I'm not used to programming this close to the bare metal, so even though these are basic concepts, this isn't something I've run into before. Thank you for pointing me in that direction.

If I'm understanding this right, if I plug a 16k cartridge into slot 1 and that cartridge starts at page 1 (0x4000), that effectively means that the RAM I have available ranges from 0x0000-0x3FFF and 0x8000-0xFFFF (pages 0, 2, and 3), because my program "is loaded" from 0x4000-0x7FFF. The RAM in page 1 can't be accessed because that's where the cartridge is. Am I close? (I'm assuming that the RAM in page 1 actually CAN be accessed, but not at the same time as the program code in the cartridge ROM, so for a plain 16k cartridge there's no way to access it.)

Next, then, let's take a 64k cartridge mapped in 16k pages, also in slot 1, also starting at page 1 but taking up page 2 as well. My available RAM is 0x0000-0x3FFF and 0xC000-0xFFFF (pages 0 and 3). If page 1 stays static (always cartridge page 0), we can swap page 2 to point to the other three cartridge pages at will. We can also access the RAM at page 2, but only from the cartridge ROM in page 1.

Please let me know if I'm horrendously off-base here.

Por S0urceror

Master (202)

25-08-2021, 21:43

Yes your statements are correct. The ROM slots, subslots and RAM pages are all 16k large. You can change all segments that your current program is not in.

But page 3 is where the BIOS stores a lot of values above HIMEM. Only when you’re not using the bios you can swap that out. While possible this is not advisable because you have to go even more bare metal then.

So in general programs that want to use the bios are confined to page 1 and 2. But you can swap to other slots or memory segments when you have a mapper. A lot of cartridges carry more then 32kb of ROM and they map the segments in at runtime. For example main loops in page 1 and level data in page 2 which is swapped when you advance through the game.

Por MsxKun

Paragon (1083)

25-08-2021, 22:45

CodeIndigo wrote:

Okay, I've reviewed some information in the wiki. Again, I'm not used to programming this close to the bare metal

The closer the better

CodeIndigo wrote:

If you are using a 64k RAM computer yes. If you are using a 8k RAM computer, the bare minimum. You'll have only from 0xE0000 to above. And keep in mind that some of the high RAM addresses are in use by the system.

CodeIndigo wrote:

The RAM in page 1 can't be accessed because that's where the cartridge is. Am I close? (I'm assuming that the RAM in page 1 actually CAN be accessed, but not at the same time as the program code in the cartridge ROM, so for a plain 16k cartridge there's no way to access it.)

Yes, you can switch that page from ROM to RAM and the way back. You can read/write to that RAM using Interslot Calls too. It's not very handy, but can be done. Using page3 should be enough most of the times, but if you need a lot of RAM...

CodeIndigo wrote:

You're right if the cartridge has a mapper. If the ROM is 64k lineal, it's different, but ROMS with mappers are common. And that's how it's done most of the times (cause it's handy and easy). Also, some mappers use 8k pages instead a full 16k page. So you have twice the pages, and half the size on every one of them.

CodeIndigo wrote:

Please let me know if I'm horrendously off-base here.

Seems correct as base unless I'm more sleepy than I think