SofaRun v2.0 bug report thread

So that's interesting, I was not aware of that. Good thing is that if that's used in MFR and EMUFILE, there are probably no known side-effects of accessing the VDP (or are there ?).

I'm reluctant to have this always enabled in SofaRunIt, but I'll consider adding this as an option. Even if I must say that from an architecture point of view... argl... I do not like this disk-driver to VDP dependency! Why not waiting also for the Music Module or other devices ? Clean way to fix those issues would be to fix the bug in the games themselves (so that it would work on ony device), but that will probably take much more time.

But OK, I'll not be too code-rigid and give it a try (so Victor, I'm interested by your VDP-wait routines).

On MSX1 program you can't have this kind of problem anyway, so you can safely skip this check on it.

On MSX2 and up this should not be a real problem since programmer should not access disk if status register 0 is not selected. At least MSX2-BIOS expects status register 0 to be selected always when BIOS routines are used. Of course it is not wrong to expect that programmers can do anything, but at least failing to follow these basic guidelines causes problems with disk motor control on many machines... So the fact that you have to change status register select to 2 and back to 0 does not really violate MSX standard in any way.

VDP.DR: equ 0006H
VDP.DW: equ 0007H
RDSLT: equ 000CH
EXPTBL: equ 0FCC1H

VDP_WaitReady:
    ld a,(EXPTBL)
    ld hl,VDP.DR
    call RDSLT
    inc a
    push af
    ld a,(EXPTBL)
    ld hl,VDP.DW
    call RDSLT
    inc a
    pop de
    ld e,a
    ld c,e
VDP_WaitReadyLoop:
    ld a,2
    di
    out (c),a
    ld a,15 | 128
    out (c),a
    ld c,d
    in a,(c)
    ld c,e
    rra
    ld a,0
    out (c),a
    ld a,15 | 128
    ei
    out (c),a
    jp m,VDP_WaitReady
    ret

Especially for certain people I made it Neos MA-20 proof . Though due to those modifications, untested. And oh, of course this touches the interrupt state, some software may be finicky about that.

Sure, but there’s no real reason to write the code like that I think (self-modifying optimisation). The interslot reads won’t have any noticeable speed effect after disk access.

The documentation only says it requires MSX-DOS2 (or Nextor), and Nextor works fine on MSX1 machines with a memory mapper…

Victor, I see in your code you check the TR flag, that indeed seems like a good idea because otherwise it could get into an infinite loop there during RAM->VRAM transfer which seems like a common thing to do (like COPY "FILE" TO (X,Y)).

I spotted a mistake in my code, jp m,VDP_WaitReady should be jr c,VDP_WaitReadyLoop. Sorry, as I said due to rewriting the snippet before posting here. But probably it should be amended with the TR check as well. Well whatever.

Hey folks -Louthrax especially, I would like to declare my unconditional love for SofaRun. It changed my life to a point I can't envision doing without it. I love it in a non-erotic, geeky kind of way.

Just a little thing. I own a physical MSX2 (a Philips NMS 8220)) with a 512 Kb memory mapper ; so I have at least 512 Kb available anytime.

I'd like to run very large ROMs with SofaRun, most notably :
- Barbarian The Duel (1 Mb)
- Super Mario World (1.2 MB)
- Pointless Fighting (2 MB)

Currently they don't wont (Super Mario World returns "*** No suitable device found", the others just freeze) :

So I setup an emulator config similar to mine, with SofaRun running from an emulated HDD :

where they still don't work in SofaRun ; though they do work if I insert them as physical cartridges.

I tried to browse threads such as this one], and then increased my available mapped RAM :

here to 2 Mb, but it doesn't help.

My understanding is that I may need an additional physical device. The "Mega Flash Rom SCC" term keeps coming, though I don't know what it consists in. Any hints ?