xdt99: New TI 99 cross-development tools available

[Willsy]

I check the hardware collision bit first. If not set then there's no collision. If set then subtract the coordinates of the sprites in question from each other and take their absolute value. If less than a tolerance that you specify (eg get 4 pixels) then there's a collision. That's how I do it. FWIW.

[Davvel]

I check the hardware collision bit first. If not set then there's no collision. If set then subtract the coordinates of the sprites in question from each other and take their absolute value. If less than a tolerance that you specify (eg get 4 pixels) then there's a collision. That's how I do it. FWIW.

Willsy, that is a clever method. I was a little worried about having to define Coincidence tables for each and every pair of objects, is there a quick and easy way just to tell TI to set CND if any non zero sprite pixel collides with any other non zero sprite pixel ? Maybe the documentation I am reading did not explain the simple default collision detection and went into complex bit mask detection techniques. http://www.unige.ch/medecine/nouspikel/ti99/gpl2.htm#COIN

[Tursi]

I don't know about setting CND, but the VDP status bit contains the collision value. You can read it the same way as the vertical blank bit (just remember that like the vertical blank bit, reading it from the chip itself clears it and the other status bits, so you're best to read from the mirror in scratchpad unless you need faster response than a single frame). the bit value is >20 (called 'coincidence' by the docs) -- it's set when any two set pixels in any two active sprites are touching.

 

More than that is generally used because you usually want to know WHICH two sprites are touching, and the hardware can't tell you that. But Willsy's advice is usually the best approach (some titles don't even bother with the coincidence bit and ONLY check distances, but of course that's not pixel-accurate.)

[Asmusr]

That's also what I do.

[Davvel]

I don't know about setting CND, but the VDP status bit contains the collision value. You can read it the same way as the vertical blank bit (just remember that like the vertical blank bit, reading it from the chip itself clears it and the other status bits, so you're best to read from the mirror in scratchpad unless you need faster response than a single frame). the bit value is >20 (called 'coincidence' by the docs) -- it's set when any two set pixels in any two active sprites are touching.

 

More than that is generally used because you usually want to know WHICH two sprites are touching, and the hardware can't tell you that. But Willsy's advice is usually the best approach (some titles don't even bother with the coincidence bit and ONLY check distances, but of course that's not pixel-accurate.)

Thanks for the clear answer. Why does all the documentation I read make it so complicated to explain such a simple concept than? They all mention that you need a coincidence table for every pair of active sprites.

[Asmusr]

Thanks for the clear answer. Why does all the documentation I read make it so complicated to explain such a simple concept than? They all mention that you need a coincidence table for every pair of active sprites.

 

The hardware coincidence bit only works for sprite to sprite collisions. If you want to check for sprite to background collision I guess the GPL COIN instruction could have its uses, but it does seem overkill. I have only used simple map lookup for sprite to background collision detection in my games.

[Davvel]

 

The hardware coincidence bit only works for sprite to sprite collisions. If you want to check for sprite to background collision I guess the GPL COIN instruction could have its uses, but it does seem overkill. I have only used simple map lookup for sprite to background collision detection in my games.

Thanks Rasmus. I understand it better now.

[Asmusr]

It looks like an XORG section is placed in a separate file when using the -i option with xas99.py. Since an XORG section is not loaded in a separate location from the AORG section in which it's included, I think this is a bug.

Another small issue is that AORG without any argument is underlined as an error in IDEA.

Thanks,

Rasmus

[ralphb]

Hovsa! You're right. Strictly speaking, it's not a bug, as the image files load correctly, but it certainly is not what I intended -- thanks for pointing it out! I pushed the fix to GitHub.

 

The other issue is noted for the next release.

[Asmusr]

Hovsa! You're right. Strictly speaking, it's not a bug, as the image files load correctly, but it certainly is not what I intended -- thanks for pointing it out! I pushed the fix to GitHub.

 

The other issue is noted for the next release.

 

Thanks. Confirmed fixed.

[Asmusr]

Would it be possible, in the IntelliJ IDEA plugin, only to include files that are being copied into the current file using an assembler directive when IDEA is suggesting label names for auto-completion, navigate to declaration (Ctrl-B), etc? I often keep several backups or other assembly files in the same project, and you can easily end up jumping to the wrong file using Ctrl-B.

[ralphb]

I know what you're talking about, this happens to me as well sometimes. But more often, it's a feature, so I guess that's why it's the default for IDEA.

 

I'm not sure I can realize your proposal, since you also want to jump back from an included file. This implies that you have multiple "projects" at a time, and you keep switching back and forth between them, and the file-to-project associations keeps changing as you edit files.

 

But I'll have a go at it later in August, after I finished up that other business and after my vacation.

 

Is it just for navigation, or also renaming? (Can't remember top of my head if you can separate those, though.)

[+jedimatt42]

Would it be possible, in the IntelliJ IDEA plugin, only to include files that are being copied into the current file using an assembler directive when IDEA is suggesting label names for auto-completion, navigate to declaration (Ctrl-B), etc? I often keep several backups or other assembly files in the same project, and you can easily end up jumping to the wrong file using Ctrl-B.

I use intellij in my day job, and some of the problem you describe is best solved by changing habits. Try using GIT and version control mechanics for those backups so your project is clean.

 

For multiple projects with duplicate definitions, try different actual intellij projects, or if that is too inconvenient, try sub modules.

 

This might help in the meantime, until intellij can consider the context of a symbol. It may help in the long run too. Then again I have not applied this to xdt99.

 

-M@

[ralphb]

I often keep several backups or other assembly files in the same project

 

Err, this just occurred to me: if you change the extension of your backup and scratch files to something different, like .a99x, IDEA shouldn't index those files any more.

[ralphb]

Last night I finally released a new version of xdt99. The main new feature is the introduction of xhm99, an HFE image manager for HxC floppy emulator images.

xhm99 can convert from disk image to HFE image and vice versa.
.

xhm99.py --to-disk image.hfe
xhm99.py --to-hfe disk.dsk

.

Additionally, it supports all options of the xdm99 disk manager to manipulate HFE images without conversion.

For example, to list the contents of an HFE image, simply type
.

xhm99.py image.hfe

.

If you want to add, extract, rename, or remove files to/from/in an HFE image, type

.

xhm99.py image.hfe -a file.txt -f df80         # add file.txt in format DIS/FIX 80 using filename FILE
xhm99.py image.hfe -e FILE -t                  # extract FILE from disk as TIFILES file file.tfi
xhm99.py image.hfe -r FILE:NEWNAME             # rename FILE as NEWNAME on disk
xhm99.py image.hfe -d NEWNAME                  # delete NEWNAME on disk

.

If you have an E/A #5 program meant for Classic 99 that you want to run on real iron, type
.

xhm99.py image.hfe -X dssd -a EA5FILE EA5FILF -t

.

to create a new HFE image with that E/A #5 program.

You can resize HFE images, e.g. from SSDD to DSSD so that the TI controller can read them:
.

xhm99 image.hfe -Z dssd

.

If you have a controller with 80 track support, you can also create or convert to 80 track images:
.

xhm99 image.hfe -Z dssd80t

.

All of these commands work with xdm99 and disk images as well.

Note that xhm99 only supports TI floppy formats (i.e., Shugart/IBM), so for all other formats you would need to rely on the original HxC tool. And I still need to add support for DSDD80T disk images.

 

xdt99 is available here, and the full manual is found here.

Finally, this is the first release of xhm99, so if you have an HFE image that xhm99 cannot process I'd appreciate it if you could send me a bug report.

 

[RickyDean]

Last night I finally released a new version of xdt99. The main new feature is the introduction of xhm99, an HFE image manager for HxC floppy emulator images.

 

xhm99 can convert from disk image to HFE image and vice versa.

.

xhm99.py --to-disk image.hfe
xhm99.py --to-hfe disk.dsk

.

Additionally, it supports all options of the xdm99 disk manager to manipulate HFE images without conversion.

 

For example, to list the contents of an HFE image, simply type

.

xhm99.py image.hfe

.

If you want to add, extract, rename, or remove files to/from/in an HFE image, type

.

xhm99.py image.hfe -a file.txt -f df80         # add file.txt in format DIS/FIX 80 using filename FILE
xhm99.py image.hfe -e FILE -t                  # extract FILE from disk as TIFILES file file.tfi
xhm99.py image.hfe -r FILE:NEWNAME             # rename FILE as NEWNAME on disk
xhm99.py image.hfe -d NEWNAME                  # delete NEWNAME on disk

.

If you have an E/A #5 program meant for Classic 99 that you want to run on real iron, type

.

xhm99.py image.hfe -X dssd -a EA5FILE EA5FILF -t

.

to create a new HFE image with that E/A #5 program.

 

You can resize HFE images, e.g. from SSDD to DSSD so that the TI controller can read them:

.

xhm99 image.hfe -Z dssd

.

If you have a controller with 80 track support, you can also create or convert to 80 track images:

.

xhm99 image.hfe -Z dssd80t

.

All of these commands work with xdm99 and disk images as well.

 

Note that xhm99 only supports TI floppy formats (i.e., Shugart/IBM), so for all other formats you would need to rely on the original HxC tool. And I still need to add support for DSDD80T disk images.

 

xdt99 is available here, and the full manual is found here.

 

Finally, this is the first release of xhm99, so if you have an HFE image that xhm99 cannot process I'd appreciate it if you could send me a bug report.

 

Done pulled it this morning while I was pulling the Flashrom files, thank you so much for your work.

[HackMac]

Hello forum,

 

the last weeks I contribute some code to the xdt99 project. Now additionally to Ralph's Python scripts for generating binary code from source files (like xas99, xga99 and xbas99 does), I added a new repository for wrapper code for using his tools in other applications like a library.

The xdt99 Wrapper Classes (xdt99-wrapper) contains actually a collection of Objective-C classes that wraps all necessary Python classes of the xdt99 to make them available for native Objective-C software development under the Cocoa framework. In future there can be make additionally wrapper for Swift, C/C++ or other programming languages, if needed.

These Objective-C classes will be released bundled together with the necessary xdt99 Python scripts as a binary framework (XDTools99.framework) for easy to use and easy integrating into native Cocoa applications for your Mac under macOS 10.8 and later. Or Xcode programmers can just use the framework project as an subproject for their own projects.

 

I started this project because I plan to expand the import options for my TI-Disk Manager. Until now it supports import of text, graphics an other formats. Also decoding and exporting of Basic and Assembler programs is possible. (For more information, take a look at the project pages.) So the next logical step is to implement the option for import source code files as binary files.

 

This wrapper collection additionally contains a XCode project for an simple application (named SimpleXDT99IDE) that will show you how to use the wrapper library. (I attach this application to that post.)

 

I hope there are other "Mac Hackers" out there who will find this framework useful.

 

Enjoy

 

SimpleXDTIDE.zip

Edited December 21, 2016 by HackMac

[ralphb]

That's pretty cool looking! Thanks for building these.

[Asmusr]

I'm having problems with forward references in EQUs:

A      DATA C                          ; This is fine
B      EQU  C                          ; ***** Unknown symbol: C
C      DATA 0
       END

Interestingly WinAsm99/Asm994a is having the opposite problem: it can handle the EQU but not the DATA.

 

Edit: Not a big deal, I have found a workaround.

[ralphb]

If I remember correctly, this is the behavior of the original E/A module. EQU expressions must be "well-defined", i.e., their value must be known in the first pass, so forward references are not possible. I'm not sure if you can relax this and still have a two-pass assembler, but I might give it a try at some point.

 

Edit: typo

Edited January 18, 2017 by ralphb

[+Lee Stewart]

Actually, according to the E/A Manual, the operand for EQU does not need to be a well-defined expression. It does, however, say that it can only contain previously defined symbols. I verified this by assembling Rasmus’ code with the E/A module. I added a second EQU statement with a previously defined symbol to prove that relocatable symbols could be used. Asm994a v3.010 actually has the same behavior.

 

E/A Assembler listing:

.

99/4 ASSEMBLER

VERSION 1.2 PAGE 0001

0001 0000 0002' A DATA C ; This is fine

0002 0000 B EQU C ; ***** Unknown symbo

***** BAD FWD REFERENCE - 0002

0003 0002 0000 C DATA 0

0004 0000' D EQU A

0005 END

.

99/4 ASSEMBLER

VERSION 1.2 PAGE 0002

' A 0000 B 0000 ' C 0002 ' D 0000

0001 ERRORS

Asm994a v3.010 listing:

 

Asm994a TMS99000 Assembler - v3.010

1 0000 0002'A DATA C ; This is fine

2 0000 0000 B EQU C ; ***** Unknown symbol: C

>>>> Error #1: Multiply defined EQUates: B

3 0002 0000 C DATA 0

4 0000 0000 D EQU A

5 0004 0000 END

5

Assembly Complete - Errors: 1, Warnings: 0

------ Symbol Listing ------

A REL:0000 A

C REL:0002 C

D REL:0000 D

 

...lee

[ralphb]

Thanks for the correction, Lee! I shouldn't write sentences that start with "if I remember correctly ...".

[+Lee Stewart]

Thanks for the correction, Lee! I shouldn't write sentences that start with "if I remember correctly ...".

 

You were basically correct, Ralph! It was just the “well-defined” part that needed tweaking. I also needed to discover the actual situation for myself because, as we all know, the E/A Manual is flat out wrong in a few places.

 

...lee

[matthew180]

Wow, I'm two years late to this thread... I just wanted to comment that this is really cool, and to say thanks!

[PeteE]

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. The result runs far far faster than the TI-BASIC that I learned as a kid, plus I can use labels instead of line numbers.