Has anyone poked around the ROM for DayStar 040 accelerators?

[Arbee]

I'd like to eventually emulate some accelerator cards and to that end I have dumps of the 4.0.1 and 4.1.1 ROMs for a DayStar 040 accelerator. I think it's the Turbo 040, but I'm not 100% on that. The problem is that the dumps don't contain any valid 68K code that I can tell, so I'm assuming they're scrambled in some way. Reordering the address or data lines or XORing all the values with some fixed value or string were cheap forms of protection used in some arcade games, for instance. Has anyone poked around with these dumps and figured out how to decode them?

Alternatively, if anyone has ROM dumps from any other accelerators, I'd love to have them.

 

[dougg3]

I never figured out how to decode the raw chip dumps, but I helped @olePigeon back in the day in my IIci mega-thread (starting around here) with some hacking on the normal Mac ROM with a Turbo 040 installed. At least in the IIci, it ends up being mapped into ROM space at $40880000. If it helps, here's an in-system dump we did of what I believe is the 4.01 ROM. You can see some human readable strings starting at $4FBE.

We also found that the Turbo 040 patches a bunch of stuff in the Mac's original ROM. I'm not sure if it makes a copy in RAM and reconfigures the MMU or what. I guess there still has to be an entry point added prior to that somehow. Maybe taking further time to disassemble the Turbo 040 dump would help reveal more about it. I do know from my past time spent looking through this that it uses the ROM checksum at $40800000 to figure out which ROM/machine it's running under.

I've also attached the dump of what the IIci ROM looks like at $40800000 when you dump it with CopyRoms with the Turbo 040 installed.

 

[eharmon]

I never figured out how to decode the raw chip dumps, but I helped @olePigeon back in the day in my IIci mega-thread (starting around here) with some hacking on the normal Mac ROM with a Turbo 040 installed. At least in the IIci, it ends up being mapped into ROM space at $40880000. If it helps, here's an in-system dump we did of what I believe is the 4.01 ROM. You can see some human readable strings starting at $4FBE.

We also found that the Turbo 040 patches a bunch of stuff in the Mac's original ROM. I'm not sure if it makes a copy in RAM and reconfigures the MMU or what. I guess there still has to be an entry point added prior to that somehow. Maybe taking further time to disassemble the Turbo 040 dump would help reveal more about it. I do know from my past time spent looking through this that it uses the ROM checksum at $40800000 to figure out which ROM/machine it's running under.

I've also attached the dump of what the IIci ROM looks like at $40800000 when you dump it with CopyRoms with the Turbo 040 installed.

It looks like it patches the location of the StartBoot pointer. That seems to lend credence to the theory it's remapping memory before CPU execution starts since they're patching pretty close to the first entry point.

 

[Arbee]

Interesting. What type is the EPROM on the card? EPROM readers always read and write in little-endian by convention, so knowing if it's a 16 or 32 bit wide ROM would help when trying to figure out how to descramble it.

 

[dougg3]

It looks like it patches the location of the StartBoot pointer. That seems to lend credence to the theory it's remapping memory before CPU execution starts since they're patching pretty close to the first entry point.

That definitely makes sense. I wonder if they only have to do it that way in a few places, or if there is enough smarts to apply all the patches that same way.

Interesting. What type is the EPROM on the card?

Going way back to my discussions in PM with olePigeon in 2011, it looks like it’s an AM27C010-150JC.

 

[Bolle]

Reordering the address or data lines

That's what they did... both address as well as data lines have been scrambled:

 

[Bolle]

At least in the IIci, it ends up being mapped into ROM space at $40880000

This is interesting... the hardware address decoder on the Turbo040 itself has the ROM mapped to 0x52000000.

What's also interesting to know... the Turbo040 does not rely on the logicboard 68030 at all. You can remove the 030 and the Mac will still start with just the Turbo040 as its only CPU.

 

[dougg3]

That's what they did... both address as well as data lines have been scrambled:

Nice work! I can confirm this is correct. Here's some code I quickly threw together to decrypt the ROM dumps based on your provided pin mappings. Comparing against the in-system dumps here, it comes out correct.

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *tmpBuf = malloc(128*1024);
    
    FILE *inputFile;
    FILE *outputFile;
    inputFile = fopen(argv[1], "rb");
    outputFile = fopen(argv[2], "wb");
    
    for (int j = 0; j < 128*1024; j++)
    {
        static const uint8_t remapAddrBits[17] = {
            16,0,1,2,3,4,5,6,11,14,13,10,7,9,8,12,15
        };
        static const uint8_t remapDataBits[8] = {
            1, 0, 3, 2, 5, 4, 7, 6
        };
        
        const uint8_t readback = fgetc(inputFile);
        uint32_t actualAddress = 0;
        uint8_t actualData = 0;
        
        for (int i = 0; i < 17; i++)
        {
            if (j & (1 << i))
            {
                actualAddress |= (1 << remapAddrBits[i]);
            }
        }
        for (int i = 0; i < 8; i++)
        {
            if (readback & (1 << i))
            {
                actualData |= (1 << remapDataBits[i]);
            }
        }
        
        tmpBuf[actualAddress] = actualData;
    }
    fclose(inputFile);
    
    // Save it
    fwrite(tmpBuf, 128*1024, 1, outputFile);
    fclose(outputFile);
    free(tmpBuf);
    
    return 0;
}

Interestingly, it isn't a perfect match with the in-system dumps. It appears that some pieces end up being filled in at runtime or something. Often it appears to be ROM (system or Turbo 040) addresses like $408xxxxx.

This is interesting... the hardware address decoder on the Turbo040 itself has the ROM mapped to 0x52000000.

Weird! I didn't look very deeply into it at the time. Maybe there's some MMU remapping going on.

 

[eharmon]

Nice work! I can confirm this is correct. Here's some code I quickly threw together to decrypt the ROM dumps based on your provided pin mappings. Comparing against the in-system dumps here, it comes out correct.

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *tmpBuf = malloc(128*1024);
   
    FILE *inputFile;
    FILE *outputFile;
    inputFile = fopen(argv[1], "rb");
    outputFile = fopen(argv[2], "wb");
   
    for (int j = 0; j < 128*1024; j++)
    {
        static const uint8_t remapAddrBits[17] = {
            16,0,1,2,3,4,5,6,11,14,13,10,7,9,8,12,15
        };
        static const uint8_t remapDataBits[8] = {
            1, 0, 3, 2, 5, 4, 7, 6
        };
       
        const uint8_t readback = fgetc(inputFile);
        uint32_t actualAddress = 0;
        uint8_t actualData = 0;
       
        for (int i = 0; i < 17; i++)
        {
            if (j & (1 << i))
            {
                actualAddress |= (1 << remapAddrBits[i]);
            }
        }
        for (int i = 0; i < 8; i++)
        {
            if (readback & (1 << i))
            {
                actualData |= (1 << remapDataBits[i]);
            }
        }
       
        tmpBuf[actualAddress] = actualData;
    }
    fclose(inputFile);
   
    // Save it
    fwrite(tmpBuf, 128*1024, 1, outputFile);
    fclose(outputFile);
    free(tmpBuf);
   
    return 0;
}

Interestingly, it isn't a perfect match with the in-system dumps. It appears that some pieces end up being filled in at runtime or something. Often it appears to be ROM (system or Turbo 040) addresses like $408xxxxx.

Likely dynamic addresses based on the ROM version it's patching?

 

[Arbee]

Awesome, thank you Bolle! LEM says the Turbo040 works on the II, IIx, IIcx, IIci, IIsi, IIvx, IIvi, and SE/30. Are those all with the same ROM on the card?

 

[Arbee]

Gonna answer myself here. There's two strings in the ROM:
'Macintosh II, IIx, IIcx, IIci, IIsi, IIvi,',$D,' IIvx, SE/30, and Performa 600.',$D,'(ASIC support included)'
and
'Macintosh LC and LC II',$D,'Performa 400, 405, 410 and 430',$D,'(ASIC support included)'

Innnnnteresting. I haven't seen anything about these working in an LC or LC II, but the ROM does have references to $40A00000 which is where the LC and LC II put their ROM.

 

[dougg3]

Innnnnteresting. I haven't seen anything about these working in an LC or LC II, but the ROM does have references to $40A00000 which is where the LC and LC II put their ROM.

I wonder if the Value 040 shares the exact same ROM? Daystar refers to the Turbo 040 and Value 040 together in a lot of places. This listing on Worthpoint implies the Value 040 is for the SE/30, but it sure looks a lot like an LC PDS card.

Also, this 1994 catalog from MacConnection shows the Value 040 being for all those LC/LC II/Performa 4xx models (page 66):

 

[Arbee]

Ahh, didn't know about the Value040. This code at the start of the ROM definitely looks like LC support.

ROM:52000040                 cmpi.l  #$350EACF0,d2   ; LC
ROM:52000046                 beq.s   loc_52000060
ROM:52000048                 cmpi.l  #$35C28F5F,d2   ; LC II
ROM:5200004E                 beq.s   loc_52000060
ROM:52000050                 cmpi.l  #$35C28C8F,d2   ; ???
ROM:52000056                 beq.s   loc_52000060
ROM:52000058                 move.l  #$40800000,d4
ROM:5200005E                 bra.s   loc_52000066
ROM:52000060 ; ---------------------------------------------------------------------------
ROM:52000060
ROM:52000060 loc_52000060:                           ; CODE XREF: ROM:52000046
ROM:52000060                                         ; ROM:5200004E ...
ROM:52000060                 move.l  #$40A00000,d4

The third ROM checksum it's looking for doesn't exist as far as I know. Possibly a late beta of the LC II ROM since it's quite close to the checksum for the final LC II.

 

[Bolle]

II, IIx, IIcx, IIci, IIsi, IIvx, IIvi, and SE/30. Are those all with the same ROM on the card?

Just to answer that again, yes. Again correct on the LC I and LC II. Surprisingly the Value040 doesn't list the LC III/Performa 450 as compatible... The Turbo040 doesn't like that one either even though an adapter for the LC III exists. That one will only run the PowerCache.

 

[Jockelill]

I never figured out how to decode the raw chip dumps, but I helped @olePigeon back in the day in my IIci mega-thread (starting around here) with some hacking on the normal Mac ROM with a Turbo 040 installed. At least in the IIci, it ends up being mapped into ROM space at $40880000. If it helps, here's an in-system dump we did of what I believe is the 4.01 ROM. You can see some human readable strings starting at $4FBE.

We also found that the Turbo 040 patches a bunch of stuff in the Mac's original ROM. I'm not sure if it makes a copy in RAM and reconfigures the MMU or what. I guess there still has to be an entry point added prior to that somehow. Maybe taking further time to disassemble the Turbo 040 dump would help reveal more about it. I do know from my past time spent looking through this that it uses the ROM checksum at $40800000 to figure out which ROM/machine it's running under.

I've also attached the dump of what the IIci ROM looks like at $40800000 when you dump it with CopyRoms with the Turbo 040 installed.

The same is for the SE/30, the Daystar is also mapped starting at 40880000. I tried getting romdisk to work in that combination, by moving the romdisk to 40900000, but no success, then I tried also injecting the by daystar modified ROM but still no luck, but that migth be explained by the byteswapping above, so very useful information.