Give this a look:
Ramones' ram detection routines
There's a long explanation in spanish and a link to the routines at the bottom. They work like a charm ;)
And then grauw midi action gave me a hint about fast interrupts.
Normaly ENASLT (especialy CALSLT) lowers the interrupt performance of the entire system. So enaslt must be interruptible. And shielded with mutex.
In Synthesix actually, I want both fast slot switching routines and short interrupt disable periods. I solve this by first preparing the values that need to be written, and then changing in a quick succession of in/out/ld instructions so I don’t need to keep interrupts disabled for long. Decoupling the preparation from the actual switching also allows programs to cache the prepared values to speed up slot operations. Also there’s a few other things; SetPreparedSlot returns the inverse values to allow one to quickly switch back. And of course ReadSlot and WriteSlot don’t need to update SLTTBL if they keep interrupts disabled during the switching.
See here for the code. Another nice thing is that the routines restore interrupts to their previous state, and don’t just leave them disabled.
Note that MIDI interrupts arrive every 320 µs, or every 1145 cycles on a 3.58MHz Z80. So keeping interrupts disabled for a hundred cycles or so is no problem, and di/ei is a very cheap operation to guarantee uninterrupted execution compared to other solutions.
The most common high-performance application that I can think of where ultra low latency interrupt response (iow code without DI) can be very useful would be line interrupts. A line takes 63.7 µs to display (228 cycles), so having interrupts disabled for even just a few dozen cycles can easily make the line interrupt effect unstable or misaligned.
In the Sony HB-10P.xml of openMSX you can read:
<primary slot="0"> <ROM id="MSX BIOS with BASIC ROM"> <rom> <filename>hb-10p_basic-bios1.rom</filename> <sha1>5e7c8eab238712d1e18b0219c0f4d4dae180420d</sha1> </rom> <mem base="0x0000" size="0x8000"/> </ROM> <!-- NOTE: page 3 actually mirrors page 3 of the RAM in slot 3! This also happens in older versions of the Sony HB-20P. --> <Mirror id="Main RAM mirror"> <mem base="0xc000" size="0x4000"/> <ps>3</ps> </Mirror> </primary>
So, this mirroring is implemented in the Sony HB-10P in openMSX. But openMSX emulates the newer HB-20P, which does not have the mirroring.
You can try to add this Mirror section at the slot 0 configuration to see if you get the same behaviour then.
Trick it to show a wrong value when reading register &HA8, until you really write on it, then it will show the correct value. But as default, what it will say is not true.
Hm, that doesn’t really make sense… RAM is paged in by the BIOS during the boot up sequence, so A8 has been written to already and it can’t be a problem with the initial boot-up value of the logic ic.
Yeh, i know it doesn't make sense. No idea what does BIOS to make it all go ok and then mess that value on the register. I really have no clue why it shows unproper value.
Page 3 mirroring machines, ouch, something new learned.
After all those years, MSX still can surprise you.
@MsxKun You said Uridium did work on your HB-20P right?
Could you try these Basic commands and see which one of them cause a crash?
OUT &HA8,48
OUT &HA8,112
OUT &HA8,176
OUT &HA8,240
If your machine is like Valkyr’s then numbers 2 and 3 will crash. If your machine does not have any mirrored RAM (like openMSX emulates), all but the fourth should crash.
Just would like to confirm whether all HB-20P models have this mirroring or just Valkyr’s. If any other HB-20P owners would like to try these I’d also like to see their results.
Ah, I see Manuel’s post now. So, if the same is said a separate source, and an older model has the same behaviour, it is more or less confirmed, then. No need to do any more tests.
In the Sony HB-10P.xml of openMSX you can read:
<primary slot="0"> <ROM id="MSX BIOS with BASIC ROM"> <rom> <filename>hb-10p_basic-bios1.rom</filename> <sha1>5e7c8eab238712d1e18b0219c0f4d4dae180420d</sha1> </rom> <mem base="0x0000" size="0x8000"/> </ROM> <!-- NOTE: page 3 actually mirrors page 3 of the RAM in slot 3! This also happens in older versions of the Sony HB-20P. --> <Mirror id="Main RAM mirror"> <mem base="0xc000" size="0x4000"/> <ps>3</ps> </Mirror> </primary>
So, this mirroring is implemented in the Sony HB-10P in openMSX. But openMSX emulates the newer HB-20P, which does not have the mirroring.
You can try to add this Mirror section at the slot 0 configuration to see if you get the same behaviour then.
So, ARTRAG, does the game run on the Sony HB-10P in openMSX?
@MsxKun @Valkyr Is there perhaps a model or serial number on the bottom or back of the HB-20P which can be used to identify whether it is a version which has the RAM mirroring?