• 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

Scott Squires

Well-known member
with color, 24-bits is sufficient to be known as "true color."

Scare quotes would be appropriate, since displays in cheap laptops and such may have 24-bit color, while only reproducing 70% of the sRGB color space. Which is nowhere close to representing the colors visible to the human eye. Even DCI-P3, which Apple likes to use in its latest displays, while a big improvement, is still just a fraction of visible colors:
1642574502110.png
 
Last edited:

GeekDot

Well-known member
@GeekDot I see your little DeclROM corner, how's that going?
It's making progress. DeclROM assembles in MPW without errors... which does not necessarily mean it's working 😤
While I feel like a walking-talking index of "Designing Cards and Drivers..." (Chapter 8) and am close to be able to read sRessource entries directly from a binary dump, there's still a lot to learn along the way.
That said, slowly but steady we're getting there 😉
 

Trash80toHP_Mini

NIGHT STALKER
Cool! That sounds like a lot of fun, I love teasing bits and pieces out of the puzzle. Which chunks of the block diagram and netherworld of the card were your focus? Hardware, firmware or I'd guess mostly software with a side order of the hardware from what I've you up to around these parts?
 

Trash80toHP_Mini

NIGHT STALKER
It's making progress. DeclROM assembles in MPW without errors... which does not necessarily mean it's working 😤
Awesome, but does that emoticon represent the shock of Home Alone at the progress you've made . . .
. . . or far more intense emotions of The Scream at the prospect of munching away at remaining complications?

While I feel like a walking-talking index of "Designing Cards and Drivers..." (Chapter 8) and am close to be able to read sRessource entries directly from a binary dump, there's still a lot to learn along the way.
LOL! I hear you about Section 8, imagine attempting to divine the mysteries of the Declaration ROM without a clue about firmware and not much in the way of software! 🤪

That said, it sounds like you're well on the way to developing the tools you'll be using on System ROM when that bug bites your behind at the finish line of this project. ;)

That said, slowly but steady we're getting there 😉
It certainly sounds like it!
__________________________________________________________________________________________________

Way to go to all three of you, this project is amazing.
 

Aeroform

Well-known member
This is beyond amazing!
I’m wondering how one finds and sets the bit depth without picture, sounds… difficult 😅. How about a ”simple” extension that sets the bit depth, wouldn’t that provide somewhat of a stop-gap measure?

Cannot wait (for hopefully being able) to buy one of these!
 

nightingale

Well-known member
This is amazing... I appreciate the decision to use a card that used "standard" parts -- are all the parts for this card still readily available? How easy is it going to be to make one of these, in terms of finding all the components?
 

GeekDot

Well-known member
About the progress... [and a request for help]

Theoretically the DeclROM for the BolleCard is done.
It compiles fine in classic MPW (doing it in the correct vintage way ;)) and boots all the way through...


What you see here is an external screen "emulating" the internal 9" at 512x342@8bit (As I don't have a real BolleCard nor the required harness)
The primaryInit already sets the formac BolleCard to be primary card and "kills" the internal video (i.e. Slot $E).
At 00:30 you see a quick "rearing up" which probably is a QuickDraw access and is quickly blackened by the secondaryInit (interrupted by some, well, interrupts which explains some non-black pixels... but you won't see them anyway.

So everything's works as requested by Sir Bolle... but there's one thing (you might help me with):

Because of frequency-o-rama and other analog things my brain is not capable to digest (@Bolle will explain that for sure), we do not want a monochrome (1-bit) mode.
I did not implement any, i.e. there's just a single 8bit mode defined in the sResource... still at some point the card is accessed in 1bit mode, e.g for a brief moment during booting. My "WAG" (to cite @Trash80toHP_Mini) is: this must be QuickDraw.
A good proof for this guess is, that running Speedometers QD-benchmark it switches to 1bit in the end and the BolleCard goes into "on strike mode" (or blank in my "emulation setup") because there is no f-ing 1bit mode, gaaaaddammit!
This is really frustrating. So much that I even started to study the QD source... which adds some more frustration 😄
Asking @Melkhior he gave me a new & good hint: His DeclROM is using 32bit QD... mine's 24bit because I want(ed) to allow compatibility with the SE/30 original ROM...
Do you guys have an additional idea, experience or Devine inspiration where/what I can look for? Is there a behavioral difference in 24 vs 32bit QD?
 
Last edited:

Trash80toHP_Mini

NIGHT STALKER
Did you yank that pesky "Video ROM" out of its socket in the SE/30? If so I'll keep Wildly Guessing. HEH! ;) If not, do so and WAG of the moment would be that the bug will have flown away. Sounds like dueling DeclROMS . . . :unsure:
 

Aeroform

Well-known member
I have no clue what I’m talking about here so sorry if this is obvious stuff, but could it be related to QD’s Gdevice record and device list? In combination with the Speedometer Benchmark calling a function to use the device suitable for a 1-bit depth?

Ie as the current device does not support the needed bit-depth, the application references the list and switches to the device that does, or, simply is coded badly and calls QD’s SetDepth function without checking for support first

“When the system starts up, it allocates and initializes a handle to a GDevice record for each video device it finds”

”If your application uses the HasDepth function to determine that the current device can support the pixel depth required for the proper display of your image, but the DeviceLoop procedure indicates that the user has changed the screen’s display, your application can use the SetDepth function to change the pixel depth of the screen. Note that the SetDepth function is provided for applications that are able to run only on graphics devices of a particular depth. Your application should use it only after soliciting the user’s permission with a dialog box.”

Copy+paste from here:

I’m wondering how the internal video is “killed”? Perhaps it still lingers around in the Gdevice record simply as an inactive device?

Again, sorry if I’m an idiot here, just shooting ideas based on zero knowledge haha.
 

Aeroform

Well-known member
(OK here I REALLY don’t know what I’m talking about) But I wonder if it’s at all possible to declare a 1-bit mode that is kind of “simulated”. Ie the card does not output a “true” 1-bit signal, but simply replaces the (internal?) CLUT with only 1-bit colors..
 

Trash80toHP_Mini

NIGHT STALKER
I'm thinking the hardware check is knocking on the $E video subsystem's door before any inits load? If the Video ROM's still in circuit, something could persist in Video Memory in $E memory space after the video subsystem is shut down in civilized fashion via INIT? Go Neanderthaler and yank it out!

When "Video ROM" doesn't show up in the Slot Managers polling at startup, there is no card at $E to address or registers to be loaded, no? That's the way it looks in the NuBus/PDS report in TattleTech in my long ago testing.

I've run the RCPII/IIsi as the only Video System on board with the "Video ROM" pulled and no problems whatsoever. $E video ceases to exist in that machine state.
 

GeekDot

Well-known member
Did you yank that pesky "Video ROM" out of its socket in the SE/30? If so I'll keep Wildly Guessing. HEH! ;) If not, do so and WAG of the moment would be that the bug will have flown away. Sounds like dueling DeclROMS . . . :unsure:
Nope, the SE/30 video ROM is still in.
But that's ok, as I politely remove all 4 Resources (0x01, 0x80, 0xA0, 0xFF) from slot $E with _sDeleteSRTRec.

I have no clue what I’m talking about here so sorry if this is obvious stuff, but could it be related to QD’s Gdevice record and device list? In combination with the Speedometer Benchmark calling a function to use the device suitable for a 1-bit depth?
[...]
Again, sorry if I’m an idiot here, just shooting ideas based on zero knowledge haha.

Well, that makes two including me ;-)
But that GDevice thingy was a trace I once followed already and got somehow distracted... maybe by another brainstorm or candy or so 🤔... mhh, candy 😋
I will definitely dig into that more concentrated! Thanks for digging this up again 👍

I've run the RCPII/IIsi as the only Video System on board with the "Video ROM" pulled and no problems whatsoever. $E video ceases to exist in that machine state.
That was Bolles initial idea: If everything else breaks, the user has to pull the onboard video-ROM... but that not the way we intend this to be.
Also forcing 32bit QD is not my style of "Mens agitat molem" 🧠

Me: "BTW, are we (again) trying to fix a hardware shortcoming by jumping through burning software-hoops?"
Bolle: "Of course we are 😛"
 

cheesestraws

Well-known member
Hey, half the point of having both hardware and software people is for them to set increasingly ludicrously complicated obstacle courses for one another
 

Trash80toHP_Mini

NIGHT STALKER
LOL! You forgot to mention upper management inserting increasingly ludicrously compressed stopwatching and marketing's ludicrously complicated rearrangement of the obstacles.

Nope, the SE/30 video ROM is still in.
But that's ok, as I politely remove all 4 Resources (0x01, 0x80, 0xA0, 0xFF) from slot $E with _sDeleteSRTRec.
Maybe, maybe not" If we knew what we were doing it wouldn't be called research.

By the time the Mac is ready to use resources after hardware check Slot Manage will have already polled the Video ROM, no? Posed this question a few years ago:


Micron solved your problem with code that must be at the very beginning of the INIT, but it wouldn't crop up with VROM removed as it checked for sense lines on the external connector, no? As the GS setup is changed in hardware with the bucket open, this shouldn't be required?
 
Last edited:

Bolle

Well-known member
Either way, looks like we're getting there. Geekdots magic and the invaluable GDevice tip seem to work out...
The card comes up in 8bit grayscale mode now on a cold boot which was not the case with the "stock" driver.
There's no 1bit mode present anymore at all now and I didn't notice anything weird so far after running the card for a few days now.

Bildschirmfoto 2022-02-22 um 09.58.09.jpgIMG_0741.jpg

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

...and some more compatibility testing. Turbo040 and Carrera040 are already confirmed to work, the socketed PowerCache is having minor issues that look like timings are a bit off and need slight adjustments. It's fine when stacked on top of a stock Asante MacCon with a right angle connector, as well as on top of one of my combo adapters. It's fine when used on a completely stock logicboard in a single card setup...
Anything of importance that I missed?
Also System 6.0.7 up to 7.5.3 confirmed so far and I think @GeekDot mentioned A/UX does work as well (can the Micron actually do that? I don't think it can) Going to have to try 8 at some point as well.
 

GeekDot

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
It's not a fight -it's just the hardware department requiring convenience-features which will be abundant in the final product anyhow 😜

AU/X works fine indeed - minus the panning features because evil interrupt thingies are "VERBOTEN!" in serious OSes 😏
Also, we're 100% '24-bit clean' (did I just say that?) which means the card works fine with any ROM installed in your SE/30...

Maybe, maybe not" If we knew what we were doing it wouldn't be called research.
We do know what we're doing - we are just astound that it works 😉
 
Top