Pageable ROM?

[+DZ-Jay]

Thanks everyone for your help as I can see where some of my trip ups have been. With that said I'm still a bit fuzzy on how much I understand what I've been told thus far.

 

Thus, I still have a couple of questions with my assumptions of what has been stated, to make sure I'm not holding to any new falsehoods of my own making that will get me into trouble later.

No problem, we're here to help.

 

 

The Files size of the dumped ROM is not the actually size of the game's ROM size (which on this form calls "kiloword size" when loaded into the television memory).

 

Just a bit of trivia: The Intellivision has a 16-bit CPU and the console hardware has been designed to support 8, 10, and 16 bit memory. 8-bit and 16-bit, I'm sure you know; but 10-bit was because at the time, memory was so expensive that 10-bit chips were more accessible than 16-bit ones. Besides, General Instruments (the CP-1610 CPU manufacturer) happened to be one of the biggest manufacturers of 10-bit memory chips.

 

When the Intellivision came out, all Mattel cartridge ROMs were 10-bits, while internally the machine used a combination of 10-bit ROM for the EXEC and GROM, and 8-bit and 16-bit RAM for scratch and system memory. Due to the 10-bit width of the ROM addresses, the programmers affectionally called the data word a "Decle". This stuck all the way to this day, and we still call the data word a "Decle" even though we use 16-bit wide ROM today.

 

Because of the above, and contrary to many other contemporary and modern platforms, the Intellivision programming community (going all the way back to the Mattel Blue Sky Rangers) measure the size of programs in "Decles" (which originally were 10-bit wide but now are 16-bits). This gave the indication of how much ROM space a cartridge needed, since that was the word-size of the machine.

 

So, when we say "8K" (without the "B" following it) in the Intellivision world, people mean "8 Kilo Decles" which translates to 1,024 x 16-bit words. File sizes are still reported by modern PCs in "KB" (Kilo Bytes), so you just need to be aware of that distinction.

 

The best way to figure out a games kiloword size is to use the Memory map values in the various Intellivision config files posted in another thread on atariage.

 

If you are assembling the game from source, the output of the assembler will give you this information. If you are trying to assess the size from a binary file, then yes, the best way is to read the memory map values in the CFG file, or take the ROM file size (in KB) and half it (to KW).

 

With that said pattern wise it seems there is a direct correlation to ROM file dump size and actual in game kiloword size. That is the files size on disk of a dumped ROM image appears to always be 2x the Game's kiloword size. I'm I correct to assume this? Or is there any of the original 127 intelivision and/or new Homebrew games that don't follow the, 2x kilword size = Dump ROM file size on disk, pattern.

 

That seems like a good assumption to make. If we accept that a "rom" or "bin" file is a binary image of the program in cartridge ROM, then it takes the same amount of space it would require to store in the cartridge, and since 8-bit Kilo Bytes are half the size as 16-bit Decles, then it works. Just make sure to start with the actual size of the file and not its allocated space on disk, which is block-aligned and may be larger.

 

Based on my testing with changing page numbers in the config file it appears that the games only work if we use page 0, 1 and 2. Short of lucky guesses is there a way we can figure out which page # they are expected to live at? Meaning is there something in jzintv debugging tools and/or easily discovered pattern wise in the dissembled assembly code that would tell us which pages it expects the games to live in?

--The Master

 

I am assuming that this is because you are trying to make use of the Party Line menu which was already created back in its day. If so, then the best way is to disassemble the ROM or to follow it's execution in the debugger. Just be aware that the code may be a bit obfuscated due to optimizations.

 

If you were building your own menu and the games were built to fit within a single page, then you can use whichever page your want, as long as it is valid, and it doesn't interfere with any other memory address space reserved by the console. (Remember, the ROM address space on the Intellivision is broken up into non-contiguous segment, and "pages" are essentially segments if addresses starting at higher bases.)

 

-dZ.

Edited September 17, 2018 by DZ-Jay

[mr_me]

...

 

Based on my testing with changing page numbers in the config file it appears that the games only work if we use page 0, 1 and 2. Short of lucky guesses is there a way we can figure out which page # they are expected to live at? Meaning is there something in jzintv debugging tools and/or easily discovered pattern wise in the dissembled assembly code that would tell us which pages it expects the games to live in?

--The Master

 

The page numbers should be in the code. Whether you're using the debugger or disassembling, the post linked below will help.

http://atariage.com/forums/topic/230132-intellivision-rom-bankswitching-cartridge-ram-questions/?p=3081037&do=findComment&comment=3081037

 

And here's a key quote from that post.

 

"Writing the value $xA5y to location $xFFF page flips the address range $x000 - $xFFF to page 'y'. If the cartridge has ROM for page 'y' in $x000 - $xFFF, then it will respond to reads in that range with the ROM data for page 'y'; otherwise, it will not respond to reads at all. If no ROM in the system responds to the read, then ultimately the CPU sees the value $FFFF. On reset (ie. ~MSYNC goes low), all page-flipped segments reset to page 0."

 

In this example x=5. The only thing I'll add, assuming the party line roms are bigger than 4k, is that it appears that it can page banks of rom larger than 4k.

Edited September 15, 2018 by mr_me

[The Master]

I must be really dense. As the wording on these two responses seem to contradict each other. The first seems to disagree with my assumption while the second seems to confirm it. My assumption being that dividing the bin/rom file size on disk in half would give you the Killoword size used in the game.

If you are trying to assess the size from a binary file, then yes, the best way is to read the memory map values in the CFG file, or take the ROM file size (in KB) and double it (to KW)

 

 

That seems like a good assumption to make. If we accept that a "rom" or "bin" file is a binary image of the program in cartridge ROM, then it takes the same amount of space it would require to store in the cartridge, and since 8-bit Kilo Bytes are half the size as 16-bit Decles, then it works.

For Example the Pitfall dump from the Intellivision ROCKS compilation is 8,192 Bytes on disk. If my assumption is correct than Pitfall used 4 Killoword size. While Beam-rider from the same compilation is 16,384 Bytes on disk would mean it used 8 Killoword Size.

--The Master

Edited September 17, 2018 by The Master

[+DZ-Jay]

I must be really dense. As the wording on these two responses seem to contradict each other. The first seems to disagree with my assumption while the second seems to confirm it. My assumption being that dividing the bin/rom file size on disk in half would give you the Killoword size used in the game.

 

 

 

 

For Example the Pitfall dump from the Intellivision ROCKS compilation is 8,192 Bytes on disk. If my assumption is correct than Pitfall used 4 Killoword size. While Beam-rider from the same compilation is 16,384 Bytes on disk would mean it used 8 Killoword Size.

 

--The Master

 

You are right, that's my mistake. I meant to say that you "half it" not "double it." You double the Kilo-Word size to get the Kilo-Byte size.

 

Sorry about that.

 

-dZ.

[mr_me]

There's a few 6k cartridges that got dumped as 8k rom files. So they show up as 16kB files rather than 12kB files. They include AD&D, Sub Hunt, LockNchase, Royal Dealer, and Shark Shark. Those cartridges have 4k and 2k 10-bit rom chips.

 

Then there's the grom which is a 2k 8-bit rom chip inside the intellivision which dumped as a 2kB file.

[The Master]

There's a few 6k cartridges that got dumped as 8k rom files. So they show up as 16kB files rather than 12kB files. They include AD&D, Sub Hunt, LockNchase, Royal Dealer, and Shark Shark. Those cartridges have 4k and 2k 10-bit rom chips.

 

There must be a couple different versions of LockNChase out there as I have one that is actually only 12kb on disk. And when I use beyond compare with another one I downloaded to see if there are any patterns I can look for in the 16kb rom available online. I see that that only difference HEX wise is that 16KB is padded with 0000 from 12kb up to 16kb. Then Looking at AD&D, Sub Hunt, and Shark Shark, they also where just padded with either FF, 00 or 00 up to a point followed by a bunch of 3F until the end of the file. So it seems when looking at ROMs it good to check to see if they where padded with blank data at the end of the file to see what their actual word size is. Assuming that padding at the end is the only thing causes them to be larger on disk then our assumption about size assumes.

 

Then there's the grom which is a 2k 8-bit rom chip inside the intellivision which dumped as a 2kB file.

This one intrigues me. Is It possible this was a bad dump? Or is it a factor of how optimized the GROM was written that in this single case it ends up having a one to one mapping of Kiloword Size to Kilobyte size on disk? If this last question is true does that mean if someone was to optimize the code in a game rom enough that the Kiloword Size could also map one to when saved to Disk as Kilobytes like the GROM image?

 

--The Master

 

---

[carlsson]

If it is an 8-bit chip, isn't it correct to dump it in bytes, compared to the 10/16-bit chips dumped in decles/words which use 2 bytes per word?

[mr_me]

The grom is mostly sprite pattern data. There might be some 10-bit instructions in there but they would get copied to 16-bit ram and executed from there, according to intellivisionlives.com.

[intvnut]

This one intrigues me. Is It possible this was a bad dump? Or is it a factor of how optimized the GROM was written that in this single case it ends up having a one to one mapping of Kiloword Size to Kilobyte size on disk? If this last question is true does that mean if someone was to optimize the code in a game rom enough that the Kiloword Size could also map one to when saved to Disk as Kilobytes like the GROM image?

 

 

If it is an 8-bit chip, isn't it correct to dump it in bytes, compared to the 10/16-bit chips dumped in decles/words which use 2 bytes per word?

 

The grom is mostly sprite pattern data. There might be some 10-bit instructions in there but they would get copied to 16-bit ram and executed from there, according to intellivisionlives.com.

 

 

The GROM is indeed an 8-bit chip. The 10-bit words stored in there are actually stored as 8-bit data with the upper 2 bits packed separately and reconstituted by a loop in the EXEC. Expanding it to 4K on disk would just be wasting space with a bunch of zeros. The Intellivision 2 EXEC skips this step and includes the extra bit of code in its extension ROM at $04xx. It still uses the same GROM though. B17 Bomber uses the EXEC code as "flak" graphics.

 

 

The page numbers should be in the code. Whether you're using the debugger or disassembling, the post linked below will help.

http://atariage.com/forums/topic/230132-intellivision-rom-bankswitching-cartridge-ram-questions/?p=3081037&do=findComment&comment=3081037

 

And here's a key quote from that post.

 

"Writing the value $xA5y to location $xFFF page flips the address range $x000 - $xFFF to page 'y'. If the cartridge has ROM for page 'y' in $x000 - $xFFF, then it will respond to reads in that range with the ROM data for page 'y'; otherwise, it will not respond to reads at all. If no ROM in the system responds to the read, then ultimately the CPU sees the value $FFFF. On reset (ie. ~MSYNC goes low), all page-flipped segments reset to page 0."

 

In this example x=5. The only thing I'll add, assuming the party line roms are bigger than 4k, is that it appears that it can page banks of rom larger than 4k.

 

Mattel-style paging always works in 4K-word chunks. If the game is switching more than 4K, it will make multiple writes to do so, for each of the 4K chunks.

 

The easiest way to find out what page something is on is to use the debugger, and put a "watch" at $xFFF for the page in question. You will see a write for $xA5y, and discover the value of 'y'. ('y' is the page number of interest.)

 

For example, if you see $5A51 written to $5FFF, you know the ROM was trying to switch to PAGE 1 on $5000 - $5FFF.

[intvnut]

One last thought: If the source ROMs you're working with aren't a multiple of 8K bytes, you may need to pad them out to a multiple of 8K bytes. Pad with zeros or all 1s... it shouldn't matter either way.

[The Master]

One last thought: If the source ROMs you're working with aren't a multiple of 8K bytes, you may need to pad them out to a multiple of 8K bytes. Pad with zeros or all 1s... it shouldn't matter either way.

 

Taking Lock N Chase which I have a 12K Byte dump as an example, why do I need to pad it with 0s or 1s so that it becomes 16K bytes? What issues would I run into if it's not padded out to a multiple of 8K Bytes?

 

--The Master

[intvnut]

 

Taking Lock N Chase which I have a 12K Byte dump as an example, why do I need to pad it with 0s or 1s so that it becomes 16K bytes? What issues would I run into if it's not padded out to a multiple of 8K Bytes?

 

--The Master

 

I meant specifically for the paged ROM Party Line construction exercise.

[The Master]

 

I meant specifically for the paged ROM Party Line construction exercise.

Blow Out, Hard Hat, and Space Cadet were already 16K Byte files. With that said are you saying that when working with Page Flipped Multi Game Carts it's a good practice to make sure each individual game's Byte size is a multiple of 8K Bytes? Even when you make your own Multi-Game ROM? Or is that something configurable when programing the Multi-Game ROM, in other words can you program your Page Flipping so it expects multiples of 4k Byte sized files instead of multiples of a 8K byte sized file?

 

-The Master

[intvnut]

Blow Out, Hard Hat, and Space Cadet were already 16K Byte files. With that said are you saying that when working with Page Flipped Multi Game Carts it's a good practice to make sure each individual game's Byte size is a multiple of 8K Bytes? Even when you make your own Multi-Game ROM? Or is that something configurable when programing the Multi-Game ROM, in other words can you program your Page Flipping so it expects multiples of 4k Byte sized files instead of multiples of a 8K byte sized file?

 

Mattel-style page flipping works on 4K-word segments (8K bytes in .BIN files).

 

For your own programs, current versions of the assembler will automatically round Mattel-paged memory up to 4K-word increments. Older versions did not. That change went in around September 2013. You can see this in asm/collect.c, output_bincfg:

.

/* ------------------------------------------------------------------------ */
/*  OUTPUT_BINCFG                                                           */
/* ------------------------------------------------------------------------ */
LOCAL void output_bincfg(void)
{
    int addr, addr_lo, addr_hi, span_lo, span_hi, span_len, slot, page;
    int span_flag;
    int fileofs = 0, i;
    int memattr_hdr = 0;

    fprintf(cfgoutf, "[mapping]\015\012");

    addr_lo = addr_hi = -1;
    span_lo = span_hi = -1;
    span_len = -1;

    /* -------------------------------------------------------------------- */
    /*  Scan through by 4K chunks, outputting any ROM/RAM/WOM segments      */
    /*  that have data.  For paged segments, output exactly 4K sized        */
    /*  chunks.  For non-paged segments, output the exact words defined by  */
    /*  the program image.                                                  */
    /* -------------------------------------------------------------------- */
    for (page = 0; page < 16; page++)
    {
        for (slot = 0; slot < 16; slot++)
        {

/*....*/

.

Demo:

.

im14u2c@elysium:/tmp[1]$ cat test.asm
    ORG     $5000:0    ; The ':0' specifies Mattel-style paging, PAGE 0.
    DECLE   42

im14u2c@elysium:/tmp[1]$ as1600 -o test.bin test.asm
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

im14u2c@elysium:/tmp[1]$ ls -l test.bin
-rw-r--r-- 1 im14u2c im14u2c 8192 Sep 18 19:29 test.bin

im14u2c@elysium:/tmp[1]$ cat test.cfg
[mapping]
$0000 - $0FFF = $5000 PAGE 0

im14u2c@elysium:/tmp[1]$ $ cat test2.asm
    ORG     $5000
    DECLE   42

im14u2c@elysium:/tmp[1]$ as1600 -o test2.bin test2.asm
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

im14u2c@elysium:/tmp[1]$ ls -l test2.bin
-rw-r--r-- 1 im14u2c im14u2c 2 Sep 18 19:31 test2.bin

im14u2c@elysium:/tmp[1]$ cat test2.cfg
[mapping]
$0000 - $0000 = $5000
 

.

Notice that the paged version got rounded up, while the non-paged did not.

 

Current versions of jzIntv try to do the "right thing" with odd-sized paged segments (rounding them to multiples of 4K words), while older versions were totally broken if they weren't exactly 4K words. (This change went in around April 2014.) You can see this around like 210 of bincfg/legacy.c:

.

            /* ------------------------------------------------------------ */
            /*  Realign the span to 4K boundaries and cut it up into 4K     */
            /*  chunks.                                                     */
            /* ------------------------------------------------------------ */
            new_s_addr = span->s_addr & 0xF000;
            new_e_addr = span->e_addr | 0x0FFF;
            new_slen   = new_e_addr   - new_s_addr + 1;
            old_slen   = span->e_addr - span->s_addr + 1;

.

(Side note on naming: I had named that file 'legacy' when I thought jzIntv was going to transition to ROM as its native format. I now support both as fully and equally as possible, especially due to page-flip support. Also, you'll see in the source I called this "ECS-style paging" and variations thereof, but really it's more accurately called "Mattel-style paging.")

 

The paged segment at $4xxx is a special snowflake. If you want to put paged ROM there, only put code at $4800 - $4FFF, and let AS1600 and/or jzIntv pad out $4000 - $47FF with $FFFF for you. That will ultimately look like a 2K-word page-flipped segment, with $4000 - $47FF remaining as ECS RAM (if ECS is present). This works in jzIntv because it bitwise-ANDs all 'responders' to an address, and the $FFFF padding makes it look "not present." LTO Flash! will also detect this case, and will construct a 2K-word paged segment at $4800 - $4FFF. It will not respond to reads on $4000 - $47FF, so it safely coexists with the ECS and does not engage in a buffer fight.

 

 

The reason I had mentioned rounding up the ROM image sizes is that mr_me had mentioned having an odd-sized ROM image:

 

The party line roms seem to be larger than 4k; between 6k and 7k. I can also say the windows emulator that come with Intellivision lives/rocks for pc doesn't support paging the way jzintv does; not sure about the playstation emulator.

Edited September 19, 2018 by intvnut

[mr_me]

The total file size is an even 48kB. Here's the part of the code that does the bank paging. It's banking both $5xxx and $6xxx, each with pages 0/1/2. That's two separate banks of 4K even though the cfg file I'm using sets up one bank of 8k (three pages).

L_DF70:
        SDBD                  
        MVII    #$5A51, R0    
        SDBD                  
        MVII    #$6A51, R1    
        B       L_DF88        

L_DF7A:
        SDBD                  
        MVII    #$6914, R1    
        MVO     R1,     G_02F0
        SDBD                  
        MVII    #$5A52, R0    
        SDBD                  
        MVII    #$6A52, R1    
L_DF88:
        SDBD                  
        MVII    #$5FFF, R2    
        SDBD                  
        MVII    #$6FFF, R3    
        MVO@    R0,     R2    
        MVO@    R1,     R3    

[intvnut]

It's banking both $5xxx and $6xxx, each with pages 0/1/2. That's two separate banks of 4K even though the cfg file I'm using sets up one bank of 8k (three pages).

 

They're still 4K pages even though you specified it as an 8K span in your config. Suppose you write this:

.

[mapping]
$0000 - $1FFF = $5000 PAGE 0

.

That'll give you two 4K page-flipped pages, one at $5000 - $5FFF, and one at $6000 - $6FFF. In the end, it's equivalent to writing:

.

[mapping]
$0000 - $0FFF = $5000 PAGE 0
$1000 - $1FFF = $6000 PAGE 0

.

The current version of AS1600 will output the latter for clarity—as will the various tools that come with SDK-1600 that understand paging—but it has the same meaning as the former. jzIntv will take any PAGEd segment, round it out to 4K boundaries (padding with $FFFF if necessary), and cut it to 4K chunks.

 

At least, this is how jzIntv interprets it as of April 2014. Prior to then, its page flipping support was... at best weird and and certainly somewhat broken for any ROM segment that weren't explicitly carved into exactly 4K chunks such as the second example.

 

The following will also work, but inefficiently:

.

[mapping]
$0000 - $07FF = $5000 PAGE 0
$0800 - $0FFF = $5800 PAGE 0

.

 

This will still end up behaving as a single 4K page despite looking like two 2K pages. However, jzIntv will actually construct two overlapping 4K pages whose combined behavior still does the "right thing," thanks to how padding works (pad with $FFFF) and how I merge overlapping ROMs with AND. I tried it just now, and you can see this evidence in jzIntv's output:

.

Paged ROM 0      [0x5000...0x5FFF]
Paged ROM 1      [0x5000...0x5FFF]

.