Well, I looked at the possibility to include a direct-to-vram unpacker with pletter, and I do not think the bitbuster/pletter algorithm is very suitable to do this. When using a buffer to read from and write to vram, one of the problems is when the part to copy overlaps with the part to copy to. So I concluded it was not worth the trouble, but don't let me stop you

If I would need a direct-to-vram unpacker, I would take pletter4, force the offsets to 8 bit, and use a circular buffer of 256 bytes in ram to keep track of the bytes written to vram.

Quote:

jltursan said : Well, you can always use aPLib. It's as good as bitbuster/pletter and also unpacks directly to VRAM at a very reasonable speed. The source code is available and it can be easily improved, specially the VRAM dump loop.

Hey ... Nice one
I'll take a a look at it and see if it is more suitable.

Quote:

sjoerd said: Well, I looked at the possibility to include a direct-to-vram unpacker with pletter, and I do not think the bitbuster/pletter algorithm is very suitable to do this

That is roughly my conclusion, also.
I tried to see if another algorythm was better suited to that purpose.
Unfortunately, most compression algorythms are based on a "sliding window" and a a length/distance copy of the already decompressed data. So a copy of the existing data is almost always needed.

Quote:

Well, you can always use aPLib. It's as good as bitbuster/pletter and also unpacks directly to VRAM at a very reasonable speed. The source code is available and it can be easily improved, specially the VRAM dump loop.

I took a look at the source, and it is the same algorythm as BitBuster/Pletter.

There is a SEGA VRAM depack subroutine and they used a VRAM read/write thru INs and OUTs to perform the data copy. So they choosed that solution over the buffer one. It might be interesting to compare speed with such a solution implemented for MSX.

I'll try to do it with BitBuster/Pletter.

I would love a bitbuster that could depack to vram... even slowly... could be great for static screens, or even to "load things once"...
I also tried to do that, changing LDI to LDIR, but with no success either

Quote:

There is a SEGA VRAM depack subroutine and they used a VRAM read/write thru INs and OUTs to perform the data copy. So they choosed that solution over the buffer one. It might be interesting to compare speed with such a solution implemented for MSX.

After some little optimization and as far as I've been using it, it's fast enough to unpack typical VRAM initialization data and even to dump in the visible screen without too much fuss, no need to use "Please wait..." messages . Of course I'm talking about common MSX1 VRAM data sizes, to unpack a SC8 page could take a bit more

@jltursan : Do you mean you already converted aPLib to MSX ?

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.

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...

Quote:

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.

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

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

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

@SLotman : look for the link earlier in this topic

Quote:

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 ?

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

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.