Converting EA3 to SSS cart

[tmop69]

I would like to convert some EA files into cart to run them using the FinalGROM on real TI and also on my MiSTer. I know how to convert the EA5 files using Tursi's tool or the Module Creator 2 program, but these tools are not accepting the EA3 format. I've tried to convert them using Classic99, using the debugger option, but without success.

 

Could someone be so kind to provide a step-by-step guide for this conversion process with Classic99 (or MAME/MESS)?

 

Moreover, I've one question for our experts in the forum:
is it technically possible to create a SSS image of the Adventure module (or the Tunnels of Doom) that includes also the file of the adventure that is loaded from tape/file?
Similarly, is it possible to create a SSS module image of the Extended Basic with a loaded XBasic program?

 

Many thanks.

[+mizapf]

Sounds difficult.

 

1. The EA3 format is a relocatible file format that allows for linking with external libraries. The EA5 does not; it assumes that all libraries are already linked into the file. There is a standard conversion practise, but it requires to know where the EA3 code is loaded into memory (can be done with the SFIRST, SLOAD, SLAST symbols, but you'd need the source code). All required libs must have been loaded as well. As you see, it is not just the file format. If the file does not depend on external libs, this may be quite easy, though.

 

2. The Adventure module expects the game in video RAM. Also, the Adventure loader prompts you for a file name. How would you specify that it should get the bytes from GROM or ROM? It is not impossible, but you'd have to patch the Adventure cartridge loader appropriately.

 

[HOME AUTOMATION]

One issue is that, unless the program was written to run from ROM, it likely wont, because many 9900 instuctions manipulte their destination operand. The FG99 can provide some RAM, but only 4K blocks, from >7000 thru >7FFF.

If your programs are small and you load them into that RAM space, using the MINI MEMORY .bin file, you can than look up the entry address in the REF/DEF table, erase all else and write your own header.

 

Alternately, if you have the SOURCE file, you can use AORG to choose your exact load destination.

[tmop69]

On 11/29/2019 at 7:19 PM, HOME AUTOMATION said:

One issue is that, unless the program was written to run from ROM, it likely wont, because many 9900 instuctions manipulte their destination operand. The FG99 can provide some RAM, but only 4K blocks, from >7000 thru >7FFF.

If your programs are small and you load them into that RAM space, using the MINI MEMORY .bin file, you can than look up the entry address in the REF/DEF table, erase all else and write your own header.

 

Alternately, if you have the SOURCE file, you can use AORG to choose your exact load destination.

 

This is an interesting observation. Surely if you intend to program for a read only memory it's necessary to avoid such development approach.

 

For the conversion of EA3 files the idea was to use the cartridge just as a storage medium istead of using the disk. The program will be executed using the 32K RAM, as in the modules converted using Tursi's MakeCart or the Module Creator 2 program.

 

The MiSTer core for the TI99 does not (yet?) support the disk, so the only choice to run disk games is to convert to a cart. On my real TI99 I have a 32K memory espansion and a FinalGROM, but not the PEB or a nanoPEB.
 

[HOME AUTOMATION]

I'm afraid that I'm not yet familiar with Mister or the other tools you've mentioned. I usually try to do things manually, or write my own tools.

Since you want to run from 32k anyway, best to load the program there initially... Then if you don't have the source code, you can look it up in the REF/DEF table. The E/A and MM loaders both load to >A000 by default. The entry address could be poked into the header by using EASY BUG and the FG99's MM save option. Alternately, you could use a HEX EDITOR on a dump from Classic99.

 

Do you have an example program?

[tmop69]

1 hour ago, HOME AUTOMATION said:

I'm afraid that I'm not yet familiar with Mister or the other tools you've mentioned. I usually try to do things manually, or write my own tools.

Since you want to run from 32k anyway, best to load the program there initially... Then if you don't have the source code, you can look it up in the REF/DEF table. The E/A and MM loaders both load to >A000 by default. The entry address could be poked into the header by using EASY BUG and the FG99's MM save option. Alternately, you could use a HEX EDITOR on a dump from Classic99.

 

Do you have an example program?

 

I've tried the following with the game "Astiroids" by Bill Bies:

 

- in Classic99 with EA module I've loaded the game (option 3, Load and Run). The game starts automatically when loaded;
- at the initial screen, I've selected the Debugger and paused it;
- from Make menu in debugger, I've selected the Save memory. For the Save Type I've choosed "GROM Copy" with High RAM from >A000 to >FFFF, inserted a cartridge name and set the start address to >A000. Not set any flag, except for the recommended "Initialize keyboard". Then I've generated a .bin file pressing the Build button.
- I've then loaded the .bin file and I can correctly see the cartridge name in the option menu, but when selected it just returns to the initial TI99 screen after few seconds.

 

Looking at the .bin file with and Hex Editor I can see that there are data in the first 8KB (the original file size is approx. that size).

 

So, you suggest to place the >A000 address in the .bin file with an Hex Editor on this dump. At which position of the header exactly?

 

In attachment the file generated in this test.

astiroidsG.BIN

[Tursi]

After a title starts is too late for many programs to make the cartridge. You want to set a breakpoint so that it stops on the first instruction. That way, loading from cartridge will behave mostly the same as loading from disk. If you start later, there's no guarantee that the program will be able to resume, as (for instance) CPU state is not saved in the cart, nor is scratchpad. Only the program is saved. Even if you restart from the beginning, it might not work. Some programs pre-initialize their variables as part of the program load, others may use self modifying code during startup.

 

If you post the EA#3 for this Astiroids I'll walk you through it. I need to make a new video anyway.

 

[HOME AUTOMATION]

Hi Tursi!

 

I've been fooling with this today myself...

...I could use a good walk.

 

I tried setting the breakpoint at the entry address(A000), it helped a little, before that the games entry screen wouldn't even come up!

I think the OBJECT file is compressed, just a little extra challenge for me!

I'm starting execution from EASY BUG (E7A30)... this switches to page 2, loads utilities to LOMEM, switches back to page 1 and copies the game program up to HIMEM, then executes. 

Still the game crashes! arrrg. I'm losing patience with this!

 

 

                    astiroids.dsk

 

                    Converting EA3 to SSS cart(BAD).zip

[Tursi]

Well, that was a challenge.  In fact I almost gave up and only noticed the cause in my last moments...

 

Ultimately, there were two problems. On your side, you were missing the E/A utilities - this game requires them. Unfortunately, Classic99's E/A utilities are corrupted in the current build (but if you declined to load them you could have still manually saved the low memory). I'll have to put out a new load.

 

The second I consider a bug in the game - it never sets the workspace. It just relies on whatever it was started with. This is fine for an EA#3 because you are guaranteed a safe workspace, but you have to do better initialization to run in other loaders. In this case, I found that it worked from a ROM copy cart, but not GROM, and I went through every byte of difference in RAM to no avail. Eventually, I found that the cause was something corrupting R15 in the GPL workspace (which manages the pointer to VDP RAM). A breakpoint showed me that was the program, and I realized it was not expecting to run in the GPL workspace, which the GROM loader starts it in. (The ROM loader starts at >8300, which is free memory, and the EA#3 loader starts at >20BA in low RAM).

 

I patched the program to set its workspace at startup, and that's what you have here.

 

ASTIROIDS_G.zip 

 

I streamed it live - muttering, swearing, and inadvertent racy backdrops whole. You probably actually had the correct process, and I demonstrate that fully in the first 15 minutes. But since it didn't work, I spent the rest of the time working out why not.

 

I finally succeed and show how to patch it at around 1h21.

 

https://www.twitch.tv/videos/516049648

(Twitch streams die after about 2 weeks, future warning )

 

[blackbox]

To change an assembly program from EA3 to EA5, take a look at R A Green's Linker program, which appears to add the required EdAs modules utilities to the EA5 output for you. Worth a look.

 

raglinker.dsk

[tmop69]

10 hours ago, Tursi said:

Well, that was a challenge.  In fact I almost gave up and only noticed the cause in my last moments...

 

So I've incidentally selected a tough example to start... good to have provided an interesting challenge for you to have fun with. ?

 

Your twitch streaming it's extremely interesting! I've started looking at it to learn the techniques used and I'll try to apply them to convert other games.

Many thanks for sharing, I really appreciated it!

 

I think a similar method could be used to create a patched version of the Adventure module (or the Tunnels of Doom) with a preloaded game, instead of loading from disk/tape.

 

And similarly for TI Basic/TI Extended Basic. I remember to have seen a cartridge file for the V9T9 emulator with the Robopod game. It wasn't compiled, since it was slow as the original game, except for the loading time that was immediate.

 

[HOME AUTOMATION]

Yea! Tursi,

 

I spent as much time or more fooling with my, somewhat forgotten, page switcher code ...as did you, with your own tools.

 

From my perspective at the time, it seemed likely that the issue related to EASY BUG having a somewhat different "hand-off". When I got there... I realized I should have saved the R11 return address... So I went back to fix this first... You should have tried it from where I had left off in EASY BUG... you would have probably solved it in a couple minutes! However your video is inciting ...in more ways than one!

The Cart Make/Save feature, in Classic 99's Debugger looked good, but did need some explaining. Maybe I should have read the manual.

 

So, armed with your advice, I added four bytes(LWPI >8300)... that did the trick! E7A30 to execute from EASY BUG.

 

Converting EA3 to SSS cart(runs).zip

 

Next, I copied the header from AMBULANCE, than edited it appropriately.
The phm3058C.BIN(ok to rename), can be used stand alone or with MINI MEMORY's phm3058G.BIN.

Note that, if you load the game directly from FG99's selection list, the GROM will be ignored.

 

Converting EA3 to SSS cart(successful).zip.zip

 

Finally, if you get stuck and want to debug on real hardware, instead of on the PC, EASY BUG and the LINE by LINE ASSEMBLER are at least second or third best.

So... Here I have returned the MINI MEMORY's ROM and RAM images, preloaded with LINE by LINE ASSEMBLER and LINES. There are also 56 bytes of boot code to get the game going... The utils load from PAGE 2, the game from PAGE 3, E7FCO does it all automatically.

 

MINIMEM, L by L, and Astiroids.zip

 

Maybe I'll replace LINES, with a small program to move code from CPU RAM to different pages in the MINI MEMORY's image, so that, programs and data can be written with the LINE by LINE ASSEMBLER and then moved easily.

 

   P.S. Tursi, nice job trimming the game program down. I missed that.

 

              ...Have fun  

                 -Alex
 

[Tursi]

On 12/2/2019 at 12:37 PM, tmop69 said:

And similarly for TI Basic/TI Extended Basic. I remember to have seen a cartridge file for the V9T9 emulator with the Robopod game. It wasn't compiled, since it was slow as the original game, except for the loading time that was immediate.

Classic99 has that built in.  (Edit: well, for BASIC anyway, not XB)

 

My recommendation is to have your BASIC program change the screen color right BEFORE the title page displays, then set a VDP breakpoint for that color register change. When it breakpoints, you can save a TI BASIC Restore, which gives you a 16k cartridge ready to go. It will load the BASIC state back into memory and resume the GPL interpreter, so you get the instant start. This way the BASIC program can do all its CALL CHARs and the like and that will be instant from the cartridge, but break-pointing BEFORE the title page is because I don't save the screen, in order to have a little space for setup code.

Edited December 4, 2019 by Tursi

[ti99iuc]

i would love to see the TI BASIC game Morphy on a cartridge ?

[Tursi]

20 hours ago, HOME AUTOMATION said:

From my perspective at the time, it seemed likely that the issue related to EASY BUG having a somewhat different "hand-off". When I got there... I realized I should have saved the R11 return address... So I went back to fix this first... You should have tried it from where I had left off in EASY BUG... you would have probably solved it in a couple minutes!

Aw, maybe. It was clear to me you did a lot of work, but I didn't know what you meant by an "SSS Cart" or what pages you were talking about. I didn't want to get pulled into the whole task of hacking up the Adventure cart so I just grabbed what looked like the simpler example.

 

[tmop69]

20 hours ago, Tursi said:

Classic99 has that built in.  (Edit: well, for BASIC anyway, not XB)

 

My recommendation is to have your BASIC program change the screen color right BEFORE the title page displays, then set a VDP breakpoint for that color register change. When it breakpoints, you can save a TI BASIC Restore, which gives you a 16k cartridge ready to go. It will load the BASIC state back into memory and resume the GPL interpreter, so you get the instant start. This way the BASIC program can do all its CALL CHARs and the like and that will be instant from the cartridge, but break-pointing BEFORE the title page is because I don't save the screen, in order to have a little space for setup code.

 

Hi Tursi,

I've tested using a simple BASIC program:

 

1 CALL SCREEN (16)
10 CALL CLEAR
20 CALL SCREEN (3)
30 FOR T=1 TO 100
40 PRINT "A TEST!"
50 NEXT T

 

I've then set the VDP breakpoint: U7=0F

I've run the program, that is halting at line 1 and saved a TI BASIC Restore (in attachment), but when I try to run the .bin in Classic99 I've just getting a noise.

 

BASIC LOOP TEST_8.BIN

[Tursi]

Haha, really good catch! I messed up when I changed the default mode of these carts from type 9 to type 8. The TI BASIC loader only stores the init code in one bank, and that change made it the wrong bank! Change the filename to BASIC_LOOP_TEST_9.BIN (bad practice to use spaces in filenames) and it will work. I'll fix that in the next push too.

[tmop69]

23 hours ago, Tursi said:

Haha, really good catch! I messed up when I changed the default mode of these carts from type 9 to type 8. The TI BASIC loader only stores the init code in one bank, and that change made it the wrong bank! Change the filename to BASIC_LOOP_TEST_9.BIN (bad practice to use spaces in filenames) and it will work. I'll fix that in the next push too.

Yesss, it's working! And the feature is also described in the manual, so too bad to not have read it before asking... ?

 

This is definitely a very cool and useful feature. If you have a FinalGROM, but not a PEB or nanoPEB this will save a lot of time if you want to run a TI BASIC program. The tape is really too slow for 2019...

Moreover, now it's possible to run a TI BASIC program also with the TI99 core in MiSTer, that, unfortunately has not (yet?) the disk support.

 

So, Tursi, many thanks for coding this! And what about a similar feature for the XB programs in a future upgrade? ?

 

In attachment a test with a real TI BASIC program. I've tested it on MiSTer (after having inverted the cart) and it's working fine. Setting the CPU Turbo to ON in the core is also improving the whole game experience. ?

 

I'll try now to convert Morphy for my friend Ciro.

 

Daddie's_Hot_Rod_9.BIN Daddie's_Hot_Rod_8.BIN

[Tursi]

XB is a bit more complex, since in addition to the loader cartridge, you need Extended BASIC! You also have to deal with the 32K memory expansion, and whether you use the 32K or not will affect whether the program runs on systems without 32K.

 

It's probably doable, but it's a lot of fiddly work to be sure it's reliable. I don't see myself doing it soon.

 

[ti99iuc]

21 minutes ago, tmop69 said:

[...]

I'll try now to convert Morphy for my friend Ciro.

Thanks TMop!  it would be very cool.
anyway i know that Morphy is very hard to convert because the steps to load it to have the sprite in TI BASIC.
but thanks in advance if you will try, i really appreciate it

[tmop69]

On 12/5/2019 at 10:50 PM, ti99iuc said:

Thanks TMop!  it would be very cool.
anyway i know that Morphy is very hard to convert because the steps to load it to have the sprite in TI BASIC.
but thanks in advance if you will try, i really appreciate it

I've tried with Morphy. This is a special TI BASIC program that uses sprites with a loader that modifies VDP. It have to be run from tape, without any expansion. There is a MM version that simplifies the loading process, so I've tried first with this one. I've disabled the SAMS expansion. To avoid a memory full error at run, after selecting the TI BASIC from MM, I've used the following sequence:

 

 CALL FILES(0)
 OLD DSK1.MORPHY-MM
 CALL FILES(0)
 RUN

 

The breakpoint was set to U7=03. I've dumped the TI BASIC, that is a C file, so I've replaced the C file of the MM with the dump. Unfortunately, when I run the MORPHY menu there is a syntax error at line 10. If you list the program we can see only garbage.

 

I think that having the disk connected is altering the VDP map configuration and the trick for getting the sprites is not working.

 

So, since Classic99 cannot save on a .wav, I've created the save file from MAME/MESS, disabled disks on Classic 99 (setting type to 0 for all the disks) and loaded this .wav from the TI BASIC with MM (I've disabled speech, SAMS and set all disks to Type=0), but I always getting a memory full error in 190. It's really strange, because when loaded from disk, using the call files(0) the game can run, but is not showing any sprite (it works fine in MESS/MAME using the bare console, the MM and loading from CS1).

 

Finally, I tried with the FASTINIT method and the original TI BASIC file (as suggested by Ciro) and so we have the working cart! ?

 

Since the game takes various seconds to start, I've changed the breakpoint to U7=01 and it's now starting directly from the title.

 

In attachment the file.

MORPHY_C.BIN

[+mizapf]

Please keep in mind that CALL FILES(0) will not work on real iron.

[tmop69]

3 minutes ago, mizapf said:

Please keep in mind that CALL FILES(0) will not work on real iron.

Yes, I know, but it was just to get some more free memory to run the game having the disk connected. Anyway, that first dump attempt was unsuccessfully. The final cart created is working fine with the real TI and the FinalGrom. ?

[ti99iuc]

Wow thanks for this!  it is very nice to have it in cartridge also if not compiled. I think that it is the most nice game in Basic developed in 1984.

8 minutes ago, tmop69 said:

[...]

Finally, I tried with the FASTINIT method and the original TI BASIC file (as suggested by Ciro) and so we have the working cart! ?

 

For FASTINIT we have to thank to SeniorFalcon that done it for Morphy some years ago and it do things easier to load it in TI-BASIC.
the thread of Fastinit is this one: 

to the same you can also find lovely other examples developed in TI BASIC recently and using sprites cheat ? 

 

[Tursi]

1 hour ago, mizapf said:

Please keep in mind that CALL FILES(0) will not work on real iron.

That's why Classic99 is a tool and not a toy.