Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ilmenit last won the day on August 27 2013

ilmenit had the most liked content!

Community Reputation

697 Excellent


About ilmenit

  • Rank

Recent Profile Visitors

11,656 profile views
  1. Millfork looks very interesting. It seems to be a good solution if you aim for program without dependency on OS, because OS and standard library support for A8 is almost non-existing. Also it's a custom language so you cannot have the same codebase for Atari and Mac/Linux/Window. It also means debugging will be very complicated and Millfork I think still does not generate symbols that can be loaded by Altirra debugger.
  2. Great to read! 🙂 Looking forward for it.
  3. No problem. If you have any further questions, do not hesitate to ask 🙂 Is it for Vaults of Nhyrmeth? Looking forward for progress with this game!
  4. I just checked different configs I use and I never had those: FILES { %O: format = atari; } FORMATS { atari: runad = start, initad = SYSCHKCHNK: __SYSTEM_CHECK__; } Are they needed? Also all SYSCHK* are optional and can be removed - they do some checks if you have enough memory. I'd propose to check if you have enough space before the RMT player. It has some specific requirements: ;* 1. RMT player routine needs 19 itself reserved bytes in zero page (no accessed ;* from any other routines) as well as cca 1KB of memory before the "PLAYER" ;* address for frequency tables and functionary variables. It's: ;* a) from PLAYER-$03c0 to PLAYER for stereo RMTplayer ;* b) from PLAYER-$0320 to PLAYER for mono RMTplayer
  5. It would be the best if you could post minimal code & compiled XEX. If it works with other examples but not in your code, then for sure there is somewhere a bug on your side. The information you posted currently at least for me is not enough to identify the cause of the problem (it can be in the music/sfx player, it can be in addresses (exported or not), it can be in the linked config, it can be in the RMT "features", it can be in the main program code). The best would be the whole build folder for such minimal example.
  6. Thanks for the interest. Orders and order related questions should be sent to our publisher email: zamowienia(at)retronics(dot)eu
  7. Update: on XEGS the game works when the keyboard is connected. We will further investigate the root cause but if anyone can help, greatly appreciated. It seems to be a "common problem" but not well documented e.g.
  8. Yes, you can even find results somewhere in the forum here. The problem with this test is that it's aiming at least 16bit machines (using heavily 16bit data types) and does not reflect properly compiler capabilities for 6502 8bit platform.
  9. Some more info regarding XEGS - we got a machine running for testing and it seems that there is an issue with the currently prepared cartridge. Similar issue was with "Ridiculous Reality" on XEGS. We will investigate it further but it seems that there are some differences in XEGS hardware from 800XE that may prevent the game from working.
  10. Thanks, therefore if it's internally 800XE (and the cartridge slot is the same), the game will work on this hardware.
  11. I'm not sure if the game was tested on XEGS... @michomis - do you have such hardware? If XEGS is compatible with 800XL/XE (PAL or NTSC) or 130XE, then I assume the game should work (it is fully joystick controlled, no keyboard required), but let me get some more info to make sure that the game will work for you. Could anyone point me to description of differences of XEGS and other hardware? Are there some differences that should be taken into consideration when writing software for this platform?
  12. Our publisher asked to pass the information that till 18th of August he will have limited access to computer, which will slow processing of the orders. No worries then if you sent an email, please.
  13. It requires 64K. More memory is recommended (e.g. 130XE or expansion) as it improves gaming experience by allowing more "undo move".
  14. I found some earlier dev version with simpler music and gr.7 galaxy-7.xex
  15. Do you mean to add more colors than 3 + background? Now it's drawing 3 rotating fractals each having 180 fixed points. For more colors we would need more fractals and for speed a custom pixel drawing procedure (now it is using slow system procedure for drawing). It would be then bigger and wouldn't fit in 256 bytes and also resolution would be worse. I had implementation first in gr.7 and the pixels were too big. Maybe I'll check it having some time.
  • Create New...