ralphb

I pushed a change where I pad all bank suffixes with 0 to the same length. Please get files xas99.py and xcommon.py to update (or PeteE's version).

Good to know, I'll keep an eye out for Mouser.

Hi Steve, thanks for the ping, but unfortunately, there are still no STM32F746s available ... Winsource wants $270 per part now. 😐 Switching power regulators I can use are also rare. But there's one hope: The regulator I used for the last board is still available in quantities at Digikey, so maybe I can keep that. The project is not dead, but it's not the only one right now.

I've pushed version 3.5.2 to GitHub. The new plugin can be found here. I've also fixed some bugs in xga99. The most embarrassing one was sign error when multiplying or dividing in an expression. Related, using negative values now yields the correct number of bits depending on whether the value occurs in a byte or word context. Finally, I may have corrected a possible label mishandling, but I'm no longer sure. I've also harmonized error reporting, so please watch for any unwanted changes. Again. I'll make a new release some time later if there are no errors.

I've pushed the newest version of all tools to GitHub. Please note that I pulled out common functions into xcommon.py, so if you download just a single tool file, you will also need xcommon. For a description of changes, please refer to MANUAL.diff. Hopefully it is clear from context to which tools each change applies. The new IDEA plugin with register alias support is here. It wasn't that easy to implement, and I hope performance didn't suffer. I'll make a new release some time later if there are no errors.

Rasmus, I've reviewed your post, and I've come up with three possible improvements: If I added registers to the list of suggestions (somewhat like you did), you'd always have 16 additional entries that you'd never select, but which are there to prevent a match with a variable entry. I find that ugly. Another improvement would be to match only prefixes, so if you type "r0", the entry "random_entry_0" would not be matched (but "r0_initial_value" would). I'm not sure if this is possible, but I'll ask. Another option I see is to introduce a new directive REQU that is only used for register aliases. As a consequence, random variables will no longer be offered. I currently prefer option 3, but what do others think? Any other suggestion? EDIT: Option 4: Just type 'r0 <space><enter>", but again this is just a hack.

Beery, I must admin that I still haven't got around to play with my Geneve, so I need some time to understand your proposal. In the context of xas99, I assume you'd like that xas99 provides assembled binaries as one of those types if a new profile parameter, say -P, is given? But what is the file format for the PSAVE'ed files? Is there more to it that just the loading address (I would assume so)?

Oh, now I see it -- it's kind of a Windows problem ... ? In addition to kl1 ... kl9, xas99 also creates an another file kl: (ASCII '9' + 1), which is invalid on Windows filesystems (macOS as well?). The reason for that many files is that the SAVEs SAVE >2000, SAVE >A000, are redundant, or rather duplicative. The first SAVE will include the entire range >2000->FFFF, and the second one >A000->FFFF again. For the first SAVE, you'll want to put an upper bound, e.g., >4000, and then the second one is OK, resulting in 4-5 files (because of the headers).

Hmm, I cannot reproduce this right now. Where file did you put the SAVEs in (Source/knightlore.a99?) and how do you assemble the file (-R -i -q -L x)? But it also occurred to me that I should make paths separator-agnostic (/ vs \). Another thing was that I had to change the capitalization of one path, but the effort to make Linux open files with case-insensitive paths would be quite high.

OK, that looks weird, but I'll fix that with the next push. Right now I'm still making the valid symbol check actually accurate, especially for strict mode.

Sorry, I don't know what I was testing yesterday, but there IS a problem, not just with the parser, but also ambiguous statements: ; modifiers vs labels a#1 data 1 b#2 data 2 x#3 data 3 clr @a#1 movb b#9, @b#2 jmp x#3 data a#1, b#2 - 2, x#3 - 4 end The last 3 statements have a syntax error. Also note that the jmp statement is ambiguous: jump to label "3", or "x#3"? I'd rather not change the modifier char # now, since that might break quite a few programs (including mine). Could you think of a different way to express those labels? Unicode ❤️ is possible! ?

Not yet. Could you please test it first for a while? I want to make sure that it doesn't interfere with modifiers, even though values (your a#1) and addresses (w#1) occupy different domains. Meaning that both @w#1 and DATA w#1 are illegal expressions. EDIT: But it's still possible that the parser will confuse the two. Oh, my bad, I didn't read your question properly. The only solution right now is to reorder the SAVE directives, as the first SAVE range will become the first file. I admit that I had to test that myself to see if it works. Would that work for you, or do you prefer a command line option? Using SAVEs has the advantage that it's a property of the program, so this information won't get lost. Of course, I could also add a new directive like ENTR, but that would only make sense for images and maybe object code (as alternative for END symbol).

Thanks for your reports, Rasmus! I've released a new version of xas99 that will fix the pragma parsing in your second example. For the first example, using SFIRST etc. won't work with non-contiguous addresses. But take for example this program: aorg >2000 data 1,1,1,1 aorg >a000 data 2,2,2,2 aorg >c000 data 3,3,3,3 If you just assemble with -i and nothing else, you'll get those files: cassiopeia ~/ti99/xdt99/test > xas -i splimg.asm cassiopeia ~/ti99/xdt99/test > ll *.img -rw-rw---- 1 ralph ralph 14 Jun 22 20:28 splimg.img -rw-rw---- 1 ralph ralph 14 Jun 22 20:28 splimh.img -rw-rw---- 1 ralph ralph 14 Jun 22 20:28 splimi.img cassiopeia ~/ti99/xdt99/test > hd splimg.img 00000000 ff ff 00 0e 20 00 00 01 00 01 00 01 00 01 |.... .........| 0000000e cassiopeia ~/ti99/xdt99/test > hd splimh.img 00000000 ff ff 00 0e a0 00 00 02 00 02 00 02 00 02 |..............| 0000000e cassiopeia ~/ti99/xdt99/test > hd splimi.img 00000000 00 00 00 0e c0 00 00 03 00 03 00 03 00 03 |..............| 0000000e You could also add some SAVE directives save >2000,>4000 save >a000,>e000 but that would only join the 2nd and 3rd chunk: -rw-rw---- 1 ralph ralph 14 Jun 22 20:31 splimg.img -rw-rw---- 1 ralph ralph 8192 Jun 22 20:31 splimh.img -rw-rw---- 1 ralph ralph 20 Jun 22 20:31 splimi.img (You're still seeing three files, as the second SAVE results in binary of 8192 + 6 bytes, which doesn't fit into one chunk.) Would that work for you, or are you looking for something else? EDIT: Oh, and I also removed # from the list of invalid chars in labels, since you seem to be using those. I think there is no danger of interpreting those #s in labels are w#/b#/s#/x#.

Oh, I didn't notice that (I guess I don't have matching label names in my code). This happens because I added labels to the register rule. I'll see if I can give higher precedence to registers than to labels.

(Un)fortunately none of those. ? I took a break, and also have to be cautions about soldering new boards, as part available has deteriorated even more. The power regulator, for example, shows an availability date of 2023 at Digikey. ? That means working on software only for quite a while ... Also got a PS5 a while ago, so ... patience. ???

I've release new versions of xdm99, xvm99 and xhm99 with support for archives, either on disk or stand-alone. You can add, extract, delete, rename, or protect files in archives, and for archives on disks you can also add files from and extract files to disk. Here is a summary of the new functionality.

Willsy, you figured out a lot yourself, that's great! You're right that xas99 allows at most one space between things in the operands field, because as the original E/A, xas99 allows "free floating" comments, like this: LI R0, VALUE + 2 * THIS IS THE INITIAL BOUNDARY Should R0 be assigned to VALUE+2 or (VALUE+2)*THIS? That's why I decided that two or more spaces introduce the comment field to avoid ambiguity. And while that restriction serves my original writing style, I finally decided to introduce a more general way of writing assembly. In relaxed syntax you can use any number of spaces, but to prevent ambiguity, you need to separate comments with ;. And since you introduce most comments with ; you can and should relaxed mode. I think you still get errors with -r because some comments start with \. But since \ is quite rare, maybe you can just replace all \ by ; ? For the alias registers, I do not really have a solution but to disable those warnings with --quiet-usage. It seems that assembly-wise you know what you're doing, so you won't need those warnings anyway. ? Finally, thanks for the code, I'll add that to xas99. I didn't count warnings so far as I didn't want to draw too much attention to them. Warnings are meant as programming aid, not as requests for improvement.

The order of assembly is given by your build.asm. The -I just says where to look for files you name in your COPY statements. So for, say, 1-00-Header.asm, the assembler will check if the file is in bank0/, which it isn't, then check in bank1/, where it is located, and then use that file. This only works because -- I assume -- you also prefix the bank as first char in your filename. This -I wouldn't work if you had identical filenames in all of bank0/, bank1/, ... So -I isn't crucial at all, it just may save you some effort in creating your build.asm. You don't have to use it, especially since you already have a working build.asm file. Yes, but to qualify that I'd have to know what you're looking for exactly. ? A ROM cartridge with 2 banks, for example, is just a contiguous 16K binary file. Any assembler can produce this. You just have to be careful that you cannot call directly from the first 8K of the file into the second 8K, and vice versa. Similarly, you cannot use any data from the other 8K chunk. Now xas99 merely checks that you don't so accidentally. It can also generate each bank separately, or all joined together. But you still have to program the actual bank switch yourself.

I guess that your COPY statements in your build.asm start right in the first column. You need spaces before COPY, though, or COPY is seen as label, and the file name is the mnemonic (even though in the example above, xas99 only sees 0 as mnemonic, which isn't the first char -- I'll have to check what's happening). So just insert some spaces before all COPYs in all lines. Now, as general strategy your approach is fine. You can save some typing by using -I (that's capital i), where you then list all folders where the files you want to COPY are. In your case that would probably be -I bank0,bank1,bank2,bank3,... By supplying -I ... you can drop all bank0/ (and bank1/ ...) prefixes from your COPY paths. Finally, is tf.obj is the final output of the assembly, you need to prefix it with -o on the command line to tell xas99 that this is the output. Otherwise, xas99 will try to assembly tf.obj, which will not work. Please let me know if that works.

The FlashROM is exactly what you're looking for. It uses an ATmega 8515 (because of its many pins) and runs at 8 MHz (IIRC). There's also a SRAM chip and some standard logic chips for bank switching and signal control as well as a SD card slot. Or are you asking for a bare MCU solution? It's possible to get rid of the three signal controllers and the SRAM if the MCU is serving the bus directly (instead of the SRAM), but then you'd need more pins than are currently available AFAIK.

@PeteE, I've implemented parentheses in addresses, but those are still not allowed in the index. I've also created a new release for that change, even though you just might want to get the updated xas99.py.

I'll see for the next release if something like this is possible in xas99. Fixing the IDEA plugin will be easier than that.

You never disappoint me! ? In that case, though, I disallowed parentheses in @addresses because that could be mistaken for an indexed address. In fact, if you drop the + sign, you got an indexed address. xas99 also throws an error for that line. Allowing address expressions with parentheses and indexes (which again might contain parentheses) will be rather difficult to parse, especially as I'm not using a grammar in xas99 as in the plugin. I'll think about this some more, but sorry, no quick fix.

I pushed a new version of the plugin with the fix for the local labels and the register aliases (same link). I even managed to retain the register coloring for the aliases. Please let me know if anything else is amiss.

Thanks for the immediate feedback. ? For the unused symbols used as registers, I thought that this might be OK, but now that I think about it I'll check if I can add registers to "label uses" without ruining the performance. I also added the duplicate labels, but forgot about local labels. ?