ralphb

I'm talking about the main programs xas99.py, xga99.py and so on, which have this hash-bang-line at the top of the file to tell Linux (and I think macOS) how they are executed. Two weeks ago I was helping Rich with the installation of xdt99, and was very surprised when none of the tools could be started. A new window opened and immediately closed again. Only when we removed the first line was it working. Not sure what Rich is using, but I think it was also Windows 10. 🤷‍♂️

I've just published a new release with the latest changes. Windows users should download the new archive xdt99-X.Y.Z-Windows.zip on the Release page. As Rich and I discovered in our Zoom call, Windows suddenly starts to interpret the #! line at the start of the file, but doesn't know what env is.

Very glad to hear that, Rich! And it was a fairly small change to make it work for you.

Hello Rich, I've added the strict syntax option, and also the extra symbols you listed (some were already included). Could you please try the attached version of xga99.py? To assemble your srxb*.txt files, you'll need to supply the -s (for strict syntax) and -R (for Ryte Data symbols) options: xga99.py -s -R srxbN.txt where N is the GROM number. Using -s and -R, you should not have to modify your sources, and you won't need Lucien's tool either. If everything is OK, I'll release a new version. In my call with Rich, I realized that Windows is trying to be clever now by interpreting the #! line at the start of each tool source file. This unfortunately means that I know have to release a special Windows version. EDIT: To clarify, please replace the the xga99.py file in your C:\xdt99\xdt99 directory with the attached xga99.py. xga99.py

xga99 has two directives to specify where the code should be places: GROM and AORG. GROM <n> is for the GROM and <n> can be a number 0-7 or address >0000, >2000, ..., >e000. AORG is the the offset relative to that GROM, You only need GROM once per GROM, and then can use AORG to jump around. Maybe you need to adjust these, but you don't have to stick everything into one file. Also note that xga99 produces binaries (which you can use in Classic99 directly), not object code, so the sizes should be different. Unfortunately, I'm very busy this weekend, but I hope to make the changes by the end of Easter.

The problem with asterisk = beginning of comment is that * is also multiplication, so some sort of disambiguation has to be done. I'll try to make it more standards compliant. The thing with the spaces is my own doing, since I like to sprinkle in some spaces to make everything more readable (IMHO). My assembler also has a strict mode that uses the original parsing of E/A so that any space in the operand field introduces the comment field. For some reason, though, I never implemented the strict mode for xga99. I'll try to add it, though.

Are you talking about assembling srxb6.txt and the error message about the END statement? That's because of a missing ; before the first * in line 1938. xga99 only recognizes * comments if the asterisk is in the first row, like with E/A.

For the other error, could it be that some symbols are missing? I've assembled your srxb6 file, and have unknown symbols CFI, LINK, RETURN, ACTION, and BADTON. Also, a few lines where you need to add one space before the comments. Could you try lucien2's tool a try? That should introduce the missing symbols, and also fix the comments.

Rich, the second error is in line 1938, where you have a comment, but the * is not at the beginning of the line. You'll need to replace the * by ; (or put a ; in front of it). * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE EXECUTE * *********************************************************** * AORG >8300 * CPUPGM DATA >8302 * CPUPGM DATA >8302 First address. * DATA >0420 * BLWP @>834A Switch contex * DATA >834A * FAC not used * DATA >04E0 * CLR @>837C Clear for GPL * DATA >837C * * DATA >045B * RT Return to GPL. * * END * <<<<<<<<< ***********************************************************

Thanks for letting me know. There's something wrong with the parsing, hence the error with the END directive. Really strange, but I'm debugging this.

Based on your description, I probably had an error similar to yours at some point when I built my batches of FinalGROM. If the LED doesn't blink, it's not a "regular" error, like file not found. The error codes returned by the JTAG library are also translated to LED signals. I assume the working and non-working boards have the same AVR software? If so, I would check if you have bad solder somewhere so that some signals are not going through. Also, did you set the AVR fuses correctly? How long did you wait for completion?

Hello Rich, I think the errors above are for operand order. Instead of CLOG >08,V@FLG(@PABPTR) write CLOG V@FLG(@PABPTR),>08 Unfortunately, that won't be fixed by lucien2's script, I think. Maybe I need to enhance xga99 so that it can deal with revere operand order for some instructions? Please allow some time for me to change it. But I'm not sure what is wrong with the END. Could you share the file with me? I suspect that there are some funny control characters in the file that confuse xga99.

We'll figure it out together tomorrow, Rich! It's possible that something changed after I wrote the documentation.

PM sent.

True, but having a cross-platform GUI does not leave that many options. But there seems to be an experimental Python to WASM compiler ... Seems worth checking out.

Hello Rich, xga99 supports the Ryte Data GPL Assembler syntax, so the opcodes should work as they are in your code. Some directives might be a little different, but they are described in the MANUAL.md. As it is now, the manual is more manual than reference, so you cannot look things up. But if you search the file or web page, you may quickly find what you're looking for. We could set up Zoom or Teams call this Sunday, if you like. What time zone are you in?

Thanks Steve, chue, and TheMole for helping. (For some reason, I cannot select the Thanks icon anymore.) My recommendations to follow would be: Follow the doc/WINDOWS.md file (online version), which talks about installing and setting up the Windows environment. I admit that these steps are quite annoying, but the command line isn't really a first-class citizen in Windows. Follow the Tutorial in the doc/MANUAL.md (online version). It talks mostly about assembly, but also uses the other tools. I highly recommend to follow all the steps to familiarize yourself with the command line. Follow the xga99 section of the doc/MANUAL.md (online version). You'll need to invest a bit of time to start using xdt99. If you decide to go this route, you can of course always ask for help here.

You're welcome. 😄 That was for Windows 7, though, so I hope Microsoft didn't mess it up in the mean time.

I've pushed a fix for xda99, and also made a new release that collects all of the changes since March.

Oops, you're right, of course, I simply cannot count! I'll make a fix that changes the value to 8. Thanks for pointing it out.

For legacy sources that won't assemble as-is, you can use the strict syntax option -s to restore the original E/A syntax. Regarding the disassembler, negative numbers are displayed as positive two's-complement, so -1 is displayed as >FF or >FFFF, depending on the size of the field. For TB, -11 and >1F are not equal (-11 would display as >F5), though, so there might be a bug if those are actual numbers. Note that the value field of SBO, SBZ, TB is 8 bit wide, so opcbitmask[12] == 8 should be correct, or did I misunderstand you?

You COPY'ed file BITMAP.asm contains an invalid Unicode char in the word "più": UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf9 in position 5103: invalid start byte (not shown without removing one except clause, though) You probably used a different encoding. So, either use the UTF-8 encoding or don't use non-ASCII chars. I don't know why the behavior is different for earlier Python versions, but my guess is that they removed some ambiguity about the encoding for text mode open().

Would it be possible for you to share the code in question? Either post a link, or mail to r@ti99.pro.

This is quite strange. Could you please try something? In file xas99.py, please comment out lines 859, 861 and 862 (should be try/except/raise) and try again on Linux. What error do you get now?

No, I'm using an F7, mostly because of its FMC and SDMMC. There's also no way I'm going to learn another SDK right now. 🙃 I'm planning to use a TI voltage regulator, though -- assuming that they'll become available again one day. I also looked at some Wifi connectivity chips by TI, but nothing beats ESP in terms of available information, tools, and community.