xdt99: New TI 99 cross-development tools available

[ralphb]

You could create a file as.bat in your source folder, i.e., the folder that contains your assembly files:

.

@echo off
rem adjust paths to match your downloaded files
c:/development/xdt99/xas99.py -R %1.a99 -L %1.lst -S
c:/development/xdt99/xdm99.py -X sssd test.dsk -a %1.obj -f disfix80
rem start MESS
c:/emulators/mess64.exe ti99_4a -peb:slot8 hfdc -peb:slot8:hfdc:f1 525dd -peb:slot2 32kmem -cart C:/mytiroms/edasm.rpk -flop1 test.dsk

.

Then you just invoke with

.

as.bat myprogram

.

to assemble your file myprogram.a99 as E/A option #3, put the result on a disk, and start MESS and E/A with it. You only need to adjust the paths of your programs in the batch file once.

[HackMac]

I've finally released a new version of the xdt99 suite.

 

The biggest change is the inclusion of two disassemblers xda99 and xdg99 for machine code and GPL bytecode, resp. They support top-down disassembly as well as "run" disassembly that tries to follow the program flow and thus won't disassemble data segments.

 

Additionally, xas99 has some new features:

• include filename in error message
• create a textual version of the binary using BYTEs
• include symbols in listing (option S of E/A)
• generate EQU file of used symbols

Likewise, xga99 is moving ahead for feature parity with xas99:

• generates listing
• generate symbols (like xas99)

Since the disassemblers are brand new and not so thoroughly tested as the assemblers yet, I'm happy to receive bug reports and feature requests.

 

Download link here (don't download the source) Manual link here

 

For the next release, I'm going to tackle my huge backlog and bug list, before I'll do a big refactoring after that.

 

 

Today, I pushed an update of my sources of the Objective-C wrapper classes and the sources of the sample App SimpleXDTIDE to be synchronously.

Link to the release at GitHub

[+adamantyr]

Hey, just a quick note...

 

I've been having some problems with my CRPG running on the actual hardware.... after a lot of sweat and tears and flummoxed testing I finally narrowed it down to the HFE image not being quite right.

 

My disk image has a 128K file on it and it was missing the last handful of sectors whenever I tried to load them. So I created a new 360K DSK image in TI99Dir and re-copied the files, only to have the loader fail hard-core immediately and dump back to the master title screen with copious screen corruption.

 

I managed to find an older DSK image I knew worked and re-copy the files, and finally everything is working as it should... but I am curious as to why the HFE image had issues. Are there any known issues interacting with TI99DIR created DSK images? I should add that the catalog commands for xhm99/xdm99 worked just fine with no issues on the HFE image, plus it cataloged just fine on the actual TI. It only failed on load attempts.

 

The only other thing I can think of is the loader is an E/A Option 5 file generated with Classic99's save utility, and it's also placed in low RAM at >3000. I can try and get a "working" and "broken" HFE image for comparison purposes if you want to investigate it.

[+mizapf]

Maybe TIImageTool can say something about that, since it can read and write HFE. Please send me the images or upload them here.

[+adamantyr]

I would, but when I went to make a new fresh image and replicate the issue, it didn't replicate. It may have been because TI99Dir and all the other tools were freshly opened, I don't know.

 

If I have further issues of this nature I'll be sure to save the images and share them here immediately.

[ralphb]

Just a note: xhm99 can also create HFE files, or decode them back to DSK. So next time you create a nonworking HFE file with TIDIR you can decode that file with xhm99 and compare the DSK images, or vice versa.

[Asmusr]

I'm having problems calculating the high and low bytes of a label. For instance for this test:

       aorg >a000
       limi 0
label  jmp  label
       byte (label/256),(label%256)
       data label/256
       data label%256
       data label
       end

This is the result:

XAS99 CROSS-ASSEMBLER   VERSION 1.7.0
**** **** ****     > test.a99
0001                      aorg >a000
0002 A000 0300  24        limi 0
     A002 0000 
0003 A004 10FF  14 label  jmp  label
0004 A006 A1FC            byte (label/256),(label%256)
0005 A008 FFA1            data label/256
0006 A00A 00FC            data label%256
0007 A00C A004            data label
0008                      end

Only the last data directive gives the correct result (label=>A004).

[Asmusr]

After more experimenting, it appears that this gives the wanted result:

byte (label&>ff00)/256,label

[+Lee Stewart]

I'm having problems calculating the high and low bytes of a label.

 

You must be needing to do this for a reason that is not obvious because “data label” gives exactly the same code as the desired result for “byte hi-label-byte,lo-label-byte”.

 

...lee

[Asmusr]

 

You must be needing to do this for a reason that is not obvious because “data label” gives exactly the same code as the desired result for “byte hi-label-byte,lo-label-byte”.

 

...lee

 

Sure, in the real use case the absolute addresses are inside a non-word-aligned byte stream.

Edited November 27, 2018 by Asmusr

[Asmusr]

I can see in the xas99 code that the reason I run into this issue is because division of a negative number x is coded as: -((-x)/y). For compatibility with the E/A assembler, I guess.

 

So ->A004 = >5FFC , >5FFC/>0100 = >005F , ->005F = >FFA1.

 

If I use AND before the division:

 

>A004 & >FF00 = >A000 , ->A000 = >6000 , >6000 / >0100 = >0060 , ->0060 = >FFA0.

Edited November 27, 2018 by Asmusr

[ralphb]

Yes, unfortunately, xas99 has to live with quite a few warts from the original E/A. For division, it probably makes sense to add an unsigned division operator, like "//". I put it on my todo list. Also, I always wanted to implement shift operators, but '>' is already taken.

[Asmusr]

Yes, unfortunately, xas99 has to live with quite a few warts from the original E/A. For division, it probably makes sense to add an unsigned division operator, like "//". I put it on my todo list. Also, I always wanted to implement shift operators, but '>' is already taken.

 

You could also add a switch to use 32-bit (signed) arithmetic in the preprocessor.

[Asmusr]

I'm trying to use multiple rom bank support with xas99 for the first time, e.g. AORG >6000,0, but the check for illegal cross-bank access prevents me from referring to anything in another bank, so how am I supposed to call a routine in another bank via a trampoline routine in scratchpad? I suggest the check should be limited to branch instructions and not to LI etc.

Edited February 13, 2019 by Asmusr

[+Lee Stewart]

For fbForth 2.0, I use three pairs of trampoline routines that I locate in low RAM. I realize you are trying to manage this from the Assembler, while I had to manage it from within the code, but the way I did it might conceivably offer some insight. You are more than welcome to the code. It is available on my website (see signature below) in the “Source Code” menu (Source Code-->Bank1-->Low Level Support). The BLBANK , RTBANK pair might be the most useful of the three pairs for your purposes, but even they use the Forth return stack, so I don’t know of their ultimate utility. You will note some rather arcane machinations in the code, which I would be delighted to explain if need be.

 

...lee

[ralphb]

I'm trying to use multiple rom bank support with xas99 for the first time, e.g. AORG >6000,0, but the check for illegal cross-bank access prevents me from referring to anything in another bank, so how am I supposed to call a routine in another bank via a trampoline routine in scratchpad? I suggest the check should be limited to branch instructions and not to LI etc.

 

Yes, you do have a point there. Not checking the bank for LI instructions and is probably safe, but I was thinking of LI R0, <other bank> followed by B *R0 -- the very thing you're trying to do.

 

Are you using XORG? An exemption for XORG would also make sense (if there even is one, I can't remember right now).

[Asmusr]

 

Yes, you do have a point there. Not checking the bank for LI instructions and is probably safe, but I was thinking of LI R0, <other bank> followed by B *R0 -- the very thing you're trying to do.

 

Are you using XORG? An exemption for XORG would also make sense (if there even is one, I can't remember right now).

 

No I'm not using XORG for this, but I have used it in many other cases, especially with F18A GPU code.

 

Another feature that would be really helpful would be to have a segment of shared code available in all banks, e.g marked AORG >6000. This could contain the header, the trampoline function, and other commonly used functions. The labels in the shared segment would not be checked for illegal cross-bank access, of course.

[Asmusr]

I can work around the checks by making equates for the labels I need to branch to in other banks, and then use those equates instead of the labels directly.

[ralphb]

I'm working on a new version of xas99. For cross-bank access, you'd append a # after your address, like

.

  bl  other_bank#
  li  r0, label_bank_2#

.

The cross-bank check applies, like now, to everything "general address", so there may be cases where cross-bank access is not caught, like you found.

 

I'd like to add some other small things to xas99 before I push it to GitHub.

 

Edit: alignment

Edited February 19, 2019 by ralphb

[+FarmerPotato]

Hi Ralph,

 

I've been using xdt99 a lot recently. Thanks for making this great set of tools.

 

 

Could you perhaps give some background on how you move DF80 object files to real iron? TI99Dir expects DOS files including DF80 to have line breaks. Tursi made them work in Classic99 for EA. It took me a while to figure out how to transfer xas99 object files to real iron.

Thread here:

http://atariage.com/forums/topic/288360-how-to-move-disfix-80-through-hdx-as-files/

[ralphb]

Personally, I'm using xdm99 for that. It's a command-line disk manager that consists of three parts, which are all included in xdt99.

 

Say you have a program.img file (extension doesn't matter, could also be bin or obj). Then you can create a disk image:

.

xdm99.py -X SSSD program.dsk -a program.img                (append -f DF80 for DIS/FIX 80)

.

Classic99 can read this, but not write to. You can also create Classic99's native format

.

xdm99.py -T program.img --ti-name -9

.

That's a lot of nonsense here, but you can get a short help description about xdm99's arguments by typing xdm99.py -h.

 

But since you asked about real iron: xdm99 has two options here.

 

If you're using a nanoPEB or CF7+, you can copy the disk image above directly to CF card:

.

xvm99.py -w program.dsk <device name> <volume number>

.

The device name depends on your OS, but since you mentioned TIDIR, it's something like \\.\PHYSICALDRIVE2 on Windows. The actual number can be figured out with one the Windows admin tools, but I forgot its name. You also need Administrator rights for writing directly to the device.

 

If you're using a Lotharek HxD, you can convert the disk image to the HFE format:

.

xhm99.py -T program.dsk

.

Then just copy the HFE file to your HxD.

 

[+FarmerPotato]

I'm using cfhdxs1 to avoid moving my CF card back and forth, so I needed a v9t9 file.

So, I will go directly to v9t9 file with your example,

xdm99.py -T program.img --ti-name -9

Here's what I hit on that worked, it's more steps:

../xdt99/xdm99.py work.dsk --initialize 720 -n G2
../xdt99/xdm99.py work.dsk -a g2.obj -f DF80

hdxcfs can't send a whole dsk, so I extract the file in v9t9 format again:

../xdt99/xdm99.py work.dsk -9 -e G2 -o  ../mount/G2

HFE/Gotek is in my near future.

Edited February 19, 2019 by FarmerPotato

[ralphb]

You could sidestep the disk image by using -9 on the file directly:

.

xdm99.py -T g2.obj -9 -o mount/G2

.

G2 will be a variation of the TIFILES format, which Classic99, v9t9 and other disk-less systems use.

[Asmusr]

I'm working on a new version of xas99. For cross-bank access, you'd append a # after your address, like

.

  bl  other_bank#
  li  r0, label_bank_2#

.

The cross-bank check applies, like now, to everything "general address", so there may be cases where cross-bank access is not caught, like you found.

 

I'd like to add some other small things to xas99 before I push it to GitHub.

 

Edit: alignment

 

Any progress on the new version?

[ralphb]

Soon.

 

xas99 has accumulated various changes which I have to consolidate, write both tests and documentation for. So this takes some time, also since I don't want to neglect SDD99 in the meantime.

Edited March 6, 2019 by ralphb