xdt99: New TI 99 cross-development tools available

[Asmusr]

I noticed a small difference between E/A#5 files produced by xas99 and other tools: xas99 includes the 6 bytes of the header in the file length in the header, so typically >2000 instead of >1FFA. This doesn't seem to matter to the loaders.

[ralphb]

Just wanted to say thanks for this great set of tools. I've been using xas99 while learning assembly language to port a NES game to the 99/4a as a cartridge ROM.

 

Thank you, PeteE, it always makes me happy if someone finds the tools useful.

[ralphb]

I noticed a small difference between E/A#5 files produced by xas99 and other tools: xas99 includes the 6 bytes of the header in the file length in the header, so typically >2000 instead of >1FFA. This doesn't seem to matter to the loaders.

 

Yes, that is correct, but it's also the behavior of the original E/A cartridge.

 

I assembled this program

.

* CHECK EA5 WITH IMAGE FORMAT


       AORG >C000

       DEF  SFIRST,SLOAD,SLAST

SFIRST
SLOAD
       DATA >1111
       DATA >2222
       DATA >3333
       DATA >4444
       DATA >5555
       DATA >6666
       DATA >7777
       DATA >8888
       DATA >9999

       BSS  >1FF0
       
       DATA >1111
       DATA >2222
       DATA >3333
       DATA >4444
       DATA >5555
       DATA >6666
       DATA >7777
       DATA >8888
       DATA >9999

SLAST
       END

.

with xas99 and with the original E/A SAVE utility, and they come out byte identical. The original E/A was in fact my reference, as I didn't find an explanation of the SAVE format.

[Asmusr]

Hmm, interesting. So Thierry's page is wrong on both this and the order of the 3 words (it has the address before the length).

 

http://www.unige.ch/medecine/nouspikel/ti99/ea_mod.htm#EA5

[+jedimatt42]

Hmm, interesting. So Thierry's page is wrong on both this and the order of the 3 words (it has the address before the length).

 

http://www.unige.ch/medecine/nouspikel/ti99/ea_mod.htm#EA5

 

Yep. After I went around on this last time, ninerpedia people updated this page to be correct:

 

http://www.ninerpedia.org/index.php?title=Memory_Image_format_E/A_Module

 

-M@

[+InsaneMultitasker]

I think the only times the extra 6 bytes could matter is if segments are loaded out of order (the first 6 bytes of the preceding segment could be trashed) or the final loaded file over-writes 6 bytes that the loader or program is expecting to remain pristine. Doubtful that either case would arise under the most circumstances.

 

I don't remember the particulars of the TI Disk Controller load opcode (>05) bug that we ran into some months ago; I tried to find that thread to refresh my memory, but my search magic isn't working here on AA. Again, probably a non-issue.

[Tursi]

I remember that one too... seems to me it was an unexpected behavior when one of the counts was 0, but I don't quite recall.

[lucien2]

I did a small WSH script to convert RXB source to be assembled by xga99. Just put all the RXB source files in the same folder as "rxb.js" and double-click it.

Here's what the script does:

- Convert DV80 FIAD files and join them to have one source per GROM.

- For comments that do not start at the beginning of the line, add "; " before the first "*"

- Change "CARR" instruction to "CARRY"

- Remove the last "," of incomplete DATA instructions

- Change "S" instruction to "SUB"

- Add missing predefined symbols at the beginning of each file

- Comment the FDIV and CFI equs to remove "duplicate symbols" errors

Here's the unique manual modification I did:

- In SRXB3-B, two lines after MSG70, a "," was missing in the middle of a BYTE declaration

I regenerated RXGB.bin with CARTSAVE from RAG objects to clear unused bytes to zero.

Then I compared both RXGB.bin files (Assembled by RAG and XGA99), they are identical!

rxb xdt.zip

[lucien2]

I did two improvements in xga99.py.

- Sort the symbol map of the "--dump" option by address and by symbol

- Generate object/cartridge output also with the "--dump" option, so you don't need to assemble two times

xga99.zip

[ralphb]

Wow, thanks lucien2, I'll incorporate your code into the main branch. I don't write that much GPL, so improvement are always welcome.

[lucien2]

Impressive, but when attempting to use this tool with Windows it wants to load a crap load of stuff normally only found in Linux or Unix.

If I was using OX X instead of Windows running Classic99 I would be interested more.

I'm running Classic99 on Windows too. The assembler can generate an RPK for MESS, but I made an utility to generate a standard cartridge bin file from multiple grom objects.

If you leave the default Python installation options, it just creates a 60MB "python" folder on your disk. If you uncheck all options (except "Register extension") it uses only 23MB.

 

Also you can not GPOKE a GPL byte in GROM and see the change result using xga99 Assembler which is a tool you lose using a BIN file that is UNCHANGEABLE in Classsic99.

I don't see the need to do this anymore, since it takes only a few seconds to assemble the cartridge.

[matthew180]

I have a feature request. It would be really great if labels could be preceded with an arbitrary amount of white space instead of having to be smack against the left. I would really like to be able to indent my assembly code for better readability.

 

I realize this breaks E/A compatibility, so maybe having to set a flag to use the option would be required. I also realize that a prefix token might be required for the label to make it possible to detect an indented label vs code. I'm okay with that. Maybe a line where the first non-white-space character is a semicolon means a label follows... or something like that.

[RXB]

I'm running Classic99 on Windows too. The assembler can generate an RPK for MESS, but I made an utility to generate a standard cartridge bin file from multiple grom objects.

If you leave the default Python installation options, it just creates a 60MB "python" folder on your disk. If you uncheck all options (except "Register extension") it uses only 23MB.

 

 

I don't see the need to do this anymore, since it takes only a few seconds to assemble the cartridge.

So any programs written in the real TI just can not be used anymore?

That excludes quite a few programs written over the last 30 years, and is not very backwards compatible.

 

In RXB I have maintained as much Backward Compatibility as possible, which is why you can run almost any TI Basic program in RXB with no issues.

(Only two issues have turned up on in over 20 years.One I have a fix for that single command, the other is a bug in TI Basic.)

 

It is very impressive what you have created, maybe at Fest West you can show me now to use your tool without loading Visual Basic onto my Windows Computer.

Edited April 25, 2017 by RXB

[lucien2]

I didn't write the assembler, ralphb did.

 

I just wrote the "gromcart" utility to generate a cartridge file from multiple objects because the assembler can't do it. I did it with VB.NET because it's my preferred platform. You don't have to install VB, just the .NET Framework 3.5 or higher.

 

I won't be present at the FestWest, I'm too busy with my two small children and it's a bit too far from Switzerland.

Edited April 25, 2017 by lucien2

[senior_falcon]

For the compiler, I need to load object code so that it ends at a particular memory location. The problem is that you don't know how long the code is until it is assembled. I tried something like this:

AORG >FFD7-SLAST+SFIRST

 

SFIRST BSS 256 (this is for testing, the actual length is unknown until assembly)

SLAST

 

Neither the TI Assembler nor Asm99 can handle this. Is xdt99 able to assemble this line? Or are there other ideas on how to do this?

 

Currently I have an XB (and now TI BASIC) loader program that will read the first line of code which contains the length, use that length to compute where to start loading, and then set the pointers so the CALL LOAD loader will put the program where I want.

[ralphb]

Neither the TI Assembler nor Asm99 can handle this. Is xdt99 able to assemble this line? Or are there other ideas on how to do this?

 

No, xas99 cannot do this, as SFIRST and SLAST must be known in the first pass of the assembly when the AORG is reached. You'd need several passes to solve this problem, like in xga99 (which uses up to 32 passes to solve a different problem of address size changes between passes).

[ralphb]

I just wrote the "gromcart" utility to generate a cartridge file from multiple objects because the assembler can't do it. I did it with VB.NET because it's my preferred platform. You don't have to install VB, just the .NET Framework 3.5 or higher.

 

So this utility basically pads the object files and concatenates them together, observing GROMs and ORG addresses?

[lucien2]

So this utility basically pads the object files and concatenates them together, observing GROMs and ORG addresses?

It pads and concatenates the objects, but it only uses the grom address from the command line, like this.

"gromcart 6000 srxb3.o 8000 srxb4.o RXBG.bin"

 

Here's the source (in module.vb)

[Airshack]

Looking for the latest version of asm994a. Help!

[ralphb]

Looking for the latest version of asm994a. Help!

 

But why?

[Airshack]

I'm trying to use it to assemble source code generated by the BASIC Compiler.

 

 

Sent from my iPhone using Tapatalk

Edited May 11, 2017 by Airshack

[matthew180]

Take this as an opportunity to switch to xdt99. :-)

[Willsy]

I'd like to give it a try. Is it easy to install?

[matthew180]

Can you unzip a zip archive? If you have python installed then it is that easy (the tools are written in python). And python comes with an installer. I suppose if you want to get the tools into your path then there is a little more setup required, but not much.

[Willsy]

Oh is that it? I already have python 2.7 installed.

 

I can do the path stuff no problem but I probably wouldn't bother. I'd just write batch files in my source code directory to invoke the assembler.