Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

rensoup

Members
 View Profile  See their activity

  • Content Count

    1,066

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by rensoup

  1. Posted

    Hi!

     

     

    I don't understand this. LZ4 can be decompressed "almost" in place (with about 8 bytes of gap between compressed/decompressed data).

     

     

    With a "small" (124 bytes) implementation, I get a little less than 49 cycles per byte, this is 500 bytes/PAL frame on GR.0 (the slowest possible), about 650 bytes/PAL frame without DMA. This is my main "copy" loop, in ZP:

     

            org     $80
docopy
	jsr	getsrc
dst = * + 1
	sta 	output_addr
	inc	dst
        bne     skip4
        inc	dst+1
skip4:
	dex
	bne	docopy
        dey
	bne	docopy
	rts

getsrc
src = * + 1
	lda     packed_data
	inc	src
        beq     skip5
        rts
skip5:	inc	src+1
	rts
    Note that the "docopy" loop uses JSR to the read routine, and the pointer is incremented on each byte read/write, this is to minimize size.

     

    You can implement it faster if you use indexed addressing, the main copy loop should be like:

     

    docopy
	lda     source_addr, X
	sta 	output_addr, X
	inx
        bne     docopy
        dey
	bne	docopy
	rts
    This would make 14 cycles/byte in the best case, so this is max about 1700 bytes/PAL frame. Certainly three times faster than my original code should be possible.

     

    Attached is a sample source code, and a program that compressed a XEX file using LZ4 (windows/linux versions).

     

     

    Sounds interesting as well, 1700 bytes best case is a lot better for lz4. :thumbsup:

  2. Posted

     

    Three years ago I've created "autogamy" and used it to compress the level data for "dye". (Also used in "E-Type".)

     

    Features:

    * fast and compact depacker (using self modifying code)

    * nearly as good as LZ4 - for small files often even better

    * in-place decompression if the source data ends at least 4 bytes behind the end of the target buffer

    * compression uses also self-referencing - so no streaming (windowing currently unsupported)

     

    Archive contains packer for Windows (exe) and source-code for de-packer cc65 header / ca65 source.

     

    You may like give it a try.

     

    Thanks! :thumbsup:

     

    I will give it a try for sure. Sounds like it would be a good fit for one of my use cases.

     

    I've got another use case which requires -no- self-ref so I will look into what's in MADS and possibly have to try my own RLE variant (not even sure it will compress much better than RLE though)

  4. Posted

    download the MADS assembler and have a look at the various crunchers.

     

    me used exomizer, deflate, lz4 in the past but sticked now to c64 depacker called "B2" & pucrunch.

     

    I've started using MADS and indeed there's plenty of crunchers. I will take a closer look but perhaps some folks here have experience with them and can tell me if one of them fits the requirements?

     

    Can't find any ref to "B2" but pucrunch/exomizer aren't quite what I'm after... way too slow to decrunch.

  5. Posted

    Hi!

     

     

    LZ4 should be as fast (or even faster) than RLE. Sure you are using an optimized implementation?

     

     

    Really ? well I tried Fox and XXL's version, it's optimized for size so probably not for speed. It looks like it can decrunch about 200-300 bytes max per frame at 50fps.

     

    The other problem with LZ4 for what I have in mind, is that it can't decrunch chunks as it uses previously decrunched data (while RLE can)

     

    I would still be interested to get a faster version if you have one.

     

    Thanks!

  8. Posted

     

    Nope, Altirra generally uses the system theme color settings including the window background color. Blame Microsoft for removing the UI in Windows 10 to configure theme colors and not updating the theme colors when dark mode is enabled in the system. I've thought about overriding this but it's a mess with dark mode not being properly exposed to Win32 and some system controls still using unconfigurable colors and theme images.

     

    Well I'm still stuck on W8 :-o I was asking for a dark background colour in debug windows not necessarily something that strictly follows windows conventions.

    I thought that'd be an easy change but I'm not a Windows expert. I've only ever used Winforms and it's easy with those.

     

     

    No, Altirra only the parses the address/opcode bytes and line numbers from the listing and uses the source field only for looking for special directives. It does not try to parse the assembly lines, which is not trivial (consider that semicolons can be embedded in string literals).

     

    :? maybe I phrased that wrong again. I'm already using source debugging with Alt-Sh-O and it works great. It just doesn't seem to default to using it and I have to use ALT-Sh-O, then point to the masm file to activate it.

    I was hoping it would do this automatically but that's not a big deal if it doesn't.

     

     

  9. Posted

     

    Debug > Options > Change Font.

     

    Damn I somehow missed that... Much better now :thumbsup:

     

    Might there be a color setting that I missed too (the white background is a little harsh) ?

     

     

    The emulator will load .lab and .lst files with the same name by default, but this won't work if you are loading the executable in code instead of letting the emulator do it. You can use a breakpoint to trigger the .loadsym command, or use .reload to reload the symbol file that has already been loaded.

     

    I'm loading from the command line and I wasn't paying attention again because it does indeed load the symbols... but it doesn't have all the comments that I wrote in the source (I still have to use Sh-Alt-O for that )... comments should be loaded from the lst file, right ?

     

     

     

    By the way, the current version of xBIOS (4.3) still does not implement burst I/O and is copying a byte at a time from the I/O buffer to the load address instead of loading sectors directly. On an actual 1050 floppy disk drive, this causes it to miss sectors and load at two-thirds speed compared to DOS 2.0S.

     

    That sounds like a dealbreaker...

    • Like 2

  11. Posted

    I've recently started a bit dev on the A8 and I'm using Altirra for debugging and while it's working pretty well overall, there are a few things that could help:

     

    Could I make the debug fonts (much) bigger ? i tried the /portable switch which created an .ini file which has fonts settings but don't seem to do anything ?

     

    Is there a command switch to automatically load the .lst file because I'm using Alt-Shift-O every time ?

     

    Although I'm using an obj file right now, I'm planning on using xBios to be able to use the whole memory space as well as loading extra data. So that means an ATR file.

    Any way making the loading time instant ? not like warp speed where everything get speed up (although I guess I could use it if I could bind it to a key).

    Or perhaps there's a way to mount a directory as if it was an ATR?

     

    Thanks

  12. Posted

    Hi Snicklin,

     

     

    1) I can't see why you couldn't use the buffer between loads for other purposes. If you're not using it, then what is the problem?

     

    Well the code could store some internal state in that buffer, maybe even just one byte. Although that's unlikely, I'd rather be absolutely sure.

     

     

    2) Alike to (1), if you're not using xBIOS, you could compress it when not in use, do something else with the area, then inflate it back to its original location before being used again.

     

    Same as 1) but that's a lot more likely. Let's say I create a disk with xBios, run it, then break into the debugger to dump the $0800-$0BFF area. Perhaps that area contains the current directory structure as well as internal states?

     

    I then add more files or update the files on disk, changing their filesizes. The initial load from the bootsector would be up to date but after decrunching the old xBios, I'd end up with old data and almost certainly a crash.

     

    Just speculating :)

  13. Posted · Edited by rensoup

    I'm planning to use xBios (seems like a great tool btw) and I'm wondering if I could get even more RAM back.

     

    the wiki says:

    $0700-$07FF        xBIOS I/O buffer$0800-$0BFF        xBIOS

    1) I'm guessing I can use the IO buffer safely between loads ?

     

    2) Assuming I've got a decompression routine already in memory that I use for other purposes, could I keep a compressed version of the $800-$c00 area ?

    I assume there is some data in there that is dependent on disk layout, and perhaps temporary variables so I can't just dump the memory and compress it ?

     

    Thanks.

  15. Posted

    Hi,

     

    Just wanted to say this the most impressive 2600 game I've seen so far.

     

    It does have gameplay limitations but damn it doesn't look like a 2600 game, heck it looks better than the Atari 8bit conversion which was great (and the first game I ever got).

     

    Bravo :)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...