Thanks! So, if we upgrade the machine to 512kB internal RAM, the issue will disappear? Or using a bigger external memory mapper as workaround to run software which needs more RAM.
Thanks for your help ro, was nice to see you again after such a long time.
The only thing we have to figure out now is what is actually defined in the standard (if anything is defined) about behaviour when selecting a segment higher than the highest RAM segment. That many machines will loop over to 0 does not mean that it is the only CORRECT behavior. What the A1F does may also be CORRECT behavior (but it may also be INCORRECT, I don’t know). My guess is that there is no expected behavior defined and as such software should not expect anything (and thus do more testing (like that basic listing does) so all possible results are covered.
Either way the best is of course to document this behavior in A1F, identify possible other machines (National machines, Canon V-30F) where similar things happen, and update any mapper detection routines where possible.
Doesn't the NMS 8220 use the same mechanic? A 128k mapper, only 64k used. Again leaving segments unconnected. This may indeed be correct behaviour.
Just to close this case (on my side), Retrofan checked my new memory mapper segment counter and it passed. here's the code. (it's assuming RAM in the slot, and also assuming MSX2 with memmap, this is just the core memmap counter)
org #c000 ;Count memory maps 2022v2. ;This complete routine + data should be in page 3, map 0 ;Out: A, total RAM maps found (0=256) MAPPRT: EQU #FC .CMADR: DB 0 CNTMAP: IN A,(MAPPRT+2) ; save current FE PUSH AF LD HL,.CMADR-#4000 ;seg x LD DE,.CMADR ;seg 0 LD C,1 ;start seg CALL CMAP.0 POP AF OUT (MAPPRT+2),A LD A,C RET CMAP.0: LD A,C OUT (MAPPRT+2),A LD A,(HL) LD (DE),A LD B,A ;backup CPL LD (HL),A CP (HL) ;is RAM? RET NZ LD A,(DE) CP B ;seg 0? LD (HL),B ;restore RET NZ INC C JR CMAP.0
So, back to the fsa1f machine.
This one has 128K, segment 0-7. But, when selecting segment 8 (which should be segment 0 again), it instead puts some ROM on the slots. Not expected behavior, for a memory mapper slot combo.
After some more checking, here's what I found on this 128K machine, setting memory mapper values:
0-7: RAM (mapper segments 0-7)
8-31: ROM
32-40: RAM (mapper segments 0-7)
41-63: ROM
etc
Amazing !!!
Funny detail, on a turbo R in DRAM mode this will work too since the last four mappers are set in "ROM" mode then.
On turbo R, it is the segments reserved by the system that can be write-protected, is not.
Nice find, guys! I knew there was something wrong with that machine. But there's no datasheet for the NEC's ULA, so there's no way to configure it to get rid of the problem...
Nice find, guys! I knew there was something wrong with that machine. But there's no datasheet for the NEC's ULA, so there's no way to configure it to get rid of the problem...
And if we upgrade the machine to 512kB internal RAM, will then the issue disappear you think? (as the software then indeed will get 512kB as reported when using the normal memory check routines without checking for ROM)
It's not clear how the machine will behave with 512kb of RAM. There's no way to know how the ULA is configured. Besides, how can we connect SRAM without additional logic chips? Let the machine be. Doesn't make sense to fix the mess made in the 90s just because TESTMAP doesn't work.
Yes, using an external memory mapper is indeed the easiest way right now. Anyway, this was an interesting issue.
I do wonder now what changes in the machine when DOS2 kernel is loaded. Is there still ROM in those segments? How could we check ro?