xdt99: New TI 99 cross-development tools available

[RXB]

1 minute ago, lucien2 said:

The .gpl files are supposed to be the converted source files, ready to be assembled.

Maybe the script is not working well with the RXB 2024 source files.

Could you send the DV80 source files of RXB 2024C so I can try myself?

 

Sure it is mostly finished.

 

The DV80 files are in RXB GPL GROM

The DOS TEXT files are in RXB GPL SOURCE TEXT

 

RXB 2024C.zip

[lucien2]

OK: source files converted.

"srxb7" is the only file that has an error: "GETSPACE" is not defined.

 

Unfortunately, all your nice formatting is lost during the conversion process.

rxb 2024C xdt.zip

[RXB]

4 minutes ago, lucien2 said:

OK: source files converted.

"srxb7" is the only file that has an error: "GETSPACE" is not defined.

 

Unfortunately, all your nice formatting is lost during the conversion process.

rxb 2024C xdt.zip 213.67 kB · 0 downloads

Yea here is the PREDEFINED SYMBOLS for Ryte Data GPL Assembler.

********************************************************************************
PREDEFINED SYMBOLS
********************************************************************************
 
Symbol Table #4 (Def,alpha)
 
0034 ACCTON    835C ARG       0032 ATN       0036 BADTON    003B BITREV
0012 CFI       0014 CNS       002C COS       0010 CSN       8372 DATSTK
0001 DIVZER    0003 ERRIOV    0006 ERRLOG    0005 ERRNIP    0002 ERRSNN
0004 ERRSQR    0028 EXP       834A FAC       0006 FADD      000A FCOMP
0009 FDIV      0008 FMUL      836C FPERAD    0007 FSUB      0038 GETSPACE
0022 INT       0010 LINK      0018 LOCASE    002A LOG       8370 MEMSIZ
003D NAMLNK    8300 PAD       0024 PWR       0012 RETURN    000B SADD
000F SCOMP     000E SDIV      8375 SGN       002E SIN       000D SMUL
8400 SOUND     0026 SQR       000C SSUB      837C STATUS    0016 STCASE
8373 SUBSTK    0030 TAN       0007 TRIGER    004A UPCASE    836E VSPTR
0001 WRNOV     837F XPT       837E YPT

Can you imagine if that is the standard in C or other languages with no format settings.

It would be impossible to debug or to even write the language.

 

So I am going to have to stick with notepad and txt files as at least it is readable.

Thanks for your help.

[ralphb]

21 hours ago, RXB said:

Does not fix srxb6.txt that crashes at END and I guess ralph is working on that one.

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.

[RXB]

1 hour ago, ralphb said:

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.

Hmm Ryte Data GPL Assembler did not care if the it was first one as * asterisk is the comment character just like ! or REM is for XB.

Exactly the same as the original TI GPL Assembler for the 990 and the GPL Code for XB version 110 and TI GPL Manual and GPL Device Service Manual.

 

Rather oddball is  ; semicolon being used as comment symbol for GPL Source, that must come from something like Python or C or another language.

I really like your GPL Assembler except for the strange changes like 2 spaces after a command or using a ; is just so weird since I have been writing 

GPL for over 35 years now.

 

Can you think of a EA or GPL command that would begin with *something?

Commands like CLR  *R8 or CLR *>8300 so why would it matter if the second character is a * as it would not be valid as any command and only a comment!

Edited March 20 by RXB
missing text

[Gary from OPA]

17 minutes ago, RXB said:

Hmm Ryte Data GPL Assembler did not care if the it was first one as * asterisk is the comment character just like ! or REM is for XB.

Exactly the same as the original TI GPL Assembler for the 990 and the GPL Code for XB version 110 and TI GPL Manual and GPL Device Service Manual.

 

Rather oddball is  ; semicolon being used as comment symbol for GPL Source, that must come from something like Python or C or another language.

I really like your GPL Assembler except for the strange changes like 2 spaces after a command or using a ; is just so weird since I have been writing 

GPL for over 35 years now.

 

Can you think of a EA or GPL command that would begin with *something?

Commands like CLR  *R8 or CLR *>8300 so why would it matter if the second character is a * as it would not be valid as any command and only a comment!

too much white space before the *

 

***********************************************************
* 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                            *
***********************************************************
* CALL EXE(address[,...])       BL @address               *
***********************************************************

so its trying to figure out what the * is doing, it has to be the first character or there has to be command in front to be assembled. a indented * doesn't work.

 

i been looking at this recently myself, as I have my SOB source code and my Pop-Cart source code, and I will to be able to assembled it both on my PC and also on real hardware using the same source files, so its a real pain in the ass since its not 100% the same. -- for now, I might stay just using my real ti99 setup, since i got it working again, all tho need to fix bugs on it as well it seems. oh'well. us GPL programmers are rare.

[RXB]

Yea you would think sticking to the the original TI standards for GPL would be pretty set in stone as TI invented GPL!

Oh and the EA format too!

Edited March 20 by RXB
comment added

[ralphb]

58 minutes ago, RXB said:

Yea you would think sticking to the the original TI standards for GPL would be pretty set in stone as TI invented GPL!

Oh and the EA format too!

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.

[RXB]

On 3/20/2024 at 11:31 AM, ralphb said:

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.

So is the format thing fixed or am I forced to use this secondary tool to use your GPL Assembly?

I am very impressed with the insane speed and very effective result of your version of GPL Assembly.

But the Tool from Lucien2 makes my GPL code almost impossible to read and edit.

 

Any progress is making it more standardized?

[RXB]

OK now I have another problem the xga99 Assembly creates Binary files but they are not the same size as the files that the Ryte Data GPL Assembler Object files in size?

In my Source Code I have AORG >1FE0 which should be jumping forward to >5FE0 from that location forward and seems to be ignore by the Binary code generated by XGA99?

 

Which explains why the size is just wrong. Also why every time I try to make the RXB module it shows huge gaps in wrong locations and just wrong?

 

Should I assemble RXB in one huge Source file? Can someone explain what is going on?

[ralphb]

12 hours ago, RXB said:

OK now I have another problem the xga99 Assembly creates Binary files but they are not the same size as the files that the Ryte Data GPL Assembler Object files in size?

In my Source Code I have AORG >1FE0 which should be jumping forward to >5FE0 from that location forward and seems to be ignore by the Binary code generated by XGA99?

 

Which explains why the size is just wrong. Also why every time I try to make the RXB module it shows huge gaps in wrong locations and just wrong?

 

Should I assemble RXB in one huge Source file? Can someone explain what is going on?

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.

13 hours ago, RXB said:

Any progress is making it more standardized?

Unfortunately, I'm very busy this weekend, but I hope to make the changes by the end of Easter.

[RXB]

7 hours ago, ralphb said:

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.

Thanks for reply Ralph

 

In making RXB using GPL most of my code was patching GPL so it was tons on AORG commands in GPL Assembler so address could remain the same for XB GPL and ROMs.

Over time I have really reduced that number but many are still there for XB ROM routines mostly, or for tables that would be really hard to move.

I did have one huge file at one time but the GPL Assembler would crash as way to many in symbol tables so I had to break it up for separate GROMs.

I will be on ZOOM today at 11 AM and will show the problems I am having.

 

Rich

[ralphb]

On 3/23/2024 at 5:45 PM, RXB said:

...

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

Edited March 30 by ralphb

[Gary from OPA]

1 hour ago, ralphb said:

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 80.22 kB · 2 downloads

Can't wait to try this myself on my pop-cart and sob GPL files as the are huge and were an issue as well when assembling. I will update this thread after the easter weekend with my own results. Many thanks for working with @RXB to make this happen.

[RXB]

On 3/30/2024 at 9:46 AM, ralphb said:

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 80.22 kB · 3 downloads

Ok thanks it works great!!!!!

 

Here is the result and works wonderful!

 

Rich

RXB GPL Source Text.zip

[ralphb]

17 hours ago, RXB said:

Ok thanks it works great!!!!!

 

Here is the result and works wonderful!

 

Rich

RXB GPL Source Text.zip 587.57 kB · 4 downloads

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

[ralphb]

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. 

[Asmusr]

3 hours ago, ralphb said:

Windows suddenly starts to interpret the #! line at the start of the file

Sorry, which file are we talking about, and when does it start to interpret it?

Edit: I understand what we're talking about now, but it works fine for me in Windows 10.

Edited April 3 by Asmusr

[ralphb]

12 hours ago, Asmusr said:

Sorry, which file are we talking about, and when does it start to interpret it?

Edit: I understand what we're talking about now, but it works fine for me in Windows 10.

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. 🤷‍♂️

[RXB]

27 minutes ago, ralphb said:

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. 🤷‍♂️

Yea using Windows 10 PRO, AMD 12 core 3900 4ghz CPU, 32Gig RAM, ASUS 570 ROG motherboard, 2TB Rocket M2 Drive C, 1TB Rocket M2 Dive D, 8 TB WD HD, 10 TB WD HD, NVidia Super 2070 Video card.