Not that, I don't think. The pixels would be numbered 0-1023.
I'm inclined to believe this. The color lookup table takes 256*something bytes.
Could it actually be a bug that no one caught? (I doubt)
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
SuperMac Spectrum - The one that started it all
- Thread starter David Cook
- Start date
Not that, I don't think. The pixels would be numbered 0-1023.
I'm inclined to believe this. The color lookup table takes 256*something bytes.
Could it actually be a bug that no one caught? (I doubt)
Great writeup, you went above and beyond with the old articles from magazines.
We thought we really did something when we got 256MB of VRAM working flashing nVidia cards. At the time there were about two games that took advantage of more than 128MB.
768k was something in the late '80's. If you had a computer at all it likely didn't have that much systems ram.
I remember a friend of mine picking up a cheap x86 computer on clearance at a popular chain in '95. Then he went straight to the Windows 95 CDROM and read the systems requirements, 4MB of RAM, half what the computer he just bought had, and 2MB upgraded was more than the price he just paid for it.
Now 16GB is a standard amount of VRAM,
I think I was running system 7 on a Quadra 610 in '95, it had a DOS card, but I don't think I ever used it. I think it had the 1MB VRAM upgrade, and I though it was really something in 16bit color.
They might have a row bytes register that is not numbered like that.
Probably 3 bytes if they had 8 bit DACs (not necessarily true for cards limited to 256 colors).
3*256=768.
The CLUT might be stored elsewhere - such as in a dedicated chip.
An emulator such as MAME could include the ROM in an emulated NuBus card and determine what register values are being written for each mode and reverse engineer their function and limits. Having the card to poke at would be better. You can then write a value to a register and see which bits were actually kept.
Thanks to a kind donation from @MJ313 I now have a 30.24 MHz full can oscillator to add 640x480 mode to this Spectrum/8 card.
I put it in the spare socket, matching the orientation on the silkscreen.
I tested the output pin with an oscilloscope to confirm it is operating correctly. Marcus got this from a working Spectrum IV card -- so it is likely to be compatible.
Unfortunately, the control panel still only reports a single 64 MHz crystal. I've seen screenshots of this control panel with newer cards, and it shows multiple frequencies.
I tried forcing the 640x480 mode.
Upon reboot, the monitor indicated that the frequency was out of range and displayed nothing.
Most SuperMac cards cycle through resolutions at boot time when initially installed, parameter ram (PRAM) is cleared (such as missing the battery), or if the option key is held down as the computer powers up. The option key does not do anything on my Spectrum/8. To reset the bad resolution setting, you can swap in a different video card, boot, shutdown, and swap the Spectrum/8 back in. Or, you can hold down command-option-p-r at boot (until the computer restarts part way through booting) to reset parameter ram manually. Or, you can remove the battery and power cord and wait a few minutes to clear parameter ram.
I pulled the crystal and installed it in the other Spectrum/8 card with the same result. I also tried the earlier SuperVideo 2.0.7 control panel without success.
Does anyone have:
* A earlier version of the SuperVideo software (prior to 2.0.7)?
* A different version of the Spectrum/8 ROM (v1.9x or higher, but I already have v1.97)
* A copy of the Spectrum/8 manual. Perhaps the optional crystal needs to be enabled in some way?
Checking the circuit, the output of each oscillator feeds into a 74F257 multiplexer. A control line selects which clock is output. This suggests that the card is indeed capable of switching between the clocks programmatically. And, this suggests that since the board works with the 64 MHz oscillator, then there isn't too much that can go wrong from that path to the 30.24 MHz oscillator.
I could connect the oscilloscope to the 74F257 control pin to trigger on it switching. That would indicate the card is at least attempting to measure/use the other clock at some point.
I could desolder and socket the original 64 MHz crystal to test the 30.24 in that location.
Other than that, any ideas?
- David
I put it in the spare socket, matching the orientation on the silkscreen.
I tested the output pin with an oscilloscope to confirm it is operating correctly. Marcus got this from a working Spectrum IV card -- so it is likely to be compatible.
Unfortunately, the control panel still only reports a single 64 MHz crystal. I've seen screenshots of this control panel with newer cards, and it shows multiple frequencies.
I tried forcing the 640x480 mode.
Upon reboot, the monitor indicated that the frequency was out of range and displayed nothing.
Most SuperMac cards cycle through resolutions at boot time when initially installed, parameter ram (PRAM) is cleared (such as missing the battery), or if the option key is held down as the computer powers up. The option key does not do anything on my Spectrum/8. To reset the bad resolution setting, you can swap in a different video card, boot, shutdown, and swap the Spectrum/8 back in. Or, you can hold down command-option-p-r at boot (until the computer restarts part way through booting) to reset parameter ram manually. Or, you can remove the battery and power cord and wait a few minutes to clear parameter ram.
I pulled the crystal and installed it in the other Spectrum/8 card with the same result. I also tried the earlier SuperVideo 2.0.7 control panel without success.
Does anyone have:
* A earlier version of the SuperVideo software (prior to 2.0.7)?
* A different version of the Spectrum/8 ROM (v1.9x or higher, but I already have v1.97)
* A copy of the Spectrum/8 manual. Perhaps the optional crystal needs to be enabled in some way?
Checking the circuit, the output of each oscillator feeds into a 74F257 multiplexer. A control line selects which clock is output. This suggests that the card is indeed capable of switching between the clocks programmatically. And, this suggests that since the board works with the 64 MHz oscillator, then there isn't too much that can go wrong from that path to the 30.24 MHz oscillator.
I could connect the oscilloscope to the 74F257 control pin to trigger on it switching. That would indicate the card is at least attempting to measure/use the other clock at some point.
I could desolder and socket the original 64 MHz crystal to test the 30.24 in that location.
Other than that, any ideas?
- David
Ok. I desoldered the existing 64 MHz crystal and added a socket in its place. Unfortunately, the legs of the desoldered crystal were too short to fit snugly in the socket. So, I had to order a new 64 MHz crystal from Mouser (ECS-100AX-640). After arrival, I verified that the new 64 MHz crystal worked and that the card operated equally well as before the socket was added. The 30.24 MHz crystal was still in the OSC2 socket to no effect.
I then swapped the crystal oscillators, such that @MJ313's 30.24 MHz crystal was in the first socket and the 64 MHz crystal was in the OSC2 socket.
Upon power up, the card automatically defaulted to 640x480! This was verified in the control panel.
This confirms that the 30.24 crystal works fine and that the card operates with a 30.24 crystal. However, note in the image above, now the 64 MHz crystal is not detected.
So, the problem is:
1. The second socket, wiring, or selector chip is bad. Unlikely since the behavior also occurs on a second card.
2. The firmware on the card does not support OSC2
3. The control panel SuperVideo softward does not support OSC2
4. The Spectrum/8 card itself does not actually support OSC2. Perhaps a design flaw that they didn't bother to fix.
5. There is a special keypress or hardware option needed to select OSC2.
Looks like I've run out of things to try for now.
- David
I then swapped the crystal oscillators, such that @MJ313's 30.24 MHz crystal was in the first socket and the 64 MHz crystal was in the OSC2 socket.
Upon power up, the card automatically defaulted to 640x480! This was verified in the control panel.
This confirms that the 30.24 crystal works fine and that the card operates with a 30.24 crystal. However, note in the image above, now the 64 MHz crystal is not detected.
So, the problem is:
1. The second socket, wiring, or selector chip is bad. Unlikely since the behavior also occurs on a second card.
2. The firmware on the card does not support OSC2
3. The control panel SuperVideo softward does not support OSC2
4. The Spectrum/8 card itself does not actually support OSC2. Perhaps a design flaw that they didn't bother to fix.
5. There is a special keypress or hardware option needed to select OSC2.
Looks like I've run out of things to try for now.
- David
Thanks for the potential lead. That was originally my thought as well. However, the jumper connector was hard jumped for production. Check it out:
The left side of the image is the slot output. SuperMac included the mounting pattern for a DE-9 connector, but obviously didn't populate it. So, it seems like they originally intended for an external clock source to be used as the secondary oscillator. On the top side, another of those DE-9 pins leads to the other jumper. Genlock maybe? An early scheme where the monitor could inform the card as to its frequency?
Now compare this to the SuperMac Graphix card. This has a populated DE-9 connector and two jumpers. If I knew more about the Graphix card, perhaps it would shed light on the original purpose of the unused jumpers on the Spectrum 8.
- David
Huh.. that's really interesting. Where do the other traces aside from the one going to JP6 from the DE-9 go to? Wonder if that was for debugging purposes? Weird.
Hello one and all! I recently came into one of these cards as well and agree that the port placement is super puzzling! It doesn't really fit on any machine I currently have around.
I figured that the missing DB9 Port was for monochrome displays like the Radius Full Page.
Anyway my card wasn't working but after reading this thread it seems I am missing a clock completely. I'd love to get this little guy working, ideally with support for the resolution of the apple two page display. It seems like we are missing documentation for this card?
I'd take getting it working at 640x480 as well just to confirm it is working.
I figured that the missing DB9 Port was for monochrome displays like the Radius Full Page.
Anyway my card wasn't working but after reading this thread it seems I am missing a clock completely. I'd love to get this little guy working, ideally with support for the resolution of the apple two page display. It seems like we are missing documentation for this card?
I'd take getting it working at 640x480 as well just to confirm it is working.
Attachments
I count 24 NEC D41264C 4bit x 64k dual ported VRam chips - 768kb VRam. I guess that‘s not enough for 24bit even at 640x480, you need 921kb or simply 1mb.
Agreed; 768kb is what I needed to get 16bit at 640x480.
Thanks for clarification, figured as much when first taking a look at that card.
1024x768@8bit was about perfect for spreadsheet, CAD and Illustration programs. GS TPD card and second card for 24bit on a small display was the go to for DTP in the day. Page layout DTP started out on 1bit B&W FPD and TPD screens. 8bit color was a nice upgrade for such a setup, even if not full on TPD res.
1024x768@8bit was about perfect for spreadsheet, CAD and Illustration programs. GS TPD card and second card for 24bit on a small display was the go to for DTP in the day. Page layout DTP started out on 1bit B&W FPD and TPD screens. 8bit color was a nice upgrade for such a setup, even if not full on TPD res.
The Spectrum/8 was 8-bit only. I will look over the earlier posts and see if I have anything to add. As I recall, I *think* OSC2 should work and the firmware runs a TimeDBRA timing loop at startup to try to find compatible oscillators that match supported (or user-defined) configs. But maybe OSC2 doesn't work. I'll think about it.
The original ColorCard, Spectrum/8 and Spectrum/24 were all similar -- deriving from support for the TMS34061 and x4 clock granularity. I have all these boards laying around. I will take a look at Spectrum/8 and see what else I can offer. I'll have to set it up and try it out with an earlier SuperVideo. It may take me some time - I am in the middle of a large and unpleasant vehicle repair project.
In case you're wondering, the other port on Spectrum/8 was for genlock input from a Julian Systems board. The original versions of SuperVideo had a "slurper" tool (eye dropper with a fun slurping) tool that would let you chromakey whatever background color you selected. So, you could use a color graphics app, do video titling over a solid background and slurp-select the background color as the video drop-out color, etc. While these features were cool, they didn't have any significant demand or use and did not survive much beyond 1988. I do also have a Julian Systems board somewhere and could theoretically try to rewind time and set this up -- but another project.
To summarize, the setup would be Spectrum/8 with a 14.31818Mhz oscillator in NTSC mode, Julian Systems, the sync interconnect, genlocked NTSC out, a color graphics app and SuperVideo 1.0 (I think). I wonder if I know the pinouts for the interconnect? Hmm. Another good question. Might be in the manual.
The original ColorCard, Spectrum/8 and Spectrum/24 were all similar -- deriving from support for the TMS34061 and x4 clock granularity. I have all these boards laying around. I will take a look at Spectrum/8 and see what else I can offer. I'll have to set it up and try it out with an earlier SuperVideo. It may take me some time - I am in the middle of a large and unpleasant vehicle repair project.
In case you're wondering, the other port on Spectrum/8 was for genlock input from a Julian Systems board. The original versions of SuperVideo had a "slurper" tool (eye dropper with a fun slurping) tool that would let you chromakey whatever background color you selected. So, you could use a color graphics app, do video titling over a solid background and slurp-select the background color as the video drop-out color, etc. While these features were cool, they didn't have any significant demand or use and did not survive much beyond 1988. I do also have a Julian Systems board somewhere and could theoretically try to rewind time and set this up -- but another project.
To summarize, the setup would be Spectrum/8 with a 14.31818Mhz oscillator in NTSC mode, Julian Systems, the sync interconnect, genlocked NTSC out, a color graphics app and SuperVideo 1.0 (I think). I wonder if I know the pinouts for the interconnect? Hmm.
Another good question. Might be in the manual.
That is really cool!
It was pretty cool in 1988. Alas, it didn't survive. :'( But...I may be able to put together a demo if everything still works.
