Jump to content

elmer

Members
  • Content Count

    254
  • Joined

  • Last visited

Community Reputation

514 Excellent

About elmer

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male

Recent Profile Visitors

4,230 profile views
  1. Yep, basically a dual-core PC of unknown build quality and longevity, with uncertain/unlikely availability of repairs or replacement parts. I'm not sure why some people seem to think that this is a reasonable substitute for consoles that were manufactured in their millions, or for a more standard PC where you can find really cheap replacement parts. I supect that the refurbished Dell 9020 that I recently purchased for $135, which unlike the PolyMega actually meets Mednafen's minimum specs for Saturn emulation, is a much better deal.
  2. Nope, it doesn't use dual-port RAM, it just uses the only manufacturer's RAM that could run at double the speed of the RAM in other machines of the early 1980s generation. That allowed it to display 320x200x4 color bitmaps, or 640x400x2 color bitmaps way earlier than other home computers. But the RAM was expensive ... so it only had 32KB when other machines at the time were starting to offer 48KB or 64KB of RAM. Everything, absolutely everything, was the product of a cost-benefit analysis of the technology that was available at the time. That's where the design choices in the Atari come from. It was designed to work with the 8KB and 16KB RAM chips that were avavilable in the late 1970s. Three years later on, the C64 and Spectrum (and Atari 1200XL/800XL) could use the newer generation of 64KB RAM chips. The Atari was absolutely amazing for its time, and it managed to do a good job of holding its own (and sometimes surpassing) the newer machines that came later ... but the genius of its design can only do so much against the march of technology.
  3. Yep, this is what I did (very carefully), and I got lucky and it worked first time. Even the removal of the old mylar was pretty smooth with a heat-gun/hair-dryer. I'm still trying to decide whether the final step is either a UAV, or the ClearPic 2002 mod. 🙂
  4. From the recent Mednafen 1.24.0-UNSTABLE release notes ... Looks like the Saturn emulator needed some tuning for the PolyMega CPU (which is under Mednafen's recommended spec for Saturn emulation).
  5. And now there's an LZSA1 decompressor, too! Testing with the same gpl-3.0.txt test file that we've been using for comparison in this thread ... The new LZSA1 decompressor runs at 51 cycles per byte in "small" mode (168 bytes), dropping to 39 cycles per byte in "fast" mode (205 bytes). To put those results in "frames" terms, so that they can be compared to timings that @xxl posted earlier in the thread ... gpl3.txt - 35147 bytes exomizer - 12382 bytes + depacker 1 page =~ 12.3 KB, decompress 128 frames (2.6 sec) deflate - 11559 bytes + depacker 2 pages =~ 11.8 KB, decompress 179 frames (3.6 sec) LZ4 - 15622 bytes + depacker <150 bytes =~ 15.3 KB, decompress 55 frames (1,1 sec) LZSA1 - 14621 bytes + depacker 168 bytes =~ 14.4 KB, decompress 50 frames (1,0 sec) LZSA1 - 14621 bytes + depacker 205 bytes = ~ 14.5 KB, decompress 39 frames (0,8 sec) The LZSA2 decompressor has been trimmed down a bit, and is now 256 bytes long for the "fast" mode (at the cost of a couple of % in decompression). Those couple of % can be optionally regained for the cost of an extra 11 bytes of code. The LZSA2 decompressor also has another couple of optional enhancements that take off 10 bytes of length, and boost performance by 3%, but they break compatibility with the standard LZSA2 format. Emmanuel Marty (understandably) doesn't want to change the LZSA2 format, so I'll probably create a fork of his LZSA for 6502 users. On top of that, Emmanuel Marty *was* willing to make some optional changes to aPLib, so APULTRA now supports an "enhanced" mode that is approximately 11% faster to decompress on the 6502. All of the decompressors are checked into the LZSA and APULTRA projects on github, which you can find here ... https://github.com/emmanuel-marty/lzsa https://github.com/emmanuel-marty/apultra/ Note: I don't use MADS, so I'll leave it up to someone else to convert the decompressors to MADS format. The LZSA ones have been converted to ACME assembler format, but the aPLib one is still in PCEAS/HuC assembler format ... aka FUJIAS assembler format now, since I've added Atari .car format to the assembler so that I can develop code for Atari cartridges. Anyway ... I *hope* that the overall result of all of this has been to show folks that LZ4 really doesn't have much of a purpose on old 8-bit and 16-bit machines, and that there are other alternatives available to developers ... including the old plain-LZSS variants, which @dmsc has shown still have a use with his LZSS-SAP utility.
  6. Dang, excellent necrobump, I never knew that this existed ... thanks! 🙂 I find this strangely appealing, especially with a 6309 that I've wanted to program on for years. I'm just trying to figure out whether I find it appealing enough to sacrifice either my 1200XL or 800XL (with U1MB) for. The 6809, together with a MyIDE2 (to provide 512KB of banked RAM and a CF card) would be awesome!
  7. I have finally written an LZSA2 decompressor to compare against my aPLib decompressor. LZ4 definitely benefits in speed by having fewer transitions between matches and literal runs (with its 4-byte-minimum match length). That means that it can spend more time in the fast inner-loop of the copy, and less time decoding the next type of compressed data. The downside is that its compression suffers. Anyway, by comparison, my aPLib decompressor runs at 69 cycles per byte on the gpl-3.0.txt test. My new LZSA2 decompressor runs at 51 cycles per byte in "small" mode, dropping to 46 cycles per byte if you allow it use an extra 15 bytes of code for more inlining. So very comperable to the performance of @dmsc's "small" LZ4 implementation, but with much better compression. It is checked into github, but I'm not going to post it here, because I'm chatting to Emmanuel Marty about some possible changes to the LZSA2 format to make the 6502 decompressor a little bit smaller (and a tiny bit faster).
  8. Where-on-earth did that rumor come from??? No, they didn't, neither of them. Just because Sony call the PS2 chipset the "Emotion Engine" doesn't somehow give it dedicated AI hardware, and nor do the 8 subprocessors in the cell chip count as dedicated AI hardware. The cell processor had a number of interesting features, but it was a real swine to program for. Don't forget that Sony started off believing IBM's optimistic projections for the power of the cell processor, and weren't going to include a GPU ... only to find out that the Xbox 360 (with ATI's chipset) was going to absolutely wipe the floor with them, causing a rapid conversation with Nvidia, who absolutely had them over a barrel, and who negotiated a sweetheart deal that cost Sony a lot of money (thus the move to an ATI chipset for the PlayStation 4). OTOH, I completely agree that the inclusion of the BluRay drive was a important factor in the success that the PlaySation 3 had. So the Neo Geo is made of "stock" parts, but the Megadrive isn't? That is despite them both sharing the same 68000 main processor, the same Z80 sound processor, both using off-the-shelf Yamaha sound chips, off-the-shelf RAM chips, and in the Megadrive's case, a Yamaha VDP chip that was a direct (and fairly predictable) evolutionary step over the previous Yamaha VDPs that were in the SMS and MSX2+ computers?
  9. Sorry, but I have no interest in trying dj-packer, fast packer or flash pack ... I'll leave those tests up to you. Exomizer is one of the other well-known-excellent compressors, so that was worth trying, even though its decompression speed is known to be slow (as shown earlier in this thread). I've added the exomizer results to my earlier post.
  10. @rensoup very kindly sent me his PoP main executable to test, so I've taken a look to see how the different compressors do with a real Atari program: Size File =========================== 40,164 popcore.bin 28,227 popcore.bin.lz4ultra 28,225 popcore.bin.smallz4 26,345 popcore.bin.lzsa1 24,366 popcore.bin.pucrunch 23,929 popcore.bin.lzsa2 23,280 popcore.bin.aplib 23,174 popcore.bin.exomizer 23,012 popcore.bin.deflate 22,926 popcore.bin.apultra
  11. Wow ... this is one heck of a necrobump for this thread! It's sad to see so much incorrect information about the PCE CD being thrown around. I hope that @JB has found out the true facts about the hardware in the last 13 years.
  12. As someone that was working as a professional game developer in the 1980s/90s/etc ... I've got to go with this, too. The NEO Geo was a more powerful piece of hardware at the time ... but it was basically an arcade machine that was being sold/rented to a small cadre of high-end rich gamers at a premium price. It really doesn't belong in any sane discussion of retail-consumer hardware. The MegaDrive was a nice evolutionary step, but it did absolutely nothing new that hadn't been seen before. The PCE CD on the other hand was a revolutionary leap (pun intended) over cartridge consoles or floppy-disc based computers. Suddenly you went from have a megabyte-or-less of game on an expensive-to-manufacture format to having 650MB available for the game and high-quality audio on a format that only cost a few cents to manufacture. It not only felt like a game-changer at the time ... it was. We've spent the last 35+ years (until digital took over) playing games that were delivered on spinning-plastic and not cartridges (excluding handhelds). The PCE CD was there first, and it gave a lot of (Japanese) developers their first chance to expand their imaginations and skills into what-was-to-become the standard way of making and delivering games for decades.
  13. Here you go, I hope that it works for you! aplib_6502.mad
  14. Thanks for that link, I hadn't seen it. It's another implementation of Jorgen Ibsen's aPLib format, but Svendahl wrote it in C# instead of C, and apparently there may be a bug in it (looking at the outstanding pull-request). Emmanuel Marty references "cap" as an inspiration for his apultra (https://github.com/emmanuel-marty/apultra). apultra compresses gpl-3.0.txt down to 12662 bytes, nearly 1/2 KB smaller than Jorgen Ibsen's compression code that I've been using in aplpak. Anyway, svendahl's decompressor is fairly similar to mine, and a big improvement on Peter Ferrie's code. My decompressor should be a little faster than svendahl's because I inline a bit more, although looking at his, I expect that the code sizes are very similar. Apart from a few other things in there, just his use of a subroutine call to read bytes from the compressed source should cost him 4 extra frames to decompress gpl-3.0.txt!
×
×
  • Create New...