Can someone confirm my assumptions on slots and interrupts?

Door Bengalack

Master (135)

afbeelding van Bengalack

08-04-2020, 09:35

I'm thinking of making a game or game engine for the MSX2 - and will need to have full control of both memory and the vdp-interrupt. Because of the "strict" game loop running at 60Hz (at least in parts of the game), I need to control every cycle that goes in here.

Currently running from DOS, and I use the disk to load levels throughout the game:

  1. I believe that the current slot and page 0, is ram, and that there has been placed hooks in the lover area, like 038h.
  2. To hook in our own interrupt routine, we can either hook directly to 038h and RETI to control it 100%, but if we put a hook in HTIMI, we will get allow the work of standard BIOS and misc I/O-periperals' code to be run.
    1. I assume that there might be other calls/interrupts to 38h, so to use this as a "clock", I need to check, every time, whether the interrupt was caused by the VDP.
    2. The HTIMI-hook: By using this I get things like disk slowing down after use (I need that), but I assume there can be many cycles going into stuff I don' have time for? Like keyboard-handling, keyboard-buffers that grows, and ... yes, how much can potentially happen here (coming from the system)? And how long can this potentially take?
  3. Memory: Currently I just run from dos, and seem to have almost 64k available for coding, but I likely need more, and I likely need to understand this better if I need to include code from others controlling sound and music. Pages and slot-handling comes into play.
    1. This seems a bit complex. Does there exist a simple way to enter this, like a C-lib that goes like the following?
           char getNumberOfTotalRAMPages
           char getNumberOfAvailableRAMPages
           some_smart_struct getOccupiedPages
           char allocateNextAvailablePages( numberOfSuccedingPagesInSameSlot )
           bool freePage( id )
          
    2. interslot call seems way more expensive than just a quick call. Do we have timings on this? Should we avoid at all costs during the strict game-loop?

Any help greatly appreciated Smile

Aangemeld of registreer om reacties te plaatsen

Van Manuel

Ascended (16692)

afbeelding van Manuel

08-04-2020, 11:03

I believe if you want an API for memory management like that, you would have to use something like MSX-DOS2 API or MemMan.

Van Bengalack

Master (135)

afbeelding van Bengalack

08-04-2020, 15:42

Thanks Manuel, I will have to look into those two then. I assume the MSX-DOS2 API requires the user to have bought and installed the MSX-DOS2, and I'm not sure if it is wise to have such a requirement for a simple game.

That said, what about my other assumptions, are they correct?

And what about the time penalty / overhead on interslot calls?

Van Grauw

Ascended (9156)

afbeelding van Grauw

08-04-2020, 19:09

1) Correct.

2.1) Correct.

2.2) It varies a bit depending on the model, but assume around 5300 cycles worst case. I posted some test results in this thread. You can shorten it by setting SCNCNT to 0 continuously and scanning the key matrices manually.

I recommend using H.TIMI initially, and only migrate to hook directly on 38H when you actually really need it, since it is the less compatible option (e.g. disk drives motors not stopping their spinning).

A good reason (IMO) to hook 38H is because you need a fast response to line interrupts. In one of my projects I hook 38H for fast line interrupt response, but defer back to the original ISR for other interrupts. That way I get the fast response but still limit compatibility issues.

3.1) If you need >64K RAM you require a memory mapper. I recommend you read the Memory Mapper wiki page.

Within a single memory mapper you can switch banks quickly without interslot calls. Often the largest mapper will be the primary by default, however on turboR the internal mapper is primary because it’s faster. The turboR ST internal mapper is 256K, so if you need between no more than 256K you can only use the primary mapper and do not need to do interslot calls. If you need more than 256K then you should support secondary mappers (=slot switching).

The mapper is easiest to use by using the extended BIOS mapper support routines. They are provided by DOS2 which is included with every modern SD interface that many people own, and also in the turboR, so it is quite widespread. In DOS1 you can use MU.COM to provide mapper support routines.

If you wish to use neither then you have to manually implement the mapper support. It is definitely more work to do this. Note that if you implement your own mapper routines, it will not work well for DOS2 users (running from SD card etc.). So you should preferably only use your own routines if the extended BIOS mapper support routines are not available.

3.2) I haven’t done an exact measurement but I vaguely recall an interslot call taking about 1½ scanlines. That would translate to somewhere in the ballpark of 342 cycles.

Van Bengalack

Master (135)

afbeelding van Bengalack

09-04-2020, 10:51

Awesome Grauw! You guys have been into most of these things already. So much knowledge in this place Smile

2.2 - Great discussion in that other thread! But 5300 is out of the question in a "tight" game. That's ~10% of the frame time in 60Hz. But I will go and scan keyboard directly anyways, so I might be able to live with some cycles "lost". That said, if only a spinning drive is the negative consequence, maybe we could just get a command to stop the drive? Would you guys know anything about that?

3.1 - Thanks, good pointers. I'll look into all of this and sort this out.

3.2 - Then it can be done during a frame, but must be kept to a minimum, zero, one or two times I reckon in my case.

Van Bengalack

Master (135)

afbeelding van Bengalack

14-05-2020, 16:27

Following up on my own, old thread Smile

2.2 - Found this: DSKSTP in the DISKROM I assume this can be used --if needed, not sure in my case.

3.1 - Ok, I'm starting to get the overview here now. Using MSX-DOS2's mapper support routines sounds nice. But, let's say I'm making an MSX2 rom-game, with memory requirements of more than 64k ram. If I don't want to require MSX-DOS2, I have to handle memory-mapping myself. If it's a rom-game, there is normally no "return to dos" (or basic). In this case, I assume there should be no need to cater for other programs needing memory? In this case, it would make sense to just handle the mapping on my own in a simple way? If I start/run my code from page 3, I can assume that page 0, 1, 2 and 3 is mapped up-front and it should be easy to scan all potentially available segments to see which other, or, how many, segments that are available. It sounds quite easy to just send a value to port #0xFC/FD/FE/FF... Am I missing something?

(and yes; developing a rom-game/application is currently all new territory too - I will need to research that too, not sure how segment or page-switching works there :) )

Van Bengalack

Master (135)

afbeelding van Bengalack

14-05-2020, 16:52

Had a look on the rom-pages. They have their own segment switching. And in that case, there is probably no need for ram-mapping? That takes me back to the scenario where things are disk-based. And then, I guess it makes sense to clean up after one-self when returning to dos1 or dos2... Smile

Van Grauw

Ascended (9156)

afbeelding van Grauw

14-05-2020, 17:48

Yeah in a ROM game you typically don’t need a lot of RAM memory, and therefore not a memory mapper.

I would (personally) not make DOS1 software that requires a memory mapper, in other words stick to the 64K. If more memory is needed, might as well just rely on DOS2. OS support for memory mappers prior to DOS2 is absent, and it’s just going to create extra work and compatibility worries if you don’t use the extended BIOS mapper support routines, so unless there is a compelling reason, requiring DOS2 is fine.

This is also why VGMPlay requires DOS2 and I’m not planning to make a DOS1 version; a lot of extra work for a limited audience (those guys can just buy an SD interface instead Smile).

Van Bengalack

Master (135)

afbeelding van Bengalack

15-05-2020, 15:53

Right. I've been thinking that I need to be able to run it on my SVI-738 upgraded to MSX2 though. Henrik Gilvad did that upgrade for me a long time ago. I had forgot, but I just found out that it also has a memory mapper of 256k Smile I probably forgot because I never used more than 64kb myself. It has FM-PAC too. Maybe even more goodies are added, I don't know. Some fun investigations are coming up Smile

I also have this SD-card/memory mapper. But once I use this, the one and only cart-slot is spent, so I need to be careful if I should ever go for game on cartridge + memory mapper need.

For DOS2: I always envisioned that one had to have this ASCII MSX-DOS2 cartridge to use DOS2 (legally) - But I assume the Nextor MSX2 works fine here. The Nextor-"deal" (with Kazuhiko Nishi) is truly fantastic!

Anyways. My options are much clearer now.