Panasonic FS-A1F and 128kb RAM upgrade

Guardian (3651)

15-04-2022, 18:22

I ran into a weird problem after upgrading the Panasonic A1F board to 128kb. TestRam and MemTest show no issues, but TestMap shows this error:

Did anyone else see this problem? Is there an additional jumper that needs to be set? I checked a few tutorials and, acording to them, no other modification other than installing 2 RAM chips and 2 capacitors are needed. The board is the same as in the Wii article:
https://www.msx.org/wiki/images/6/6f/Panasonic_FS-A1F_PCB.jpg

If DOS2 is started from Carnivore2, testing the internal mapper doesn't show any errors. This is really weird.

Any thoughts?

Por sdsnatcher73

Enlighted (4317)

16-04-2022, 07:16

Please note that the issue is actually not a result of the memory upgrade. The unmodified 64kB machine also has this issue! It’s still very interesting to figure out what is happening here…

Por sdsnatcher73

Enlighted (4317)

18-08-2022, 09:57

I wonder if this is a design mistake on the machines or the software using incorrectly the mapper. I have seen this issue now on:

- Canon V-30F
- National FS5000F2
- Panasonic FS-A1F
- Panasonic FS-A1FX
- Panasonic FS-A1ST

Biggest sample size is in FS-A1F and FS-A1FX but even there not all machines showed the problem. I only have 1 V-30F and 1 FS-5000F2. I have 2 FS-A1ST but have only tested 1, will check the other. Most machines are National/Panasonic.

User RetroFan found that e.g. Unknown Reality and Pumk Adventure 3 don’t work correctly on these mappers. Japanese games (who probably don’t even touch the mappers) work fine. But DOS2 also works fine. Maybe it is related to mapper segments and page allocation? Should all segments be usable in all pages? Might this be implemented incorrectly by Panasonic? Or could the software access memory too quickly after switching (are there any rules in that area)?

I will try to check if the issue with Unknown Reality and Pumpkin Adventure 3 can be replicated on my machine.

Por gdx

Enlighted (6442)

18-08-2022, 11:28

It looks like the read register test is failing, is not?
I suspect a bug from Testmap. I have never noticed any issue with my turbo R. I only noticed that the pages declared as used under DOS2 were no longer accessible (which is normal and occurs also on GT).

Por sdsnatcher73

Enlighted (4317)

18-08-2022, 14:57

It is writing FF to address 8000 and reads back 00.

Por gdx

Enlighted (6442)

18-08-2022, 15:40

Yes, it's not a failure while reading registers but probably a software bug.

Por Retrofan

Paragon (1339)

18-08-2022, 19:00

Thanks both sdsnatcher73 and gdx!

BTW, I also saw this nice upgrade kit for FS-A1F for example a RAM expansion and other things (translate with Google Translate) http://niga2.sytes.net/msx/A1Fkai_man2.html

There's a connection mentioned to the S1985, see step 2. Don't know if this also is neccessary for the 128kB upgrade.
Just checking.

Por sdsnatcher73

Enlighted (4317)

18-08-2022, 21:12

No it is not needed. They use a 4MB mapper on the expansion board which requires a slot select signal. The upgrade to 128kB uses free positions on the mainboard and just extends the existing mapper, which already has the appropriate slot select signal.

What I did find is that ROM adapter board for early revisions. Apparently the FDC ROM was updated, could there be a bug in the FDC ROM? But it’s then weird the A1FX and A1ST still have this issue (at least some models). Maybe the FDC registers are also in the mix?

Por sdsnatcher73

Enlighted (4317)

25-08-2022, 10:25

Unknown Reality and Pumpkin Adventure indeed have issues on this machine. It seems they detect a larger mapper than is actually present, could it be due to the back annotation that is also reported by TESTMAP as being 5 bits?

Unknown reality reports 512kB RAM. Pumpkin Adventure 3 locks after the UMAX logo (presumably because it tries to load into a RAM segment that is not present and overwrites its own code). On a unmodified machine (just 64kB) Pumpkin Adventure 3 passes it’s RAM test (reporting >=128kB).

It seems to me that possibly the mapper in the MSX engine is not configured correctly? Maybe some lines should have been connected to GND or 5V? If so could this be corrected so software compatibility for this machine improves?

Also, this behaviour is not emulated by openMSX for this machine (and possibly others).

Por sdsnatcher73

Enlighted (4317)

25-08-2022, 10:43

I will try the same on some other Japanese MSX2/2+.

Por Grauw

Ascended (10821)

25-08-2022, 10:51

It’s definitely not a hardware bug or misconfiguration, rather it is a software bug. Mapper registers should not be read by software in the first place, if you just insert a second differently sized memory mapper, it is clear that there can be no sensible result with both simultaneously returning different values for their upper range. Even if you ignore this and still do read it, there is no documented requirement that the number of bits the mapper’s register can store should match the memory available.