Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

593 Excellent

About enthusi

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • Location
    Potsdam, Germany
  • Interests
    Astronomy, Assembler 6502 /07/10, C64, VCS 2600, Photography, Tapes, Coding/Reversing in general, C, Python

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hey, it arrived I still love it with headphones or a proper amp attached \o/ Thanks for your efforts.
  2. Ok, makes sense! Thank you for clarification.Seems quite straight forward so far. Best wishes!
  3. Dear Karri, I have not yet tackled eeproms but intend to do so now Why are there so many eprom*.s files in that folder and is there a source for eeprom access code (or is that THE best document/source already?) Speaking of your branch of PCBs (of course!) Thank you very much! I have been absent from Lynx land for a while but never abandoned it, of course.
  4. Very nice. That's exactly what I use for the Watara Supervision development as there want even a half decent emulator at the time. Maybe I should aim for Lynx as well for tight tests.
  5. Hi The project is alive but pretty much on hold as main contributors took some time off from it. While there wasnt too much Atari Lynx stuff going on in the meantime we were quite active in general. A boxed release of Assembloids is next on list. 'Lacim's Legacy' is something the whole team looks forward to, so rest assured it will come Eventually
  6. The shorter the time the more shallow the game will (have to) become. While you can set up a puzzle engine rather easily. It is the balancing and testing that really takes (and should!) time to be able to release a stable and proper version in the end. Not to speak of anything more in the adventure/RPG genre. If exclusive titles (and not mere ports) are wanted -and the Lynx can pull off fanatic things when pushed a little- you need rather a year than few weeks. Not full time job on 1 year of course. But people with kids for example had way LESS time during lockdown usually.
  7. In our Bastion demo we use that hardware sprite clipping for the wiping of the credits texts.
  8. It is more interesting for speed rather than space at least the use cases I know of. Not by much though. STY *+4: CMP #23 is not that bad either 🙂
  9. Very nice improvement! :) sprpck is about the only tool that I kept using and it looks like it might stay so.
  10. Nah, I love optimizing things alot In fact, to me that is what most of the fun is about. Also I do not mind people using C or BASIC or whatever if they enjoy THAT more than other options.
  11. I haven't done intensive testing but RLE packed sprites are a bit slower as far as I know, but yes, agreed - it would be a waste NOT to use it. But optimizing it for a few percent while using a c-framework does not really make sense in the end.
  12. For the bitmap gfx in Assembloids I pack the data with an individual algorithm straight into memory. Much higher packrate that simple RLE naturally.
  13. That apply to write as well though and while there is some jitter in the colors it is certainly not 0-15 cycles. But rather the remaining cycles of the interrupted opcode. It would be cool to see your analysis with ROM cart reads in a loop.
  • Create New...