E/A5 (Program) Format

[Stuart]

Looks like E/A5 (Program) format only supports programs that load in a contiguous memory area - is that correct? It's no use for a program that loads portions in both low and high memory areas?

[+mizapf]

Have a look at https://www.ninerpedia.org/wiki/Memory_Image_format_E/A_Module

[+jedimatt42]

What I don't see on that page is that the launch address is the load address of the first file in the set.

 

-M@

[HOME AUTOMATION]

In another thread I tried to figure out the format used by the EASYBUG'S cassette SAVE utility. I'm afraid there is a slight exception here:

Memory Image Easybug

 

"Length

This word specifies the length of data. File size should be the sum of the header size (4 bytes) plus the length of data. If the file is larger, only the given length of data is used."

I don't see how a larger file could be generated in the first place...
I think that the EASYBUG's SAVE option only allows a max. 8192+4 bytes.

maybe a typo?

sounds a little like "only the given length is used" means that... there is no load address... or that the header is not summed.

[Asmusr]

Looks like E/A5 (Program) format only supports programs that load in a contiguous memory area - is that correct? It's no use for a program that loads portions in both low and high memory areas?

 

No, it can load into both low and high memory.

[Stuart]

 

No, it can load into both low and high memory.

 

But can it load into low and high memory in the same file - or will the SAVE uility save all the memory areas between low and high memory as well?

[apersson850]

You can always create the file(s) to load yourself, without using the SAVE utility. I've used the program format to store memory images I've created myself, with a different program.

[+TheBF]

Looks like E/A5 (Program) format only supports programs that load in a contiguous memory area - is that correct? It's no use for a program that loads portions in both low and high memory areas?

 

I have not tried it but since a large program must be broken into 8K pieces and each file has a load address in the header,

and file names control the load order by using the last character,

 

I believe this strategy would work:

( And the number of files and load addresses could be as many as needed since the flag is the delimiter for the last file.)

File #    File Flag Length Load Address    File Name    (in header)
1         >FFFF     >2000   >2000            MYFILE1      
2         >FFFF     >2000   >A000            MYFILE2      
3         >0000     >xxxx   >C000            MYFILE3    (last file <8K)

Edited March 18, 2019 by TheBF

[+jedimatt42]

But can it load into low and high memory in the same file - or will the SAVE uility save all the memory areas between low and high memory as well?

 

You will have to have separate files for low mem and himem...

 

Here is an example of the PARSEC ea5 file set headers:

 

PARSEC1: ff ff 20 00 a0 00 --- more files flag, 8k length, load address >a000 ( also start address )
PARSEC2: ff ff 20 00 bf fa --- more files flag, 8k length, load address >bffa
PARSEC3: ff ff 19 00 df f4 --- more files flag, 6400 bytes, load address >dff4
PARSEC4: 00 00 11 7a 26 8c --- last file flag, 4474 bytes, load address >268c (lower memory)

My point was, here the lower expansion is loaded last, and we have a couple files less than 8k... Nothing has to be contiguous, or in a particular order. But given that these files are loaded with the DSR LOAD operation, they go into VDP RAM, the header is read, and then copied into CPU ram.

EA5 ( as noted in the scratchpad loader source ) loads them into >1380 in VDP, so they have to be small enough to sit there and still have room for storage devices to have PABs and file sector buffers in the top of VDP.

 

---

(Rasmus shows us that the following supposition is wrong with regard to the original Editor Assembler SAVE tool)

I believe there is still a documentation discrepancy on the LENGTH field (2nd) in the EA5 header. When I use tools like ea5split with gcc, the LENGTH is the size of the program data, not the size of the file. This parsec example has the length set to the size of the file.

I suspect this is just imprecision from hand crafted examples, but I've never used the original SAVE tool...

In the case of PARSEC here, the load address of the second file is not >A000 + 8k... it is clearly -6 bytes.

The elf2ea5 tool will create a LENGTH field for an 8k file of >1ffa, as that is how much program data is in the file.

I have written about 4 ea5 loaders now... And when I subtract 6 from LENGTH before copying from VDP to CPU ram, (as you would logically do if the LENGTH was the sum of data+header) a program like PARSEC loads, but many others crash at runtime having left out data if their length is precise. Expecting LENGTH to be number of bytes to copy works. So I believe that length is not meant to include the 6 bytes of header...

An 8k file that looks proper (to me) has a length like elf2ea5 creates, of >1ffa.

 

None of this is checked at time of load... So if a PARSEC files says to copy 6 bytes that aren't in the file, the loader copies 6 extra bytes of garbage from VDP, then the next file contains the correct 6 bytes and when it is loaded it replaces the garbage.

 

-M@

[Stuart]

Thanks all!

[RXB]

In RXB I explored a GPL 15K EA 5 Program Saver/Loader using SAMS for SAMS that would only have VDP tables and a buffer. plus a PAB.

 

I was trying to get away from 12K limit of size.

 

RXB 2015 had a 8K SAMS Saver/Loader for two 4K pages at a time, but restricted to Lower 8K only support.

 

Oddly I instead reversed to 4K Program Image size for SAMS Saver/Loader in RXB 2019, and it is unrestricted to any RAM area.

 

The problem is 100% limited to VDP size of less then 15K max available, using RAM as a buffer opens a different can of worms.

[Asmusr]

I just tried the SAVE utility for the first time and the information on Ninerpedia is correct: the length of the header is included in the length field. In other words, an 8K file has the length field set to 8192 and contains 8186 bytes of data plus a 6 byte header.

[+jedimatt42]

I just tried the SAVE utility for the first time and the information on Ninerpedia is correct: the length of the header is included in the length field. In other words, an 8K file has the length field set to 8192 and contains 8186 bytes of data plus a 6 byte header.

 

Thanks for that test! Awesome... ok, so that might mean we have something else running around ( like ea5split ) that is setting length to 0x1ffa instead of 0x2000 when it creates an 8192 byte file...

 

-M@

[+InsaneMultitasker]

I took a look at some of the older multi-part programs, like DiskAssembler, Disk Utilities, DM1000, Telco, Mass Transfer - all follow a maximum length of >1FFA with a file size of >2000. On the other hand, I found some earlier programs like the TI assembler, CannonBall Blitz, and a few "hybrid" game dumps that contain a maximum header length of >2000 with a file size of >2000.

 

Older GRAM Kracker GROM image dumps seem consistent in that the files are >2006 (8198) bytes with an internal header length of >2000 (8192) bytes.

 

I suppose if a EA5 loader tried to be too smart about its own memory management it could be tripped up by the "extra" header bytes. GRAM loaders might wreak havoc if the header length value is greater than >2000, especially if the loader moved >2006 bytes into GRAM space with a wraparound effect.

 

While the SAVE utility includes the data+header length in the header, that does not mean it is a best practice, and would even suggest that a header including its own length is silly to me. I also admit it may be a moot point for most use cases. Food for thought.