Jump to content
IGNORED

xdt99: New TI 99 cross-development tools available


Recommended Posts

21 hours ago, ralphb said:

I'm slightly confused that SAVE did produce 20 KB of data -- that is way to much for a cartridge,

The file is in fact just around 20k. I’ve successfully used EA3+SAVE to make three (8k+8k+4K) EA5 files from my source code.
 

The next tool I use is Fred’s Module Creator, to make a 20k .bin file. 
 

Are you saying xasm99’s -b or -c capabilities are limited to 8k? Perhaps I’m confusing the terms cartridge and bin?
 

Admittedly, the MAME conversation is further confusing me as I don’t use MAME. My goal is a binary for Classic99 and FinalGROM.

1 hour ago, Airshack said:

Are you saying xasm99’s -b or -c capabilities are limited to 8k? Perhaps I’m confusing the terms cartridge and bin?


1 cartridge ROM BANK is limited to 8k(>6000->7FFF). 20k would require 3 BANKs!:o

  • Like 1
  • Thanks 1

Yeah.. technically 4 banks because the count needs to be a power of 2. Apologies, I didn't even notice the SIZE of the program (I thought you were just doing a quick proof of concept).

 

When your ROM cartridge exceeds 8k, you have two choices. Both require bank switching, meaning you get to learn about the infamous "inverted vs non-inverted" debate... though I think we're settling on non-inverted for all but XB. ;)

 

Option one is to modify your program - change it so that it is divided into 8k pieces, and carefully control which 8k chunk is running at any particular time - complete with manually switching banks at the correct point.

 

Option two is to make a "copy cart" that works more like an EA#5 loader, but from ROM. The loader copies your program from ROM to RAM, then starts it. This is plenty fast and the only real downside is the 32k requirement. We've got lots of sample code for this already.

 

In both cases the bank switch needs to be considered carefully... since when you change banks the /entire/ 8k changes. The two main approaches to this are just making sure that the bank switch always happens at the exact same address in every bank (easy if it's the first code), or to create a "trampoline" - bank switch code that runs in the scratchpad or other RAM. The cartridge jumps to the trampoline code, the trampoline changes the bank, then "bounces" back to the ROM, but at the new address.

 

  • Thanks 1
2 hours ago, Tursi said:

 

Option two is to make a "copy cart" that works more like an EA#5 loader, but from ROM. The loader copies your program from ROM to RAM, then starts it. This is plenty fast and the only real downside is the 32k requirement.

This must be what Fred Kaal’s Module Creator is doing then? I had a 24k XB256 compiled BASIC program converted to 32k binary using this tool.
 

   With all the new technology out there such a cheap and easy 32k sidecars and FinalGROM, I’m just looking to make a single binary file of my code to simplify loading. 


   I wish to eventually post a .bin file which can be loaded from FinalGROM, offering ease of use and portability.
 

   I’ll explore bank-switching on another project where I can plan it from the ground up. Sounds like another interesting pain in the a$$.

1 hour ago, Airshack said:

This must be what Fred Kaal’s Module Creator is doing then? I had a 24k XB256 compiled BASIC program converted to 32k binary using this tool.

 

I’ll explore bank-switching on another project where I can plan it from the ground up. Sounds like another interesting pain in the a$$.

That also explains why xas99 -c wasn't working -- the -c option only supports 8K carts.  As I said, I don't recommend it except for simple programs.

 

I never used Fred's program, but I assume that it adds a routine that moves the program to RAM, since turning a binary into a bank-switched cart is pretty difficult.

 

EDIT:  Finding appropriate difficulty ?

Edited by ralphb
On 8/7/2020 at 6:12 PM, PeteE said:

So you want to be able to create a cartridge binary from an .asm program that would normally load and start at >A000? 

Yes! @PeteE I basically want a single 32K .bin which I can use to run from FlashGROM or an emulator. I believe this is what Fred's Module Creator 2.0 builds and what @Tursi mentioned as a "copy cart" or EA5 loader. Your description of what I am trying to do is much better than my own so apologies for any confusion created by my earlier posts.

 

Something like this (which was built by @F.G. Kaal Module Creator 2.0 from a compiled-BASIC program's EA5 .obj files):

SCRAA.bin

2 hours ago, ralphb said:

That also explains why xas99 -c wasn't working -- the -c option only supports 8K carts.  As I said, I don't recommend it except for simple programs.

 

I never used Fred's program, but I assume that it adds a routine that moves the program to RAM, since turning a binary into a bank-switched cart is pretty difficult.

 

EDIT:  Finding appropriate difficulty ?

The banked cart scheme I added to xas99.py can be added to the -c option as well.  I will do so and then send the pull request on github.  The trampoline to copy the code from the cart space to the RAM space was already done in my modified version, above, though I forgot to add a check and error message saying it requires the 32K expansion.  The limitation is that it only allows using the upper 24K of the expansion, and splits it into 6K chunks so there is room for the GPL header and trampoline in each bank.

  • Like 2
  • Thanks 1
6 hours ago, Airshack said:

This must be what Fred Kaal’s Module Creator is doing then? I had a 24k XB256 compiled BASIC program converted to 32k binary using this tool.

Yes, it's what my old one did too, but I moved my functionality into Classic99. Classic99 can also create loader carts from anything loaded into RAM (though, since you need to tell it the addresses it has turned out to be unpopular compared to the ease of an EA#5 converter ;) )

 

I pushed my changes to my github fork of xdt99, and made the pull request for @ralphb.  I've found the new banked cartridge option "-B" simplifies my workflow immensely by putting all the banks together in a single file that can be opened directly in classic99 or FinalGROM99.  I also changed the "-c" option that creates a .rpk for MAME so that it can create banked cartridges with pcb="paged378" in the layout.xml file.  With either option, I made it so that if the program is at >A000 it will insert the GPL header and trampoline and create a 32K banked image that will copy the program from each ROM bank to RAM and then run it.

 

If you want to try it, the direct link is: https://github.com/peberlein/xdt99/raw/master/xas99.py

  • Like 4
19 minutes ago, Tursi said:

You keep saying GPL header, but it's not a GROM, right? You just mean the Standard TI Header For Anything and Everything? ;)

 

Yeah, it's ROM not GROM.  I didn't realize it had an official name, and was following RalphB's convention (s).  ?

Edited by PeteE
  • Like 1
9 hours ago, PeteE said:

Yeah, it's ROM not GROM.  I didn't realize it had an official name, and was following RalphB's convention (s).  ?

The main reason is everything in a GROM Header works, but much of any other standard header do not function.

Very much like TI Basic program headers vs XB Program header are not the same.

Both can be used as program headers, but how those are set up are kind of backwards.

  • 2 weeks later...
On 8/1/2020 at 11:25 AM, Lee Stewart said:

 

I know talk is cheap, but I really do intend to move over to Ralph’s xdt99 tools soon. Comfort is my excuse as well. Perhaps I will make the move when I get to fbForth 2.0:13, which will happen, at the very least, when I get around to making fbForth 2.0 work with >1 MiB SAMS.

 

Hooboy! It may be quite a while before I can make use of xas99.py. The proscription of ‘$’ from labels will break fbForth. They are scattered all through the code—many inherited from TI Forth. I was so looking forward to making the move, but this will take a lot of time to sort out.

 

...lee

  • Sad 1
8 hours ago, Lee Stewart said:

 

Hooboy! It may be quite a while before I can make use of xas99.py. The proscription of ‘$’ from labels will break fbForth. They are scattered all through the code—many inherited from TI Forth. I was so looking forward to making the move, but this will take a lot of time to sort out.

 

...lee

 

Lee, perhaps it’s easier to patch xas99.py so that it tollerates ‘$’ in labels. 

Another possibility: for what it’s worth I’m using the dot “.” character as a delimiter in my labels and that works ok.

 

Edited by retroclouds
  • Thanks 1
3 hours ago, retroclouds said:

 

Lee, perhaps it’s easier to patch xas99.py so that it tollerates ‘$’ in labels. 

Another possibility: for what it’s worth I’m using the dot “.” character as a delimiter in my labels and that works ok.

 

Actually, I included $ in the list of forbidden symbols because $ has a special meaning, but of course you can still use it with other chars as label.

 

If you open xas99.py in an editor, search for "def valid", and in the return statement (should be line 846) just remove the $ sign from the last expression.  You might also remove other symbols, but since they all have special meaning in xas99, labels containing them might or might not work.

  • Like 1
  • Thanks 1
3 hours ago, ralphb said:

Actually, I included $ in the list of forbidden symbols because $ has a special meaning, but of course you can still use it with other chars as label.

 

If you open xas99.py in an editor, search for "def valid", and in the return statement (should be line 846) just remove the $ sign from the last expression.  You might also remove other symbols, but since they all have special meaning in xas99, labels containing them might or might not work.

 

Does not ‘$’ only have a special meaning in xas99.py when used by itself to represent the current program counter as is the case in the TI Assembler? I am trying to anticipate trouble before actually trying your and @retroclouds’s suggestion of patching xas99.py. I would expect label failures to be obvious, but I do worry about silent errors. I will definitely make a run at this with the suggested patch. Thanks for your assistance.

 

...lee

45 minutes ago, Lee Stewart said:

 

Does not ‘$’ only have a special meaning in xas99.py when used by itself to represent the current program counter as is the case in the TI Assembler? I am trying to anticipate trouble before actually trying your and @retroclouds’s suggestion of patching xas99.py. I would expect label failures to be obvious, but I do worry about silent errors. I will definitely make a run at this with the suggested patch. Thanks for your assistance.

 

...lee

Yeah, that's what I wanted to say. ?

 

Silent errors are quite unlikely.

 

For #, you can define such a label, but if you use it in any instance you would use a label in, xas99 issues a syntax error.  So you'd need to combine the use # with forgetting an @ to accidentally write mov b#1, r0, which would put the wrong value in r0, but only if you put the # in the correct 2nd position.

 

Using ! in a label is safe unless the label starts with !, in which case the label will be local.  This isn't a problem per se, but backward jumps would require a minus sign before the label.

 

And I hope nobody uses +-*/ in a label, or @.

 

EDIT:  I think I'll relax this validity check when I find some time.

Edited by ralphb
  • Like 1
  • Thanks 1

OK—I set up a master ALC file with COPY directives for all 27 of the separate files for fbForth 2.0. The first problem I ran into was thousands (could have just been many hundreds—didn’t count) of warnings that wanted to know if a symbol I used (which did not happen to be Rx) for a register was intended as an address. Half of the fbForth registers are referred to by mnemonic labels that occur in many hundreds to thousands of lines of code. Every one of those lines generates this warning. This makes warnings useless information for me, so I have no choice but to turn them off with the ‘-q’ option. I do not know whether other warnings are potentially this onerous, but perhaps at some point in the future, this warning could be quieted separately.

 

With warnings turned off, xas99 claimed there were about 70 errors I did not have with asm994a:

  • A handful of errors were caused by comments separated from code by only one space—easily fixed.
  • A few errors were due to use of ‘#’ in symbols. They were mnemonic, but with longer labels allowed, fixing them should be relatively painless.
  • 2 syntax errors: 
    • One was due to ‘#’ use—no prob.
    • But, I am flummoxed by the other one, which I presume is the text constant, ''', in the following line of code: 
      TIK__N DATA 1+TERMBT+PRECBT*LSHFT8+'''+TERMBT
  • The bulk of the errors were multiple symbols:
    • EQUates for the same values at the beginning of each bank that I use for clarity, but easy enough to live without the duplicates. They occur in a few other places as well, notably the Floating Point Library.
    • Labels of executable code that are at the same address in each bank but have different code in the startup bank. Because of this last situation I do not think I can mitigate this with a BANK ALL directive. I can manage different labels with adequate comments, I suppose.

I have not yet tried the BANK directives, but I do not suppose they will have any effect on the multiple-symbol errors. I realize that the multiple-symbol “errors” represent poor coding practice on my part, so I should probably bite the bullet and do the surgery.

 

...lee

I downloaded the latest xdt99. 

 

In 9d9damashi, I replaced symbols with # and $.

I had been using # as a shorthand for a numeric constant, and $ for the end of a block. 

 

I tried compiling the version of Raycaster on github, and it uses a "xas99.py -w". Any idea what -w  is?

 

  • Like 1

Hi Lee, I sent you a private message, but I will post it here also in case it is informative to others:

I made some changes to both the xas99.py assembler and your fbforth source code (from your web site) and got it to build.

I modified xas99.py as follows:

  • Allow $ in symbol names
  • Disable error "Invalid cross-bank access"
  • Disable warning "Treating as register, did you intend an @address"
  • Includes my changes to build a single file banked binary, option "-B"

I modified the fbforth source code:

  • Duplicate symbols prefixed with '!' to make local (xas99 extension)
  • Some duplicate EQUs commented out
  • Each AORG followed by BANK opcode to select bank (xas99 extension)
  • Changed single quote literal from ''' to '''' - xas99 escapes two singles quotes as one
  • Changed symbols containing #
  • Created fbforth.a99 which COPY's all sources into one

To build:

python xas99.py -B -R fbforth.a99 -L fbforth.lst -o fbforth_9.bin

I didn't bother to merge the cartridge headers using BANK ALL, but it can definitely work because I use it in my programs.

  • Like 1
  • Thanks 1
3 hours ago, Lee Stewart said:
    • But, I am flummoxed by the other one, which I presume is the text constant, ''', in the following line of code: 
      
      TIK__N DATA 1+TERMBT+PRECBT*LSHFT8+'''+TERMBT
  • The bulk of the errors were multiple symbols:
    • EQUates for the same values at the beginning of each bank that I use for clarity, but easy enough to live without the duplicates. They occur in a few other places as well, notably the Floating Point Library.

The problem is the ''' in the expression.  According to E/A manual, page 51, to include a quote in a string you need to double it.  Thus, your subexpression should be ''''.  Yours is like an undelimited string.

 

Regarding EQUs, if they all have the same value, you could replace them with the undocumented WEQU (weak EQU) instead, which allows redefinition with the same value.  But I actually plan to change that dehavior: EQU can be redefined with the same value, and WEQU can be redefined with a different value, but only for one value.  So I would recommend to comment out extra EQUs, or split your file into multiple files for each bank.  In the latter case, you have to extract the common symbols (EQUs) into a common file you can COPY into each bank file.

 

Also, -q (for older versions, -w) turns off all warnings.  On my TODO list is the introduction of classes, so you could disable only certain kinds of warnings.  Could you please give an example instruction that triggered the "... use as address" warning?  Using registers different from n and Rn is a bit unusual, but I see why you might want to do that.

 

(I've just seen that PeteE also answered some of these, thanks!)

  • Like 3
  • Thanks 1
4 hours ago, ralphb said:

Could you please give an example instruction that triggered the "... use as address" warning?

       S    *SP+,*SP

 

4 hours ago, ralphb said:

Using registers different from n and Rn is a bit unusual, but I see why you might want to do that.

 

fbForth inherited from TI Forth labels for registers different from Rx for the Forth registers. TI Forth changed R1 – R7 to TEMP1 – TEMP7, which I changed back. R8 – R15 are U (User variable area pointer), SP (parameter Stack Pointer), W (inner interpreter current Word pointer), LINK (LINKage for BL subroutines), CRU (obvious), IP (Interpretive Pointer), R (Return stack pointer), NEXT (NEXT instruction fetch routine in the inner interpreter).

 

...lee

  • Like 2
  • Thanks 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...