BitBuster depack in VRAM | MSX Resource Center (Page 3/10)

Enlighted (6933)

12-02-2008, 19:27

AFAI understand aPLib do not need any conversion apart the change in the port numbers.

SMS use $be as VDP (data) and $bf VDP (control) instead of $98 and $99.
The I/O is exactly the same, so no need of further changes.

By jltursan

Prophet (2619)

12-02-2008, 19:54

Right, as ARTRAG says, is a straightforward port (and maybe assembler syntax) conversion. You can also apply the following optimization to get some more speed:

ap_VRAM_ldir_dest_to_dest:
  ; This may be a major speed bottleneck
  ; possibly could take some stack space for a buffer? but that'd need a lot more code space
  ; if it uses overlapping source/dest then a buffer will break it
		ex af,af
ap_VRAM_ldir_dest_to_dest.jmp:		
		call ap_VRAMToHL_read
		in a,($98)
		call ap_VRAMToDE_write
		out ($98),a
		inc de
		cpi
		jp pe,ap_VRAM_ldir_dest_to_dest.jmp
		ex af,af
		ret

Of course you can always avoid CALLing subroutines to speed it up even more...

By Metalion

Paragon (1622)

12-02-2008, 20:17

Right, as ARTRAG says, is a straightforward port
Well, I am not so sure : when you set up VDP for direct VRAM access, you tell it if it is a write or a read operation and then it goes into auto-increment mode.

In SEGA aPLib, the read and write are made simply by OUTing the 16-bit address (with high order byte bit 6 set for write) and then OUTing or INning the data. Does not work like that in MSX, although I agree there is not much missing for it to be a working MSX source.

ap_VRAMToDE_write:
  push af
    ld a,e
    out ($bf),a
    ld a,d
    or $40
-:  out ($bf),a
  pop af
  ret

ap_VRAMToHL_read:
  push af
    ld a,l
    out ($bf),a
    ld a,h
    jr - ; space optimisation

Anyway, my VRAM depacker for BitBuster is almost working, there is only the data buffer issue to solve. I will work toward a RAM buffer free version of it.

By dvik

Prophet (2200)

12-02-2008, 20:56

No this code works fine for MSX as well. The VRAM direction bit is set for write and cleared for reads.

By SLotman

Paragon (1242)

12-02-2008, 22:33

where someone may find this "SEGA VRAM depack" routine? I googled for it, but havent found anything about it...

By ARTRAG

Enlighted (6933)

12-02-2008, 22:55

?
SEGA aPLib has exactly a VRAM depacker
What you mean ?

By Metalion

Paragon (1622)

13-02-2008, 07:16

@SLotman : look for the link earlier in this topic

No this code works fine for MSX as well. The VRAM direction bit is set for write and cleared for reads.
In this case, is it still necessary that I work on a BitBuster/Pletter VRAM depacker ?

By ARTRAG

Enlighted (6933)

13-02-2008, 07:24

well, it could be a matter of performance, how goes aPLib against Pletter 05?

By jltursan

Prophet (2619)

13-02-2008, 15:19

No idea of the real numbers; but the unpack routine is bigger than the others, not very useful if you have in mind a 1Kb ROM and about the speed, tha author says that the unpacking to VRAM rates about 10Kb/sec. Unpacking to RAM must be very close to the numbers of bitbuster & pletter.

By Metalion

Paragon (1622)

13-02-2008, 15:34

Thanks to Arjan and the aPLib routines, I have now a working VRAM depacker routine for BitBuster that uses no RAM buffer (its footprint is 186 bytes). It is almost ready for release, I just need to solve a last bug and make sure it is MSX1 & MSX2 compatible.

I made a speed test on a 256x64 screen 5 image between :
- a RAM depack followed by a BIOS LDIRVM RAM to VRAM transfer
- and a direct VRAM depack

The direct VRAM depack is 2.5 times slower.