Buildable Micron Xceed Color 30HR ROM Source

[zigzagjoe]

https://github.com/ZigZagJoe/Color30HR-ROM

In case it interests folks, I have been idly fiddling with the original Micron source dumps in order to get an environment set up that can build a copy of the ROM. I've succeeded in building an exact copy of what I believe is the shipping ROM for the Color 30 HR from 1993. Everything required has been uploaded at the repo. There's a ready made HFS image, or you can download the source and go it on your own. Be advised you'll need to run System 6 or the helper tools from Micron's original dump won't work.

There is one major deficit with the original dump, which is theDriver.a was missing. This is the code that provides the interface between MacOS and the hardware, allowing you to change bit depth/CLUT on the fly. I think the software interface is described at the top of 369Color.a.

To work around this, I extracted the assembled code from the shipping ROM and have translated it as byte literals into a file which suffices to assemble the ROM. It really needs proper disassembly and reverse engineering to allow tweaking as it does seem to have some interaction with resolution options.

This code is intended for Color 30HR cards with Gambler ASICs.
If you have a Color 30 card with a Rev F PCB and Maverick ASIC, it would be trivial to modify this source to build a ROM to turn it into a Color 30HR - see this thread for details.

 

[cheesestraws]

Very nice!

 

[Melkhior]

There is one major deficit with the original dump, which is theDriver.a was missing. This is the code that provides the interface between MacOS and the hardware, allowing you to change bit depth/CLUT on the fly. I think the software interface is described at the top of 369Color.a.

There's the DRVRHeader at the beginning (which is why you need byte-exacteness, as that hardwires the offsets of driver functions) and the function code as well so you're right:


The important function for control of the FB is the drvrCtrl function ; open is quite big so I presume they check for which hardware they have there (you can find an example of a working Declaration Rom for my own device, nearly entirely in C for Retro68, in my GitHub).

Once you start cleaning stuff up in Ghidra, reverse-engineering confirms suspicfion ; for instance by defining the struct passed in paramter (they are in Universal Headers), you get a switch on csMode in Ctrl and case 2 (cscSetMode) looks like this:

pvVar1 is from dCtlStorage, which is usually storing a private structure. Clearly the depth is at offset 4, as csMode in the VDPageInfo of cscSetMode is the depth parameter. The FFEF is the -17 of controlErr, checks out. The unamed function are likely setting the hardware to the proper values. I have no idea why the uVar5 decodes to some weird stuff, in assembly it's just setting the return value to 0 == noErr and returning.

 

[zigzagjoe]

Yep, that lines up with what I found. I did a little bit of preliminary work in IDA for my Color 30->30HR project. It all looked fairly standard, to the extent I can tell, and I noticed common constants with the rest of the ROM that'd be pretty easy to sus out and replace. Crucially it wasn't touching the major sensitive register I needed to change for the HR upgrade, so that's where I stopped. Given all of the SwapMMUMode calls, it makes it really easy to figure out when it's getting ready to tickle hardware.

It didn't look too terrible overall to reverse engineer at a basic level, but I decided to take the binary blob approach as I wasn't quite ready to tackle getting the disassembly to 1:1 with the original binary as a baseline. I'll have to look at ghidra - looks like a cool tool.

Also, I was wrong, the bits at the top of 369color (line 58 onwards) is hardware interface info, not (directly) related to the driver. Possibly outdated, the constants in 369includes.a should be used instead.

I'll probably fiddle with it some more, but that does beg the question of the best way to track source for efforts like this that need to go into an emulator to assemble... github doesn't like \r only line endings, and mac obviously is allergic to anything but \r. It would be possible to update it so a modern assembler could assemble it, but I didn't feel like translating all the macros.

 

[Melkhior]

If you can figure out the hardware registers (at least enough of them to get something working in basic resolution/depth), it might be easier to write the Declaration Rom 'from scratch' - or at least from a 'known good' starting point ;-) Mine should be reasonably readable for that purpose though it's probably not 24-bits compatible in its current state (with 8 MiB of framebuffer in the NuBusFPGA, no point in trying to work with just 1 MiB of NuBus slot space...), and it mostly just needs Retro68 in Linux to build so it's easy to handle in GitHub and the like.

 

[zigzagjoe]

The micron dump contains the rest of the source with basic register descriptions, and the tech docs give further detail on which bits do which (pg 48 - those docs are an amazing windfall). There's enough info that I'm pretty sure you could do just about whatever you want within the limits of the hardware.

It'd be possible to entirely rewrite the DeclROM, but as we have the working source for the rest of the ROM, it's easier IMO to just reverse that driver at least for minor modifications. I've personally met my goal of upgrading my card to 30HR, but I'm sure there's some folks that'd like to see the 68040 issue fixed. That one might get complicated.

 

[zigzagjoe]

I've committed a version of the code that now supports building a ROM for either Gambler or Maverick ASIC, and also supports (requires, actually) MPW 3.2+ under System 7 to ease development pain. I've verified that this builds an exact match for my modified Maverick ASIC ROM or the stock Gambler ASIC ROM.

An archive with a working mixed MPW 3.3/3.2 is also in the github now.

 

[zigzagjoe]

Well, after hacking at it a little: Looks like 256 colors at anything higher than 640x480 is not possible. If I am understanding correctly, the hardware can either do either 512 bytes or 1024 bytes per row. The number of columns (width) must fit in this amount of RAM.

So, no matter your bit depth, row count * row size must be less than the size of the VRAM. Anything higher than 640 columns, it halves the per-row size to 512 bytes (which requires halved bit depth) to allow enough rows to fit in VRAM.

640 (cols) x 480 (rows) @ 8bpp ( 1 byte) = 480 rows * 1024 bytes per row (640 b used) = 491.52 KB total VRAM
1024 (cols) x 768 (rows) @ 4bpp (0.5 byte)= 768 rows * 512 bytes per row (512 b used) = 393.216 KB total VRAM

800x600 @ 256 would require 1 byte per pixel, and thus requires a 1024 row size. With 600 rows, this would exceed the 512kb of VRAM on the card.

Basically the takeaway here is no real additional resolutions are possible. I suppose you could have a black and white only 1152 x 864 with an 80mhz RAMDAC, but it'd be pretty pointless.

Takeaway is, I guess Micron's engineers knew what they were about. Who could have guessed?
The only other interesting room to proceed I see here would basically be driver improvements to fix compatibility issues with 68040s, or alternative OSes, which of course requires reverse engineering of that part as we don't have the source. Might still be possible to do increased vertical resolution on grayscale.

Unrelated: For those who like playing with 27C256, but are tired of wasting chips - get yourself some Winbond W27E257, they are drop-in compatible EEPROMs.

 

[zigzagjoe]

I've added a v2.1 that allows booting into A/UX with a grayscale setup installed where previously, it would lock up during boot unless you attached a monitor. This is because A/UX does not support gracefully disabling the onboard video.

Instead, for the time being, with the 2.1 ROM, if A/UX and Grayscale is detected, grayscale will not be used under A/UX (B&W only).

No special process to go into A/UX is required with this ROM installed. Boot your mac normally into the A/UX System 7 (grayscale will be working at this point), then boot A/UX itself. Video will hand back to stock during A/UX boot process.

Using the micron to drive an external display under A/UX will continue to work normally, and no changes have been made that would affect MacOS's behavior.

To use, pick the ROM corresponding to your chip version and write it to a suitable EPROM or EEPROM.

Tech details:

Changes begin here.

Root cause is during GS Init sequence, it disables stock video by removing its resources with _sDeleteSRTRec. This is not supported by the A/UX toolbox. A/UX reinitialized everything during its boot sequence and when the micron rom tries to disable internal video it crashes everything.

Workaround: don't disable stock video, don't initialize grayscale instead if A/UX is running.

Also, added code to reset the default display PRAM value if this card does not have a monitor or grayscale attached (or, if we are booting a/ux). This helps with some funny behavior when switching from grayscale to external monitor setups.

Fun fact, you can change the startup display value using the monitors control panel and holding option.

 

[zigzagjoe]

(I wish the edit interval was longer!!)

Reverted version 2.1 version number back to 2.0, as this breaks MonitorXceed extension's ability to recognize the card. I don't feel like updating that too. Interestingly, however, reviewing its whitelist suggests there may be a Color 30HR v2.5 ROM in the wild somewhere.

 

[tt]

Wow! Since this is top of mind, I am wondering, would it be possible to change the driver to make the Xceed board report the typical internal video resolution of 512x342 when it is in greyscale mode? As originally designed, the driver reports 512x341 which can cause issues with programs like HyperCard.

 

[zigzagjoe]

Wow! Since this is top of mind, I am wondering, would it be possible to change the driver to make the Xceed board report the typical internal video resolution of 512x342 when it is in greyscale mode? As originally designed, the driver reports 512x341 which can cause issues with programs like HyperCard.

I forgot to mention it in this thread, micron changed to 342 pixel with the Color 30HR firmware. So that's all taken care of already.

 

[tt]

Yeah, actually I saw your other thread and saw that you mentioned it there. I didn't know that resolution hack was eliminated which is a great find.

I just went to check if I had a later ROM version to help with your search, but only have one that says 2.0 on it. I am guessing that if there is a v2.5, it would be a board that does not have Micron branding on it since I think they spun off the company into "Xceed" at some point.

 

[tt]

@zigzagjoe Where do you recommend buying the Winbond EEPROMs? Do you think @dougg3 's programmer would be compatible?

 

[zigzagjoe]

Yeah, actually I saw your other thread and saw that you mentioned it there. I didn't know that resolution hack was eliminated which is a great find.

I just went to check if I had a later ROM version to help with your search, but only have one that says 2.0 on it. I am guessing that if there is a v2.5, it would be a board that does not have Micron branding on it since I think they spun off the company into "Xceed" at some point.

Yes, you're right about the rebrand. Very very late PCBs they started labeling as Xceed also.

@zigzagjoe Where do you recommend buying the Winbond EEPROMs? Do you think @dougg3 's programmer would be compatible?

I got them from this ebay auction. They shipped from china, took some time but were legit chips with CDROM firmware on them. However, you only really need these if you intend to (re)write them multiple times (ie. development work).

Otherwise, you can use the original 27C256 EPROMs just fine, they are cheaper and more available. It's just a single shot per chip as there is no way to erase them.

Unfortunately the DougG3 programmer will not work to my knowledge as it is going to be expecting flash chips not EPROM/EEPROMs. I used a Xgecu TL866II Plus / T48 programmer to write mine. If you don't want to get a full programmer, you might be able to order some 27C256 from Digikey/Mouser/Arrow and have them program them for you.

 

[tt]

Ah bummer. I guess getting a programmer is something to look into since it seems more projects being posted here are using them. Is it fairly straightforward to program them for someone not being familiar with that type of programmer? I wonder if there's some arduino type project that might work if it's something someone's doing as a one-off.

 

[cheesestraws]

Is it fairly straightforward to program them for someone not being familiar with that type of programmer?

For most use cases, you tell them what kind of chip you're using and what file you want and hit 'go'.

 

[zigzagjoe]

Ah bummer. I guess getting a programmer is something to look into since it seems more projects being posted here are using them. Is it fairly straightforward to program them for someone not being familiar with that type of programmer? I wonder if there's some arduino type project that might work if it's something someone's doing as a one-off.

You probably could make it happen with an arduino and a bit of patience. Annoying, however, as it does require 12v to program and the details of the algos are sometimes not easily found.

For a one-off - some folks play with ROMs and have spare 26c256 hanging around - I'd post a WTB in the trading post to see if someone would program one and drop it in an envelope for a nominal cost. Or see if digikey/mouser/etc could program one.