Jump to content

ralphb

Members
  • Content Count

    767
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by ralphb

  1. It should be possible, if you add that mode to the CPLD firmware. I currently have more important things to do, however, and I also cannot easily build CPLD firmwares at the moment.
  2. For the record, I no longer have the original version of the CPLD firmware. I have tried to reconstruct it, but it's untested. You can give it a try if you want. There is a small chance that you'll brick your FinalGROM, though. update_1.0_recreated.pld
  3. Oh dear, oh dear, it has come to my attention (thanks, @HOME AUTOMATION) that the Mini Memory image fgminimem-2.zip with SAVE option published here doesn't work as intended. So I proudly present fgminimem-3.zip , which has now been confirmed to work (thanks, @HOME AUTOMATION)! To use it, you might have to revert the CPLD firmware contained in fgminimem-2 (I didn't test it); if so, use the latest version published on the homepage instead. If you don't plan to use Minimem with SAVE feature, you don't have to change anything at all.
  4. That probably wouldn't help, since both lines are equivalent. I'm hedging my statement since the preprocesser happens before label conversion, so I don't actually know. But I wanted to rewrite the macro handling anyway.
  5. The problem is that the preprocessor handles everything with a '.' before the assembly passes start. So the labels of all the the macro instantiation would appear before source in the list file. Also, when writing something like this, .defm m !a data 1 .endm x .m you'd have a label conflict. But I'm in the process of rewriting this. You'll have one comment line with the "outer" label, and then the instantiation with the "inner" labels. That'll also tell you which macro you invoked.
  6. ralphb

    SDD 99

    The questions is, "When to get one?" 🙂 I'll let you know if there is something to report.
  7. Hmm, that sounds a lot like a SAMS! 🙂 I think this is difficult to achieve. The problem is that you'd need to two additional registers of 7 bits each, and there may not be enough resources in the CPLD left. Also, I noticed that the CPLD IDE (which also does the synthesis) no longer works on my current Linux version, so future modifications really need some effort (like a VM).
  8. I think ExtBASIC was just an example. But obviously when you add RAM/GRAM to it, you need to adapt the bank switching as well! I assumed he wrote a cart from scratch, and there I don't see the difference.
  9. That's actual news to me! But then, I don't know any "original" carts with more than 8K ROM files. For the FlashROM and FinalGROM, all files have to be uninverted.
  10. That's clever, but also a bit dubious. You'll have to reapply your change to every release xas99, or stay at this release forever (which would mean no bug fixes and no enhancements). The biggest disadvantage, however, is that only you will be able to assemble your source files. Maybe this is fine for you. If not, you could supply a "patch" (not sure about the availability on Windows) to introduce your ~ into current versions of xas99. Then other users could apply this patch to their xas99 versions in order to assemble fbForth. EDIT: BTW, I really liked your earlier definition, which you deemed ugly. For me, beauty is achieving our complicated goals with the limited means we have at our disposals, so your earlier macro qualifies as elegant. 🙂
  11. What HOME AUTOMATION said was basically correct. You cannot switch to RAM mode while you're running. What you could do is reloading the same image with RAM mode enabled (induces a small delay, also state might be lost). What is the problem of having RAM right from the start?
  12. Yes, I also immediately thought of macros. The problem, though, is that macros are "semantic", not "syntactic", and there is also no loop construct available. But I wanted to improve the macro system anyway (not sure when, though).
  13. Sorry, I had missed that (also ignored the comment saying so). I would suggest the following: Send me the entire modified code (here or PM), and I'll try to make it work with XORG. You did everything right, but maybe a combination of things breaks the program.
  14. It's only a guess, but I think the AORG followed immediately by BANK could be confusing the move. I assume you didn't include to code to copy the XORG range? Also, how do you know where the end of the XORG range is? I'd attach labels to XORG and AORG, and use those labels as boundaries for the code to copy.
  15. Without knowing your code, I can only offer some guesses here. Did you copy the XORG area to RAM? XORG just influences the address pointer, but it doesn't move the range to RAM. The pattern is li r0, <target> li r1, xorg_start li r2, xorg_end - xorg_start ! movb *r1+, *r0+ dec r2 jne -! ... xorg_start xorg <target> ... xorg_end aorg ... ; normal program continues Inside the XORG range, any addresses outside the range will remain fixed (as you'd expect). Maybe something goes wrong with your DATA statements with the expressions?
  16. I must admit that my mental model of bank switching was a cartridge, with a simple switcheroo in ROM. Also, x# should help the programmer, not frustrate him or her. I'll also try to merge your patch, although I would change the command line interface slightly. 👍
  17. Congratulations! Patching the DORG should not be necessary, though (I mean, it probably is, but shouldn't). I'll have a look at the default bank handling of the ORGs -- I hope I remember everything I promised. 🙂
  18. I see. If that is all, you'd need to prepend all references in bank 2 to bank 0 with x# -- or disable the cross-bank check. I'll make that an option. But how do you know if an address points to bank 0, 1, 2, ..., or n? The final program doesn't contain labels, just addresses. In your example, it just seems like a convention that the linked list is in bank 2, and interpreters in bank 0.
  19. The labels you put in shared segments (BANK ALL) are accessible in all banks. And if you know what you're doing, you can do cross-bank accesses by prefixing "x#" to the symbol in question. This shows some valid use of x#: https://github.com/endlos99/xdt99/blob/master/test/asm/asshbankx.asm BTW, as all ORGs, AORG + BANK n keeps track of the last used address for that bank and AORG, so in the example, bank 0 and bank 1 have the same addresses. As a rule of thumb: AORG should be followed by BANK, a BANK does not need a previous AORG if that bank has already been written to. In not entirely sure about your use case: Why would you access a symbol of a different bank, unless that symbol has the same value in all banks? Could you perhaps give a small example?
  20. I second PeteE's suggestion, although the other way also works. The problem here is that AORG will not keep the previous bank, but resets it to "non-banked program", which results in a wonky state for banked programs. Thus, you need a BANK after each AORG (the same could probably be said for other *ORGs). I guess it'll be OK to keep the previous bank, maybe also issue a warning. My TODO list keeps on growing ... 🙂
  21. The problem is the ''' in the expression. According to E/A manual, page 51, to include a quote in a string you need to double it. Thus, your subexpression should be ''''. Yours is like an undelimited string. Regarding EQUs, if they all have the same value, you could replace them with the undocumented WEQU (weak EQU) instead, which allows redefinition with the same value. But I actually plan to change that dehavior: EQU can be redefined with the same value, and WEQU can be redefined with a different value, but only for one value. So I would recommend to comment out extra EQUs, or split your file into multiple files for each bank. In the latter case, you have to extract the common symbols (EQUs) into a common file you can COPY into each bank file. Also, -q (for older versions, -w) turns off all warnings. On my TODO list is the introduction of classes, so you could disable only certain kinds of warnings. Could you please give an example instruction that triggered the "... use as address" warning? Using registers different from n and Rn is a bit unusual, but I see why you might want to do that. (I've just seen that PeteE also answered some of these, thanks!)
  22. Yeah, that's what I wanted to say. 🙂 Silent errors are quite unlikely. For #, you can define such a label, but if you use it in any instance you would use a label in, xas99 issues a syntax error. So you'd need to combine the use # with forgetting an @ to accidentally write mov b#1, r0, which would put the wrong value in r0, but only if you put the # in the correct 2nd position. Using ! in a label is safe unless the label starts with !, in which case the label will be local. This isn't a problem per se, but backward jumps would require a minus sign before the label. And I hope nobody uses +-*/ in a label, or @. EDIT: I think I'll relax this validity check when I find some time.
  23. Here is a DS/DD disk image with all individual P system disks combined. If your controller can handle DS/DD, the disk makes it a lot easier to work with the P system. Thanks to Anders for helping me create this disk! pcode.dsk
  24. Actually, I included $ in the list of forbidden symbols because $ has a special meaning, but of course you can still use it with other chars as label. If you open xas99.py in an editor, search for "def valid", and in the return statement (should be line 846) just remove the $ sign from the last expression. You might also remove other symbols, but since they all have special meaning in xas99, labels containing them might or might not work.
  25. Alas, it doesn't work for Parser or other legacy programs. What dumping does is save the image in memory back to SD card. Now, for ROM and GROM carts, this doesn't do anything, because you cannot modify the image in memory, as ROM and GROM are read-only. But if you active RAM and/or GRAM mode, you can modify the image (i.e., allocate variables inside the image, and then update them) and save this back to SD card. For example, AORG >6000 DATA >AA01, 0, 0, ... ; header SCORE: DATA 0 HIGHSCORE: DATA 0 START: CLR @SCORE ... HIT: INC @SCORE ... As a ROM cart, this "game" doesn't work, since SCORE and HIGHSCORE are in ROM and cannot be modified. If you activate RAM mode, however, you can modify SCORE and HIGHSCORE, and the dump function would write the changed SCORE and HIGHSCORE along with the rest of the image back to SD card. Hence, the progress is saved. Parsec, on the other hand, allocated variable in scratchpad RAM, which is not contained in the image, so you cannot save that by dumping Parsec.
×
×
  • Create New...