Maybe they wanted to avoid crowding the I/O port range which is quite limited (256 entries) in view of future MSX generations and extensions.
But with hindsight, dedicating 4 ports for the sub-slots selection would have greatly simplified the work of the programmers.
The $FFFF address is not RAM, it's a port. Like $A8, $98 and so on...
OK, I understand now.
So it's like the SID and VIC-II register addresses of the C64, that you address directly like they are in RAM.
Very strange choice, since every other MSX port is ... well, a port.
Well it's not completely unique, also chips like SCC or OPM use memory mapped I/O. But indeed, strange choice to not use a regular port for this.
With some selection logic they could even have done it with a single port.
Well it's not completely unique, also chips like SCC or OPM use memory mapped I/O. But indeed, strange choice to not use a regular port for this.
Yes, it's not new and not unique at all. Z80 have two buses. I/O port was made for peripherals and memory port for RAM/ROM but in fact nothing prevents connecting peripherals instead of RAM/ROM on the memory port. This has been done since the MSX exists (Mappers, FDD controllers, expansion sounds, etc). It's not a strange choice except for the secondary slots. As Aoineko says, it would have greatly simplified the programming.
Maybe they wanted to avoid crowding the I/O port range which is quite limited (256 entries) in view of future MSX generations and extensions.
But with hindsight, dedicating 4 ports for the sub-slots selection would have greatly simplified the work of the programmers.
Well... I would say MSX slot selection has caused most of the compatibility issues over the years and it is commonly misunderstood, so indeed it is easy to say now that they should have chosen different approach that would have been more user friendly... How ever I think they had very good reasons to do what they did:
First of all when the design was made, this was "for the future"... First generation MSX machines very rarely implemented this subslot selection mechanics in any part of the hardware, only in BIOS. It may sound weird that they used memory address or that the read value is inverted, but they serve a purpose.
If the select register would be in "global" I/O range then we would run in to same issues as we do with multiple memory mappers (I/O registers should not be read back in order to avoid bus conflict) The other problem is that it would be impossible to detect reliably if certain main slot has subslots implemented or not. For sure I/O ports could be made "local" (= main slot specific) as well, but then we would need to come up with page selection mechanism, that is automatically there in two most important bits when talking about memory addresses. Other option would be that the cartridge in main slot would be somehow aware of the slot it is inserted to, but all of the solutions I can think of start to add complexity to the design.
I would have definitely appreciated "global" subslots over "local", but I think this was best "free of charge" solution that they could come up without need to start adding HW costs to manufacturers. It sure made programmers life a tad difficult and slowed down slot selection, but I think it was acceptable trait considering the available options. It might be that if they would have not come up with this, the whole idea of subslots might have been thrown out of the window on "added costs vs. minor benefits" design wars.
On many other CPUs like the 6502 there are no I/O ports at all, so MMIO (memory mapped I/O) is basically the only way to wire hardware to the CPU, which explains why 6502-based systems like VIC-20, C64 and Famicom/NES does it like that. Although the C64 supposedly uses the custom 6510 variant of the 6502, which does have 6 I/O pins, that should be enough for 64 I/O entries.
it is easy to say now that they should have chosen different approach that would have been more user friendly...
I heard this reproach since the beginning of the 90s so it does not date from today.
If the select register would be in "global" I/O range then we would run in to same issues as we do with multiple memory mappers (I/O registers should not be read back in order to avoid bus conflict)
No why do you say that? Using eight I/O ports. There can be no such problem. And by doing that, they could have even used the FFFFh address for the memory mappers, and thus removed the problem with multiple memory mappers.
Slots are entities related to Memory addressing, not with I/O addressing. That's the reason why the mechanism to detect an expanded slot was implemented at a given memory location, $FFFF which is "mirrored" between the sub-slots of the same slot.
While slots and subslot addressing are context dependant, I/O addressing is global, That's the reason why slot selection is performed through I/O rather then by memory.
If the select register would be in "global" I/O range then we would run in to same issues as we do with multiple memory mappers (I/O registers should not be read back in order to avoid bus conflict)
No why do you say that? Using eight I/O ports. There can be no such problem.
I don't quite follow your idea, but what I'm trying to say is that the slot expander does not know to what slot select signal it is connected to and therefore it can't assign it self unique I/O port. There are naturally ways around it, but all of them make the design more complex.
... Personally I think good solution would have been to agree that all writes to $FFFF are global and all reads are local so that all sub slot registers would just update to same value at a same time. I think this little change would have been already enough to solve the complexity problem.