SofaROM bug report thread

Page 12/20
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17

Par Jipe

Paragon (1560)

Portrait de Jipe

09-09-2017, 17:17

Par Louthrax

Prophet (2432)

Portrait de Louthrax

09-09-2017, 17:19

Jipe wrote:

a mapper page is false GDX have you the add circuit for decode D5 in your Turbo-R

But everything works fine in R800 mode on GDX machine... What's the role of this D5-related circuit? Could that be impacted by the speed or CPU mode?

Par sd_snatcher

Prophet (3557)

Portrait de sd_snatcher

09-09-2017, 17:51

This circuit implements the read back of the bit5 of the MemoryMapper, since it's missing on the S1990. It only affects the software that ignore the MSX coding guidelines and read the memory mapper registers directly.

Par Louthrax

Prophet (2432)

Portrait de Louthrax

09-09-2017, 18:04

Thanks Snatcher!

So a non-modded turboR has no or bits-limited memory-mapper readback capabilites? As my turboR has been modified by Jipe, it should have it. That's another potential difference I was not aware of. Wondering about openMSX... (strange thing though is that SofaROM does not read the mapper ports at all!).

Par sd_snatcher

Prophet (3557)

Portrait de sd_snatcher

09-09-2017, 18:11

Yes it's limited. The turbo-R only has the read-back of the bits D0 to D4 implemented in its memory mapper. So everything is covered up to 512KB of RAM. When the machine is expanded to 1MB, the D5 bit reading has to be implemented externally.

Does SofaROM read the memory mapper registers directly?

Par Louthrax

Prophet (2432)

Portrait de Louthrax

09-09-2017, 18:23

sd_snatcher wrote:

Does SofaROM read the memory mapper registers directly?

No, it uses MSX-DOS2 for allocation and only writes to the memory mapper registers. Also I do not see why the behavior would be different between Z80 and R800...

Par sd_snatcher

Prophet (3557)

Portrait de sd_snatcher

09-09-2017, 23:45

Hummm. If SofaROM doesn't read the mapper registers, then the lack of the bit D5 shouldn't make any difference.

gfx and Grauw, could you please run TestMap v4.2 both in Z80 and R800-ROM modes just to be sure that everything is fine with the MainRAM in your machines? I'm sure you understand that for a proper diagnose, all possibilities must be investigated.

Grauw: Is the MainRAM in your machine original or was it modified?

Par Louthrax

Prophet (2432)

Portrait de Louthrax

09-09-2017, 23:53

I saw the same problem on Meits machine, with the same corrupted tile. I think GDX launched TESTRAM and saw no problems, but maybe TESTMAP is different, could be worth trying it (in both Z80 and R800 modes).

I'll need to find another turboR machine to perform tests at home, remote debugging is too long for a tricky bug like this one...

For now I'll just disable Z80 mode for turboR mapper (switching to R800 mode). Not a big issue, the Memory Mapper mode is faster anyway, but still, I'd really like to understand what's happening under the turboR hood here Smile

Par sd_snatcher

Prophet (3557)

Portrait de sd_snatcher

10-09-2017, 01:48

Yes, TestMap is way better than the other tests. It discovered problems in cases where the other tests just said that everything was fine.

I decided to test this version to see if I could help. I tested in two different machines:

- FS-A1ST expanded 1MB using 514400 80ns DRAMs and with the D5 readback implemented.
- FS-A1ST expanded to 512KB with 80ns DRAMs

The results were identical in both machines:

- Maze Of Galious: Runs fine, without any gliches, either in Z80 or R800, albeit noticeably slower in Z80 mode.
- Maze Of Galious with my patch applied: Runs with the palette all wrong, either in Z80 or R800.
- USAS: Runs fine in either Z80 or R800 mode, albeit noticeably slower in Z80 mode.

BTW, I would advise against doing any turboR memory upgrades with:
- DRAMs faster than 80ns
- SIMM30 memory modules: these have the /OE pin tied to GND and that causes it to have a different response timing than the normal 44256 DRAMs.
- Long cables or wires to connect the sockets to the DRAM

They might seem they work at a first glance, but I've seen it cause glitches on many occasions even on A1ST computers, depending on the combination of what you run on the machine and what you connect to its slots. The A1GT is pickier and might not even boot. But just booting isn't enough proof that the machine is running fine, since the MSX BIOS memory test is very basic.

Par Louthrax

Prophet (2432)

Portrait de Louthrax

10-09-2017, 02:26

Thanks Snatcher for these tests, I was feeling a bit alone beeing the only person for whom this was working Smile

I was aware of the palette bug with your patched Maze of Galious: our routines are just occupying the same high-memory areas.

The turboR mapper device will always be the slower one in Z80 mode. I managed to optimize the routines a bit, but that won't change too much (of course slowdowns will be more or less observable depending on how frequently the pages are swapped by the game...).

Mystery is still here... I was thinking about checking the serial numbers of the turboR machines here... Maybe Panasonic fixed something for the R800 mode at some time... But the GTs should be the latest produced machines, and the bug was happening on Meits GT too.

Grauw, GDX and Meits, I'd be curious to see the result of the TestMap tool on your machines if you have time, even if I don't believe too much that all 3 of you have a memory issue!

Page 12/20
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17