Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

698 Excellent

About TheMole

  • Rank
  • Birthday 09/11/1979

Profile Information

  • Gender
  • Location

Recent Profile Visitors

9,280 profile views
  1. You can get the gcc linker to output flat binaries and a text file with the symbol table, with those two things you should be able to write a relatively simple tool that combines the information in those two files in to an EA3 object file. I think it might even be possible to write a linker script to output something that converts easily to EA3?
  2. I'd be interested if the programming language was free to choose, especially since performance does not play a factor in determining the winner.
  3. Cool! Then feel free to add me to the list
  4. I'd like one as well, but will be moving continents soon (June), so do you reckon I could get one here in Belgium before that?
  5. I guess Rasmus' point (although I probably shouldn't speak on someone else's behalf) is that these concerns have been expressed over and over again in the past and nothing new has been added to this discussion in quite a while. Some of us simply want to experience what it would've been like if the TI's architecture had continued to be developed for much longer than it has, and initiatives like the F18A or the StrangeCart are designed to address that need. It's perfectly fine for people like yourself and Fabrice to not experience that same need, but it's really really hard to see the added value of repeating that very same position over and over again in each thread that discusses F18A implementations. I mean this with the sincerest and deepest respect to you and others that feel the F18A detracts from the pure retro TI experience, but could we agree to disagree on the matter and just let this thread continue as an on-topic discussion of what can be done on the F18A for those of us that want to explore that avenue? If any of us feels the need to continue the discussion, perhaps we can create a new thread for it, or resurface one of the older discussions on the topic?
  6. aPLib compression should be able to reduce sprite data to roughly 1 quarter of it's original size (though you might need to deinterleave the bitplane data for that), check out this implementation here: https://github.com/emmanuel-marty/apultra. That should turn those 6K of sprite data into roughly 1.5k. An aPLib decompressor on the Z80 is less than 200 bytes, so it could be feasible. You could also take a look at exomizer, https://bitbucket.org/magli143/exomizer/wiki/Home, which also tries to provide an algorithm that can run well on retro-class hardware. Agreed though, more memory on the F18A would open up a whole new world of possibilities!
  7. Would it be possible to store the sprite patterns in the upper 2K of VRAM (0x4000 - 0x4800) in a simple compressed format and once per frame have a GPU program decompress and stream the compressed data to the sprite pattern table in regular VRAM depending on which sprite patterns are needed that frame? You'd still only be able to have 8 distinct 32x32 sprites on screen at the time, but you could conceivable have quite a few more patterns available compressed in the upper 2K to use throughout the level. You wouldn't be eating into the bandwidth available between CPU and VDP and I'm sure the GPU would be fast enough to decompress on the fly. It could look something like this: - After the start of the HBLANK period, your main code uploads a full sprite list to VRAM, with pattern ids pointing to a virtual sprite pattern id containing all of the patterns used in a level. - At the start of the frame, a GPU program looks at the sprite allocation table to see which patterns are needed this frame - the GPU finds the compressed patterns and decompresses (max 8 32x32 patterns) them in the sprite pattern table in regular VRAM - the GPU updates the sprite allocation table so that each sprite entry points to the right decompressed pattern definition, depending on where in VRAM it ended up. The big challenge will probably be writing a small enough GPU program to leave enough space for compressed pattern data.
  8. FWIW, "Tak" is Thanks in Danish
  9. Wow, this was one of those days back in the day that convinced me the TI was a capable competitor to its more commercially successful brethren here in Europe in terms of games. Absolutely awesome to see the code released!
  10. True enough, but given that Matthew is working on the mkII which will also support more VRAM, it might be good to align with him if he's open to that. I for one look forward to whatever you guys come up with!
  11. I'm not against 99x8 support, but I think it would be good to at least look at the f18a first. Most of the new software aiming for better-than-the9918a graphics seems to be targeting that chip, and I've always found the existing 99x8 library a bit lacking, especially in the games department.
  12. This is impressive! We should try to figure out if this comes with a somewhat complete AGI engine. If so, perhaps it can be used as a springboard to port some of the other Sierra adventure games.
  13. I will happily commit to buying a set at that price,. provided shipping to Europe doesn't double the cost ;). Although I would really prefer a cartridge. Aren't most of the new boards updatable in some kind of way anyway, these days, even if with a minipro? You could socket the EPROM and ship updates on new chips for a small fee if push comes to shove?
  • Create New...