ralphb

Wow, that sucks ... But I'm glad you solved your problem.

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.