Possible MSX2+ upgrade option
Wierzbowsky opened this issue · comments
As you offer v9958 installation, it could be good to offer an upgrade option to MSX2+. This will require port F4 and FM-PAC mono functionality. The FM-FAC SRAM option could be skipped. And you need a new BIOS and SubROM from a known MSX2+.
OPLL YM2413 is not a standard equipment of MSX2+ machines, although many (most) did have it.
As I wrote in #4, I'll consider adding it for the future versions
F4 port - at this stage would require major changes: An additional SPLD pin chip select, R/W decode, D flip-flop to store the value and a three-state buffer to read it back. Again, that goes on the wish list for the next revision.
I have an idea how to enable 0xF4 port without major changes. I can use printer port bit D7 to store the value, and use one of currently unused 74*125 3-state buffers to read it back.
In this case I'll program the SPLD so that it will generate /PRT_DAT_WR on both printer port 0x91 and 0xF4 writes. And to generate /PRT_BSY_RD on both printer status port 0x90 and 0xF4 reads.
The implications are: printer port values will be changed when 0xF4 port is written. It shouldn't affect the printer, but might affect Covox, and other devices that use printer port without using /STROBE to qualify the output. Also, when reading printer status back, it will return printer port bit D7. But that shouldn't really matter, because in any case only bit D1 is defined when reading port 0x90.
Do you know at what condition (and when exactly 0xF4) is being written?
https://www.msx.org/forum/msx-talk/hardware/fooling-f4-register
Well, that's what I did (even before reading that post). It is interesting though if the MSX2+ BIOS boot gets stuck because of the lack of F4 register or something else (e.g. looking for memory mapper in Slot 3-0). I guess, it is a time for little disassembly exercise 😸
Well, that's what I did (even before reading that post). It is interesting though if the MSX2+ BIOS boot gets stuck because of the lack of F4 register or something else (e.g. looking for memory mapper in Slot 3-0). I guess, it is a time for little disassembly exercise 😸
It's probably stuck looking for the subROM on the subslot 3-1. By default, you need to place the subROM on that specific slot on the MSX2+, or modify the BIOS if you placed it on another slot.
Do you know at what condition (and when exactly 0xF4) is being written?
It's rarely written, if ever.
But you have to make sure that the bit-7 of the printer port will be reset by a hardware reset.
Placing the expanded RAM on the subslot 3-1 is quite easy on the omega, I was modifying to 3-0 just for fun and its easy to test if 3-1 helps, just changing one of the .jed files.
I would do it, if you want.
It's not the RAM that goes on subslot 3-1, but the subROM+optROM. :)
The default MSX2+ slot mapping goes like this:
- mainROM: slot 0-0
- mainRAM: slot 3-0
- subROM: slot 3-1, 0000h~3FFFh
- optROM with bootlogo: slot 3-1, 4000h~BFFFh
The bootlogo can be combined with some other ROM on the same slot. Usually it's the KanjiDriver, but it can be the MSX-Music BIOS or even just the standalone bootlogo code.
Do we still have this issue? As far as I know Omega boots nicely with MSX2+ BIOS. The bug was (and it was fixed a while ago) that only addresses 0x0000-0x3FFF of the subROM were mapped to the CPU (at it is done on MSX2). Current SPLD configuration maps the entire 0x0000-0xFFFF range.
Suggestion: If you replace U27 with a 74HCT573, the bit D6 can be used to implement the MSX2+ I/O port F4h without the issue of conflicting with the parallel port, and will also allow the parallel port assembly to be suppressed (or optional) in the future.
The BIOS will only have to be patched to mask out the other bits when reading.
The remaining unused data bits can have their output side connected to a pin header and be used to activate other things on the future, like a turbo and even to implement some of the higher bits of the I/O port F5h.
Do we still have this issue? As far as I know Omega boots nicely with MSX2+ BIOS.
Humm. I wasn't aware of that. I was fooled by the fact that the project description still states that "This project is an open source implementation of an MSX2 compatible computer" and the fact that this feature request is still open. 😅
Well, this feature request talks about 0xF4 register and FM-PAC, neither of which are implemented in Omega... Although technically the MSX2+ BIOS works without 0xF4 register, and MSX-MUSIC is not a required MSX2+ feature ;-)
And so I left it open so that we can consider adding these features in the next major revision.