Gram Kracker / Gramulator / HsGpl File Headers

[kl99]

Hi Guys!
I try to get a possibility to convert any Gram Kracker Dump File and reuse it for other Gram Devices or resuse it as cartridge within any emulator or resuse it for burning eproms.

Basically I want any format to be convertable to any other format.

For this I started developing a new tool.

 

Now I got stuck with a few of the .grm Files that seem to be cartridge image files created with the Gramulator and meant to be running with Pc99 Emulator.

Their 6 byte header doesn't seem to fit the specifications I read about so far. I don't mean the Grom Header starting with "AA ..." that is the first byte from the Grom Memory content, I mean the 6 byte pre header that is added up front by most Gram Devices in order to properly know where to place the various files in its ram chips.

 

Example: phm3058.grm, Mini Memory

"FF 20 20 00 60 00 AA 00 ..."

 

The problematic byte is the second (Byte 1) which defines the Bank (Destination Indicator).

 

According to GramKracker Specs legal values are:

>01->08 for Grom0-Grom7

>09 or >0A for Rom0 or Rom1

>00 or >FF for Memory Expansion

 

Gramulator Specs extended the former list of legal values to support MBX Carts with:

>0B for MBX Ram Bank 0

>0C for MBX Ram Bank 1

>0D for MBX Ram Bank 2

>0E for MBX Ram Bank 3

 

So what does the value >20 for the Bank Byte mean?

 

I also know about a tool from Cadd called "Universal Gram File Converter". Anybody has the manual or the program?

 

Klaus

Edited June 15, 2016 by kl99

[+Schmitzi]

Hi,

 

not the converter, but I found this. Maybe somehow usable.

 

PROGRAM FILE FORMATS.pdf

 

 

[+Ksarul]

Klaus, you might want to look at the loader code in the Wiesbaden Supermodul II. I think it will load pretty much every GROM format out there (although the MBX extensions of the Gramulator will probably fail).

[+Torrax]

>>Quote: So what does the value >20 for the Bank Byte mean?

 

I believe this Indicates the persistance RAM area at >6000.

 

>0x - none

>1x - >6000->6FFF (TOP 4K)

>2x - >7000->7FFF (BOTTOM 4K)

>3x - >6000->7FFF (FULL 8K)

 

Hope this helps.

Edited June 15, 2016 by Torrax

[kl99]

Many thanks for the replies. And for your time to write the answer.

 

cfg.exe (Configuration Tool for Pc99) interpretes the Bank byte as such:

>20 means MiniMemR0

>29 means Rom 2 (TI-Calc)

>2A means Rom 3 (TI-Calc)

 

For phm3055.grm (Editor Assembler) the value for the Bank >05 (Grom4) doesn't seem to match the Grom Bank defined in the AA header (Grom3).

 

At least all within the PHM Folder are handled now by the tool. Will test all other .grm files (third party) tonight.

 

The basic idea is to get the files into comparable pieces and compare their sha-1 hashes. The sha-1 hash is already contained within the rpk files, used by Mess.

Rpk files even contain Meta Data which can be checked once to be valid. Then you can ensure that a file having a certain hash is PHM3055, was released in year 1982, publisher was Texas Instruments. You can map a certain cartridge label to it, a certain manual or manual cover to it and stuff like that. Bad dumps can be marked as such.

 

The tricky part is to get the files into comparable pieces, meaning identify a header to be a header and not part of the dump. But I am far already with that.

Edited June 16, 2016 by kl99

[kl99]

Example of different formats for the same cartridge:

- bin files spread across directories

- files within zip Library across directories

- zip files within zip Library across directories

- files within rpk Library across directories

- grm files spread across directories

- dsk files (V9T9/PC99) containing PROGRAM Files which are GRAM/RAM files

- single TI Files of type PROGRAM which are GRAM/RAM files across directories

 

Then there are differences like:

- 6 byte header included or not

- Grom header included or not

- all Rom banks in one file or each Rom bank has its own file

- all Grom banks in one file or each Grom bank in its own file with size of 6k or 8k

- Grom bank extended to 8k with data or not

Might sound complicated but it will be all handled by the tool.

[kl99]

For those interested: this is the current auto-generated(!) output file.

shaxml.xml

 

The meta data you see \sha1\meta\names is extracted from within the rpk files.

That meta data will be audited later once all files were auto-mapped to each other.

Same is true once there is only one entry left for each cartridge. Then it only takes a fresh dump on a real TI from the original module to see if the dump is fine.

If there are dumps with actual different content for the same cartridges, it will take a fresh dump from the original module as well to audit the correct one as such.

Sometimes the content really seems different.

 

It's work in progress.

For now I let the tool analyze everything from these location:

1. ftp.whtech.com\Cartridges\MAME\*.*

2. Cyc\pc99\*.*

 

The Pc99 directory contains quite a few images that can not be mapped to any image within the MAME Folder.

Search for <name id="" in the xml file to get to the area where a file could not be mapped to a rpk file.

But in that Pc99 Directory are not only cartridge images but dsr, speech and system roms, so those non-cartridges would have to wait anyway for phase 2.

 

I am not checking yet Gram Files within Disk Images, as I started this as an external tool. As soon as this feature gets integrated into Web99, it will be easy to identify a ti-file within a Disk as Gram File and identify the cartridge of it based on the hashes.

 

- this shall help to reduce the number of unknown ti-files on your disks/disk images

- this shall help to create a reference library for all modules with the option to export the library in any desired format (gram kracker, eprom, rpk, zip, bin) with any desired naming type (be it phm3xxx or be it a 8-char module title, a 10-char module title, ...).

- this shall help you to actually use your gram devices on your real ti, because you will have whole library of modules, sorted and in your desired format

- this shall help you to use your favorite emulator with the whole library of modules, sorted and in the required format already

- the final hash list can be used by any ti-tool for the pc to identify a gram file within a disk-image to be a certain cartridge, this is not just for Web99

[RXB]

One of the reasons I put into RXB the ability to save XB programs only in Internal Variable 254 format.

 

Example:

SAVE DSK1.PRGMEXPL ! NORMAL XB SAVE IN PROGRAMS FORMAT

 

RXB NEW SAVE FEATURE

SAVE DSK1.PRGMEXPL,IV254 ! RXB FORCES SAVE INTO A IV254 FORMAT FOR XB PROGRAMS FOR EASY CATALOGING

[+acadiel]

Let's put the HSGPL in the mix just to throw some fun in...

 

http://home.arcor.de/system-ninety-nine-user-group/hsgpl/hsgpl_e.pdf

 

 

Header-Byte >0

The target address of the modules is in bytes >0 and >1 of the Header. There is further information in byte >1, in which no address sharing in byte >1 and like >00 is considered. It is here that the target address must and is always placed in multiples of 256 (>100).

 

Header-Byte >1

In this byte is the information is stored about which in memory area the file will be copied and where additional data will be loaded.

 

Bit 0-3 - Not Used at this time

Bit 4-6 - Target Bank +1 in ROM >6000

Bit 7 - Additional Load Bit

 

The additional load bit determines where the next file will be loaded or if the file is the last file in the series. If the additional load bit is set as 1, the next filename will be loaded and the filename must end in the next al- phabetical letter.

The target Bank in the range of ROM >6000 is where the file will be loaded. The values are set by default to 1 to 4. If they are set to zero, the file is written to GRxM.

 

Header-Bytes >2 and >3

The file size is shown here. The HSGPL Control Program ignores these bytes. It will always copy >2000 bytes (8 KB) to the target Bank.

 

Header-Bytes >4 to >2003
This is the actual file data. All of the values between >00 and >FF are transparently written.

 

Example for a Header:

 

Byte >0 and >1 = >6001, and Byte >2 and >3 = >2000 means "Memory GROM 3, load next file"

Byte >0 and >1 = >6004, and Byte >2 and >3 = >2000 means "Memory ROM >6000, Bank 2, last file"

Byte >0 and >1 = >0000, and byte >2 and >3 = >2000 = "Memory GROM 0, last file"

Byte >0 and >1 = >6003, and byte >2 and >3 = >2000 = "Memory ROM >6000, Bank 1, Additional files to load"

 

[+mizapf]

For now I let the tool analyze everything from these location:

1. ftp.whtech.com\Cartridges\MAME\*.*

 

Klaus, just to keep it in mind, the RPKs will undergo some changes in the near future; I'll replace (at first just add, then remove) the layout.xml with a new XML file that is compatible to the MAME ROM loader. Eventually, we'll switch to the ZIP files for the standard cartridges; the RPKs will be kept for the non-standard cartridges (like homebrew, under development, or hacked variants).

 

Would it be helpful if I upload the MAME-internal software list (ti99_cart.xml) to WHTech that describes all ZIP cartridges?