#mac se

[commodorez]

Maccy and Twoee from the Macintosh Librarian

VCF Midwest 20

[centralbunnyunit]

[lonelyrollingstar]

Today’s friend

[512lab]

CAVEPAINT - MacCalligraphy (1986) on Macintosh SE

Playing with MacCalligraphy, ingenious software that uses the speed of the mouse to dynamically vary the brush size. 

Instagram  -  Explore NFT gallery.

[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.

[techav]

SE Exp30

I ordered some boards for my Mac SE accelerator. I'm quite pleased with how they look.

Assembly wasn't too bad. The 0805-size resistors and capacitors can be a bit fiddly to work by hand, but they're still manageable. In all, it just took a couple hours to put together the first test board.

It fits in my SE with plenty of clearance between it and the floppy drive cages.

So the big question is — does it work?

Of course not! What fun would that be?

First run attempt was just a garbled screen, and not even the infamous checkerboard pattern. I didn't expect it to be fully functional at first attempt, but that pattern is a new one.

Time for the logic analyzer.

I can see the hand-off working. The accelerator asserts the Bus Request signal to take the SE 68000 off the bus, and waits for the Bus Grant signal in response. Once the 68000 is off the bus, the 68030 is brought out of reset and allowed to take over. That much worked as expected.

Next thing to look at is whether the 68030 is starting up properly. The first thing it's going to do is load the initial startup vector and stack pointer from ROM. These are 32-bit values, so each will take two access cycles over the 16-bit SE bus. It was getting stuck on these initial read cycles, waiting for a bus termination signal

The 68k processor family has a great asynchronous bus that relies on peripherals providing an appropriate bus cycle termination signal. Macintosh computers generate the termination signal synchronous to the system clock. What I found was the faster 68030 (running at 12MHz for testing) was sometimes ending one cycle and starting the next within a single clock pulse of the main 8MHz SE clock. The SE motherboard logic never saw the new CPU cycle begin.

My first draft of logic was largely asynchronous, and paid little attention to the system clock. But since the SE motherboard logic is synchronous and expecting 68000 bus cycles, I need my logic to better emulate 68000 bus cycles.

So I rewrote nearly all of the logic for the CPLD to roughly emulate 68000 bus cycles.

Never thought I'd be happy to see a Sad Mac error. That error means the 68030 is running enough code for the initial ROM checksum to fail. That's quite an improvement over not even loading the initial vectors.

I've got a long way to go on this project, but it's looking promising. Running any code at all is a great sign. I can already see a the next few logic bugs that need to be addressed, and I've found a few hardware bugs that'll need bodge wires.

[bak3lite]