Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ralphb last won the day on May 2 2017

ralphb had the most liked content!

Community Reputation

845 Excellent

About ralphb

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • Location
  • Interests
    Developers, developers, developers, developers

Recent Profile Visitors

7,404 profile views
  1. There was some discussion a while ago about the FinalGROM overwriting some bytes in the RAM area when writing back to the SD card. The solution was first to change the addresses of those bytes, but later it occurred to me that I just needed to read those bytes first. To be honest, I'll have to recheck which version I'm shipping now with the FinalGROM. I may also have to re-create the Minimem image. BTW, this thread is for the older FlashROM. For the FinalGROM, see here.
  2. Since comments about the FinalGROM keep on ending up in the FlashROM thread, I'm bumping this thread to make it more visible for people looking for the FinalGROM.
  3. I've rolled all my previous changes up into a new release 2.0.1 (grab the xdt99.2.0.1 archives, not the source ones). This will be the last Python 2.x-only release. The next release will by Python 2.x and 3 enabled, as I'm starting to prefer Python 3, and Python 2 support will end this year.
  4. My FinalGROM 99 is the successor to the FlashROM 99. The FinalGROM runs ROM, GROM and mixed ROM/GROM cartridges, and features 1 MB of RAM for images, among other improvements. You can get it from me via email, from Arcadeshopper (who sells my carts), or various other sellers offering clones of unknown quality throughout the web. The demo you saw could only handle single-bank GROM images, at least at the time. If you don't need an SD card for supplying images, there's also the very capable UberGROM (also at Arcadeshopper).
  5. Indeed. The value of s#X is the difference of X and Y, where Y is the next label following X. So this works for . greet: text 'HELLO!' byebye: text 'GOOD BYE' textend . where s#greet is @byebye - @greet and s#byebye is @textend - @byebye. If textend were missing, s#byebye would not yield the correct result, or throw an error. Also note that the number of statements/directives following the start label is irrelevant: . aa: data 1 byte 1, 1 text 'XX' bb: text '....' . In this example, s#aa yields 6. There's one special case for an odd number of bytes: . greet: text 'HELLO' weight: data 69 . Here, the difference between weight and greet is 6 bytes, because weight is even-aligned. xas99 keeps track of this, so in this case s#greet actually yields 5. Again, this applies to all kind of statements, not just TEXT. s# will not include the padding byte. When using s#, you need to make sure that there's a label after the thing you want to size. In general, this happens naturally, with the possible exception of the last element in a source file.
  6. An update for xas99, xga99, xda99, and xdg99. For xas99, there is now a size modifier s# that denotes the "size" of the symbol attached to, where size is the distance from the symbol to the syntactically subsequent symbol. Padding bytes are observed. xga99 now has even more similarity to xas99, but for that I needed to rename the syntax option -s to -y. Please don't hate me. And xda99 and xdg99 have now options to format the disassembly, which by default is now lower-case. There's also a -k option to skip bytes of the disassemblee.
  7. Another update for xas99 fixes bugs from my own list and some public ones on GitHub. Also, auto-generated constants now allow for letters, like cb r0, b#E ; compares to 'E' I'll add a few constants like 'enter', 'erase' etc. later. For xga99, I now have functional feature parity with xas99. In particular, xga99 now supports local labels and text generation. Modifiers make no sense for xga99, since GPL supports immediate values in almost all operand positions, and there is no LSB of a register. Cross-GROM access is also not a problem. And finally, I did fixes and feature requests for xdm99. No big changes, but you can now rename a disk with -n, and also specify a target directory with -o.
  8. Oh, I hadn't thought about this case ... But I guess keeping just the buffers equal to a CALL FILES(1) would be safe? Anyway, I'll put the code back in, also in light of what Matt said ...
  9. It seems that I was too hasty: Based on my tests, it appears that those buffers are used only by the TIFC, and not at all by BASIC. This implies that for SDD99, I need neither buffers nor CALL FILES (except for compatibility, but FILES/>16 will just be a NOP).
  10. Matt, I have not forgotten about this request. But to be honest, I'm not 100 percent excited about it. Would it work for you, as some sort of compromise, to keep the labels flush to the left, but indent the instructions to the right? Similar effect, but more conventional parsing.
  11. Thanks for all the info. I knew about the 518 bytes part (although I couldn't remember the number), but not the 6 bytes before the whole thing. I wrote my own code now, and in fact I found an earlier attempt to convert the TIFC functions to SDD99 again. The TIFC code isn't actually complicated at all, with the exception of their function to read and write VDP memory. The linked DSR thing was once and for all cleared up by Lee. And yes, I do have a DSR for which I need CALL FILES, but I cannot simply call another DSR with DSRLNK as a shortcut.
  12. Lee, I wrote some code for updating the file buffers at the top of the VDP RAM that I erroneously called PABs. But now where are these "linked PABs" of BASIC that >833C should point to? That address contains 0 after entering BASIC. EDIT: Is the OPEN command in the DSR handling this? I also had another look at the TIFC, and for that device at least >16 and FILES are identical in function.
  13. Thanks Fred, that looks very much like the TIFC disassembly from Thierry. I already have this, but I'm too obtuse/impatient to understand this. But thanks for removing the fat from that code, I may have to make use of it.
  14. Sorry, I didn't know there's much of a difference between both functions. These documents are exactly what I've been missing! I think I should be able to write something, although it's not 100 percent clear to me yet where to draw the boundary between FILES and >16.
  • Create New...