MSX Assembly Page

Wow that's freakin' awesome!

It doesn’t, or rather, it presses 8 notes at once. On the SFG, the IO0 and IO1 pins are connected to ground through a resistor, so I’m not sure how healthy this is; if you press the multi sensor and a key at the same time, it would connect the output pin to ground… I think the resistor protects the circuitry from getting too high a current flow so it’s ok, but my electronics knowledge is limited.

But other than that, the second question is more or less answered and confirmed, albeit in another direction. The wiring in the service manual or my interpretation of it must be wrong. (It’d still be nice if Manual can try the Yamaha keyboard on his Toshiba module I reckon, just for the hell of it.)

The other two questions remain open, whether IO0 and IO1 are connected on the FS-CA1 as well so the Toshiba’s multi sensor can be used, and what signals the YK-20’s ribbon sends.

Recently Wouter Vermaelen from the openMSX team finished part II of his V9938 VRAM timings article, this time focusing on the pattern modes. These are excellent technical articles and give great insights in the inner workings of the V9938.

Both of these can now also be found on the MSX Assembly Page.

I was just looking at the DoCopy routine on the MAP and I think I see some room for optimisation:

;
; Execute a VDP command.
; hl = pointer to 15-byte VDP command data
; hl <- updated
; Modifies: af, bc, de, hl
;
DoCopy:
    ld bc,(15 | 128) << 8 | 99H
    ld de,(17 | 128) << 8 | 32
    di
    out (c),e  ; set indirect register access to r#32 + auto increment
    out (c),d
    ld de,2 << 8 | 0
VDPready:
    di
    out (c),d  ; select s#2
    out (c),b
    in a,(c)   ; read CE flag
    out (c),e  ; back to s#0, enable ints
    ei
    out (c),b
    rra
    jp c,VDPready
    ld c,9BH
    outi       ; 15x OUTI is faster than OTIR
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    outi
    ret

When there is no command currently executing it is just 1 cycle faster than the original DoCopy, however when it needs to wait the loop is 22 cycles shorter (19%) so it should be able to respond a little faster. Interrupts are disabled for a shorter time as well.

At the time I originally wrote it I didn’t know yet that you do not need to wait between VDP register writes (only VRAM writes). I haven’t tested it so I won’t update the MAP just yet, but I thought it’d be nice to post here.

p.s. BiFi objects to the name DoCopy, so if you want you can call it VDP_ExecuteCommand :). Fun fact: I inherited the name from Stefan Boer’s VDP course.

More inspiration for bios improvement
When the vertical blank interrupt would pick his status register on his own, all the other codes could be faster.

with vblank interrupt restoring R15 via mirror byte, the wait code goes

	... b = 15, c = 0x99 ...
	ld a,2
	ld (RG15SAV),a	;like with mapper. first write mirror byte, then hardware.
	di
	out (c),a
	ei		;z80 early EI thing
	out (c),b
wait:	in a,(c)	;if interrupt occures, it restores status via rg15sav
	rra
	jp c,wait
	dec c
	15xouti
	ret

The wait code is so much shorter. It feels like the OS has made the hardware faster
And finaly one could snip all the opcodes till the wait.
Like, for the whole duration of the sprite engine no change is needed.
"before any call to executecommand, call begincommand". like opengl glbegin/glend things

but where is RG15SAV? The assembly page has a link for it, but it doesnt work I fear bios got none, then one must snip another byte in USR.