• 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

cheesestraws

Well-known member
I'm hoping QuickDraw functions are ready by then as drawing the screen with grey works

Unfortunately, as GeekDot said above, you can't call anything except for the slot manager in PrimaryInit. The grey and the logo are poked directly into VRAM.
 
Last edited:

Aeroform

Well-known member
As GeekDot said above, you can't call anything except for the slot manager in PrimaryInit. The grey and the logo are poked directly into VRAM.

Ah! Then my current approach would be to reference the (a) driver (stored in the DeclROM) in the PrimaryInit. It should then get loaded into main memory by the slot manager. Then; use the "driver" to call the QuickDraw functions (if available).

So the current setup does not include any "driver" at all? Only a primaryInit? I'm surprised this works, but then again, I just dived into the topic some working hours ago.
 
Last edited:

Melkhior

Well-known member
[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.
The cscGrayScreen/scsGrayPage selector doesn't (cannot) use QuickDraw to fill the screen. It's commonly a loop to fill the VRAM with a pattern (unless you have some other hardware capable of more efficiently doing this, typically in accelerated devices). There's an example in DCDMF3 p587 (pdf p628).

The primaryInit works the same; I don't think DCDMF3 has an example, but one appears in the sample codes for declaration ROMs:

Code:
;  Clear video RAM to a nice gray
                                MOVE.L  #$AAAAAAAA,D0                           ;graypat1 := $AAAAAAAA
                                MOVE.L  D0,D1
                                NOT.L   D1

                                MOVE.W  #defScrnRow,D4                          ;sRow := defScrnRow             {Bytes per pixel line}
                                MOVE.W  #$200*4-1,D3                            ;sHei := defScrnHeight  {Screen Height in pixels}
                
                                MOVE.L  A2,A1                                           ;init row pointer                                                                                                                               ;REPEAT
NxtRow                  MOVE.L  A1,A0                                           ;get next row
                                MOVE.W  #defScrnRow/4-1,D2                      ;  rowlongs := defScrnRow/4 - 1 {How many Longs there are}
NxtLong                 MOVE.L  D0,(A0)+                                        ;    (A0) := graypat(1/2)
                                DBF             D2,NxtLong                                      ;  UNTIL rowlongs < 0
                                EXG             D0,D1                                           ;  graypat1 <-> graypat2
                                ADD.W   D4,A1                                           ;  A2 := A2 + sRow
                                DBF             D3,NxtRow                                       ;UNTIL sHei < 0

;  Exit
Exit                    RTS                                                                     ;Return

There's nothing forcing you to fill out the screen with patterned grey, it's just what Apple specify you should do. You could use/copy any pattern instead. In fact on a Mac booting in 32-bits mode, there's nothing stopping you from adding 256 MiB worth of pictures data mapped in the super-slot area and copy some of those at boot time, provided you can do it 'fast enough' (I have no idea what would happen if you were to spend a lot of time doing an animation here by copying multiple pictures with a delay loop). Booting 24-bits mean you only have 1 MiB to play with so it restricts a lot what you can do at PrimaryInit time. But you can do almost anything at SecondaryInit as I think you can switch to 32-bits mode there anyway.
 

Trash80toHP_Mini

NIGHT STALKER
Terms/definitions time someone? 1-2-3 of VidCard boot sequence would be much welcome right here, still half asleep. :sleep: Great discussion!

What I've been calling a "splash screen" would be the Radius Logo their cards display in the lower left corner of the "gray screen?" This disappears when CPU has passes POST and loads "Curious Mac" animation from System ROM.

So that logo data (splash screen) and the low level driver for the card would be stored in DeclROM and loaded into VRAM by CPU very early on in the boot sequence?
 

Trash80toHP_Mini

NIGHT STALKER
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.
Half a cup of coffee later. :) Do any of the cards you've looked at splash a logo against the phosphors at primary INIT time? Vaguely recalling SuperMac and Rasterops making an appearance?
 

Aeroform

Well-known member
Half a cup of coffee later. :) Do any of the cards you've looked at splash a logo against the phosphors at primary INIT time? Vaguely recalling SuperMac and Rasterops making an appearance?

I just found this very interesting video of a Raster Ops 264 booting. ->
If you look at the reboot at 00:10, it seems to me that:

- The (very fancy and animated) splash appear before the VRAM is wiped with the grey (Assembly code loop) screen.
- It seems to take a second or so before the VRAM is wiped and turned grey on the secondary (internal) monitor, as you can see the graphics staying in place even after the splash is displayed.
- It seems the primary monitor (the external) lets the splashscreen "finish" before being wiped with a grey screen.

I'm guessing different cards did it differently. I like you was primarily thinking of the "added logo or whatever" on top of the grey screen as the splash screen. Leading me to think that perhaps you could utilize QuickDraw for this. At least that is how the system rom draws the happymac icon, utlizing the QuickDraw routine PlotIcon(). But, it might be that QuickDraw isn't available between the greyscreen loop and the happymac screen.. and in that case I guess you'd have to do some scary low level kind of stuff to display something.
 

Melkhior

Well-known member
@Trash80toHP_Mini There's three element to the video device booting/usage:

(a) PrimaryInit ; this runs very early (and just once), is very restricted (only SlotManager calls), and only has access to whatever is available in the ROM (i.e. an older version of the SlotManager, not 32-bits QD). Should only be used for basic hardware initialization (such as disabling VBL interrupts or the display itself). It normally fills out the VRAM with 'grey', but that's not really necessary (or blanking), if you don't mind a display showing garbage immediately after power-up.

(b) SecondaryInit ; same as PrimaryInit but this runs after System Patches have been applied, and so has access to the 'proper' functions (newer SlotManager, presence of 32-bits QD).' It's the one that actually should initialize everything for a 'good' device, meaning one that can't really live with just 1 MiB of address space (unless you decide to ignore machines that boots in 24-bits mode, and do everything in PrimaryInit assuming 32-bits mode and a recent ROM in which case you don't need a SecondaryInit). This includes e.g. switching to whichever mode is selected in the PRAM.

(c) Driver ; or really just some helper functions that are called by System/MacOS to use the device (and each function can potentially do multiple things selected by a integer parameter called the 'selector'). This includes getting the base address for the VRAM for the current mode (so that the VRAM can be directly updated by e.g. QuickDraw), changing the CLUT (color look-up table for indexed mode like 2, 4 or 8 bits), switching mode/resolution, etc. Those normally don't touch the VRAM except for some specific selector such as scsGrayPage ("page", if I understand correctly, is basically an area of memory displayable to the screen; you only need one, but if you have more, that means that you can double-/triple-/quadruple-/... buffering).

As far as I can tell, whatever is in the VRAM and displayed on the screen is fully under the device ('s declrom) control until the driver open() function is called, at which point System/MacOS may start writing in the VRAM on its own (and likely the first thing it will do is call the scsGrayPage selector).
 

Aeroform

Well-known member
@Trash80toHP_Mini There's three element to the video device booting/usage:

(a) PrimaryInit ; this runs very early (and just once), is very restricted (only SlotManager calls), and only has access to whatever is available in the ROM (i.e. an older version of the SlotManager, not 32-bits QD). Should only be used for basic hardware initialization (such as disabling VBL interrupts or the display itself). It normally fills out the VRAM with 'grey', but that's not really necessary (or blanking), if you don't mind a display showing garbage immediately after power-up.

(b) SecondaryInit ; same as PrimaryInit but this runs after System Patches have been applied, and so has access to the 'proper' functions (newer SlotManager, presence of 32-bits QD).' It's the one that actually should initialize everything for a 'good' device, meaning one that can't really live with just 1 MiB of address space (unless you decide to ignore machines that boots in 24-bits mode, and do everything in PrimaryInit assuming 32-bits mode and a recent ROM in which case you don't need a SecondaryInit). This includes e.g. switching to whichever mode is selected in the PRAM.

(c) Driver ; or really just some helper functions that are called by System/MacOS to use the device (and each function can potentially do multiple things selected by a integer parameter called the 'selector'). This includes getting the base address for the VRAM for the current mode (so that the VRAM can be directly updated by e.g. QuickDraw), changing the CLUT (color look-up table for indexed mode like 2, 4 or 8 bits), switching mode/resolution, etc. Those normally don't touch the VRAM except for some specific selector such as scsGrayPage ("page", if I understand correctly, is basically an area of memory displayable to the screen; you only need one, but if you have more, that means that you can double-/triple-/quadruple-/... buffering).

As far as I can tell, whatever is in the VRAM and displayed on the screen is fully under the device ('s declrom) control until the driver open() function is called, at which point System/MacOS may start writing in the VRAM on its own (and likely the first thing it will do is call the scsGrayPage selector).
I could def. have misunderstood something. But from what I interpreted from "DCaDftMF", the driver (if embedded into the DeclROM and the correct "flags" are set in PrimaryInit) is executed before the SecondaryInit (p. 166, p. 202 and onward). It states that cards that needs the secondary init to function will not display any system messages (happy mac or even the welcome to mac screen) at all (p. 177-178).
 
Last edited:

cheesestraws

Well-known member
Can I suggest that speculation about how to write video declroms to do whizzy things be taken to its own thread, rather than confusing the issue in this one?
 

Trash80toHP_Mini

NIGHT STALKER
Cool, to further keep it clean, how about a second thread dedicated to any possible A/B integrity complications under long term use at the expanded 512x384 resolution of 12" RGB zaTopper Display?

A/B appears to handle it just fine as is, but might some low rent version of APM's Retina Display hack be in order? Uprating a couple of components as he did might be in order, if not a couple of turns added to the flyback to split the difference?
 

Aeroform

Well-known member
Can I suggest that speculation about how to write video declroms to do whizzy things be taken to its own thread, rather than confusing the issue in this one?
Sorry for going full spammy on this topic, I just got excited is all and interpreted the splash to be the last remaining topic (kind of). Now if I weren’t an idiot I could have noticed that @GeekDot already had sorted out displaying a Bolle icon at boot as evidenced in video.

If at all possible I would love to see the src code for your (Geekdot) DeclRom, would be really interesting to see your approach.

I’ll shut up now.
 
Last edited:

cheesestraws

Well-known member
Sorry, that wasn't meant to sound harsh, it's just that I think there's benefit in splitting off talking about declroms from the thread about this specific piece of hardware.

I'm not writing the new declrom and haven't really had time to meaningfully contribute, alas. GeekDot deserves all the credit for that...
 

GeekDot

Well-known member
If at all possible I would love to see the src code for your (Geekdot) DeclRom, would be really interesting to see your approach.
No worries. I will publish it on my github as soon we're done - or at least have something we can call V1.x

Now if I weren’t an idiot I could have noticed that GeekDot already had sorted out displaying a Bolle icon at boot as evidenced in video.
Hehe... and I wasn't aware that you weren't aware. That would have saved a lot of written bytes being wasted 😅

I’ll shut up now.
No offence - but if you have kids, you know how "are we there yet?" feels after a couple of miles/kilometers 😉

And guys, as much as I hate to be the party-pooper here, there will be just so-and-so many cards available (<30 IIRC) due to the (currently) limited number of TMS34061 Bolle was able to accumulate... so how far should a poor hobby programmer go to satisfy each and every feature-creep for a userbase that's smaller than a 1/20th of the global Bugatti Vreyon owner number?

So let's do this step by step:
  1. Make it work
  2. Make it really work
  3. Add a single sensible feature (and I do not consider a fancy splash-screen "a feature")
  4. rinse and repeat
BTW: Did Bolle mention that it can display a correct 4:3 ratio? (512x384 instead of 512x342)
 

Bolle

Well-known member
number of TMS34061 Bolle was able to accumulate
more like "was willing to pay for before we even knew we could get it to work"
The RAMDACs aren't exactly what I'd call "available" as well. That's what you get when building stuff around old crap :p
Currently looking into what the address decoder is actually doing and why it won't work with our larger 16k ROM to get the totally cosmetic splash screen feature working in a nice way.

The tube sockets I ordered from a local seller do not fit the CRT, got another bunch from a Chinese seller now and hope they'll fit (I kind of hope they don't, so I won't have to build a ton of the CRT neck boards - hate all that through hole crap)
 

Aeroform

Well-known member
No worries. I will publish it on my github as soon we're done - or at least have something we can call V1.x


Hehe... and I wasn't aware that you weren't aware. That would have saved a lot of written bytes being wasted 😅


No offence - but if you have kids, you know how "are we there yet?" feels after a couple of miles/kilometers 😉

And guys, as much as I hate to be the party-pooper here, there will be just so-and-so many cards available (<30 IIRC) due to the (currently) limited number of TMS34061 Bolle was able to accumulate... so how far should a poor hobby programmer go to satisfy each and every feature-creep for a userbase that's smaller than a 1/20th of the global Bugatti Vreyon owner number?

So let's do this step by step:
  1. Make it work
  2. Make it really work
  3. Add a single sensible feature (and I do not consider a fancy splash-screen "a feature")
  4. rinse and repeat
BTW: Did Bolle mention that it can display a correct 4:3 ratio? (512x384 instead of 512x342)
Well, the good thing is I got the pleasure of diving into fun apple dev docs haha. And, if I manage to snag one of the few available cards (oh boy do I want to), what's to stop me from buying a rom programmer and making my own fancy splash screen haha ;).

And, yes, I have a 1yr old and a 4yr old, so I know the feeling. But here I consider myself having been more of a backseat driver asking whether you had tried putting it into 5th gear or not 😂

Well, best of luck with your continued endeavour, and let me know if there's any way I could contribute.
 

Melkhior

Well-known member
But from what I interpreted from "DCaDftMF", the driver (if embedded into the DeclROM and the correct "flags" are set in PrimaryInit) is executed before the SecondaryInit (p. 166, p. 202 and onward)
Just for the sake of accuracy and completeness in this thread (further discussion should have their own thread): you are correct. I was interpreting differently, but testing the behavior shows that Open() and some selectors of Control() and Status() are called prior to the call of SecondaryInit (using my virtual FB with Qemu/Q800 & MacOS 8).
 

Bolle

Well-known member
Long time, no update...

I've got a batch of hopefully "final" prototypes on the way and I think so far I got most of the parts I need to build a few sets are in my stock now as well. So @GeekDot will soon be able to actually work out the last firmware/driver details on the real hardware. He has still been doing most of it up to now in emulation and as far as possible on one of the original Formac cards that this is based off. There's some hardware differences that found their way into the "clone" that proved this to not be too easy to work with :D

I think he also mentioned that he's preparing a separate post about all the things that he learned on declaration ROM coding.


Another reason I am posting an update: everybody please refrain from messaging me individually asking when this will be available for sale, if I can put you on a waiting list or if you can pre-pay for a set. I can't keep track of everyone who wants one, leave alone get back in touch once cards are available and wait for responses. I tried this before, it did not work out. Half of the people don't ever answer again, half of who's left suddenly doesn't want a card anymore for whatever (of course, valid) reason.
This isn't meant as a rant, I just can't keep up with answering individual messages on this topic anymore and don't want people to be upset because they're not getting an answer.

Please don't forget this is purely a hobby for me, which I have to find time for next to my other hobbies, my day job and most recently a new family member that takes most of my free time away ;)

There's still things to work out before I feel comfortable to sell sets of the cards to others. The firmware/driver has to be finished, hardware installation and setup has to be documented - this is not going to be a plug and play upgrade. Everyone will have to dial in the analogboard settings and image centering using the centering rings on the tube after installing the card. Some input from "tech-savvy" people is needed so I don't miss out on steps and things which are obvious to me but might not be for others.

Once cards are available I will have a post in the trading section on here and from there it's first come, first serve.
As much as I would want to take reservations and build cards for everyone in the first throw... I don't have the means to do that, unless I make some free time by quitting my job ;)
 

amedeo_68k

Well-known member
Awesome! Take your time. I think we should have no rush. This is a collection hobby. No real use are made. Thank you so much!
 
Top