I remember when I had a dozen FAT12 partitions. Just the single FAT16 partition sure was a big improvement .
@Louthrax If you want me to do a few tests on my turboR GT to add a 3rd result, feel free to mail me with some files and instructions.
Mail sent! Curious about the results.
GDX, the only problem I have here is a latency in the bottom part of the screen update in Maze of Galious on some screens (but if you wait a while the screen will finally be updated):
That's caused by the fact that the turboR mapper switch mechanism takes a lot of code and slows down the game, but I do not have the same graphical corruptions you posted.
The games are definitively slower in turboR mapper / Z80 mode, but it's still the best mapper for games that are playable in R800 mode (like the FRS patched version of Metal Gear 2), because it runs in turboR internal RAM (super fast) and have no in-game disk accesses (8KB pages).
I tested;
Video: Usas
I see corruption in the same spot, what it looks like may depend on how long I linger in the intro demo because I’ve also seen it have blue sky tiles there, but not the clouds that are supposed to be there:
Video: Maze of Galious
Corrupted graphic changes after a while, music also does some weird things.
I see corruption in the same spot, what it looks like may depend on how long I linger in the intro demo because I’ve also seen it have blue sky tiles there, but not the clouds that are supposed to be there:
It seems something is writting to #EC00. That byte encodes that metatile.
Thanks a lot Grauw, that totally discards any RAM problem!
My best hypothesis so far: the problems are caused by the slowdowns in Z80 mode (as everything seems OK in R800 mode).
- In turboR mapper mode, I do a reliable interruption saving / restoring in the emulation routine, based on your routines Grauw
- In memory mapper mode, I let the user choose how to disable / restore interruptions (DI/EI, DI/DI, etc...), in order to optimize performance.
My bet is that interruptions are happening at some slightly different timings, and that my expanded ST model has a different RAM chip causing a different behavior...
So, I'll make a quick new version of SofaROM that does a simple DI/EI (or DI/DI) in the emulation routine, like in Memory mapper mode (which seems to work on GDX turboR ST).
Still odd that you can’t reproduce it yourself…
Not a big fan of the RAM chip theory.
I see corruption in the same spot, what it looks like may depend on how long I linger in the intro demo because I’ve also seen it have blue sky tiles there, but not the clouds that are supposed to be there:
It seems something is writting to #EC00. That byte encodes that metatile.
Mmmm, interesting, thanks Guillian... But why only in Z80 mode and why does it work on my ST?
But you still can’t reproduce it yourself? That’s odd.
No way to reproduce that so far, that's crazy!
Not a big fan of the RAM chip theory.
I do not believe in it too much either, but that's the only difference we coud have... Or maybe some difference in the turboR BIOS or in the RTC settings ? (text colors or screen width ?? But you are in 80 columns too on your video...)
So I realized the /I option to handle interruption mode already has an effet on turboR (totally forgot that).
Could you guys try the same tests on the same disk but just add a "/I2" option at the end of the command line?
It changes nothing…
Both in MoG and Usas.
Darn! Thanks Grauw! Next step here is to fix the turboR mapper emulation in openMSX (will always be useful), and then hopefully reproduce the problem...