#se-vga

[techav]

VCF Southwest

This was the first time I've been able to attend a VCF, and it was the first held in the Dallas area in over a decade. I was lucky enough to participate as both event staff, helping to plan and run the show, and as an exhibitor. It was exhausting, it was overwhelming at times, and I nearly lost my voice by the end of the first day ... But it was also an incredible experience and I really enjoyed it.

I brought a few of my projects to show off. First and foremost was my Wrap030-ATX project, which I paired with a Wyse WY-30 terminal I rescued from Computer Reset, and had running a demo program for printing names on my recently-repaired Apple ImageWriter II/L. Next to that was my Wrap030 board stack running a Mandelbrot fractal renderer using its 68882 FPU and video generator cards. Then came the Mac SE from Computer Reset I repaired, with my SE-VGA card driving an external monitor, and running Oregon Trail (always a crowd favorite!). Finally I had my Franken-Plus, which sadly suffered a power supply failure early on the first day and sat dark all weekend.

My exhibit was situated just down the row from @commodorez , who won the show's Best Microcomputer award for his "VICs that aren't 20" exhibit of rare and lesser-known Commodore computers. Across from Commodore-Z was Usagi Electric, who won Best in Show for his exhibit of the Centurion, a PDP-11, and his vacuum tube computer.

I had a great time talking to Commodore-Z, @ms-dos5 , Usagi Electric, Nybbles and Bytes, Macintosh Librarian, Retrotech Chris, Kevin & Michael of the Turbo 9 Team, Al Williams, and so many more wonderful people that I couldn't even begin to catch names for.

I also got to go into deep-dive discussions on very specific details about my projects with people who already knew so much more about the components and the tools that I'm using than I do. It's energizing to be around people that understand the work that goes into these projects and appreciate what I've accomplished.

The show was so much bigger than I anticipated. Including staff, volunteers, sponsors, speakers, exhibitors, and attendees, we saw nearly 900 people come through the main hall over the course of the weekend. Seminars were full, with CuriousMarc's presentation on Restoring the Apollo Guidance Computer forming an imposing line for entry well ahead of the scheduled start of the talk. We had incredible community turnout; it was great to see entire families come through with awestruck small children in tow.

There was so much to see and do, so many people to talk to. The entire weekend is just a blur. My brain is still trying to process everything from the show.

One thing does stand out though — an unbelievably generous act from someone I spoke to on Saturday about my homebrew builds and my methods for testing and debugging. This kind soul was so impressed by what I have accomplished without an oscilloscope that he bought one from the VCFSW charity auction and gave it to me on Sunday. I was so surprised I didn't think to even get his name before he disappeared into the crowd. I can't wait to put it to good use, and I hope that what I build with it lives up to his expectations.

Following VCF East earlier this year, Bil Herd said something about riding that high from VCFE, and that prompted him to agree to come out to join us at VCFSW this year. Now that I've experienced it for myself, I understand what he meant. I've been looking though all the pictures and blog posts everyone has been sharing, and catching up on recordings of the presentations I missed. Interest in some of my projects has me thinking about what I can do with them next. It's exciting.

I can't wait until next year.

[techav]

Combining Projects

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 !UDS and !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 PEEK and POKE 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.

[techav]

SE-VGA

I've started a new project.

Inspired by recent work on creating modern reproductions of the Mac SE logic board and following my previous CPLD VGA generator project, I've been working on a PDS card for the Mac SE that mirrors its video on a VGA monitor.

I'm using a similar approach to the [bbraun] project, which used an stm32f4 to watch the SE's CPU bus for writes to the SE frame buffer memory addresses. Instead of using a microcontroller I'm using an Atmel ATF1508AS CPLD to monitor the SE CPU bus for writes to the frame buffer addresses and storing the data in a pair of 32kB SRAM chips. The CPLD then reads back the video data to generate a 640x480 monochrome VGA signal with the SE video in letterboxed in its original 512x342 resolution.

The circuit itself is fairly straightforward. The CPLD runs everything off a single clock signal from a can oscillator, and uses the pair of SRAM chips for video memory. Other than those four chips, there are a few passive components. It's simple enough I could have built one with point-to-point wiring or even wire-wrap. But, to reduce debugging and the potential for noise disrupting the SE's normal operation, I decided to lay out and order some small PCBs.

I got these from JLC for $2 plus shipping and they arrived in just under two weeks. Build was easy enough. I used the drag solder technique with a lot of flux to solder on the 100 pin QFP package CPLD and it went on with no problems. Everything else is through-hole.

I tried to take a methodical approach to build and debug. I started with just the CPLD and clock to make sure it could generate a proper sync signal that was recognized by my monitor. That much worked without issue, so I moved on to testing if it could read data from its VRAM bus and display it. This part took some work with a logic analyzer and a few rounds of updates, but eventually I was able to tie one VRAM Data pin high and get it to display lines.

From there, I added the VRAM sockets to test if it could properly read from VRAM and display its contents. SRAM powers on to random contents, and when I added the SRAM to the board and powered it on, I was greeted with a screen of random pixels. VRAM was working, and the video generator was displaying a stable, consistent image.

At this point there was only one thing left to do — solder on the (expensive!) DIN 41612 connector and test it out in the SE.

Well, it was half working.

I had half of the image on screen, so it was clearly recognizing CPU write cycles, storing it in VRAM, and recalling it in sequence. I quickly found and corrected a bug in the code looking for the 68000 lower data strobe (!LDS), and inverted the final output and tried again.

It ... Wasn't quite right. It started out fine while Mac OS was booting. There was a little noise in the image, but not too bad ... until it reached the Finder. By the time it was finished booting, it was flashing, alternating between valid video data and a garbage data. The garbage data seemed to be encroaching on the valid data as well, the longer the system ran.

The first bug didn't take long to find. The classic Macs, including the SE actually support double-buffered video. They have a primary frame buffer and an alternate frame buffer, selected by setting or clearing one output bit on the VIA chip. I designed the card to support both frame buffers, and to also watch the CPU bus for writes to the specific VIA bit that controls frame buffer selection. I had calculated the VIA address wrong though, so it was swapping between frame buffers when it shouldn't have and that's what was causing the flashing.

I still had the problem of garbage data being displayed however. This one took a while to figure out, and I'm actually still not sure how it was happening to begin with.

The logic analyzer showed that every so often a VRAM write cycle would overlap with a VRAM read cycle. The VRAM write state machine shouldn't have allowed that to happen, but it was. Unable to find anything that would cause the cycles to overlap, o added a test to delay the write cycle if it detected a current read cycle.

The result?

No more garbage data.

I really can't believe it. I wasn't sure I could get this to work, and I wasn't sure it would fit into a CPLD with only 128 macrocells. To top it off, this is my first real project using System Verilog instead of VHDL.

It's not perfect yet. There is one column of garbage data being displayed on the left of the image, and it looks like the last column off the right is also ending up on the left. But, it is completely useable.

I'm not finished with this project yet. I want to bump it up to XGA resolution (1024x768), which would allow the SE video to be pixel doubled and take up more of the screen. The 65MHz clock necessary for XGA is hard to come by, so I'm thinking about spinning up a rev 2 board that uses an FPGA instead of a small CPLD.

This has been a fun project. It's always so exciting for a project to have visible results.

I have the project on GitHub if anyone is interested in taking a closer look.

[techav]

SE-XGA

I've been working on the new revision of my SE-VGA project I mentioned previously.

These new boards use nearly all surface-mount parts, instead of the through-hole parts used on the first boards. The biggest functional change is the can oscillator has been replaced with a 13MHz crystal and a selectable clock multiplier — this allows a 65MHz pixel clock for running 1024x768@60 resolution (XGA) instead of the 640x480@60 (VGA) from the first boards. The Mac 512x342 resolution can be pixel doubled to fit into an XGA frame, with small black boarders (letterboxing) top and bottom.

I've rewritten the logic from scratch. The original logic was overly-complicated and I wasn't able to adapt it to the new resolution. Of course they means a whole lot of debugging, and brings to fore a problem with moving to small surface-mount components — no place to attach test leads.

I soldered some 30ga wire-wrap wire to key signals (in this case the VRAM control signals) so I could watch them with a logic analyzer for debugging. These pins are quite small, no larger than the wire itself. Soldering to them was finicky and took a few attempts. I taped the wires down to prevent them from pulling out while working.

Another big difference with these new boards is they support not just the Mac SE, but also older 68000 Macs as well. Here I've assembled one for a Mac Plus and I'm testing its fit around other components on the Mac Plus motherboard.

The logic is coming along well. I've encountered many of the same problems I had with writing the VGA logic and had to solve them all over again. At this point it does show the whole frame of video, but I have some random glitches with VRAM writes, and some of my timing is a little off. It is working as a proof of concept though. I should be able to clean up the logic and get it running smoothly.

This project has some interesting firsts for me. It's the first project I've ever designed a second revision and ordered a second round of boards for. It's also the first project I've ever made more than one of. Depending on how things go I might actually do a third board revision to clean up anything I find not working reliably.