SuperMac PDQ, Spectrum 8, 24, Thunder ROMs

[Arbee]

@MacOSMonkey In MAME terminology a "core" is a CPU emulator. We actually have 2 68K cores: a perfect 68000/68008 that's generated by a Python program from the microcode and schematics, and a less-perfect (but still very good) 020+ written conventionally. The "Ample" GUI is a great way to get into MAME for Apple emulation on modern macOS (I, II, ///, and Macs up to the LC580).

 

[MacOSMonkey]

@Arbee OK -- gotcha. I will look into it. Intuitively, it seems like MAME mappings would be a good application for ML/AI vs. Python or trying to render transistor layouts by hand (go into a cave and come out 10 years later ).

 

[Trash80toHP_Mini]

@Trash80toHP_Mini your rom had a different number from mine. Have you tried what OS versions your card support? Would be interesting to compare our roms if we could get them dumped .

I can't get at hardly anything in my collection ATM. I've got several ROMs that need to be dumped, one unfortunately dating back several years. I never try to push any Mac much beyond its release OS. Really only run early 7, the 7.5.5(?) general release and OS9

RAMDAC capability seems to be the limiting factor for output. Swapping Radius ROMs didn't help, newer one worked, but with the same 8bit limitation with the 24bit version of same. Might have bumped up OS support though? There's a thread somewhere about this.

@Melkhior have you looked at a way to poll VRAM on early cards to harvest their large extended desktop data? Bypassing RAMDAC in order to spit out the much larger resolution via HDMI would be amazing.

 

[Phipli]

RAMDAC capability seems to be the limiting factor for output. Swapping Radius ROMs didn't help, newer one worked, but with the same 8bit limitation with the 24bit version of same. Might have bumped up OS support though? There's a thread somewhere about this.

On the PrecisionColour, RAMDAC limits resolution, VRAM limits colours (except the 8XJ, which is limited by the RAMDAC). Plus there is something that causes the XP to not use all of its VRAM to do 256 colours at 1024x768 when you swap in other ROMs.

 

[MacOSMonkey]

The RAMDAC controls color output at various frequencies. For 8-bit video, you only need a single-channel 8-bit DAC (e.g. BT or AD478). For 24-bit (millions), you need a triple channel 8-bit DAC (e.g. BT or AD473) -- or 3 single-channel 8-bit ones. Also, the BT47x variants were faster and the Bt45x variants were slower -- like the Bt453.

VRAM limits maximum screen resolution at any given bit depth. For example, it takes 3Mb of VRAM to do 1024x768 @ 32bpp (typical 19" resolution). On the Mac, QuickDraw has sloppy boundaries and may access memory either slightly before a board's base address or slightly beyond the bottom right screen coordinate in memory. For maximum robustness, there should be buffers at both ends of screen memory to prevent bus errors (but these issues are corner cases).

Example VRAM size calculations look like this:
1024*768 * 32bits = 25,165,824 bits
25,165,824 / 8 bits per byte = 3,145,728 bytes
3,145,728 / 1024 bytes per kilobyte = 3,072 Kb
3,072 / 1024 Kb per megabyte = 3Mb

Similarly, the VRAM size requirement for 8-bit boards at 1024x768 is 768Kb.

So, including the extra CopyBits buffers, VRAM for video boards should be slightly bigger than the above sizes.

 

[Phipli]

The RAMDAC controls color output at various frequencies. For 8-bit video, you only need a single-channel 8-bit DAC (e.g. BT or AD478). For 24-bit (millions), you need a triple channel 8-bit DAC (e.g. BT or AD473) -- or 3 single-channel 8-bit ones. Also, the BT47x variants were faster and the Bt45x variants were slower -- like the Bt453.

VRAM limits maximum screen resolution at any given bit depth. For example, it takes 3Mb of VRAM to do 1024x768 @ 32bpp (typical 19" resolution). On the Mac, QuickDraw has sloppy boundaries and may access memory either slightly before a board's base address or slightly beyond the bottom right screen coordinate in memory. For maximum robustness, there should be buffers at both ends of screen memory to prevent bus errors (but these issues are corner cases).

Example VRAM size calculations look like this:
1024*768 * 32bits = 25,165,824 bits
25,165,824 / 8 bits per byte = 3,145,728 bytes
3,145,728 / 1024 bytes per kilobyte = 3,072 Kb
3,072 / 1024 Kb per megabyte = 3Mb

Similarly, the VRAM size requirement for 8-bit boards at 1024x768 is 768Kb.

So, including the extra CopyBits buffers, VRAM for video boards should be slightly bigger than the above sizes.

To clarify my post, Radius used the same board for most of their precisioncolours. They used three speed grade RAMDACs, and two different amounts of VRAM. So in the context, the RAMDAC limits resolution, and the VRAM (proportionally) limits the colours... Except they also locked the cards to the resolutions they wanted them to do.

The XJ is a different board and uses an 8bit RAMDAC.

I was saying the same thing, just in very specific context.

 

[MacOSMonkey]

I understand what you are saying -- context, etc. -- just a bit non-standard.

SCREEN RESOLUTION generally refers to the XY screen size and/or DPI rating.

BIT DEPTH generally refers to the bit-per-pixel setting, which is tied to the physical amount of VRAM. However, as we are discussing, certain bit-depths (8 or 24-bit) are only possible based on the presence of specific RAMDACs, making the RAMDAC the limiting factor in OUTPUT. See the next one.

COLOR OUTPUT (or COLOR RESOLUTION, if you prefer) generally refers to how the digital pixel data in VRAM is output as an analog signal by the RAMDAC (for Mac color video), making the RAMDAC the limiting factor in what appears on the display.

VIDEO TIMING is a function of the video controller and the RAMDAC and includes refresh rate.

So, strictly speaking, VRAM limits physical resolution (screen resolution and bit depth) and the RAMDAC limits the analog color output to the display.

At lower screen resolution (i.e. 640 x 480), it may be possible to output 24-bit color, but only if the correct RAMDAC is present (8- or 24-bit version). For example, the SuperMac ColorCard/24 can do 640x480 24-bit and 1024x768 8-bit, but only because it has a 24-bit RAMDAC. Spectrum/8 Series III neither has enough VRAM (I think 1Mb) or an appropriate RAMDAC to output 24-bit at a resolution of 640x480 (>1Mb required).

Anyway -- not trying to split hairs here, just trying to be clear in explaining the primary hardware limiters. It's nice to see the PrecisionColor info.

 

[Trash80toHP_Mini]

Yep, RAMDAC limits resolution support at the video-out connector, but not an available virtual desktop contained in Video Memory.

My question to @Melkhior was about accessing that extended desktop held in VRAM that's panned through the 640x480 video connector viewport of my first rev Spectrum. If the entire virtual desktop is not present in VRAM that'd be a no go.

 

[Melkhior]

My question to @Melkhior was about accessing that extended desktop held in VRAM that's panned through the 640x480 video connector viewport of my first rev Spectrum. If the entire virtual desktop is not present in VRAM that'd be a no go.

Even if it is, it's not just the DAC itself; both the memory and its controller need to be able to sustain the bandwidth to the DAC - 1920x1080@60Hz needs about 6x the bandwidth of 640x480@67Hz. Even the 17"-friendly 1280x1024@60Hz requires almost 4x the bandwidth. 1024x768@60 is still near 2.3x... (assuming they all use the same depth, with only change the absolute numbers, not the relative demands).

If everything in the card is designed for a resolution and only the DAC is lower-specced for 'cheaper' device(s) with lower maximum resolution, then swapping the DAC (and ROM) is an option. However, given the cost of contemporary memory and in particular VRAM, odds are the VRAM (and perhaps other components) are lower-specced as well...

 

[MacOSMonkey]

@Trash80toHP_Mini

What you are considering would be very difficult to achieve or just end up being a huge waste of time.

If I recall correctly, the VDTs on that board are (h x v): 1024x1536, 2048x1536 and 4096x1536. 640x480 13" mode probably also includes 1024x768.

Anyway, the best timing to use on a 1080p would be 1024x768 19" 60Hz mode (not 13" 640x480). So, it wouldn't matter what size your old Mac monitor was (since you wouldn't be using it). With the board in 19" 1024x768 60Hz mode, instead of trying to bypass the DAC, you would use some kind of video converter (probably exists somewhere) on the DB15 out from the board that converts sync-on-green analog video out to 1080p/HDMI (again...assuming it could sync to/recognize the 19" 60Hz signal). The rest of the pixels on the 1080p beyond 1024x768 would be displayed as a black area (unless you chose an option on the monitor/TV like zoom fit, etc.).

And, further, if you had this kind of smart video signal converter, then VDTs would work as VDTs on the 1080p monitor with a converted visible area of 1024x768, since the image would be coming directly off the board and work as normal.

 

[MacOSMonkey]

And just to clarify, when I open by saying "the best timing to use [for] 1080p would be 1024x768 19" 60Hz mode (not 13" 640x480)," I am talking about running it through a converter, as the post later outlines.

 

[Trash80toHP_Mini]

Again, not talking about the specific board in this discussion in terms of harvesting and displaying extended desktop. It doesn't do extended desktop does it?

Was thinking it would be cool to bit-bang(?) contents of VRAM on early cards with extended desktop and shoot the entire thing out HDMI, doing an end run around the RAMDAC roadblock somehow. If all VRAM were socketed, there could be a wedge there?

 

[MacOSMonkey]

Trash - my comments are not necessarily restricted to specific cards. If there were a DB15-to-HDMI 1080p video converter that happened to recognize all the standard analog timings, it would accomplish what you are suggesting without having to bit-bang anything and/or rework every board to try to extract data from VRAM (that either wouldn't offer any benefit or just wouldn't work).

Sorry to misunderstand -- what boards and extended desktop resolutions are you specifically suggesting? Typical "extended" or "virtual" desktops on SuperMac boards are 1536 vertical pixels when only 1080 pixels are available in 1080p (so the VDT wouldn't fit).

The stock resolutions that would theoretically be most compatible would be: 1024x768 60Hz, 1024x768 75Hz, 1152x870 and 1280x1024 and 1360x1024 (none of which are "extended desktops," except for maybe 1024x768 on a 640x480 monitor, as I mentioned). You would just change the card timing and convert video out from the DB15 port to be displayed on a 1920x1080 display (and also use VDTs at any of those resolutions (since the video out would be whatever the Mac card is displaying).

Once you get to 1600x1200, you are out of luck vertically (or with any of the 1536 VDTs -- or whatever hypothetical resolution that a non-specific board might offer that exceeds 1080 vertical lines -- where SuperMac cards offered the lion's share of VDT functionality). Some RasterOps cards also had VDTs (but fewer, as I recall -- but I'm not really a RasterOps expert).

 

[Trash80toHP_Mini]

what boards and extended desktop resolutions are you specifically suggesting? Typical "extended" or "virtual" desktops on SuperMac boards are 1536 vertical pixels when only 1080 pixels are available in 1080p (so the VDT wouldn't fit).

I have a few boards, but the one I'm mainly interested in would be the very first rev of the Spectrum which is entirely programmable for any given resolution/dot clock. Just curious about spelunking VRAM for getting its contents out into the real world by bypassing RAMDAC limitations.

 

[MacOSMonkey]

OK - so a Spectrum/8 (Rev B) board (which was not infinitely programmable - the clock cap was just a little over 64Mhz with /16 divider on the TMS34061). Have fun with your project...or just look for a compatible RGB->HDMI adapter to convert RGB Sync-On-Green. I think that board also has a hardware limitation where the max refresh rate is around 60Hz.

 

[Aeroform]

Just recieved my programmer and am ready to dump some roms. Problem is I have no clue which chip/pic type to choose? . Anyone know what type from the list should work for this rom? Thanks

 

[MacOSMonkey]

It's a 27C128 28-Pin DIP EEROM. In your programmer you should be able to choose a vendor and part number/type. It doesn't look like you're looking in the right place. The part you want is not on that list - that is a list of PIC chips (Microchip microcontrollers). Also, I guess there are DIP PIC chips, but they are usually PLCCs or maybe J-bend devices (at least the ones I have used in the past). Anyway, not the droids you're looking for.

 

[Aeroform]

It's a 27C128 28-Pin DIP EEROM. In your programmer you should be able to choose a vendor and part number/type. It doesn't look like you're looking in the right place. The part you want is not on that list - that is a list of PIC chips (Microchip microcontrollers). Also, I guess there are DIP PIC chips, but they are usually PLCCs or maybe J-bend devices (at least the ones I have used in the past). Anyway, not the droids you're looking for.

Thanks. That explains it, I have the completely wrong tool. Back to shopping

 

[Phipli]

Thanks. That explains it, I have the completely wrong tool. Back to shopping

What did you buy?

You want a TL866 probably.

 

[Aeroform]

What did you buy?

You want a TL866 probably.

Turns out I ordered a Pic 150k. Didn’t look too closely and it was $10 with next day delivery so didn’t think twice. Oh well, might be handy some other time. The cheapest TL886 variants seems to run about $85