Assembly under emulation

[+Vorticon]

Hi.

I finally decided today to move the Ultimate Planet development from real hardware to emulation because my ram disk and IDE card are getting flaky and I did not want to risk losing my work to glitches. Besides, even with these cards, compilation is getting ever slower as the program grows in size.

 

Now, after moving my files to my PC, I need a little guidance on how to proceed from there. With my previous large assembly project (SkyChart), I had used V9T9 as my emulation platform, but the old PC I have dedicated to DOS is starting to also become unstable, so I figured I'll try a modern platform for a change.

 

I used TIDIR to convert my source files to PC text files, then used the ASM994a program to assemble them without errors or warnings generated. I ended up with a nice list file which will be very helpful for debugging, a hex object file, and a compressed object file (COF). I assume that only the latter is needed for running the program.

 

Here's my question: how do I convert that COF file to an option 3 file that will run under Classic 99? Using TIDIR, I converted it to TI file which yielded a V9t9 format, then converted to latter to TIFILES format, and finally tried to run it under Classic 99 only to get an I/O error 2. Where am I going wrong? Is there a better way to go about assembling source files under emulation outside of using the old creaky TI Assembler?

[ceratophyllum]

Hi.

I finally decided today to move the Ultimate Planet development from real hardware to emulation because my ram disk and IDE card are getting flaky and I did not want to risk losing my work to glitches. Besides, even with these cards, compilation is getting ever slower as the program grows in size.

 

Now, after moving my files to my PC, I need a little guidance on how to proceed from there. With my previous large assembly project (SkyChart), I had used V9T9 as my emulation platform, but the old PC I have dedicated to DOS is starting to also become unstable, so I figured I'll try a modern platform for a change.

 

I used TIDIR to convert my source files to PC text files, then used the ASM994a program to assemble them without errors or warnings generated. I ended up with a nice list file which will be very helpful for debugging, a hex object file, and a compressed object file (COF). I assume that only the latter is needed for running the program.

 

Here's my question: how do I convert that COF file to an option 3 file that will run under Classic 99? Using TIDIR, I converted it to TI file which yielded a V9t9 format, then converted to latter to TIFILES format, and finally tried to run it under Classic 99 only to get an I/O error 2. Where am I going wrong? Is there a better way to go about assembling source files under emulation outside of using the old creaky TI Assembler?

 

Why not just build a Hex object file in win994a's assembler, throw it in the DSK1 directory under classic99, and load and run it in EA or MM.

I just tried the first example in the famous "Assembly My Way" thread and it worked ok.

[+Vorticon]

 

Why not just build a Hex object file in win994a's assembler, throw it in the DSK1 directory under classic99, and load and run it in EA or MM.

I just tried the first example in the famous "Assembly My Way" thread and it worked ok.

So if I understand you correctly, you just take the hex object file produced by the assembler, which is essentially a PC text file, throw it in Classic 99' DSK1 without converting it to TI format and load it with EA option 3? This really should not work, and as far as I can tell it does not. Can you please detail exactly what you are doing so I can try to duplicate it?

I thought that EA #3 required a compressed object code, not a hex list file...

[ceratophyllum]

Actually, I happened to have Mini Memory loaded and used option one "Load and Run." I tried a bigger program and it worked too.

Just tested the obj file with EA opt3 and it works there too.

***********************************************************
*                    CALL KEY (1,KEY,STATUS)            *
* This module will input from arrow keys(E,D,X,S)    *
* and display a message indicating the pressed key.  *
***********************************************************
   DEF   BEGIN              * Reference needed utilities.
   REF   KSCAN,VMBW         * Address to select keyboard
KBOARD EQU   >8374           * Holds ASCII # of pressed key
KEY    EQU   >8375           
*
KEYUP BYTE 5                 *             ASCII values
KEYRT BYTE 3                 *           of E, D, X and S
KEYDN BYTE 0                 *               keys
KEYLT BYTE 2                 *
HEXFF BYTE >FF               * No key pressed value
ONE   BYTE 1                 *
*
UP    TEXT   'UP KEY PRESSED     '
RIGHT TEXT    'RIGHT KEY PRESSED'
DOWN  TEXT   'DOWN KEY PRESSED '
LEFT  TEXT   'LEFT KEY PRESSED '
   EVEN
*
MYREG BSS    >20
*
BEGIN LWPI MYREG
   MOVB @ONE,@KBOARD      * Check left side of keyboard.
LOOP   BLWP @KSCAN         * Check for keyboard input.
   CB    @HEXFF,@KEY      * Was a key pressed?
   JEQ   LOOP             *
   CB    @KEYUP,@KEY      * Compare to see which
   JEQ   PUP              * arrow key was pressed.
   CB   @KEYRT,@KEY
   JEQ  PRIGHT
   CB   @KEYDN,@KEY
   JEQ  PDOWN       
   CB   @KEYLT,@KEY 
   JEQ  PLEFT       
   B    @LOOP       *  If key not found, LOOP again.
PUP    LI   R1,UP    *  Load
   B    @PRINT      *       correct
PRIGHT LI   R1,RIGHT *               message
   B    @PRINT      *                       into
PDOWN LI    R1,DOWN  *                            R1
   B    @PRINT      *
PLEFT LI    R1,LEFT  
   B    @PRINT      
*
PRINT LI    R0,138    * Print
   LI   R2,17       *     message on
   BLWP @VMBW       *                screen
   B    @LOOP       * Repeat program
   END              * End program.

 

I compiled the text above in Win994a with "Def Regs" and "Produce hex obj file" checked.

This cut & pasted from chapter 7 of beginning assembly for the TI.

There was only one typo! I was interested in seeing about

some way to scan keys faster than basic.

 

The file's attached.

key.zip

[+Vorticon]

OK well I'm stumped then... I'm attaching my source file for Asm994a, so could you please see if you are able to assemble it and run it under EA#3?

planet_s.zip

[ceratophyllum]

ok, it works. zipped object included below.

planobj.zip

Edited March 21, 2011 by ceratophyllum

[+Vorticon]

Thanks

I did figure it out: I was deleting the .obj suffix before running the file. This is definitely not a standard way of loading files, but I guess emulators are allowed artistic license he he...

Now my problem is that Asm994a is not assembling the source code correctly because that hex field you get when you start the program should have been populated with units (check the Ultimate Planet posts for pictures). The units are there, just not being displayed for some odd reason. The source code assembles fine when using the standard assembler under the EA cart in Classic 99, so I guess it must be a bug with Asm994a or maybe it's expecting something I am not providing. It came with only a skeleton of docs, so I don't know how to fix this. Suddenly V9t9 is starting to look real good now

[+Vorticon]

.

Edited March 21, 2011 by Vorticon

[matthew180]

The first thing you need to do is make sure you have the 3.010 version of Asm994a. This version was not yet released (AFAIK), but Cory sent Tursi an update due to a bug with one of the jump instructions producing the wrong object code. I found the bug the hard way (discovered it on my own while writing FlyGuy II). You can search the forum for the exact instruction since I can't remember. If you don't have the 3.010 version, PM me.

 

As for work flow, setting up a cartridge based program is absolutely the fastest. The work flow is like this:

 

1. Open your text editor for coding (I use Textpad, but Notepad++ is good too.)

 

2. Open asm994a and set up a project:

 

Add your source files.

 

Checked: DEF REGS

Unchecked: Use your fav equ/def

Checked: Produce listing

Checked: Produce hex object

Unchecked: Compressed Obj

Checked: Produce Cart BIN File

 

Specify listing file

Specify hex object file

I do NOT use compressed binary files, never have, never knew what could read them.

Specify cartridge binary file. This step is what makes this process so fast. Make sure your file name ends with a 'C.bin' as required by Classic99. For example, with flyguy my binary file name was: flyguyC.bin

 

Run the assembler once to get the binary file.

 

3. Open Classic99

 

Select Cartridge->User->Open and navigate to your program_nameC.bin file and select it. Now you can select your game from the TI menu to run and test it.

 

At this point, your work flow goes like this:

 

1. Edit in your text editor. Save.

2. Hit the "Assemble" button in asm994a. Make sure there are no errors.

3. Select File->Reset in Classic99, then '2' '2' (any key from the master title screen, then '2' to select your program)

 

That's it. It is *very* fast and works because Classic99 graciously rereads the cartridge binary file every time you do a "reset". And since asm994a writes the binary file every time you assemble, it all goes very smoothly. Of course you have to have your program set up to be compiled as a cartridge, which is not really that hard, but you also have to remember the restrictions of coding for a fixed location program, i.e. one that uses AORG.

 

 

Method 2: Using the E/A to run. This method also works because Tursi does a nice job about reading files with Classic99!

 

1. Open your text editor for coding.

 

2. Open asm994a and set up a project:

 

Add your source files.

 

Checked: DEF REGS

Unchecked: Use your fav equ/def

Checked: Produce listing

Checked: Produce hex object

Unchecked: Compressed Obj

Unchecked: Produce Cart BIN File

 

Specify listing file

Specify hex object file (yes, it can end with .obj) *MAKE SURE* you specify the object file in the DSK1, DSK2, or DSK3 directory under your Classic99 directory.

No compressed binary file

No cartridge binary file

 

Run the assembler.

 

3. Open Classic99 and make sure you have the E/A cart selected via Cartridge->Apps->Editor Assembler.

 

4. Hit '2' '2' from the Master Title Screen and select E/A option 3 (Load and Run)

 

5. For your object file, type DSK1.program_name.obj (yes, you can have the .obj extension!).

 

6. Hit enter to skip loading another object file.

 

7. Type the start name in your program to run the code.

 

8. Select File->Reset to start over.

 

 

Now your work flow is a little more involved on the emulator side:

 

1. Edit in your text editor. Save.

2. Hit the "Assemble" button in asm994a. Make sure there are no errors.

3. Select File->Reset in Classic99, then '2' '2' (any key from the master title screen, then '2' to select the Editor Assembler)

4. Select option 3 (Load and Run)

5. Type your object file

6. Enter

7. Type the program entry point to run

 

That's it. Thanks to Classic99 being able to read TI file from the PC's drive, you don't have to fuss with converting to/from PC/TI formats for testing, running, etc.

 

Hope this helps.

[Tursi]

It's important to know why things are happening, so please take the time to read the manual. I put in pictures!

 

Classic99 uses the extensions COB, OBJ (for Asm99 output) and TXT to determine that a file might be a WINDOWS text file instead of a TI file. You can configure this behaviour so that it will also take files without an extension as Windows text, but by default the extension must be there.

 

Classic99 does not emulate the TI disk controller. It emulates a "Classic99" disk controller, which interacts in the same way as the real one will when I build it this summer. There is nothing in the TI operating system that says a file device is limited to the restrictions of the TI disk controller, that just sort of became the convention.

 

Anyway, the way that it identifies a file is like so. If any of these steps are disabled in configuration, it is completely skipped. The steps are always done in order, which is important to know when there is more than one possible result.

 

1) Check for TIFILES header by testing the first 8 bytes of the file - return as TIFILES if pattern found.

2) Check for V9T9 header by doing a fuzzy match of the first 10 characters of the file with the filename - return as V9T9 if match succeeds.

3) Check for a Windows extension of COB, OBJ or TXT. Return as Windows text file if so.

4) If "Allow text files without extension" is on (it's not by default in the current build but it IS in old builds), and there is NO Windows extension on the file, then return as Windows text file.

5) If "Allow no header as DF128" is on (it /is/ on by default) and there is no extension, return a file type of DF/128. This matches the file type that files transferred to the TI via XMODEM would be if they had no header.

6) If none of the above options were matched (non-default configuration), give up and return unidentified file.

 

Asm994A does have SOME bugs, if you are using the version from the Win994a distribution, I am not sure if the jmp opcode bug is fixed yet. (Does anyone know?) Corey gave me a temporary fix over a year ago that you can install into the folder just to try it: http://harmlesslion.com/temp/WinAsm99.zip - I recommend you save the original file just in case this is no better. The only other bug I'm aware of involves using the BYTE directive before any DATA directives, it sometimes drops the first byte in my experience. It's also aggressive in my experience about alignment, and mixing TEXT, BYTE, and DATA directives may end up with alignment bytes inbetween.

 

The worst is that some of these bugs do not show up in the listing file, so it may be helpful to use Classic99's debugger to make sure the tables are correct when they are loaded in memory.

 

Otherwise, maybe you've found a Classic99 bug.

[matthew180]

I documented the troubles with the asm994a assembler somewhere in this forum, and specified the differences between what you can do with TI's assembler that you can not with asm994a. Like Tursi said, it mostly has to do with the alignment and assembler directives BYTE, DATA, and TEXT. And of course the jump instruction bug.

[Tursi]

Thanks, Matthew, looks like we were writing at the same time! Two comments:

 

I do NOT use compressed binary files, never have, never knew what could read them.

 

E/A#3 can read them, too, it's the same tagged object file format, but instead of the data being spelled out as 4 hex bytes, it's stored as two binary bytes. It /usually/ works okay to ask Classic99 to read it as text, but it's easy for a binary byte to screw up a text file, so it's not recommended to use that feature in Classic99. XB can not read compressed assembler files either. In TI's Assembler, the 'C' option wrote these files, and they are DV80 instead of DF80.

 

The other comment is just on the workflow using Editor/Assembler instead of a cartridge. I find it faster to hit FCTN-= than File->Reset.. since you don't have to reload the ROM it's a menu you don't have to navigate. Personal preference, though. Another thing that's useful if you are doing a LOT of rapid iteration with a number of startup commands (I use this both for Editor/Assembler and certain types of XB), is to take advantage of the Edit->Paste command. Since it simulates keypresses, and since it waits for actual calls to KSCAN, you can use it to navigate the whole menu stream. I'll sometimes set up a notepad window with contents like this:

 

223DSK1.MYOBJFILE.OBJ

 

START

 

Basically all the keypresses needed to get in there and start the app. Then to run, I focus the Notepad, hit Control-A (select all), Control-C (copy), switch to Classic99, reset the emulator (either way), and select Edit->Paste.

 

In XB I was doing this a lot when I was playing with the Missing Link and my TMNT program, trying numerous things that would often crash the system. Same with the XB bitmap loader.

 

There are tons of ways in though.. you'll find what's most comfy for you.

[+Vorticon]

Thanks Matt

Option 2 is what I have settled on with the help of ceratophyllum, assuming I can get Asm994a to assemble correctly. I have version 3.009, and if you can email me the newer version I would greatly appreciate it! I am too far into the program to convert it to cart format at this point, although I might consider it once it's complete and if there is enough interest out there.

Otherwise, my only option will be to replicate my real hardware workflow using PReditor for editing and the EA assembler, which will also work fine with me as I am quite used to it and will be pretty speedy under Classic 99 with Overdrive on.

I was planning on doing some work on Ultimate Planet this afternoon, and I ended up spending most of my time figuring out how to work with the emulators In the long run though this will be a better option from a reliability standpoint.

[+Vorticon]

It's important to know why things are happening, so please take the time to read the manual. I put in pictures!

Sorry but my eyes glazed over when I saw it was 43 pages! In retrospect, given the time I spent today trying to figure things out, I should have read the manual first

 

Asm994A does have SOME bugs, if you are using the version from the Win994a distribution, I am not sure if the jmp opcode bug is fixed yet. (Does anyone know?) Corey gave me a temporary fix over a year ago that you can install into the folder just to try it: http://harmlesslion.com/temp/WinAsm99.zip - I recommend you save the original file just in case this is no better. The only other bug I'm aware of involves using the BYTE directive before any DATA directives, it sometimes drops the first byte in my experience. It's also aggressive in my experience about alignment, and mixing TEXT, BYTE, and DATA directives may end up with alignment bytes inbetween.

 

The worst is that some of these bugs do not show up in the listing file, so it may be helpful to use Classic99's debugger to make sure the tables are correct when they are loaded in memory.

That's the thing! The listing looks perfectly fine, so I could not figure out where the issue was...

[+Vorticon]

I documented the troubles with the asm994a assembler somewhere in this forum, and specified the differences between what you can do with TI's assembler that you can not with asm994a. Like Tursi said, it mostly has to do with the alignment and assembler directives BYTE, DATA, and TEXT. And of course the jump instruction bug.

What I like most about it is the speed of compilation and the fact that I am not limited by the size of the source files as I am under the TI environment. Coupled with Classic 99's ability to process the object files directly without conversion really makes for an ideal development package.

Now how would one convert these object files to work on real hardware?

Edited March 21, 2011 by Vorticon

[matthew180]

I'll sometimes set up a notepad window with contents like this:

 

223DSK1.MYOBJFILE.OBJ

 

START

 

Basically all the keypresses needed to get in there and start the app. Then to run, I focus the Notepad, hit Control-A (select all), Control-C (copy), switch to Classic99, reset the emulator (either way), and select Edit->Paste.

 

That is sweet! Thanks for that info, I will definitely use that!

 

As for FCTN-quit vs. the File->Reset, well, I usually forget to LIMI 2 for my loops, so my code does not honor the keystroke...

[matthew180]

Now how would one convert these object files to work on real hardware?

 

You don't have to "convert them", they are already TI hardware ready. You only have to get them over to your real TI, and for that, if you have a CF7, you can use TI-DIR. If you don't have a CF7, then you can use MagicFM. Finally, you can take that cartridge .bin file created by asm994a, burn it to an EPROM, and stick it in a multi-cart board and plug it in to your TI.

[+Vorticon]

Now how would one convert these object files to work on real hardware?

 

You don't have to "convert them", they are already TI hardware ready. You only have to get them over to your real TI, and for that, if you have a CF7, you can use TI-DIR. If you don't have a CF7, then you can use MagicFM. Finally, you can take that cartridge .bin file created by asm994a, burn it to an EPROM, and stick it in a multi-cart board and plug it in to your TI.

The reason I asked is because TIDIR labels them as DOS type... That's easy enough then. Thanks.

[matthew180]

The best way to know is to try. If TIdir says it it a DOS file, it may be due to end-of-line character, or simply because the file is sitting on a PC filesystem without any kind of header or wrapper, like a TI-Files header or something. I typically find that, with a little messing around in TIdir, I can usually get the files in to whatever format I need. It all depends on how you are going to get the object file to your real hardware.

[ceratophyllum]

Asm994A does have SOME bugs, if you are using the version from the Win994a distribution, I am not sure if the jmp opcode bug is fixed yet. (Does anyone know?) Corey gave me a temporary fix over a year ago that you can install into the folder just to try it: http://harmlesslion....mp/WinAsm99.zip - I recommend you save the original file just in case this is no better. The only other bug I'm aware of involves using the BYTE directive before any DATA directives, it sometimes drops the first byte in my experience. It's also aggressive in my experience about alignment, and mixing TEXT, BYTE, and DATA directives may end up with alignment bytes inbetween.

 

I couldn't sleep so I tried out the fixed winasm99 above.

Vorticon's game seems to work better with assembled with the bugfixed asm994a.

The game pieces appear and you can move them around.

Not sure what else planet_s should do at this point.

[RXB]

Everyone is using Assembly only. Using the Ryte Data GPL assember is similar but the Ryte Data one is a endless pass assembler. You guys should disassemble it and use it instead.

When I assemble GPL my options are:

LCSFPF

 

L = Generate a List file.

C= Compressed Object file (For GPL the only loader is GPL*LOADER that only loads Compressed format into GRAMS)

S= Symbol table, now F means 16 passes of symbols to make sure all of them are assigned and not duplicates.

P= Passes this is where the endless pass comes in when you use F that means 16 passes it will continue to make passes on the code resolving endlessly.

 

The reason why I say that this assembler is better is that it was writtin by the best minds the TI community ever had.

Almost all the stuff we know today is by mostly this group of guys that started the TI market for third party Cartridges, devices and programming.

 

I am icluding a attachement from PC99 as that is where the first copy appeard for Emulators.

 

If you get the RXB GPL Source files you can see tons of GPL Code. Or included on the CYC CD are some examples along with tutorials.

Edited March 21, 2011 by RXB

[+Vorticon]

Asm994A does have SOME bugs, if you are using the version from the Win994a distribution, I am not sure if the jmp opcode bug is fixed yet. (Does anyone know?) Corey gave me a temporary fix over a year ago that you can install into the folder just to try it: http://harmlesslion....mp/WinAsm99.zip - I recommend you save the original file just in case this is no better. The only other bug I'm aware of involves using the BYTE directive before any DATA directives, it sometimes drops the first byte in my experience. It's also aggressive in my experience about alignment, and mixing TEXT, BYTE, and DATA directives may end up with alignment bytes inbetween.

 

I couldn't sleep so I tried out the fixed winasm99 above.

Vorticon's game seems to work better with assembled with the bugfixed asm994a.

The game pieces appear and you can move them around.

Not sure what else planet_s should do at this point.

Yes, that did it. I'm now all set to resume development

As for the current state of the game, that's pretty much all you can do at the moment. I have several sheets of handwritten code I need to type in that will provide additional things like jettisoning units from transports and some other minor enhancements, and I should get that done this week (with debugging likely to take most of that time...).

The AI will be next.

[matthew180]

What are you using for an editor? Also, make sure you have some syntax highlighting set up. It makes a difference!

[+Vorticon]

What are you using for an editor? Also, make sure you have some syntax highlighting set up. It makes a difference!

I settled on Notepad++. Makes the source much more readable. I could get used to this

Edited March 22, 2011 by Vorticon

[Tursi]

Someone made a syntax highlighting file for Notepad++, didn't they?

 

I still haven't got into that. But maybe I could.

 

The bug in Asm994a was that one of the jump instructions (JH?) assembled to a different kind of jump. So it was a pretty important one!

Edited March 22, 2011 by Tursi