PDPs are enormous computer units created by the Digital Corporation released in the 60s, that were sold mostly to scientists and engineers, with runs of under 800 units being popular. The PDP-1 was the center of the absolute prehistory of the hacker subculture as it emerged at MIT, and the first video game ever (Spacewar) ran on one.
Fun fact: the man who managed the PDP has a weird comics connection, as he is the father of Astro City author, Kurt Busiek, who was a vice president at Digital in the 70s.
I have been building my 68030 computer around a 25MHz-rated part, so that has always been my target. My original wire-wrap prototype initially ran at half that, but as I continued to expand the project, the best I could manage was 6MHz. Eventually, the whole thing got so unstable I had to abandon plans to continue adding FPU, DRAM, IDE, etc.
I do still want to add those parts to the project, to learn more about working with them. That’s why I ordered the custom PCBs — I was hoping a PCB would be a more stable platform for future expansion and allow me to finally run the machine at the 25MHz target.
Once I got the new PCB prototype working I tried again with a 25MHz oscillator (my new glue logic no longer divides the clock like my original).
It didn’t work.
In fact, at 25MHz it failed in the same way it always had on the old wire-wrap prototype. It seemed 12 MHz was my limit.
Or was it? Maybe I just had a bad oscillator. Perhaps a new one would work better?
A ridiculous line of thought, given that the 25MHz oscillator I had did indeed run the computer at one time. But, I did want to see how fast I could get it to run, and there are some respectable speeds between 12MHz and 25MHz. So I placed an order for a few oscillators, 16MHz, 20MHz, 24MHz … I also stocked up on some common resistors and capacitors to make the most of the shipping fee.
Got the new parts in, threw on the 24MHz oscillator and … nothing. It didn’t work.
There is a problem I noticed when I did my original troubleshooting on this PCB — some of the wired-or signals had very slow rise times. I don’t have a proper oscilloscope, so it’s hard to tell sometimes if analog problems like that are measurement error or induced by stray capacitance of the measurement leads. But, the 8kΩ resistor networks I had gotten from surplus to use as pull-ups on this project were a bit high. Perhaps a lower-value pull-up resistor might help here.
Among the resistors I ordered were some 4.7kΩ and 1kΩ resistor networks. 4k7 is a fairly standard pull-up value, and some rough math had shown 1k might be a good value for this project. So I swapped out the 8k resistor networks for the new 1k networks and gave it a shot. It still ran without issue at 12MHz…
And at 16MHz.
And at 20MHz.
And at 24MHz.
And at 25MHz.
And at 32MHz.
And at 40MHz.
My MC68030 rated for 25MHz was running BASIC stable at a 60% overclock. Even the RAM was overclocked at this point, with cycles reduced to 50ns for SRAM rated for 55ns. It would seem that all this time my choice of pull-up resistor value had as much or more to do with my speed limits as the method of prototyping.
It wasn’t perfect though, and as soon as I added my SE-VGA card back into the mix it would no longer successfully load BASIC at 40MHz. It did however run just fine at 32MHz, even with the SE-VGA card.
Ludicrous Speed
In the years since I started this project I acquired another 68030 CPU — a 40MHz-rated 68EC030 (the EC units lacking the on-board MMU). I’m sure you can see where this is going.
First, I needed to modify my glue logic. RAM access cycles were going to need another wait state, ROM another two. While I was at it, I created a new cycle specifically for my SE-VGA card, with three wait states. Since my UART (68B50) is actually rated for 2MHz, and my timing was originally factored for 1MHz with a 25MHz base clock, I left the UART timing alone to push it closer to its rated speed. All-around, the new timing should support up to 50MHz base clock.
New logic, everything ran fine at 32MHz. Swapped in the EC030 and no problems. Time to see how fast it will go.
40MHz, no sweat
50MHz, still running cool
56MHz, no problems
I’m out of oscillators. My 68030 homebrew, with a 40MHz-rated EC030 is running reliably at 56MHz, a 40% overclock. Even the SE-VGA card is working, and much happier with its custom timing added to the glue logic.
I’ve been using a simple Mandelbrot rendering BASIC program as a benchmark. On my original 6MHz 68000 build, this program takes around 9 minutes to complete. When I first ran it on the 68030, running at 12MHz, with cache disabled, and BASIC in 8-bit ROM, it took just under 5 minutes. Now, with BASIC running from RAM on the 32-bit bus, L1 cache enabled, and CPU at 56MHz, the Mandelbrot program completes in 14 seconds. That is an incredible performance increase for a simple homebrew computer.
It does generate some heat now, so I added a small heatsink to the CPU to be safe. Current consumption for the system is up 300mA just from raising the clock speed.
Motorola originally sold 68030 CPUs rated as high as 50MHz. I wonder if my later production units just benefit from what they learned pushing the architecture that high, or if it’s reflective of what the CPU can handle in general. Could I push a 50MHz part up 40%? A 70MHz 68030 homebrew certainly would be interesting.
My 68030 homebrew computer is coming along nicely. It’s running stable at 12MHz, I’ve got BASIC running, I can transfer programs to it from another computer. I think it’s ready to take to the next local retro computer meetup. I just need some flashy demo program.
Well what would be better than giving it a video output? And it just so happens that I have a perfectly good video card designed for the 68k bus just sitting around.
I added my SE-VGA card to my 68030 homebrew.
I already had expansion bus ports on my 68030 protect, I just needed an adapter for the 68000 socket & bus.
I threw together a card that stacks on top of my 68030 and connects to its expansion bus. The SE-VGA card plugs into the adapter card. A couple TTL chips (a 74HCT32 and a 74HCT14) provide the discrete !UDSand!LDS signals for the 68000 bus on the SE-VGA, as well as a power on reset circuit. Jumpers for the SE-VGA are set for 2MB, since that’s the amount of RAM I have on the 68030.
And that’s all it took. I didn’t have to update logic for the SE-VGA or glue logic for the 68030. Updating the video output just requires writing to the video buffer addresses that a Mac SE would use with 2MB of RAM (0x1FA700)
I can use the PEEKandPOKE functions in BASIC to write to the video buffer, but this is painfully slow. I’ve started writing some helper functions that can be run using the BASIC CALL function to handle some screen drawing tasks in Assembly. These make drawing to the screen a much more reasonable task.
This isn’t the direction I intended to take this project (the goal has always been multi-user *nix with multiple serial terminals), but it’s been fun to play with. Computer video always seemed like black magic. It’s been fascinating to build it from the ground up and see how it all works.
I have a 1996 LaCie Tsunami 9GB external SCSI hard drive. It actually works just fine, but there are a couple filter capacitors on the output stage of its power supply that have leaked. I had some equivalent replacements on hand from previous repairs, so it took no time at all to replace them.
ALT
Hopefully this will keep this power supply humming along well filtered for another quarter century.
i don’t think macs are ugly or bad, but they’re bred with such little concern for the computer’s health that their existence is an unethical fact. again no ill will towards the macs themselves
I miss the mid-late Mac II era. Like, I love my IIcx. It had just a single thumbscrew holding the case closed (which I promptly lost), and a couple latches. It could support more memory (128MB) than would be common for another decade, and had three self-configuring screwless expansion slots.
It was such a well-planned design that Apple CEO Jean-Louise Gassée introduced the model by assembling one on stage.
This in sharp contrast to the current models that offer zero expandability options (soldered RAM and SSD (because those never fail), two USB ports only, etc.), more glue holding them together than a child’s paper mache project, and of course serial-keyed parts that can only be replaced by Apple.
(Not to mention the complete and utter hell that is trying to manage Macs in an enterprise environment)
Don’t get me wrong, more of Mac history has been hostile to maintenance than not. Apple has always had an unhealthy obsession with the proprietary, and the first Macs were intentionally designed to be replaced, not upgraded. Even the early Mac II era cases were designed to sound like cracking plastic when opened to scare people out of doing so. But for a brief period we had a glimpse into a better world.
Games on early B&W Macs traded colors for a higher resolution and they often looked very good. However, this was difficult to do in Warlords, a turn-based strategy game with eight nations, where the color was the only way to differentiate between them. The Mac version has unique graphics for buildings and flags (held by warriors) to overcome the lack of colors and the result is surprisingly nice, but the colors on PC are more practical anyway.
David asked me if I could help him with transferring all files from the pack of floppy disks he used during the late 80s with an 8-bit Atari (800XE). We are working on the Atari version of our Sieve Benchmark (to compare the performance of old computers) and he told me that, as a kid, he created many assembly programs that can now speed up the development . The ultimate goal is to compare extremely optimized assembly versions of the benchmark for 6502, Z80 and 8088 to find out, which CPU is faster.
I didn’t have any modern disk emulator for the system so I transferred the files to the PC the old way. I used Atari 800XL and two floppy drives (1050 and XF551). At the beginning, I had just one drive, but then I realized that I was not able to create at least a small RAM disk on a 64k machine with MyDOS – that would allow me to copy files from one disk to another without using multiple drives (this is not straightforward when each of the disks has different density).
Copying files to different disks was necessary. David used the 130KB “ehnanced density” format that is not readable on floppy drives in PC. The Atari XF551 disk drive supports all the Atari formats up to the 360KB double-sided double density that is sort of compatible with PC drives. With the two drives connected to the Atari, I copied the files from the old disks to a few “new” ones and started searching what is necessary to do on the PC side.
At the end, I used two MS-DOS programs – ATUTIL for reading/writing individual files and WRITEATR for creating ATR disk images out of real floppies. All of this took me two evenings, but I’m happy that I didn’t have to use modern hardware to copy files both ways between 8-bit Atari and PC.
(btw David also decided not to use modern hardware so he is programming directly on the Atari 800XL with Atmas II macro assembler from 1985)
This is one of the demos that were used by Silicon Graphics and Nintendo to show the graphics features of their upcoming game console (Project Reality / Ultra 64 / Nintendo 64) during CES in 1994.
SGI used an Onyx supercomputer to run the demo. I recorded it in 1024x768 (true-color) on a much less powerful SGI O2 workstation (released in 1996). O2 is based on a graphics architecture similar to what was actually used in Nintendo 64. It was a perfect fit for an inexpensive highly-integrated computer as well as a game console.
I would rather use a different SGI computer (Octane2 was my first choice), but O2 was the only machine that was compatible with my cheap VGA-to-HDMI converter.
We prepared a small room with old computers as a part of a bigger event at work. After careful consideration, we selected Atari 800XL and Commodore Amiga 500 for the contest purposes. Atari was running Space Invaders and each visitor played with the highest difficulty (three lives, level 12). For Amiga, we chose Pinball Dreams and the goal was to get the highest score using just a single ball.
To make the room more appealing, we brought several old computer magazines and 80s props. Curious visitors could also experience ZX Spectrum+ with the Who Dares Wins game. The feedback on our room was very positive and people were talking a lot about their first computers there. However, the biggest surprise for me is that the joystick survived all the players. Some of them gave it a hard time.
Thanks to friends of mine, I was able to get two working parallel-port ZIP drives from Iomega. My father used to use these during the 1990s as ZIP disks were popular in offices in Czech Republic. He later switched to an internal ZIP drive connected to IDE when his parallel-port external one died and used it for another 10 years.
I have a few systems where it is not possible to add a network controller so I though that this would be a good device for faster data transfers (compared to a null-modem cable or diskettes) or accessing data larger than the internal hard drives.
It works just fine. The only drawback is that you usually need a 486 system to leverage full speed of the external drive. My 386 laptops do not support the ECP/EPP protocols on the parallel port, so the access speed is significantly limited (150KB/s?). Anyway, it is still convenient enough for running DOS programs straight from the external drive. I am surprised how nice driver support Iomega provided for DOS and Windows 9x. There is even a “guest” driver in a form of a single exe file – just run it and you can immediately access the drive using a newly assigned drive letter.
In the mid-1990s, there were so many articles about how cheap all the RISC CPUs were compared to what Intel offered. You could read it in an every computer-related magazine every month. Scientist friends of mine at universities desperately wanted to have such RISC CPUs in their own personal computers. They never really liked x86 design and they were used to work on UNIX workstations, so they didn’t even need any support for running Windows. However, although these CPUs were marketed as inexpensive, it was nearly impossible to build a computer based on them. You could only buy a complete UNIX workstation or a hi-end workstation-class mainboard with a lot of unnecessary features. There was no way to buy a reasonably priced basic mainboard.
At least that was the situation here in Central Europe. What was your experience? Was it different in your country?
ALT
ALT
