What is EA5 conversion?

[Everett1954]

I just picked up a FlashRom99 and there is a mention of EA5 conversion.

 

What does it mean and what is it?

[+Lee Stewart]

I just picked up a FlashRom99 and there is a mention of EA5 conversion.

 

What does it mean and what is it?

 

“EA5 conversion” refers to converting program image files, which are loaded into the 32 KiB expansion RAM and run with the Editor/Assembler cartridge's Option 5, to ROM binaries that will do the EA5 load and run without needing the E/A cartridge. These ROM binaries can be loaded into ROM cartridges (including the FlashROM99) from which the EA5 programs can be launched. Such programs require 32 KiB expansion RAM. The EA5-loading ROM binaries can be created with Fred Kaal's (@F.G. Kaal) Module Creator 2.0 available on his website on the “modules” page.

 

...lee

[Everett1954]

Thank you for that great explanation.

[+Lee Stewart]

Thank you for that great explanation.

 

You are more than welcome.

 

I should add that the E/A5 conversion to ROM binary makes it possible to run the program without requiring a disk drive or similar device, as long as the program itself does not do device I/O.

 

...lee

[apersson850]

And since these programs still load into RAM when they execute, you don't have to consider the constraints that are necessary for programs that runs in ROM only. If you happen to have one of these consoles that are modified to have the RAM expansion internally, you need nothing else than the console and the cartridge.

[+acadiel]

To confuse things even further, there's also the way to convert EA/5 program images to load and run from GROM as well. Classic99 can save a memory segment (say A000-FF00) as a GROM type file. This looks like and smells like a GROM, and copies to 32K and executes (you get a nice "Cart conversion by Tursi" tagline when running it.) In fact, it's how I got TimXT To run from the UberGROM (copy to 32K from the Atmega GROM space and run it in 32K.)

 

So yeah, two different "EA/5 conversions" need to be notated going forward:

 

1) Unrolling from ROM to >A000 onward and Branching @ whatever (>A000 etc) - Fred's converter, Tursi and I's original assembly to do this

2) Unrolling from GROM to >A000 onward and Branching @ whatever (>A000) - Tursi's converter

[apersson850]

Then you have TI's original meaning of the phrase. But they refer to when you transfer a piece of software from the tagged object code file format to the memory image format used by E/A option 5. This is essentially the same thing, but here the files are supposed to load from disk, or even cassette, instead of loading form various ROM devices.

[RXB]

I just picked up a FlashRom99 and there is a mention of EA5 conversion.

 

What does it mean and what is it?

Not attempting to confuse you but RXB has 2 routines that complicate the listing of Program Image files.

 

RXB has CALL BSAVE that saves the Lower 8K into a Program image file and CALL BLOAD loads those saved Program Images.

These files are 32 Sectors unlike most other program image files that are normally 33 Sectors or more in size.

 

Exclusively the reason for CALL BSAVE and CALL BLOAD in RXB is for using the SAMS Memory Card as an example is a game I wrote called IN THE DARK

that uses 640K of the SAMS 1 Meg memory not counting the 32K being used previously from the SAMS card.

 

Can anyone name a game that used as much memory as this game?

Or can anyone name a TI 99/4A program ever that used 640K ever?

Edited June 19, 2017 by RXB

[apersson850]

A 32 sector file is enough to fit in 8 K code. Since the BSAVE/BLOAD in RXB seems to always save from and load to 8 K RAM, there's no need to keep track of any load address. The normal memory image files are 33 sectors, since they can hold 8 K code plus the address, byte count and link indicator (to link to the next file, if the memory image is more than 8 K).

 

I once wrote a program, or rather tried to, that would have needed somewhere like 200-256 K RAM to run well. I had to abandon it, since it was too slow when doing all data processing via disk. That's the largest I've done, and I haven't heard anybody making anything bigger, even if that of course very well could have happened.

[Asmusr]

Anyone can use a lot of RAM. The challenge is to store the biggest game in the least possible memory, like the Legend of Zelda that manages to store 128 screens in 5K. That's very impressive.

[RXB]

A 32 sector file is enough to fit in 8 K code. Since the BSAVE/BLOAD in RXB seems to always save from and load to 8 K RAM, there's no need to keep track of any load address. The normal memory image files are 33 sectors, since they can hold 8 K code plus the address, byte count and link indicator (to link to the next file, if the memory image is more than 8 K).

 

I once wrote a program, or rather tried to, that would have needed somewhere like 200-256 K RAM to run well. I had to abandon it, since it was too slow when doing all data processing via disk. That's the largest I've done, and I haven't heard anybody making anything bigger, even if that of course very well could have happened.

I have created a GPL program that saves 32K at a time to disks or hard drives. But of course does it in 8K chunks to make a large Program Image file.

 

Just never found a use for it as it would not be compatible with RXB. I was going to use it for a loader for SAMS using the EA Cartridge side.

[apersson850]

I wasn't writing games (there are many of them already) when I ran out of memory, but was designing a program which would need a large database to work. The main database could be on floppy disk without too much time penalty, but I couldn't even fit in the index into the database in RAM, and then finding what I needed took too long time.

Now I have a Horizon RAMdisk lying around. It isn't functional, but if I spend time fixing it, then that program would be doable. But now it's not really needed any longer, as my TI activity is very low.

[WhataKowinkydink]

I'm trying my hand at this with StarBase Raiders from TI Gameshelf

 

It turns out there are 3 binary files raider.tfi, raides.tfi, raidet.tfi which I've extracted from the disk using TI ImageTool.   It seems to me these three files need to be combined into one .bin file.   Please correct me if I'm wrong.  If I'm right, how do I combine these files?  Also, would the inverted paging be necessary for this cart?

[+mizapf]

The tfi files are TIFILES files with their headers. You'll have to save the contents of the files, then you can concatenate them

- in Linux using cat

- in Windows using copy

 

TIImageTool: Right-click on the file, Save as plain dump.

Edited September 30, 2020 by mizapf

[WhataKowinkydink]

Okay.  So I got this to work after a bit of messing around.   The following is what I did.  DISCLAIMER: I won't be covering how to set up Fred's Module Creator, that is covered in the README and his website.

 

• Extract the PROGRAM (EA5) files from the .dsk image using TIIamgeTool
• Use TI99Dir to make sure the headers are V9T9 not TIFiles
• Bring the extracted files to the folder were Module Creator lives
• Run Module Creator and give a title in Program 1 box
• Select the first (in my case first of three) PROGRAM file in Program 1 box (do not worry about selecting the rest of the PROGRAM files, Module Creator will take care linking them)
• Uncheck the "inverted paging" box
• Hit the create module button

 

And that's it.  Enjoy your new module

[WhataKowinkydink]

I guess I should have done more testing.  It appeared to be working, and starting playing [StarBase Raiders], but ran into trouble when I realized no keyboard input was being accepted (though the joystick still works).   When I tried it again after loading and checking the disk version (which was fine of course) the gameboard doesn't display properly.

 

I'm attaching the final bin file that Module Creator produced which I used on the FinalGROM.  Also attaching the three EA5 program files that I used with Module Creator to create the .bin file.

StarBase_R.bin Raiders.zip

Edited October 1, 2020 by WhataKowinkydink