zigzagjoe
Well-known member
I've been up to something fun with @Bolle today.
Thanks to some hardware hackery by bolle, and baby's first ROM modification for my part, that's an IIsi logic board driving an SE/30 internal screen
Storytime: While writing the driver for my 30Video cards, I was consulting the SuperMario (660/840AV) ROM Sources, specifically to review video driver code to sanity check some things I'd done. In there you can find references to a hypothetical SE-form-factor machine that would utilize the RBV (Ram Based Video) video controller from IIsi and IIci. Interesting, but the question was open - how would such a beast actually be wired? Does the software support exist?
Well, @Arbee leaked the RBV datasheet (attached) which makes it clear, and it's very, very simple!
Lift a pin on the RBV and ground it, easy enough, and Bolle found that it'll even kindly output the special horizontal drive signal (SE.HSYNC) required by SE type analog boards. Grab TTL video from before the RAMDAC, and in theory you've got everything you need to drive the SE monitor: VSync, TTL Video, and the special Hsync.
Bolle wired this up and found that the SE video definitely works in hardware. The picture is exactly correct which means the syncs are sane, the pixel clock appears consistent (for uninitialized RAM). The board was upset due to lack of 5vSB, but it can clearly be seen the video is working. This now becomes a problem of software support.
Based on a review of the driver code, it sure looks like there is sResources for the SE type display at multiple depths! Score! (Hypothetical grayscale possibility here!). With any luck this means it'll be a simple tweak to get it to bring the RBV up for an SE monitor.
With an unmodified ROM and a working IIsi board, you only get a black screen. Well, that's fair enough - the PrimaryInit is looking for a specific BoxFlag in order to know if it should bypass the no-monitor-detected condition and initialize video anyways. Normally, the 111 sense code means no monitor, but on the SE-type RBV machine it means no external monitor, enable the internal monitor. As the machine ID is NOT one of the BoxAuroraSE constants, PrimaryInit goes welp, no monitor, time to die and there we end.
So, the first change needed is to tweak that final BEQ (branch on equal) before 'noMon' to an unconditional BRA into the initalization code. 0x67 becomes 0x60, easy enough. WIth a bit of creative searching for hex strings it was possible to identify this section of code in IDA without needing to fully disassemble and RE the lot. Around offset 0x7EEE0, for the record. Using @cy384's CRC calculation tool I send Bolle a new ROM image to try. Unfortunately, this one sad chimes after the memory test, but it works perfectly in SE/30. ROM CRC's good, then.
The odd part? This happens with any monitor detected, and not when there's no monitor connected. Hmmm. Even after patching code that isn't even touched (thus no change in ROM behavior) we'll still get sad chimes. Seems a lot like there's a secondary level of integrity validation being performed on the IIsi image I've been working on. Any time a monitor is present or is hotplugged after boot - immediate death chime. How weird. I also investigated if we could just change the BoxFlag, but as expected most of the neccisary declarations for a new machine type have been stripped out, so the ROM would likely explode in spectacular fashion (and Mac OS would, if the ROM didn't).
Extensive combing of the supermario source doesn't find anything that could explain this behavior. Before giving up I decided to try a later Universal ROM - the Quadra 650 in specific - as I know it will boot an IIsi. The 660AV would have been ideal as it would match the sources 1:1, but alas it will not work in an IIsi. Performed the modification after locating the same code in IDA, and handed it to Bolle... after a search for some suitable flash chips:
No joy, and sad chimes again. Progress though! Works with a normal monitor attached. We are definitely further in the boot process.
This is clearly ordered data. There's logic to it, it's not random and happens on each boot. Working theory: This looks much like I might expect lowmems at $0 to potentially look like, if dumped straight into a framebuffer. Which is also where the RBV framebuffer always starts. If the RBV framebuffer is in use, then the MMU is used to remap logical address $0 to a different physical address in RAM. As this is deep voodoo, The RBV memory map has to be set up real early in the boot process, before DRAM is in general use: it probably also needs a case for the SE type machine rather than deallocating the framebuffer as would otherwise be done. If bolle boots with a monitor attached, and detaches it, The SE will display incorrect contents due to the incorrect memory setup/size - but it's doing something sensible. So clearly, the SE setup is not all the way done.
Time for some more digging on how the RBV framebuffer is allocated. What's this I spy here? A MMU setup table for the RBV? With an obvious jump table that points to sets of data defining the framebuffer size. And you'll note the entry for 111 - the no-monitor sense code, or the sense for SE-monitor - is 0, where it will later deallocate the framebuffer. Let's change that to 0x10, which is 16 bytes from start of table, the offset to SETable entries. Update checksum. Make sure it seems sensible on my machine: boot with no monitor attached and later attached it, I get the below. This looks a lot like I'd expect for a 512x342 signal with incorrect video timings (VGA). Very promising.
Sidebar: The RBV docs seem to imply hotplug is possible/planned for, and during earlier testing I definitely found plugging a monitor into a screenless machine would cause the crash immediately at any time post RAM test. There's definitely some kind of dynamic behavior here. Curious how this is being done post boot, as normally monitor sense is a one-and-done affair. The SE video will also turn off immediately for safety (to prevent driving the analog board out of spec). Sidebar over.
OK, hand the ROM with modified MMU table to bolle. What's this?
First time that's happened in a few decades!
The additional depths are also shown in Monitors and can be switched to, so the sResource setup is good! There's some video glitch in the nondisplay area on the right side, it looks like that is backed by actual VRAM that is simply blanked. It is the same trick to what I did for the 30Video GS card and it may need some cleanup on depth changes. It's what MaxAppleZoom exploited back in the day to get a little extra display real estate.
Very promising! Right now, the display is still 1bit black and white as it's coming directly off the LSB digital output from the RBV but as the RAMDAC should be properly working too grayscale harness could be bodged onto the standard video output for grayscale operation
We've less than a day of tinkering on this so far, I'm sure there will be more to come. To-do list: Grayscale testing, figure out what gets the IIsi ROM all bothered, and test possibility that a 512x384 resolution could be used to drive the SE screen. Exciting!
Thanks to some hardware hackery by bolle, and baby's first ROM modification for my part, that's an IIsi logic board driving an SE/30 internal screen
Storytime: While writing the driver for my 30Video cards, I was consulting the SuperMario (660/840AV) ROM Sources, specifically to review video driver code to sanity check some things I'd done. In there you can find references to a hypothetical SE-form-factor machine that would utilize the RBV (Ram Based Video) video controller from IIsi and IIci. Interesting, but the question was open - how would such a beast actually be wired? Does the software support exist?
Well, @Arbee leaked the RBV datasheet (attached) which makes it clear, and it's very, very simple!
Lift a pin on the RBV and ground it, easy enough, and Bolle found that it'll even kindly output the special horizontal drive signal (SE.HSYNC) required by SE type analog boards. Grab TTL video from before the RAMDAC, and in theory you've got everything you need to drive the SE monitor: VSync, TTL Video, and the special Hsync.
Bolle wired this up and found that the SE video definitely works in hardware. The picture is exactly correct which means the syncs are sane, the pixel clock appears consistent (for uninitialized RAM). The board was upset due to lack of 5vSB, but it can clearly be seen the video is working. This now becomes a problem of software support.
Based on a review of the driver code, it sure looks like there is sResources for the SE type display at multiple depths! Score! (Hypothetical grayscale possibility here!). With any luck this means it'll be a simple tweak to get it to bring the RBV up for an SE monitor.
With an unmodified ROM and a working IIsi board, you only get a black screen. Well, that's fair enough - the PrimaryInit is looking for a specific BoxFlag in order to know if it should bypass the no-monitor-detected condition and initialize video anyways. Normally, the 111 sense code means no monitor, but on the SE-type RBV machine it means no external monitor, enable the internal monitor. As the machine ID is NOT one of the BoxAuroraSE constants, PrimaryInit goes welp, no monitor, time to die and there we end.
So, the first change needed is to tweak that final BEQ (branch on equal) before 'noMon' to an unconditional BRA into the initalization code. 0x67 becomes 0x60, easy enough. WIth a bit of creative searching for hex strings it was possible to identify this section of code in IDA without needing to fully disassemble and RE the lot. Around offset 0x7EEE0, for the record. Using @cy384's CRC calculation tool I send Bolle a new ROM image to try. Unfortunately, this one sad chimes after the memory test, but it works perfectly in SE/30. ROM CRC's good, then.
The odd part? This happens with any monitor detected, and not when there's no monitor connected. Hmmm. Even after patching code that isn't even touched (thus no change in ROM behavior) we'll still get sad chimes. Seems a lot like there's a secondary level of integrity validation being performed on the IIsi image I've been working on. Any time a monitor is present or is hotplugged after boot - immediate death chime. How weird. I also investigated if we could just change the BoxFlag, but as expected most of the neccisary declarations for a new machine type have been stripped out, so the ROM would likely explode in spectacular fashion (and Mac OS would, if the ROM didn't).
Extensive combing of the supermario source doesn't find anything that could explain this behavior. Before giving up I decided to try a later Universal ROM - the Quadra 650 in specific - as I know it will boot an IIsi. The 660AV would have been ideal as it would match the sources 1:1, but alas it will not work in an IIsi. Performed the modification after locating the same code in IDA, and handed it to Bolle... after a search for some suitable flash chips:
No joy, and sad chimes again. Progress though! Works with a normal monitor attached. We are definitely further in the boot process.
This is clearly ordered data. There's logic to it, it's not random and happens on each boot. Working theory: This looks much like I might expect lowmems at $0 to potentially look like, if dumped straight into a framebuffer. Which is also where the RBV framebuffer always starts. If the RBV framebuffer is in use, then the MMU is used to remap logical address $0 to a different physical address in RAM. As this is deep voodoo, The RBV memory map has to be set up real early in the boot process, before DRAM is in general use: it probably also needs a case for the SE type machine rather than deallocating the framebuffer as would otherwise be done. If bolle boots with a monitor attached, and detaches it, The SE will display incorrect contents due to the incorrect memory setup/size - but it's doing something sensible. So clearly, the SE setup is not all the way done.
Time for some more digging on how the RBV framebuffer is allocated. What's this I spy here? A MMU setup table for the RBV? With an obvious jump table that points to sets of data defining the framebuffer size. And you'll note the entry for 111 - the no-monitor sense code, or the sense for SE-monitor - is 0, where it will later deallocate the framebuffer. Let's change that to 0x10, which is 16 bytes from start of table, the offset to SETable entries. Update checksum. Make sure it seems sensible on my machine: boot with no monitor attached and later attached it, I get the below. This looks a lot like I'd expect for a 512x342 signal with incorrect video timings (VGA). Very promising.
Sidebar: The RBV docs seem to imply hotplug is possible/planned for, and during earlier testing I definitely found plugging a monitor into a screenless machine would cause the crash immediately at any time post RAM test. There's definitely some kind of dynamic behavior here. Curious how this is being done post boot, as normally monitor sense is a one-and-done affair. The SE video will also turn off immediately for safety (to prevent driving the analog board out of spec). Sidebar over.
OK, hand the ROM with modified MMU table to bolle. What's this?
First time that's happened in a few decades!
The additional depths are also shown in Monitors and can be switched to, so the sResource setup is good! There's some video glitch in the nondisplay area on the right side, it looks like that is backed by actual VRAM that is simply blanked. It is the same trick to what I did for the 30Video GS card and it may need some cleanup on depth changes. It's what MaxAppleZoom exploited back in the day to get a little extra display real estate.
Very promising! Right now, the display is still 1bit black and white as it's coming directly off the LSB digital output from the RBV but as the RAMDAC should be properly working too grayscale harness could be bodged onto the standard video output for grayscale operation
We've less than a day of tinkering on this so far, I'm sure there will be more to come. To-do list: Grayscale testing, figure out what gets the IIsi ROM all bothered, and test possibility that a 512x384 resolution could be used to drive the SE screen. Exciting!
FINALLY! 
