EA5 files and size in header

[+jedimatt42]

Ok, so first word: EA5 magic numbers: FFFF == more files to read, 0000 == last file to read.

second word: size?

third word: address to load to, and branch to for execution.

 

This has been my understanding. But I see a lot of files, where the header says >2000 , and there are only 8192 bytes in the file. The file includes the 6 byte header, so the maximum size can only be >1FFC

 

Do all of the ea5loaders, just ignore the size? and read to the end of the file?

 

I know this is in contradiction to the docs on Thiery's page which say:

 

Address	Content
>0000	Flag. >0000 = last file. >FFFF = load one more file
>0002	Address where to load the program.
>0004	Number of bytes to load (not counting these 6). 

But when you see files where the 3rd word is C006, you know he has word 2 and 3 backward, since the files are never >C006 bytes big.

 

-M@

[+jedimatt42]

http://www.ninerpedia.org/index.php?title=Memory_Image_format_E/A_Module

 

This page notes that my understanding is correct. But then suggests that many 8k data dumps are actually 8k + 6 bytes. Yet, I seem to have a bunch of games in ea5 format that are 8192 byte files. I wonder if something copying them lost some bytes somewhere, and since they load in ea5, the loader must do something like load up to the size or eof, whichever comes first. Is this a source of corruption from years past?

 

-M@

[RXB]

RXB has a utility that saves the Lower 8K in Program Image Format but has no header so the 32 Sector RXB file has no header just the 8K copy.

 

You can have Program Image files smaller than 32K in some formats as if you only need 28 sectors it only needs a 6 Byte header plus the 28 sectors to save, still loads fine.

 

There is nothing really preventing a 24K Program Image file it just requires you stop and reload the VDP for the next 8K chunk to be loaded and saved like a sector dump.

 

RXB has a feature of Reading Sectors and they are loaded into the Lower 8K just so you can also use CALL BSAVE to save them.

 

Nothing prevents you from making any size of EA5 Program Image files really, just no one has done it often.

 

I had planned on a version of Program saver and loader that used a 24K size of Program Image files for loading and saving the SAMS card,

or using a format similar to XB IV 254 like say 97 Sector chunk each time with a 256 extra sector used for loading location and notes of use.

Edited February 2, 2017 by RXB

[+InsaneMultitasker]

http://www.ninerpedia.org/index.php?title=Memory_Image_format_E/A_Module

 

This page notes that my understanding is correct. But then suggests that many 8k data dumps are actually 8k + 6 bytes. Yet, I seem to have a bunch of games in ea5 format that are 8192 byte files. I wonder if something copying them lost some bytes somewhere, and since they load in ea5, the loader must do something like load up to the size or eof, whichever comes first. Is this a source of corruption from years past?

 

-M@

There should be no corruption. The text was quite likely copied from the Gram Kracker verbiage, linked at the bottom of the page. I suspect Michael will chime in at some point as the EA Module entry should be changed to specify a maximum 'data' size of 8186 bytes + 6 bytes header.

[+mizapf]

As "View history" says, the text is not from me but from HackMac. But you are right, the EA5 files are at max 8192 bytes long, including the 6 bytes header. In contrast, the cartridge dumps for my Geneve are 8198 bytes long and obviously have GK format. Someone's going to fix it.

Edited February 2, 2017 by mizapf

[+InsaneMultitasker]

As "View history" says, the text is not from me but from HackMac. But you are right, the EA5 files are at max 8192 bytes long, including the 6 bytes header. In contrast, the cartridge dumps for my Geneve are 8198 bytes long and obviously have GK format. Someone's going to fix it.

I updated the entry.

[+jedimatt42]

Thanks! That makes me feel better.

 

-M@

[HackMac]

It is difficult to say what a 'size' field represents. The documentations aren't precisely enough at this point. SIze can name different things: Size of file, size of data, size of a Banana? You may need to look into the code. But which code is the correct? Loaders can be buggy at this point.

I often find memory dump files where the size of the file does not matches any combinations of the content of the size field and header size...

[+InsaneMultitasker]

It is difficult to say what a 'size' field represents. The documentations aren't precisely enough at this point. SIze can name different things: Size of file, size of data, size of a Banana? You may need to look into the code. But which code is the correct? Loaders can be buggy at this point.

I often find memory dump files where the size of the file does not matches any combinations of the content of the size field and header size...

 

In the case of EA5 and similar formats, the length of the data represented by the header is the more 'precise' number and is expected to be used by the loaders as-is, regardless of the full file size or file attributes.

 

EA5 loaders have been around for quite some time and the meaning of the headers is well-defined. What bugs or discrepancies have you seen? An example or two would be interesting to investigate and/or document.

[+mizapf]

Here is an example of EA5 files: CERBERUS and CERBERUT

 

The first file CERBERUS loads at >A000:

 

 

000000: ff ff 20 00 a0 00 04 60 d2 36 30 44 c0 09 40 44     .. ....`.60D..@D
000010: cc 0e 50 44 d8 0d 60 44 e4 08 00 e2 00 0e 01 06     ..PD..`D........
...

 

The second file CERBERUT loads at >BFFA:

 

 

000000: 00 00 1e 90 bf fa c8 20 a0 22 83 98 10 24 98 20     ....... ."...$.
000010: a0 67 83 75 16 0a c8 20 a0 2e 83 aa c8 20 a0 26     .g.u... ..... .&
...

 

This shows that the offset is >1FFA, or >2000-6, although the size in the first file is given as >2000. So this includes the header.

 

@jedimatt42: You can verify this in a similar way: Just check the offsets of the files. In most cases (not guaranteed, though) the files are loaded without gaps, one after another.

[+jedimatt42]

Thanks! This understanding has worked well. I've been able to write an EA5 loader in gcc, reading the EA5 streams out of a memory mapped IO port. A major milestone!

 

I also got confused by things like WINGAR/WINGWAS, because WINGAR is a small EA5 file, but WINGWAS isn't at all. It appears WINGWAS is a raw data file, and WINGWAR is yet another loader that looks for DSK1.WINGWAS. Explains why that doesn't load off HDX like all the other EA5 files I have sitting around.

 

I can load EA5 versions of AMBULANCE, MOONPATROL, BIGFOOT, PARSEC quite well now... Just toying around, before getting into the TI file based DSRs.

 

(Funny how I'm always shouting the names of TI things )

 

-M@