xdt99: New TI 99 cross-development tools available

[Asmusr]

 

That makes me very unhappy.

 

There's no way I'm going to develop any new software directly on the TI. Waiting times and lack of a proper debugger would make this far too time consuming and frustrating. I have great respect for the people who did this in that past (some are still doing it I guess?), but to be honest I would rather have my teeth slowly pulled out than attempting to create a game like Bouncy (my latest project) on the TI. The TI is great as a target platform because it still has unexplored potential, but as a developer platform - nah. I'm sorry if this makes you unhappy, but that's the way it is.

[palmheads]

 

There's no way I'm going to develop any new software directly on the TI. Waiting times and lack of a proper debugger would make this far too time consuming and frustrating. I have great respect for the people who did this in that past (some are still doing it I guess?), but to be honest I would rather have my teeth slowly pulled out than attempting to create a game like Bouncy (my latest project) on the TI. The TI is great as a target platform because it still has unexplored potential, but as a developer platform - nah. I'm sorry if this makes you unhappy, but that's the way it is.

 

And ralphb's tools are pretty damn awesome! Makes learning assembly wayyy more accessible for someone like me,

 

Daryn

[TheMole]

There's no way I'm going to develop any new software directly on the TI. Waiting times and lack of a proper debugger would make this far too time consuming and frustrating. I have great respect for the people who did this in that past (some are still doing it I guess?), but to be honest I would rather have my teeth slowly pulled out than attempting to create a game like Bouncy (my latest project) on the TI. The TI is great as a target platform because it still has unexplored potential, but as a developer platform - nah. I'm sorry if this makes you unhappy, but that's the way it is.

 

Well said, this pretty much sums it up for me.

[Willsy]

Assembling TurboForth on my laptop: just over two seconds.

Assembling on the TI: 10 minutes. Then it runs out of labels space.

 

'Nuff said!

[+mizapf]

Concerning the Geneve, I'm using TASM (should be better using GenAsm, I know) together with LDR in a batch file. Unfortunately, GeneveOS does not use return values so that one could think about conditional execution; now, I use PAUSE to be able to break the build process after assembling. Using TIC requires an additional compilation phase at the beginning.

 

The last program I wrote for the Geneve was XMODEM, and I used an editor on the PC, then transfered the files to the Geneve for building.

[Opry99er]

Were it not for text editing and emulators, Magellan and Patterns, the majority of TI programs that have come out in the last 10 years would never have happened.

 

That said, TI-only software development is flippin' hardcore and commands mad respect.

[HackMac]

The TI is great as a target platform because it still has unexplored potential, but as a developer platform - nah. I'm sorry if this makes you unhappy, but that's the way it is.

No, it doesn't make me unhappy how you like to develop software for the TI, and it isn't the respect for the people.

 

I'm unhappy about that there everybody works on her/his own solution, there is no such a community which works together, on the same project. And it makes me unhappy that you aren't one of them who is working for a suitable development platform like for example Richard does it with his RXB/REA tools.

Its crazy when you realize, there is no DevSys (no proper) for the TI, they build a new one from scratch for a foreign system. I can't believe that. The TI is not a gaming console, you can develop on it!

[+Ksarul]

@HackMac, I think a good part of this discussion does bear a lot on the xdt99 topic. It is a collaborative project of the type you are looking for. RalphB has added a lot of functionality to it because of that community input. It shows where the current crop of software developers are doing the bulk of their development work--as those suggestions have been coming from a lot of people, including Rich when the topic was which GPL Assembler to support.

 

I agree that it is unfortunate that we don't have a similarly inclusive development environment that will run on the original hardware--but some of that is inherent in the limitations of the hardware too. There was an effort to develop an environment that ran on the TI at one point--as the community began to port all of the development tools available at the time to use with the SAMS card, as that was one of the only TI hardware enhancements that was big enough and flexible enough to make an attempt at such a project. Most of the tools were completed too--but very few people actually used them back then, and even fewer use them today. Why? The OS-flavor-of-the-week tools being used and developed today are even more flexible than something using the capabilities of a SAMS card in a TI system. The new tools are fast and target multiple TI end environments. That is a wonderful thing. Most of the tools have been shared with the community as well--and that is an even better thing.

 

The cross-pollination of ideas that goes on here at AtariAge every day is probably the most wonderful thing that has ever happened to the TI. BITD, there was sharing, but it was limited by distance and opportunity. Any of the larger old-school user's groups was a hotbed of innovation--but each was usually separate and only gained limited benefit from what was going on in other groups, because the only time they really had a chance to talk to each other was at one of the computer shows. Now we talk to each other constantly, on a global basis, and we have a whole lot of fun doing it. It will be amazing to see what fruit xdt99 bears in the end--but with the programmers we have in the community today, I can almost guarantee one thing: the results will be mind-blowing.

 

Thanks for the thoughts too--you made me think deeply on this subject, and that is a very good thing!

[RXB]

New carts with massive memory are prefered today and this has detracted from the insanely good design of the SAMS or 9938 or 9958 VDP cards with 128K or more.

 

Hence few applications using SAMS or EVPC or TIM or other Video cards that were part of the TI community 20 years ago.

[Opry99er]

Hey Rich...

 

I don't see how high capacity cartridges are in "competition" with SAMS and others...

 

Maybe I am missing something, but carts are a storage medium where SAMS is additional memory.

[+Ksarul]

And a few of those high-capacity cartridges take advantage of SAMS memory too, Rich--your RXB and Willsy's Turbo Forth are two that immediately come to mind.

[RXB]

Yea very few apps take advantage of SAMS or larger VDP size.

I could access the VDP Registers of the 9938 and 9958 from GPL and move around the 128K VDP memory. (Or TIM card 163K VDP Memory)

Have no idea how I would do that on the F18A but is a hot topic and popular as a new device.

 

It just seems any old devices are totally abandoned to new devices.

I miss these and would like to see more then me working on using the SAMS and Extra memory of the 9938 or 9958.

 

Really how many new games can you count using the SAMS in the last 5 years?

Edited September 27, 2015 by RXB

[HackMac]

I see the work from the developers of RXB/REA and Turbo Forth. In my eyes they are the real TI heroes.

But when I read somewhat of "respect to the developers" and later in the same text on the other side somewhat like "TI sucks for developing", I get a bit confused. For me this is a slap in the face for those developers, who develop on and for the TI. In other words they can stop their work on their projects, cause everybody is developing on foreign systems? Who still needs a REA or Turbo Forth on a TI?

And the myth of limitations of resources on the TI is an alibi. By using MESS, these limitations gets irrelevant.

 

Yes, xdt99 is a collaborative project, no question. Each of them are. But like I told, these are all only isle projects. When someone contributes more then just ideas to a project, but rather contribute additional code, this I would refer collaborating.

I still don't know why someone starts a completely new project instead of joining to an existing project. Joining to a project would really respects the work of developers, not in creating competitively projects.

 

My topic was the desire for dev tools for an common platform. And the only common system is the TI-99/4A.

[ralphb]

This could be an interesting discussion, but I'm really baffled that this comes from someone whose introduction to AtariAge was a Disk Manager, for OS X only, that AFAIK doesn't do anything that TI Image Tool wouldn't already do. So why did YOU start a completely new project instead of joining an existing project?!

For me the TI 99 is about the community. Everybody has his or her own motivations on why they deal with an obsolete system: Some like to tinker, some like to play, some want to finish what they left 30 years ago, some cherish their childhood memories, some want to learn new stuff, some like to have a second go at it with much broader knowledge now, some are obsessive collectors, some are even in it for the money -- and they probably all just want to have fun. Any reason for tinkering with the TI 99 is as good as anyone's else, and I won't judge people by it.

Having said that, I think cross-development is simply the most efficient way of getting results onto the TI 99. Of course these results might just as well be native tools -- think of it as boot-strapping. Didn't Texas Instruments use mini computers to write software for the 99 as well? If we design and use new hardware for the TI that includes today's state-of-the-art technology, why shouldn't we design new software using today's state-of-the-art as well?

I don't own a SAMS card, a hard-disk controller, or a Geneve, even though I've been on the lookout for years. I can and do appreciate the technical prowess that went into their design, but these options are just out of reach for me to build new software.

For me xdt99 is, among other things, a means to my own game (that I started work on about two weeks ago). Once in a while you get side tracked a little, like by Rich and his enthusiasm for GPL, but that's the fun part of it all. And we all here do use other people's tools regularly -- there probably isn't anything that Tursi doesn't have covered.

So I can't see an issue here at all -- the community as a whole is always exploring, looking for new hacks, based on the previous work of others. What else could you wish for?

[TheMole]

I don't own a SAMS card, a hard-disk controller, or a Geneve, even though I've been on the lookout for years. I can and do appreciate the technical prowess that went into their design, but these options are just out of reach for me to build new software.

 

I think this pretty much sums up why I believe the TI is not considered a viable development platform these days. If these technologies would've been available longer, or would be easily available for purchase these days, the story might be different. Unfortunately, where TI sold around 3 million TI-99/4A's, I believe only a couple of thousand Geneve's were sold. No one should be surprised that there's not a lot of new software being developed for those systems. The fact that MESS does an admirable job of emulating the advanced hardware is a red herring, for most people the real attraction is the actual hardware.

[TheMole]

I miss these and would like to see more then me working on using the SAMS and Extra memory of the 9938 or 9958.

 

I actually did look at that for my game, but unfortunately all of the new screen modes added in both v99x8 chips are bitmap oriented instead of tile oriented. That makes them less suited for scrolling platform games. Otherwise, I would've happily added support for them in Alex Kidd.

[Opry99er]

I love my development environment, although I would like to see a true IDE (like Eclipse) for the TI. I do not have the skill to write it though. A great text editor and Classic99 coupled with TI99Dir does everything I will ever need, although it is a bit tedious at times, especially when debugging a compiled XB program.

 

But I am grateful for the tools I have and for those who have put the time and effort into creating them.

 

Our community is fantastic.

[ralphb]

Lots of errors :-)

 

Well, there you go.

 

I've looked at your code snippet, and I think it boils down to this:

.

START BYTE 1
L1
L2    DATA 2
      DATA L1,L2

      END

.

Now both xas99 and the original E/A assembler will assemble this into

.

00008        A0000B0100B0002C0001C00027F8C0F                                0001
7FFC9F                                                                      0002

.

whereas WinAsm thinks it's

.

00008        A0000B0100B0002C0002C00027F8BFF                                0001

.

Personally, I wouldn't expect the instruction for L2 to have an influence on L1, so I'll side with the E/A assembler here.

xas99 was done with the E/A manual as reference, but I noticed that the description often left some room for interpretation, especially for border cases. The asdirs.asm file I attached is basically a probe for figuring out how the assembler really ticks inside. There are many more such files, e.g., for ORGs or BSS. I also use them for regression testing, and they're all part of the source on GitHub.

Interestingly, the only case where I found the E/A manual to be plain wrong was the EVEN directive. The manual states that the value of the location counter is assigned to the label before the EVEN (i.e., it stores the odd address), when in fact it's assigned after the EVEN (i.e., the label value is always even).

[Asmusr]

I'm not good at reading object code, but I would expect both L1 and L2 to point the the data word 2 at address 2. Which of the assemblers are doing that?

[ralphb]

I'm not good at reading object code, but I would expect both L1 and L2 to point the the data word 2 at address 2. Which of the assemblers are doing that?

 

Sorry, the forum ate my color markings:

 

xas99 and E/A:

A0000B0100B0002C0001C00027F8C0F

 

WinAsm

A0000B0100B0002C0002C00027F8BFF

 

The green word is the BYTE 01 (plus alignment), the red word is the value of L1 -- this is where they disagree. WinAsm does what you expect, but I and E/A beg to differ.

 

A label doesn't have to have an instruction, and an instruction doesn't have to have a label, so when you have one of each you may munge them together, but in rare cases this might change their behavior.

 

Also note that

.

L1
    EQU 1

.

is not a valid statement for the original E/A assembler for this very reason.

 

(The latter is somewhat inconvenient for long labels, though, as I would like to write

.

my_long_label equ 1

.

and still properly align fields. So I came up with label continuations for lack of a better word:

.

l1:
   data 1   ; single statement b/c of :

l2
   data 2   ; two statements

.

Yes, it's rather philosophical, but we're talking about border cases here.)

[+Lee Stewart]

I'm not good at reading object code, but I would expect both L1 and L2 to point the the data word 2 at address 2. Which of the assemblers are doing that?

 

...

The green word is the BYTE 01 (plus alignment), the red word is the value of L1 -- this is where they disagree. WinAsm does what you expect, but I and E/A beg to differ.

...

 

WinAsm99 adds a gratuitous EVEN after non-word-aligned code if the next code is a machine instruction or a word-oriented directive (DATA). This has the effect of aligning all labels between the non-word-aligned code and the machine instruction or word-oriented directive. Consider the following code snippet:

 

EVEN

BYTE "This string is odd."

L1

L2

L3 DATA 123

 

WinAsm99 will generate an EVEN directive between the end of the BYTE directive and the start of the DATA directive, resulting in L1, L2 and L3 all pointing to the word containing 123. WinAsm99 will simply not allow the consecutive odd and even labels E/A generates. I guess Cory Burr assumed that a programmer would never intend to do that.

 

...lee

[Asmusr]

 

 

WinAsm99 adds a gratuitous EVEN after non-word-aligned code if the next code is a machine instruction or a word-oriented directive (DATA). This has the effect of aligning all labels between the non-word-aligned code and the machine instruction or word-oriented directive. Consider the following code snippet:

 

EVEN

BYTE "This string is odd."

L1

L2

L3 DATA 123

 

WinAsm99 will generate an EVEN directive between the end of the BYTE directive and the start of the DATA directive, resulting in L1, L2 and L3 all pointing to the word containing 123. WinAsm99 will simply not allow the consecutive odd and even labels E/A generates. I guess Cory Burr assumed that a programmer would never intend to do that.

 

...lee

 

As I understand it xas99 is also doing this for L3 but not for L1 and L2, which will both point to the last byte of the string. Is that correct?

[ralphb]

As I understand it xas99 is also doing this for L3 but not for L1 and L2, which will both point to the last byte of the string. Is that correct?

 

Yes, you are correct.

 

It seems that many people think that L1, L2, and L3 are all labels for the same instruction DATA 123 when in fact only L3 is. L1 and L2 are just labels without any mnemonic, and they get assigned whatever value the LC currently has, be it even or odd. In fact, you could replace DATA 123 by EVEN and still get the same result.

 

Or think about this example:

.

L1
L2 EQU 1

.

Should L1 to be the same value as L2, or should it contain the value of the line counter? For E/A, it's the latter.

 

This might not be intuitive, but I guess it was easier to implement for the TI guys back in the day. I opted to keep compatibility with the E/A assembler, even when I felt things could be improved by doing things differently (precedence of arithmetical operators being the most egregious example).

 

This is a bug in WinAsm, although it might be a deliberate one.

Edited September 29, 2015 by ralphb

[+Lee Stewart]

Begging your pardon; but, code that does what a programmer intends is not a bug. It may create incompatibility or be misguided; but, it is certainly not a bug.

 

...lee

[ralphb]

Begging your pardon; but, code that does what a programmer intends is not a bug. It may create incompatibility or be misguided; but, it is certainly not a bug.

 

The problem is that different programmers intend different things while writing the same code. And the observed behavior is a bug with respect to the E/A manual, but as I said, it might be well intended.