30Video: New video board for SE/30 / IIsi / more?

[zigzagjoe]

For

Yep, but C16M is a reference signal independent of CPUCLK, no? Else the MaCon's wouldn't be choosing between the two in it's timing (phase lock? function) or so it seems to me. As a reference point I'd think C16M would be preferable for your use case?

Forgot about the IIfx, doesn't it work on multiple clocks?

No, C16M = CPUCLK on SE/30, they're wired together.

And yes, both the IIsi and IIfx have multiple clocks going on, which is why I suspect the maccon can select between C16M and CPUCLK.

 

[Trash80toHP_Mini]

Ah! The only stupid question is the one never asked. Thanks for clearing that up.

 

[MacOSMonkey]

Amazing job! Wow! Looks cool.

A few quick comments:
There should be no issue in returning csBaseAddr. I'm not sure why it wasn't working for you. Maybe there is some library issue with the VDPageInfo rec? Don't know -- but, as you know, it is used in calls like VideoReset, etc. Anyway, should work fine. Whether or not it has any real value vs. the device info is another matter...but it shouldn't cause problems.

Oddly, VideoReset is required by A/UX -- occurs during boot -- but is not used on the MacOS side.

If you need to run things slightly differently under A/UX vs. MacOS to special case certain functionality or driver calls, you can check for A/UX by looking at the 0x200 bit at low-mem 0xb22 (HwCfgFlags -- defined in LowMem.h -- I think? Depends on compiler version/environment) -- in case you didn't know about this low-memory global. Anyway, the 0x200 bit is set when A/UX is running.

If you are seeing weird CLUT crap on screen with Macsbug or A/UX (because of 1-bit mode switching - SetEntries, etc.), you need to do direct CLUT updates. This problem was always an issue for Mac video board developers. A/UX was the more common use case -- most users were not using Macsbug.

 

[zigzagjoe]

Amazing job! Wow! Looks cool.

A few quick comments:
There should be no issue in returning csBaseAddr. I'm not sure why it wasn't working for you. Maybe there is some library issue with the VDPageInfo rec? Don't know -- but, as you know, it is used in calls like VideoReset, etc. Anyway, should work fine. Whether or not it has any real value vs. the device info is another matter...but it shouldn't cause problems.

Oddly, VideoReset is required by A/UX -- occurs during boot -- but is not used on the MacOS side.

If you need to run things slightly differently under A/UX vs. MacOS to special case certain functionality or driver calls, you can check for A/UX by looking at the 0x200 bit at low-mem 0xb22 (HwCfgFlags -- defined in LowMem.h -- I think? Depends on compiler version/environment) -- in case you didn't know about this low-memory global. Anyway, the 0x200 bit is set when A/UX is running.

If you are seeing weird CLUT crap on screen with Macsbug or A/UX (because of 1-bit mode switching - SetEntries, etc.), you need to do direct CLUT updates. This problem was always an issue for Mac video board developers. A/UX was the more common use case -- most users were not using Macsbug.

Yes, sorry, changed my position on csBaseAddr later but no way to edit. You should always return dce->dCtlDevBase and your static base offset to framebuffer, if any, matching the active sRSRC. It's only actually /used/ by MacsBug and SysError, Mac OS ignores it, but returning dCtlDevBase should always give MacsBug something it's happy with.

It should always be whatever dce->dCtlDevBase is at the time of the call, not anything cached or a calculated 32bit base, since dCtlDevBase may be updated during 24 bit addressed QD to 32 bit addressed QD transition that occurs at secondary init time for later OSes. If returning a 24 bit base address in 32 bit QD, problems, likewise for 32 bit address in 24 bit QD time.

I'm not sure I've ever noted VideoReset used by A/UX, but A/UX and Mode32 definitely call drivers' close routines. Not sure if anyone's ever noted the latter case before.

Yep, that is what I do for A/UX.

#define hwCbAUX 9
#define Glob_HWCfgFlags 0xB22

/// @brief is AUX running?
uint8_t IsAUXRunning() {
    return ((*(volatile uint16_t*)Glob_HWCfgFlags) & (1U << hwCbAUX)) ? 1 : 0;
}

Curious about what you mean by direct CLUT updates? I haven't any misbehavior with CLUT personally.

 

[MacOSMonkey]

Sounds good. I may have commented on the A/UX thing somewhere else, but this thread is also a good place for it. I don't know if I knew that Mode32 called Close. Maybe back in the ancient days of yore. But yes to A/UX and if you check for Reset, you should see it being called under A/UX.

The CLUT problem has to do with the fact that MacsBug and A/UX are switching the board from the current bit-depth/mode into 1-bit mode. Also, Macsbug is turning off interrupts, I think. So, depending on how that switch happens, you can end up with weird colors on screen or CLUT flashing, etc. -- it depends on how you're doing updates, what hardware you're using, etc. But, to avoid these problems, update the CLUT index values directly so that you are not caught mid-transition when something slams the board into 1-bit mode. It's mostly a cosmetic screen issue.

It is preventable. If you test enough, you may eventually encounter it -- like if you suddenly find yourself staring at a purple or green Macsbug screen instead of B&W. Timing-related.

You will get a SetEntries call for 1-bit and if it's A/UX or interrupts are disabled for MacsBug (check the status register), then make sure you directly update the entries for the DAC. If your code already does direct updates and they are not deferred to blanking (which also typically prevents screen artifacts so that users don't see CLUT switches during active video), then that may be why you haven't seen this issue. For the most clean bit-depth changes, you can defer CLUT entry updates until blanking, except when it's MacsBug or A/UX special cases that require an immediate response.

Hopefully, the above better explains the issue. My recollection is a little crusted over and covered in cobwebs, but I think that's how it works.

 

[zigzagjoe]

Sounds good. I may have commented on the A/UX thing somewhere else, but this thread is also a good place for it. I don't know if I knew that Mode32 called Close. Maybe back in the ancient days of yore. But yes to A/UX and if you check for Reset, you should see it being called under A/UX.

The CLUT problem has to do with the fact that MacsBug and A/UX are switching the board from the current bit-depth/mode into 1-bit mode. Also, Macsbug is turning off interrupts, I think. So, depending on how that switch happens, you can end up with weird colors on screen or CLUT flashing, etc. -- it depends on how you're doing updates, what hardware you're using, etc. But, to avoid these problems, update the CLUT index values directly so that you are not caught mid-transition when something slams the board into 1-bit mode. It's mostly a cosmetic screen issue.

It is preventable. If you test enough, you may eventually encounter it -- like if you suddenly find yourself staring at a purple or green Macsbug screen instead of B&W. Timing-related.

You will get a SetEntries call for 1-bit and if it's A/UX or interrupts are disabled for MacsBug (check the status register), then make sure you directly update the entries for the DAC. If your code already does direct updates and they are not deferred to blanking (which also typically prevents screen artifacts so that users don't see CLUT switches during active video), then that may be why you haven't seen this issue. For the most clean bit-depth changes, you can defer CLUT entry updates until blanking, except when it's MacsBug or A/UX special cases that require an immediate response.

Hopefully, the above better explains the issue. My recollection is a little crusted over and covered in cobwebs, but I think that's how it works.

Ahh, gotcha. That all tracks.

I sidestepped that: I "immediately" update CLUT entries during setEntries, but I busywait for vsync if needed to avoid glitches. Which is wasteful, but avoids both issues. The only game I know to use CLUT animation (Simcity 2000) didn't seem to be impacted, so that's where I ended up.

 

[zigzagjoe]

Excellent idea to allow installing a straight connector for the IIsi! The only disadvantage is the lack of FPU socket which breaks A/UX compatibility on the IIsi. Would it be hard to add one?

I still can‘t emphasise enough what a fantastic project this is! I‘d be definitely in for at least one.

As the original board took a turn for SE/30 and grayscale in specific, I'm working on this for a IIsi / less expensive SE/30 use case.

I'm including the possibility to run the FPU off the 50mhz VGA clock - in theory this should work, but I believe it's been a little troublesome in the past due to signal integrity issues. Too bad I got rid of my IIsi last year, I'll have to track one down again.

Also including the possibility to install a second crystal to enable other resolutions, but I am not sure this will end up used. I definitely can't do any kind of standard 1024x768 due to pixel clock and counter restrictions; about the only other "interesting" resolution I came up with is 960x540 (perfect 2x scaling to 1920x1080), but this is nonstandard: I don't know how many monitors would want to sync it. Open to ideas...

 

[Reasons.]

I think 960x540 would be interesting, if only to combine with some variety of VGA-to-HDMI scaling solution like GBS Control. A 15" 1080p panel would give you an effective DPI pretty close to 72 (73.423), so you'd be able to match it with the SE/30's internal screen and get true WYSIWYG across the board.

(For what it's worth I'd probably be in for one of these as a dedicated external video card, provided you made enough that I wouldn't be taking one away from someone else.)

 

[cheesestraws]

about the only other "interesting" resolution I came up with is 960x540 (perfect 2x scaling to 1920x1080), but this is nonstandard: I don't know how many monitors would want to sync it.

I think 960x540 would be interesting, if only to combine with some variety of VGA-to-HDMI scaling solution like GBS Control.

Yeah, agreed. It would be a good resolution for people using external video scalers.

 

[zigzagjoe]

In general, I plan to keep making these as long as there's some interest - so not worried about supply

I'll have to tinker with timings and clocks and see if I can find a lowest common denominator that works. Previously I was using my 50.35mhz clock to drive it, and only one monitor correctly synced it (sure looked nice though!). I probably have a better chance with timings calculated rather than guessed and a more appropriate clock.

 

[Reasons.]

One other thought I had on additional resolutions: the datasheet for the Epson S1D13705F00A200 (apologies if that's not the exact controller you're using) mentions "direct hardware 90° rotation of display image for portrait mode display." Supporting 3:4 or 9:16 resolutions would be a nice way to bypass classic Mac OS's lack of support for portrait video in software, and as far as I know it'd be a pretty unique feature.

 

[zigzagjoe]

One other thought I had on additional resolutions: the datasheet for the Epson S1D13705F00A200 (apologies if that's not the exact controller you're using) mentions "direct hardware 90° rotation of display image for portrait mode display." Supporting 3:4 or 9:16 resolutions would be a nice way to bypass classic Mac OS's lack of support for portrait video in software, and as far as I know it'd be a pretty unique feature.

I use the 505 - close enough. It does support that function also (SwivelView), but it comes with a big gotcha in that 1/2/4 bpp support is dropped, it becomes 8BPP only. Mac ROMs, at least the older ones, really need you to come up in 1BPP mode so it becomes hacky if you aren't able to do this. This was a major problem for Bolle's grayscale card for a while. Not impossible, but definitely a wrinkle.

I also would like to get 15bpp working at some point, but this also will require an ugly hack to make possible (endian mismatch issue) so that will likely be a while. Won't be fast, but it's doable. Both of these are just software though so at least no hardware changes will be required if that materializes.

 

[Reasons.]

Ah, gotcha. Should have known it wouldn't be that easy. Hopefully you can get it to work someday, if only for the six or seven dedicated portrait monitor sickos out there. I'd use it, at least.

 

[Arbee]

Mac ROMs, at least the older ones, really need you to come up in 1BPP mode so it becomes hacky if you aren't able to do this.

The PowerBook 165c and 180c have a chip that sits between the off-the-shelf SVGA chip's VRAM and the 68030 and packs/unpacks the pixel data as the Mac reads and writes. So if you write $55 to framebuffer offset $1 in "1bpp mode", it would write $00 $01 $00 $01 $00 $01 $00 $01 to framebuffer offset $8. An '030 read would do the same thing in reverse. That was interesting to emulate!

 

[zigzagjoe]

Yeah, @demik mentioned that to me too. I'd entertained the idea of introducing a CPLD to the databus to allow inline transformation of data for 15 bit mode but I don't think it worthwhile to do so just for 15bpp or to mangle the bytes for lower bit depths - most likely using another controller would make sense at that point for performance reasons. We'll see how things evolve!

 

[zigzagjoe]

Looking pretty science! I need to track down an IIsi to test the FPU in, however.

Functional changes are the addition of the FPU (with option to clock at 50mhz rather than 20, to be tested) and possibility of adding a second crystal for an additional resolution. Intended for IIsi, but will work in SE/30 either as the top card in a stack (ie. bolle setup) or with a right angle connector it could support a second card on top.

I would be curious if anyone has thoughts on build systems, though. Right now I use a makefile to govern the main process, but I'm getting to the point where I need to run multiple sub-builds for card variants over time. Also, I hate touching the makefile; it drives me nuts.

For example: the grayscale card actually has two declroms, selected based on the active operating mode, each which must be built with different flags, then merged. The Si card is software compatible and is able to use the same ROM, but it's not right for it to report being a GS card when it isn't, so that should really be its own sub-build.... and so on; I want to get a LC version going soon which would definitely not be ROM compatible so it will only get worse.

 

[zigzagjoe]

Performance vs builtin. Faster in all cases except for scrolling, not a huge increase, but it's there. Most are going to be limited by CPU rather than video performance, I think. Notably performance on large blits (Cbits L/*) is quite a bit better, which would benefit games which render a frame in RAM then transfer to framebuffer (marathon, doom, etc mostly). Unfortunately, most of those games are going to be CPU limited.

FPU works at 20mhz, but does not work at 50mhz with a spurious interrupt exception, which is probably actually a "coprocessor protocol violation" exception. And some odd periodic display corruption. I'll have to get a frequency generator out and play with it, even if running the FPU faster is of limited use.

 

[Reasons.]

Wrote this in the for-sale thread but realized it made more sense here. A succession of silly Wednesday afternoon thoughts on constructing a universal VGA and Ethernet I/O board for the SE/30:

1. The existing I/O board is just a passive connector, which I'm pretty sure is also the case with Bolle's Ethernet riser.
2. Might make sense to just add AUI to the mix; you could have a backplate with VGA, RJ-45, and AUI connectors.
   • Connect things appropriately on the inside, add a transceiver on the outside. It's not neat but it would get the job done without active circuitry.
3. Hmmmm, but the AUI connector is pretty big. Probably couldn't fit that on the I/O plate with the rest. If only there was a smaller connector, sorta a mini DisplayPort equivalent.

This is how I found myself reinventing AAUI, an objectively cursed idea. Those connectors are still available, though, and I do know enough KiCAD to be dangerous...

 

[zigzagjoe]

Wrote this in the for-sale thread but realized it made more sense here. A succession of silly Wednesday afternoon thoughts on constructing a universal VGA and Ethernet I/O board for the SE/30:

1. The existing I/O board is just a passive connector, which I'm pretty sure is also the case with Bolle's Ethernet riser.
2. Might make sense to just add AUI to the mix; you could have a backplate with VGA, RJ-45, and AUI connectors.
   • Connect things appropriately on the inside, add a transceiver on the outside. It's not neat but it would get the job done without active circuitry.
3. Hmmmm, but the AUI connector is pretty big. Probably couldn't fit that on the I/O plate with the rest. If only there was a smaller connector, sorta a mini DisplayPort equivalent.

This is how I found myself reinventing AAUI, an objectively cursed idea. Those connectors are still available, though, and I do know enough KiCAD to be dangerous...

Both Bolle and the Sethernet designs are passive, with a couple of LEDs on the both for activity/link. A thought I just had is to have a daughterboard for vintage NICs to do the AUI to RJ45 piece and come out to a female connector for the "modern" NICs' passive connection. So, for those with modern stuff the io board can be cheap but it's also not an entirely new design for a vintage design.

Either that or contrive a secondary bracket to mount the vintage IO board to, and just extend the RJ45 to the "new" io board.

As far as tertiary connectors go, I think (micro)SD would probably be the next most desirable connector for most folks.

Also, update on the Si board, it's passed all my initial testing just fine. 50mhz FPU is off the table for now, might someday make a return. Should hopefully have one to a beta tester soon, the only thing I really need tested before GA is to confirm the Carrera fix borrowed from the GS board works on the case someone wants to use one on a Bolle stack. Plan is to bring a few of these with me to VCF, along with my other bits n' bobs.

 

[zefrenchtoon]

Wrote this in the for-sale thread but realized it made more sense here. A succession of silly Wednesday afternoon thoughts on constructing a universal VGA and Ethernet I/O board for the SE/30:

1. The existing I/O board is just a passive connector, which I'm pretty sure is also the case with Bolle's Ethernet riser.
2. Might make sense to just add AUI to the mix; you could have a backplate with VGA, RJ-45, and AUI connectors.
   • Connect things appropriately on the inside, add a transceiver on the outside. It's not neat but it would get the job done without active circuitry.
3. Hmmmm, but the AUI connector is pretty big. Probably couldn't fit that on the I/O plate with the rest. If only there was a smaller connector, sorta a mini DisplayPort equivalent.

This is how I found myself reinventing AAUI, an objectively cursed idea. Those connectors are still available, though, and I do know enough KiCAD to be dangerous...

Are you thinking about something like this ?

MacTwister: a MacCon/Etherport/Dayna Twisted Pair breakout board

Hello, I would like to share my project that is long overdue for publishing here - MacTwister, a fairly universal Twisted Pair breakout board for a variety of SE and SE/30 network cards. It’s about the small PCB that you screw to the computer chassis that contains an external connector. I was...

68kmla.org