SofaRun v2.0 bug report thread

Page 29/33
22 | 23 | 24 | 25 | 26 | 27 | 28 | | 30 | 31 | 32 | 33

By Grauw

Ascended (8515)

Grauw's picture

23-12-2018, 15:10

Not saying they aren’t, just that it’s bad practice to execute VDP commands without waiting for CE.

By Louthrax

Prophet (2093)

Louthrax's picture

23-12-2018, 16:07

Victor wrote:

even the DSK in MegaflashROM (with OPFXSD) and EMUFILE check if a VDP command is executing... but... no problem... This is your program...

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 Running Naked in a Field of Flowers ? 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 Smile and give it a try (so Victor, I'm interested by your VDP-wait routines).

By Louthrax

Prophet (2093)

Louthrax's picture

23-12-2018, 16:17

Grauw wrote:

Surprising that games would 1. run a VDP command during loading, and then 2. run another after loading without first waiting for the CE bit. Ouf.

Rune Master 3 does. That's a just a bug (which was never noticed until new fast FDD drivers), and definitively bad practice (looks like they did not had a generic "VDP command" routine ??). But I'm not so surprised by that, there are already lots of other bugs related to slots or memory management in (even Japanese) MSX games.

By NYYRIKKI

Enlighted (5398)

NYYRIKKI's picture

23-12-2018, 16:56

Louthrax wrote:

Yes, I know the reason of the problem, but I do not feel like having a dependency on the VDP from the disk driver (SofaRunIt is basically a disk driver), is wise. That implies not doing this wait on MSX1, and just the action of waiting for the VDP might also mess up things in some cases (I guess you need to change registers in order to know if a VDP command is in execution, that can definitively have unpredictable side-effects...).

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.

By Victor

Champion (470)

Victor's picture

23-12-2018, 19:51

sd_snatcher wrote:

I don't have a complete list, but this is the list I have so far:

- Illusion City (translated version): Doesn't boot, aborts to the MSX-BASIC
- Xak Tower of Gazzel: Runs with glitches and corrupted graphics
- Elite (MSX1): Doesn't boot, aborts to the MSX-BASIC

Then there's the list of games that I just couldn't find a way to run with SofaRunIt:
- Rona: doesn't even boot
- Magnar: doesn't even boot. Maybe related to single-sided 3.5" disks?
- Zone Terra: hardcoded to the disk interface on slot3-2
- ParaDream: requires diskBIOS2. But works fine if I copy the files to a folder in the mass storage device
- MoonLight Saga: requires diskBIOS2

You can see them here working in Flashjacks with my DSK emulator

By Grauw

Ascended (8515)

Grauw's picture

24-12-2018, 02:05

Louthrax wrote:

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

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 Smile. Though due to those modifications, untested. And oh, of course this touches the interrupt state, some software may be finicky about that.

By Victor

Champion (470)

Victor's picture

24-12-2018, 05:56

Grauw wrote:

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

The diskROM in Sofarunit is in RAM, so Loutrax can write the VDP register number just before launch the DSK inside the routine. And Sofarunit is only for MSX2 or higher, so no need to check MSX version.

After that at the begging of the DISKIO:


DISKIO:

	
	call wait_VDP_ready

	;here your DISKIO routine continues


wait_VDP_ready:
;Function : wait if a VDP is execuitng
;Input    : none
;Output   : none
;Registers: none
	di
	push	af
	ld	a,2
	out	(099h),a
	ld	a,08fh
	out	(099h),a
	

wait_VDP_loop:	
	in	a,(099h)
	and	081h
	dec	a
	jr	z,wait_VDP_loop
	
	xor	a
	out	(099h),a
	ld	a,08fh
	out	(099h),a
	pop	af
	ret

By Grauw

Ascended (8515)

Grauw's picture

24-12-2018, 13:37

Victor wrote:

The diskROM in Sofarunit is in RAM, so Loutrax can write the VDP register number just before launch the DSK inside the routine.

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.

Victor wrote:

And Sofarunit is only for MSX2 or higher, so no need to check MSX version.

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.

By Victor

Champion (470)

Victor's picture

24-12-2018, 14:31

Grauw wrote:

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

Yes, you're right. Perfect.

By Tarnyko

Rookie (31)

Tarnyko's picture

21-04-2019, 13:12

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 ?

Page 29/33
22 | 23 | 24 | 25 | 26 | 27 | 28 | | 30 | 31 | 32 | 33