Is rapid swapping of ROM pages OK or a problem?

Master (185)

06-01-2021, 23:04

In short, is there some risk or problem in swapping the ROM page mirrored(is this the correct word?) with ASC16 memory mapper to slot 2 maybe a dozen times in a short timespan (I guess within 3 screen refreshes' time)? I'd prefer knowing if there's a showstopper before I go deeper into adding memory mapper support to my game engine.

The situation in greater detail... I looked into updating my adventure game engine (the one I used in Jäästä) to allow the use of a memory mapper to facilitate larger games.

Currently, I store all references to locations, scripts and everything as 16-bit memory addresses in ROM. I thought that if the actual executable code fits in one page, that can stay loaded/usable/whatever-the-correct-term-is as long as the game is running, but page 2 would have to change to mirror whichever page I want to read data from.

Since I can tell what each read address is supposed to be (location, item, script, compressed string, ...), I thought I could use the two most significant bits in the "address" to tell which ROM page of that type this address refers to (say, 2nd page of graphics could be the 5th page in the ROM file, the 1st page with compressed strings the 3rd in the ROM file and so on). The actual memory address pointed to will have those bits set to 1 and 0 to point to the correct slot anyway.

However, this way when the player moved to a new location, the game would have to do roughly the following "page swaps" in quick succession:
- read the location record from one page
- read the graphics records from one page, return to location record page
- go through all item records (on one page) to find if they are at the new location; return to location record page.
- start interpreting the location entry script on one page, which usually displays the location description automatically (again, the string read from yet another page).
- return to the page of the script that caused the transition to the new location.

By Grauw

Ascended (9826)

07-01-2021, 00:52

A ROM or RAM mapper bank change is instant.

By thegeps

Paladin (792)

07-01-2021, 01:44

I agree with Grauw. You (or people running your game) may have some slowdown only if running the game from sofarun on a SD device, due to SD access (I noticed it, in my SD mapper a led is on when swapping bank/accessimg SD and sometimes software has a little slowdown)

By Daemos

Paragon (1948)

07-01-2021, 06:57

I swap rom and ram like the plague. About a 100 times per frame. Never has the msx crashed on me during testing. There are even instances where I need to switch to rom just to execute a few lines of code from there or fetch a piece of data to then trow in another block followed by a ram switch. Never went wrong. The only thing that happenee to me once but it could have been something else was switching twice to the same adress.

By Metalion

Paragon (1362)

07-01-2021, 10:03

I switch rom page 4 times per frame on VBLANK for my music replayer (once for the code, once for the data, and then back). Never had any problem.

By Uninteresting

Master (185)

07-01-2021, 12:10

Thanks -- I had no idea if I didn't know something I should know. Given how the game is definitely not an action game, a delay due to SD cards won't be an issue.

@Daemos What do you mean by switching twice to the same address? Do you mean mirroring same page simultaneously in two slots or swapping page X to slot 2 after page X was already there? The former shouldn't happen for me (outside of maybe initialisation steps), but the latter might if I need to allow scripts being stored on multiple pages and the scripts call one another on the same page (and if I haven't explicitly avoided this in the page-swapping routines).

By NYYRIKKI

Enlighted (5745)

07-01-2021, 12:17

Yes, the page swap is instant as Grauw said. If you change the page under execution next instruction (after the page swapping LD (xxxx),A instruction) will be read from new page.

How ever thegeps has a point here as well although constant loading should be much less likely on ASCII16 mappers as it is with ASCII8 mappers due to fact that MSX memory mapper has same page size. If you are planning to release your game as physical cartridge there is no problem. How ever if you are going to release the game as downloadable file then practically only options for user is to use PC, phone or similar that can see MSX as software standard trough emulation or then use some sort of nonstandard ASCII16 mapper emulation hack on real MSX hardware. (ASCII did not release any programmable mapper cartridges) This can be done either by hardware (practically build or buy non commercial Flash/SRAM memory cartridge) or by software (Software searches your LD (xxxx),A instructions and replaces them ie. with OUT (Fxh),A instructions or with call to custom routine)

If you plan to release it downloadable then I think for this type of game, it would be best if you could release disk version your self that uses standard memory mapper as then user would not need to rely to 3rd party hacks that just try to guess how to patch your code... At least please try the game first with 5 most popular loaders and try to write it so that they find your routines and patch them correctly. (Unfortunately this is not exact science, but more like trial and error) It is also not bad idea to publish a list of hardware & loader combinations that have been tested successfully to run your game without fatal problems.

By Uninteresting

Master (185)

07-01-2021, 13:57

Oof. This... sounds bad. I was thinking of making this my MSXdev'21 entry, so it'd be digital-only. This also sounds like I couldn't just add an opt-in for X "wait-for-screen-refresh" calls or a busy-wait loop that'll try reading a byte from the incoming page that would identify when the page load is complete (say, the first or the last byte in the page)?

I got only one MSX myself and even that's been broken for some years now, so testing this out myself isn't happening. Well, I have said I have more ideas to make into a game... so maybe I'll take one of those up first.

I was looking at ASCII16 because the wiki has an example of how to make a ROM file using that. It doesn't sound like other mappers would work any better?

By Daemos

Paragon (1948)

07-01-2021, 14:40

Quote:

When you instruct the mapper to switch to the same block twice or when you switch for example the ROM in page 1 twice to exactly the same ROM. Should be save and nothing happens but in my experience once or twice the system did not like that. Then on the other hand I do it the "wrong" way ($A8)

By Grauw

Ascended (9826)

07-01-2021, 18:14

Sorry NYYRIKKI, but I don’t see the problem why you would discourage the creation of a MegaROM? A mapper like ASCII16 or ASCII8 should work just fine, they are simple mappers. Of course you need either a physical cartridge release or a flash cartridge, that’s the concept of the ROM environment. But I would say nearly everybody of us has those, and they are affordable as well.

But ok, say you don’t have one and instead try loading + autopatching a ROM file into a memory mapper with SofaRun, indeed 16k bank size is better. But that’s not really the proper environment to run a ROM file in. So tbh, as far as I’m concerned, I would not be spending effort on trying to support that (unless the change is obvious and minimal). Also I would choose between ASCII16 and ASCII8 based on what’s convenient for my programming and my project (e.g. for tile² 16k is impractical).

By Grauw

Ascended (9826)

07-01-2021, 18:44

Uninteresting wrote:

This also sounds like I couldn't just add an opt-in for X "wait-for-screen-refresh" calls or a busy-wait loop that'll try reading a byte from the incoming page that would identify when the page load is complete (say, the first or the last byte in the page)?

I think you maybe misunderstand how a mapper works. No data is copied from one place to another and you don’t need to wait for anything to complete.

What happens is that say there is a 512K ROM connected to a 16K mapper, the top two bits of the 16 address line bits are replaced by 5 bits from the mapper registers, forming a new 19-bit address. So if you access address 4688H on the CPU side and the mapper register for the first page is set to 7, it will read from address 1C688H of the ROM. If you change the mapper register setting, it immediately affects all memory reads that follow.

So the mapper circuit sits between the CPU and the ROM and changes the address bits every time a byte is read by the CPU, truly “mapping” the CPU address to another memory address of the ROM.