Jump to content

xxl

Members
  • Content Count

    1,710
  • Joined

  • Last visited

  • Days Won

    1

xxl last won the day on February 18 2013

xxl had the most liked content!

Community Reputation

1,856 Excellent

About xxl

  • Rank
    Stargunner

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Rabka-Zdrój /Poland

Recent Profile Visitors

17,747 profile views
  1. is on the list. is one of the leading decompressors def: 1,598 --- > decompressor for Atari: https://github.com/pfusik/zlib6502
  2. https://github.com/emmanuel-marty/lzsa/blob/master/pareto_graph.png https://atariage.com/forums/topic/316628-most-efficient-compression-for-atari/?tab=comments#comment-4741617
  3. what's the problem with asking Lothark for the original BIOS upgrade program?
  4. remember ID: 00 = LZ4, 01 = aPLib, 02 = ZX0 I included a virtual decompression procedure and identification of such binaries with Chkxex - the sources are available in Pascal. http://madteam.atari8.info/uzytki/chkxex.7z I am wondering about this error check, actually it is very simple but I would doi it like this: frame color red = error - let the user know with the frame color that the block has a checksum error. (I didn't change Antic's prorgam, didn't write anything to the screen's or to the E:ditor.) the following questions also arise: should the record counter be extended to two bytes? because with one byte we have max. 32K binary. so either one byte of the counter and records about twice as long, or two bytes per record counter ...
  5. x is ok but wait a moment because I have newer versions of loaders but I'm waiting for Tebe to publish SP (he said it would be soon) this is simple to use but not necessarily an advantage ... if we are considering error correction it may even be a disadvantage ... but it is true that it would be good to be able save binaries with a record of any length - there were copy programs where individual blocks had different lengths 🙂
  6. thanks 🙂 I will take a look at it 🙂 it's a pity that this idea wasn't popular 35 years ago ... the trauma has remained until today enough that there is xc12 in the room and I start creeping up like a cat.
  7. yes i did some tests as well ... firstly, the method: I see two relatively easy ones - the first is that when the loaded record has a bad checksum, the user receives the information to rewind the tape by one or two records and continue loading, the method requires interaction with the user, the second method is that we want to be 100% sure that the program will be loaded even with 25% damage !!! in fact, 5% is enough (Reed-Solomon error correction) - this method unfortunately has two drawbacks - the first is decoding requires a double record buffer, the record decoding time requires an extension of the interval between records - this can of course be compensated by the compression method used within the record limits (small effectiveness) or within the limits of the program (requires a buffer), it can also be improved using e.g. compression with an external dictionary (I performed tests for LZ4 where the external dictionary was the computer's ROM and the effect was satisfactory but the problem is that a different rom in the computer means that decoding is impossible) ... generally, both methods have considerable disadvantages :/ I keep thinking about the one used in Buldoger Copy, but testing it on the emulator seems impossible to me - like rewinding the tape by a few seconds? (I find it quite tempting because we will also get a record counter for free )
  8. I noticed Zaxon did a 512K external memory expansion
  9. to this day there are releases on cassettes 🙂 the one at the bottom is ultra rare. It's true that the Atari xc is not the best device (poor as hell) - that's why hardware turbo or software systems like hybrid loaders have appeared to reduce the loading time. does it make sense? same as stamp collection: D.
  10. possible - I will deal with it as soon as a new version of SuperPacker is released. I have new versions of loaders but I'm waiting to check them out.
  11. Unlike most general purpose compression algorithms, Brotli uses a pre-defined dictionary, roughly 120 KiB in size, in addition to the dynamically populated ("sliding window") dictionary. nice try... LZ4 allows you to use compression with an external dictionary - a properly prepared dictionary for a data type can do wonders. So what, because the decompressor must have access to this dictionary Brotli is just such a "wonderful" child. you have to try harder Brotli: 1537 added
  12. Shrinkler vs PackFire is a compressor clash for Amiga vs AtariST 🙂 both are from the same period - updates are from 2020 and 2017 🙂 The advantage of unShrinkler with low requirements (in a minimalist form 1KB buffer) it crushes the competition. PackFire (Tiny) seems to be stronger than the top compressors: Deflater, aPLib, ZX0 - although more testing is needed here, and only Deflater requires a buffer. Who's gonna beat the Shrinkler? Evidence!
  13. xxl

    AVGCART

    I think that the clock will only increase the cost of the device and the carbon footprint and if some funny DOS want to use time, let them learn to use the time provided from the network
×
×
  • Create New...