swapd0 Posted May 9, 2018 Share Posted May 9, 2018 I've implemented something like a file system on the cartridge, so when I need a graphics or sound I copy them from the cartridge space (skunkboard) to main ram... well all data are packed so I unpack from ROM to RAM. This mean that I'm reading the memory (ROM) byte by byte, there are some issues with byte reading? I've included some checks after the unpack and sometimes the output file it's bigger than the original, but sometimes it works. By the way I'm using lz77 and lz78 from here http://s390174849.online.de/ray.tscc.de/code.htm Thanks. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted May 9, 2018 Share Posted May 9, 2018 I'm not aware of any issue with reading data from ROM... Which processor are you using (68k, GPU...)? Is the ROM bus width correctly set for the Skunkboard (16-bit)? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted May 9, 2018 Author Share Posted May 9, 2018 68000, I haven't changed anything about ROM bus width, do you mean MEMCON1 6 MEMCON2 registers? Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted May 9, 2018 Share Posted May 9, 2018 Yes. Try including the piece of code in the first post of that topic to see if it fixes the problem: http://atariage.com/forums/topic/256149-rom-asset-management-accessing-assets-from-rom-directly/ Quote Link to comment Share on other sites More sharing options...
swapd0 Posted May 10, 2018 Author Share Posted May 10, 2018 Thanks I've included the code but it still fails, but I've realised that with some files the depack routine overwrite the output buffer, it fails always on the same files. Even using the PC application, some files when you depack them you got a huge file... Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted May 10, 2018 Share Posted May 10, 2018 Have you tried this version? http://www.jagware.org/applications/core/interface/file/attachment.php?id=161 I think CJ also has some decompression code. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted May 10, 2018 Author Share Posted May 10, 2018 It looks that It's the same packer that I'm using lz77, the problem it's that I need the packer for OS X. That's why I'm using lz77 & lz78 from ray's web. The packing routine had a bug that I've fixed, at least now I don't have buffer overflow. Quote Link to comment Share on other sites More sharing options...
42bs Posted May 11, 2018 Share Posted May 11, 2018 Check out 7z/lzma. It comes with sources and I think the depacker is fairly ease to port to 68k/GPU/DSP. There should be an OS-X version. Or at least lzma can be compiled for macOS. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted May 11, 2018 Share Posted May 11, 2018 I use NRV2e from CheckPoint: https://www.dhs.nu/bbs-coding/index.php?request=5184 I have also used LZ77 without any issues. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.