xdt99: New TI 99 cross-development tools available

[+TheBF]

I had never heard of this little unit before now.  After some quick skimming here http://www.floodgap.com/retrobits/tomy/general.html

It seems hard to find a schematic of this thing.  From the pictures of the PCB it looks like it has 2 8K static rams which means it might be able to be expandable to 64K with a pair of 32K static rams.

 

If you are new to this low level computing arena here are some general thoughts:

 

You will need some kind of a loader.  The LOADER will put your binary program file that you build with the Assembler into RAM in a way that the TUTOT knows where it is and knows how to jump to the start of the program.

 

Maybe somebody has created a loader already OR it exists in the system ROMS and you need to learn how to start it.

It may be possible that BASIC can do that for you but you will need a loader.

 

A Brute force method could be to write a BASIC program and put the program data in DATA statements and POKE  the bytes/words into memory if the BASIC has POKE().

 

The electrical connection to the storage seems to be via cassette tape.

That could pose a real challenge if you had to encode your file as a compatible cassette file. Probably too tricky to consider now.

 

An alternative would be to load your program into a compatible rom chip, put in on a cartridge board and install it in the cartridge port.

This will mean you need to understand the binary layout of a ROM for this beast.  It also means you can properly emulate the ROM that the Tutor uses.

 

Hope that wasn't telling you what you already know.

 

 

[ralphb]

There is one multi-cart for the Pyuuta I know of, but sadly no FinalGROM or Ubergrom.

 

This means that you probably need to use a programmer to flash your assembled program to an EEPROM on an adapter cartridge.  There are probably additional constraints, similar to the GPL header of TI 99, that you would need to include in your program.

 

Maybe someone else has any additional insights.

 

[+Ksarul]

I also have some 8K and 16K cartridge boards for the Tutor that I made a few years ago, as well as one I made that should work as a 32K 3D cartridge board or even as a multicart (although I haven't tested that one yet, so anyone trying to use it will be working in guinea pig mode).

[+retroclouds]

I know my version of Pitfall! was assembled for the Tutor and works fine, have a ROM cart with the game on it.

 

Did not have time to concentrate on the Tutor but have 2 of them and a pyuuta game console, so one day...

[+retroclouds]

I filed an issue on github for this. Thought I might share here in case some runs into.

 

Quote

seto r1,<value> assembles without error

 

The parameter following the 1st parameter is ignored and probably treated as a comment.
Should throw assembly error as "seto ..." should not take any additional parameters following 1st parameter.

 

Example:
seto r1,>4a4a

 

Presume this is not the only instruction, but applies to the class of instructions seto belongs to (haven't checked though)

[ralphb]

Just a small status update regarding xdt99:

 

You may have heard that support for Python 2 is ending this year.  Over the past months, I've been porting all xdt99 programs to Python 3, and during that process, I'm also refactoring and extending most programs.  For example, xas99 will get a proper linker, and xbas99 will work with labels in addition to line numbers.

 

I'll publish each program when I'm done with it, so please wait with your upgrade until all tools you're using have been published.  Python 2 won't stop working, and potential bugs aren't as devastating as, say, in the browser.

[+InsaneMultitasker]

Ralph - I migrated my horizon ROS "development" files to the PC and am using xdt99 to take advantage of faster assembly/link/testing speeds.  Today I ran into a problem where my DSR test results were not making any sense. Fortunately, I had made a backup of the folder last month and was comparing source files when it dawned on me that I had LIST files in both folders.  I scanned the two LIST files looking for differences and sure enough an instruction was not being assembled due to a formatting mistake.  (I looked at this code multiple times and didn't see it!).  I'm a step closer to learning how to use a repository like GitHub to make ROS source publicly available.  Thank you for the tools and your ongoing efforts.

[matthew180]

Ralph, I was just reading the xdt99 docs and saw the support for the F18A instructions, very cool!

xas99 supports the F18A GPU instruction set.

CALL <gas>
RET
PUSH <gas>
POP  <gad>
SLC  <wa>, <count>
PIC  <gas>, <gad>

I just two notes:

 

1. The Pixel instruction is called PIX (not PIC) and is a re-purposing of the XOP instruction (you probably know that).

2. The GPU also utilizes the 9900 IDLE instruction (I'm not sure if xdt99 already supports that opcode or not?)

 

[Asmusr]

9 hours ago, matthew180 said:

 

2. The GPU also utilizes the 9900 IDLE instruction (I'm not sure if xdt99 already supports that opcode or not?)

 

I also forgot that IDLE is part of the standard TMS9900 instruction set.

[ralphb]

15 hours ago, matthew180 said:

I just two notes:

1. The Pixel instruction is called PIX (not PIC) and is a re-purposing of the XOP instruction (you probably know that).

2. The GPU also utilizes the 9900 IDLE instruction (I'm not sure if xdt99 already supports that opcode or not?)

Thanks for the correction; I'll fix it in the upcoming release.  IDLE and all the other forbidden instructions are supported, but probably not that well-tested.

 

Regarding the new release, I noticed that I commingled changes to various programs, which means that I have to release them all at once.  Right now I'm busy checking a lot of edge cases.  For example, look at this object code: Can you get the original assembly source from it?

 

00020        A0004A0006A0006B0000A0008BFF00A00097F681F                      0001
7FFC9F                                                                      0002
:       xdt99 xas 

 

Edited January 11, 2020 by ralphb
Clarification

[matthew180]

8 hours ago, ralphb said:

IDLE and all the other forbidden instructions are supported, but probably not that well-tested.

If the assembler generates the correct opcode, then it is tested.

 

8 hours ago, ralphb said:

Can you get the original assembly source from it?

It is mostly a bunch of consecutive address records, which does not make sense.  The code seems to be missing:

0 0020 32 bytes of code, no IDT
A 0004 load address 0004
A 0006 load address 0006
A 0006 load address 0006
B 0000 absolute data
A 0008 load address 0008
B FF00 asbolute data
A 0009 load address 0009
7 F681 checksum
F end of record
7 FFC9 checksum
F end of record
:

The closest code I could come up with is:

 

AORG >0006

DATA >0000

BYTE >FF

 

Not must of a program.

[ralphb]

Yes, it's just a nonsensical example program, and the assembler could optimize a lot here.  But this is the actual output of the Editor/Assembler (and xas99), and with that you can  derive the original source again.  In the above case:

 

 rorg >4
 bss 2
 bss 1
 byte 0
 rorg >8
 byte -1
 bss 1
 rorg >20
 end

 

It's just an example of what took me a while to figure out correctly ...

[+jedimatt42]

Is there a directive that would allow injecting comments or whatever they are, in the generated DIS/FIX 80 object file?  Is that what TITL did?

 

Like the

:       xdt99 xas

or can I just add another line starting with ':'   --- this is probably a LOADER question for the EA manual.. 

 

My goal is to get the build version of a binary into the file, cause 99'ers will rename things, and lose track. But it doesn't need to be in the loaded code. That would just waste memory.

 

-M@

[+jedimatt42]

8 minutes ago, jedimatt42 said:

Is there a directive that would allow injecting comments or whatever they are, in the generated DIS/FIX 80 object file?  Is that what TITL did?

 

Like the

:       xdt99 xas

or can I just add another line starting with ':'   --- this is probably a LOADER question for the EA manual.. 

 

My goal is to get the build version of a binary into the file, cause 99'ers will rename things, and lose track. But it doesn't need to be in the loaded code. That would just waste memory.

 

-M@

 

No,is the answer from the EA manual... It does say this about the final record starting with ':'

 

Quote

The last record of an object module has a colon (:) in the first character position of the record, followed by the identification code 9914 AS.

 

So, I suppose I could just place other text in that last record. 

 

-M@

[ralphb]

Well, you could also have a DEF V12345 in your source, and that will create a 5/6 tag with that version symbol.

 

Or try putting a comment after the : line, although I'm not sure if all tools can deal with that (the new xas99 linker won't).  Modifying the : line itself is probably safer if you do it for the final object code.

[+9640News]

Ralph,

 

I'm going to throw out a request.  If you are able, fine.  If not, fine as well.

 

I've seen a lot of posts regarding the xdt99 with various users getting everything properly installed, etc.

 

I'm assuming this can run on a Raspberry PI.  If it can, and assuming you have a Raspberry PI, and then assuming all the licensing is permitted, can you distribute a SD card image with everything ready to go for Raspberry PI.  Depending upon your PI, it may be something only suitable for a zero, 3+, or maybe a 4.

 

That way, a user can download and burn the image on a SD card, and be ready to go right away.

 

If this is not possible, as I said no problem.  I think there may be more people that would try to use the system if they did not have to figure out what went wrong in the setup.

 

My 2 cents.

 

Beery

 

[ralphb]

Beery, yes, this can run on a RPi.  In fact, it can run on any platform where Python is available, and that includes all the RPis.

 

But xdt99 and core Python is less than 5 MB combined, so creating a 1 GB image just to have xdt99 seems a little wasteful.  I get your point, however, and I'll think about easing installation.

 

[+9640News]

1 hour ago, ralphb said:

Beery, yes, this can run on a RPi.  In fact, it can run on any platform where Python is available, and that includes all the RPis.

 

But xdt99 and core Python is less than 5 MB combined, so creating a 1 GB image just to have xdt99 seems a little wasteful.  I get your point, however, and I'll think about easing installation.

 

I presently have three PI's (two 3+ and a 4).  Both 3+'s are in PEBox TIPI's and the third is not connected to anything yet.  I have a sidecar TIPI I was planning to use with one of the PI's but have not hooked it up yet.  The AfterHours BBS work I am doing will use it soon.

 

What I would end up doing would be to have an xdt99 SD image and I could interchange as necessary with another PI to be purchased in the future.  

 

Beery

[PeteE]

4 hours ago, BeeryMiller said:

I presently have three PI's (two 3+ and a 4).  Both 3+'s are in PEBox TIPI's and the third is not connected to anything yet.  I have a sidecar TIPI I was planning to use with one of the PI's but have not hooked it up yet.  The AfterHours BBS work I am doing will use it soon.

 

What I would end up doing would be to have an xdt99 SD image and I could interchange as necessary with another PI to be purchased in the future.  

 

Beery

Hi Beery,

 

The TIPI SD card image has xdt99 preinstalled at /home/tipi/xdt99.

 

[+9640News]

7 minutes ago, PeteE said:

Hi Beery,

 

The TIPI SD card image has xdt99 preinstalled at /home/tipi/xdt99.

 

I had gotten a private message to that comment as well.  Is it installed, or a script that needs to run to install it?

 

I will need to pull down Matt's latest TIPI image for the PI 4 and see what happens from there.

 

Beery

 

[PeteE]

1 minute ago, BeeryMiller said:

I had gotten a private message to that comment as well.  Is it installed, or a script that needs to run to install it?

 

I will need to pull down Matt's latest TIPI image for the PI 4 and see what happens from there.

 

Beery

 

No need to run any installation script.  The python files are all there, ready to run:

tipi$ cd xdt99/
xdt99$ ls
COPYING  ide  README.md  xas99.py   xda99.py  xdm99.py  xhm99.py
doc      lib  test       xbas99.py  xdg99.py  xga99.py  xvm99.py

 

[+jedimatt42]

You don't really install it in the traditionally complex sense you are assuming. You put the directory in your PATH and then use it. 

 

I don't add it to your PATH for you because using the TIPI image for extra curricular activities means you know what you are doing and I don't. 

 

Upgrading xdt99 on TIPI may break TIPI functions. 

 

There is a lot of internet dedicated to installing python on Windows. People should read some of that. 

 

-M@

 

 

[ralphb]

17 hours ago, PeteE said:

The TIPI SD card image has xdt99 preinstalled at /home/tipi/xdt99.

Pardon my ignorance here, but can you invoke the xdt99 tools from the TI 99?

[+jedimatt42]

2 hours ago, ralphb said:

Pardon my ignorance here, but can you invoke the xdt99 tools from the TI 99?

By intent, no. 

 

I use xdt99 on TIPI, to facilitate 3 features:

  DSK image extraction to directories. - there is a little inotify daemon watching file activity, and I front it with a track-dump to sector-dump converter if necessary. 

  BASIC text file conversion to PROGRAM on LOAD or back to ASCII on SAVE.

  BASIC to text conversion in the TIPI web UI's BASIC editor.

 

3 great features, made possible by delegating to your xdm99 and xbas99 tools.

 

Technically, I support sockets, and the PI image has telnet enabled to allow correcting configuration issues, so you _can_ open a socket, interact with `localhost` port 23, and issue bash commands. Someone could write a front end, even in BASIC, that drove xdt99 assemblers and tools. 

 

-M@

[+retroclouds]

I have been thinking of using xdt99 as backend assembler in my TiVi editor. Could do some cool stuff, like assemble, halt on error and jump to the corresponding source code line.