Wow, a great article!
And then openMSX emulates these things.
Wow, a great article!
And then openMSX emulates these things.
Yes, at least to some degree...
OpenMSX disk emulation is still byte-based, augmented with locations of special-A1-markers. We don't (yet) emulate any of the MFM-encoding or PLL stuff.
And for the moment this is sufficient for all the known MSX disk copy protections. There can certainly be (theoretical) copy protections where this is insufficient, but we're not aware of any such protections that are used in practice (on MSX).
On this MAP page (and elsewhere) I found routine examples to get page's current slot that add the content of SLTTBL
to result slot-ID even if bit #7 of EXPTBL
is not set.
I guess this is an optimization to avoid having to add a branch in the code, but in the MSX Technical Data Book it is noted:
"SLTTBL - Indicates the value currently output to the expansion slot register. Valid only when corresponding EXPTBL holds 80H."
So 2 questions :
- Is the EXPTBL
value of a non-expanded slot always equal to 0? (despite what the MSX Technical Data Book seems to say)
- Is it OK to have an invalid value of sub-slot in a Slot-ID if bit #7 is not set (and so, slot not expended)?
- Is the EXPTBL
value of a non-expanded slot always equal to 0? (despite what the MSX Technical Data Book seems to say)
No, see BIOS source code. (I presume you meant to say SLTTBL
here.)
They are initialised, but their contents will be unpredictable based on the (uninitialised) contents of the memory address FFFFH in that slot.
- Is it OK to have an invalid value of sub-slot in a Slot-ID if bit #7 is not set (and so, slot not expended)?
Yes, see BIOS source code, although I object to the wording “invalid value” ;).
When bit 7 is not set then the secondary slot register is never written and the contents of bits 2-3 is irrelevant. 00 is equally meaningless as 01, 10 and 11 are. If you want bits 2-3 to be zero for some reason, e.g. for display purposes or peace of mind, you will need to clear them either afterwards or by modifying the GetSlot routine (insert a ret p
after the first or c
).
If a slot is not expanded, slot selection routines must never write to the secondary slot register anyway or else they will corrupt memory (and if the memory is a mapper, this can corrupt not just the top byte but real memory in use in another page). So it is guaranteed that slot selection routines discard the bits, not just by the way the BIOS is written but by the slot selection mechanism itself.
Thank you for the explanation.
I have read somewhere that slot-id's unused bits had to be reset but as you say, it was perhaps just a peace of mind advice. ^^
So, let's simplify MSXgl slot detection routine...
Grauw is right.
Only the bits of the extended slots are to be taken into account in the SLTTBL table. The others should be considered undefined.
Bits 3-5 of EXPTBL should be 0 and bits 2-3 considered undefined if the bit 7 is 0. Other bits are always used even for empty slots.
Regarding the SS bits in the return value of GetSlot for unexpanded slots, I added the early return so that they always remain zero. I thought I had changed this already but apparently had not submitted it yet .
Two reasons for this;
One, to avoid confusing the reader needlessly. For the careful reader it can be a bit unexpected and warrants extra explanation, which I also thought about adding, but elaborating on that detail is not the point of the source code example. The question can be avoided by simply not having the situation in the first place.
Two, setting these bits to zero for unexpanded slots normalizes the value, that is, if you compare two normalized slot IDs then the values will be equal when the slot is equal. Whereas if the value is not normalized, an identity comparison is more complicated.
I also more precisely documented the return value to contain zeroes in bits 4-6. Even though for slot IDs these bits are irrelevant, your own code can use them for some purposes, in which case it can be useful to know that they can be assumed to be zero.
p.s. The previous suggested change of just adding a ret p
was insufficient, since the routine should not modify hl
.