• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Building an internal grayscale card for the SE/30

MacSE/30

Well-known member
Considering apm's "Compact Mac retina display" hack (640x480 internal CRT) what we need now is a 603e based CPU card. So we could run a networked 640x480 grayscale Mac OS 9.1 on SE/30, and boot it from ROM ...😈
 

Trash80toHP_Mini

NIGHT STALKER
Considering apm's "Compact Mac retina display" hack (640x480 internal CRT) what we need now is a 603e based CPU card. So we could run a networked 640x480 grayscale Mac OS 9.1 on SE/30, and boot it from ROM ...😈
Gotta reverse engineer the 1400 board to meet that spec, you can add PCMCIA WiFi with ease to your breakout board and boot from the other slot when necessary. ;)
 

Aeroform

Well-known member
All that's left now is an endless fight about how the routine that displays a boot splash screen should be implemented now :p

Now if you feel like complicating it further, how about a animated boot splash? If it all possible to let’s say display 5-20 different boot screens in quick succession, that could be really cool!

Let me know if you want any design/animation help. I’m a (was) a graphic designer by trade.
 

Trash80toHP_Mini

NIGHT STALKER
Great idea, but probably in the interesting notion category? Methinks such would require intelligence on the board. Splash seems to me to be a simple, binary on/off decision determined by machine state of the card? It's on when the card fires up, but flipped off by the time is the startup screen needs to be displayed? Wondering if a simple counter setup could do the dirty?

So curious now, especially about which ot the three sorcerers fields the question! I wonder if there's room in the ROM corner for a complex GS image? What does the card's native boot screen look like?

edit: I'm digging the notion of an eight character S E / 3 0 / G S C or some such on a rolling GS field of distinct rectangles per D I G I T A L logo might work? Let the endless fight begin! :p
 
Last edited:

Aeroform

Well-known member
Great idea, but probably in the interesting notion category? Methinks such would require intelligence on the board. Splash seems to me to be a simple, binary on/off decision determined by machine state of the card? It's on when the card fires up, but flipped off by the time is the startup screen needs to be displayed? Wondering if a simple counter setup could do the dirty?

So curious now, especially about which ot the three sorcerers fields the question! I wonder if there's room in the ROM corner for a complex GS image? What does the card's native boot screen look like?

edit: I'm digging the notion of an eight character S E / 3 0 / G S C or some such on a rolling GS field of distinct rectangles per D I G I T A L logo might work? Let the endless fight begin! :p
Now, I’ve never programmed a rom or boot routine or whatever sorcery would be needed haha. But in my uninformed mind a simple timer loop switching images every X milliseconds should do the trick haha. If there’s space enough for x amount of images in the rom of course.
 

Trash80toHP_Mini

NIGHT STALKER
But in my uninformed mind a simple timer loop switching images every X milliseconds should do the trick haha.
Might could be, that'd be the counter setup I mentioned. I've never done any of the above either. It will be very interesting to see what the developers have to say.
 

GeekDot

Well-known member
Now if you feel like complicating it further, how about a animated boot splash? If it all possible to let’s say display 5-20 different boot screens in quick succession, that could be really cool!
Well, I thought about that, too (obviously), but there are certain limitations:

There are "the 3 commandments for a primaryInit":
  1. Thou shalt have no calls to ROM routines except for the Slot Manager
  2. Thy code length must be less than 16KB - but ideally it should be 2KB or less.
  3. Thy code execution time shalt be no longer than half of a mans blink (200ms)
In all cases, if you do not obey, you will burn in Windoze-Hell until the end of days :devilish:🔥.

Animation would mean:
  • draw an image
  • wait a bit
  • clear that image
  • draw the next image
  • wait a bit
  • ....
You get the gist... time waste.

Let me know if you want any design/animation help. I’m a (was) a graphic designer by trade.

Me too... That makes it a company ;) [Following my rule of "Two's a company, three is a crowd"]

Great idea, but probably in the interesting notion category? Methinks such would require intelligence on the board. Splash seems to me to be a simple, binary on/off decision determined by machine state of the card?
There's no intelligence on the board. Neither in your Mac... it sits in front of it. ;)
Seriously, the intelligence is your 30's is the 68030 - he's doing all the fancy stuff the DeclROM asks him to do. And following the 3 commandments, he's pretty much on his own. No toolbox, no warm slippers, no nothing...

So curious now, especially about which ot the three sorcerers fields the question! I wonder if there's room in the ROM corner for a complex GS image?
In the current 8K ROM, there are 5k left for a logo.
We're exploring the breathtaking world of a 16K ROM right now (needs a working additional adress-line on the unmodded formac card.)
 

Aeroform

Well-known member
Well, I thought about that, too (obviously), but there are certain limitations:

There are "the 3 commandments for a primaryInit":
  1. Thou shalt have no calls to ROM routines except for the Slot Manager
  2. Thy code length must be less than 16KB - but ideally it should be 2KB or less.
  3. Thy code execution time shalt be no longer than half of a mans blink (200ms)
In all cases, if you do not obey, you will burn in Windoze-Hell until the end of days :devilish:🔥.

Animation would mean:
  • draw an image
  • wait a bit
  • clear that image
  • draw the next image
  • wait a bit
  • ....
You get the gist... time waste.



Me too... That makes it a company ;) [Following my rule of "Two's a company, three is a crowd"]


There's no intelligence on the board. Neither in your Mac... it sits in front of it. ;)
Seriously, the intelligence is your 30's is the 68030 - he's doing all the fancy stuff the DeclROM asks him to do. And following the 3 commandments, he's pretty much on his own. No toolbox, no warm slippers, no nothing...


In the current 8K ROM, there are 5k left for a logo.
We're exploring the breathtaking world of a 16K ROM right now (needs a working additional adress-line on the unmodded formac card.
16kb of code

16kb of code seems plenty, 5k for animated graphics haha not so much 😂. Perhaps 16k would be good enough to animate some stuff in code, altough I guess there’s no graphics or animation libraries available so it would be quite the pain to code 😅

In what order would the splash screen show? Would it replace the happy mac screen or come after? I’m quite the purist so my initial anination idea was to transition from a 1bit happy mac to a grey scale one, and in the end add the grahic card logo. Would look pretty clean and tell the story nicely I think.
 

Trash80toHP_Mini

NIGHT STALKER
There's no intelligence on the board. Neither in your Mac... it sits in front of it. ;)
I thought that's what I was saying.
Seriously, the intelligence is your 30's is the 68030 - he's doing all the fancy stuff the DeclROM asks him to do. And following the 3 commandments, he's pretty much on his own. No toolbox, no warm slippers, no nothing...
My Radius boards appear to splash the screen at startup whether the Mac successfully boots or not. That's why I said it would a two state system requiring no intelligence.

0 - Board On - Splashes Radius Logo in lower left corner - No Intelligence required - Logo is baseline frame buffer image from DeclROM
1 - Board's frame buffer is filled by CPU running from ROM - Curious Mac is in System ROM - Splash Off

So think we're talking about very different things. Your fight/endless discussion and experimentation appears to me to be about a segue from baseline Curious Mac in one bit to GS to Happy Mac?

That's a stepped version of System ROM hack @dougg3 pulled off so many moons ago?

Curious to see your explanation of what's really happening. ;)
 

cheesestraws

Well-known member
0 - Board On - Splashes Radius Logo in lower left corner - No Intelligence required - Logo is baseline frame buffer image from DeclROM

This isn't true. There's no such thing as the 'baseline frame buffer image from DeclROM' on any card I've ever seen and even if there were, there would be no way to copy it to VRAM at startup if the CPU were not running. The splash screen is still displayed under the control of the CPU, just at primary init time, very early in the boot sequence, long before the happy mac is displayed.
 

Trash80toHP_Mini

NIGHT STALKER
Thanks much for clearing that up! I knew it was very early on the the sequence because it shows up even if the Mac doesn't fully boot. I can't remember if it appears before chimes of death, don't think so?
 

Aeroform

Well-known member
Seems I got hooked on this topic haha. After having stared at "Designing cards and drivers" for two days, my guess is that (and I expect you know A LOT more than me here so sorry if I'm stating something obvious or stupid here):

The splash screen image should be called in the open routine of the video driver (located in DeclROM). Just right after calling the 'GreyScreen' control routine seems like a good place :).

The way I understand it, the flow would be PrimaryInit -> Loading video driver in ROM -> Video driver sets the screen to fully grey (amongst many other things) -> System takes over and displays the Happy Mac.

In other words, the fully grey screen we see just before the Happy Mac should be under control of the video driver, and is loaded after the PrimaryInit but before the SecondaryInit. This should mean the splash screen does not have to take into consideration the 3 commandments.


Random copy+paste's from Designing cards and drivers:

"Normally, a driver associated with a Nubus expansion card may reside either in the card's declaration ROM or on disk. But video drivers differ from other drivers in that they should be able to support screen displays soon after the system is started up, before any code is read from disk. Hence, for video cards, at least a rudimentary driver should reside in the declaration ROM. Such a driver would be loaded during initialization and should display at least 1 bit per pixel. This would let the computer display messages during the startup process."

"The video driver used at the beginning of system startup (the one that makes the "happy Macintosh" appear) must be taken from a video card's declaration ROM because the System file is not yet accessible."

"Its driver must provide a pointer to the card's video RAM, which QuickDraw then accesses directly. Writing pixel information directly into RAM is faster than using driver calls."
 

cheesestraws

Well-known member
In other words, the fully grey screen we see just before the Happy Mac should be under control of the video driver, and is loaded after the PrimaryInit but before the SecondaryInit. This should mean the splash screen does not have to take into consideration the 3 commandments.

This also isn't true. At least in the video declroms I've read, the initial framebuffer setup and filling with grey is done in primaryinit before the driver is loaded. I think the confusion is that

This would let the computer display messages during the startup process

This doesn't mean splash screens. This means things like the happy mac/sad mac and the DSAT messages emitted by the early boot System.
 

Aeroform

Well-known member
This also isn't true. At least in the video declroms I've read, the initial framebuffer setup and filling with grey is done in primaryinit before the driver is loaded. I think the confusion is that



This doesn't mean splash screens. This means things like the happy mac/sad mac and the DSAT messages emitted by the early boot System.

In Appendix C, the grey screen is called from the video driver example under the “open” routine. Also it’s mentioned in the documentation that indeed the driver is responsible for filling the screen with grey (not PrimaryInit). I could have another look and get back to you with page nr’s.
Edit: Sorry I was wrong here, it is indeed PrimaryInit that sets the (initial?) gray screen. I mixed it up as the driver also calls the grey screen in a few different scenarious. Anyhow, this shouldn't really matter for the splash screen, as the point below should still be true, ie. the driver is loaded before the happy mac.

Of course I’m aware system messages doesn’t mean splash screens. My point was that this tells us the driver is loaded before the system messages, and as the driver does not have the constraints of the primaryinit, this would be a good place to run the code that would display a splash image either before the system messages, or through some magic trickery have it stick also during certain system messages (such as the happy mac). Can’t find any sources now, but I believe I’ve seen a (rasterops?) splash displaying in the bottom left simultaneous to the happy mac.
 
Last edited:

cheesestraws

Well-known member
My point was that this tells us the driver is loaded before the system messages, and as the driver does not have the constraints of the primaryinit, this would be a good place to run the code that would display a splash image

The problem here is that when someone tells you 'this piece of hardware does X', saying 'well, the book says it should do Y' is a statement of no actual implementation relevance at all, unless you're personally volunteering to make it do Y instead.
 

Aeroform

Well-known member
The problem here is that when someone tells you 'this piece of hardware does X', saying 'well, the book says it should do Y' is a statement of no actual implementation relevance at all, unless you're personally volunteering to make it do Y instead.

I don't know whether the current hardware does utilize any driver code (though I'd be super interested in learning :) .
And yes, I'd be absolutely thrilled to contribute in anyway I can, I feel like I already kind of invited myself into this endeavour haha (sorry if I'm annoying anyone, def. not my intention). If you're willing, feel free to share your current code and I could have a look and try to implement it (although I would have no way of testing my code sadly..)

My current line of thought would be to investigate (maybe through trial and error) whether the (color) QuickDraw function PlotCIconHandle() would be retained through the happy mac screen. I think there's a chance that perhaps when the Mac Rom calls the (almost the same but simpler) PlotCIcon() function to plot the Happy Mac icon, it would only write/update the pixels in the 32x32 square containing said icon in the centre of the screen. So, what I'm hoping is that if you run (as part of PrimaryInit or the later driver stage) the function to draw a splash image in let's say the lower left of the screen, the later happy mac wouldn't refresh the entire screen but rather just add the icon "on top".

And, if that's the case, you wouldn't need any additional logic to clear the splash, as that would happen "automatically" once the entire screen is refreshed (perhaps by the welcome to mac screen or even later).

Another thing that I still need to investigate more is whether the function requires 32 bit QuickDraw or not, should be quite easy to confirm.

Full code block / example below from some old Apple QuickDraw documentation. Another interesting note is that it has been confirmed to work that patching in the PlotCIcon() function ("C" for color) in the Mac Rom, referencing a color Happy Mac icon, it displays as a greyscale icon on a SE/30 with a Micron Xceed setup!


Code:
Listing 5-8 shows how to use PlotCIconHandle to draw an icon of resource type 'cicn' with a specific alignment and transform. Listing 5-8 uses GetCIcon to get a handle to the color icon record of the desired icon and then passes the destination rectangle, alignment, transform, and handle to PlotCIconHandle.
Listing 5-8 Drawing an icon of resource type 'cicn' with a specific alignment and transform



PROCEDURE MyPlotAcicnWithAlignAndTransform
              (resID: Integer; destRect: Rect;
               align: IconAlignmentType;
               transform: IconTransformType;
               VAR myCicnIcon: CIconHandle);
VAR
   myErr: OSErr;
BEGIN
   myCicnIcon := GetCIcon(resID);
   myErr := PlotCIconHandle(destRect, align, transform,
                            myCicnIcon);
END;

[Edit to add:] The above code block is so small I guess it would fit inside the PrimaryInit constraints without issue. I'm hoping QuickDraw functions are ready by then as drawing the screen with grey works. Another area I'm diving into is to try and see how much graphics I can squeeze into say 3kb or so. Perhaps with a few different icon rescources and plotting them on different areas on the screen in succession you can get somewhat of a "animation" effect without using tons of code or graphics.
 
Last edited:
Top