#VCFSW

[techav]

Stepping Backwards a Bit (or 24)

I was looking for a simpler project. My recent 68030 work has been challenging and really pushing the limits of what I can do. I wanted something I could work on, but perhaps where someone else has already worked out the hardest parts.

I find laying out PCBs to be rather relaxing. It's one of those repetitive, almost meditative tasks, like needlepoint or whittling. The kind of hobby where I can turn on some music or a comfortable old TV show, zone out for a few hours, and wake up to this new thing that I created.

Debugging however is very mentally taxing, and the design work required to have a functional schematic to create a PCB for is an active whole-mind prices. So what I really needed was an existing project I could design a board for.

Enter [Grant Searle]. If you're not familiar with [Grant Searle], he has excellent designs for breadboard computers with a very minimal parts count. I studied his minimal Z80 design when I was first starting to build my own computers and learned a lot from it. I highly recommend his work for anyone who is interested in learning how to build their own computer but doesn't know where to start.

I was recently given a Rockwell 6502 CPU pulled from a dead LED marquee. I've never actually worked with 6502, so this seemed like a good time to try building Grant's 8-chip (or 7-chip) 6502 computer.

A few hours later, I had a PCB design completed, gerbers generated, and an order placed. Less than $5 for 5 boards, including shipping. A couple weeks later they arrived in the mail.

I did end up making a few modifications to [Grant]'s design. Instead of a clock circuit made from a discrete crystal and a couple inverter gates, I used a TTL oscillator because I've always found them to be more reliable. I also added support for an FTDI USB Serial adapter chip so that the board can be used with a modern computer as a terminal. And finally, since a PCB is much harder to add new components to relative to a solderless breadboard, I added an expansion header. All of it wrapped up in a compact PCB with lots of helpful silkscreen marking.

I realized after I had ordered the PCBs that the 16kB ROM chips [Grant] used are no longer manufactured or readily available. I have plenty of 8kB EEPROM chips on hand however. Thankfully the OSI BASIC interpreter [Grant] ported to this design fits within 8kB, so I was able to make a few adjustments and re-assemble it to work with the ROM chips I have on hand.

After a small glitch with my EEPROM programmer, it works!

It's quite a change going from my 33MHz+ 68030 to this tiny 6502 running at just under 2MHz. The BASIC text-based Mandelbrot renderer that completes in seconds on my 68030 takes four and a half minutes on the 6502. Not bad at all, considering my bus-impaired 68000 build takes 9 minutes to do the same.

This was a fun little project. It was a nice little break from some of the more difficult projects I've been working on. I have shared the project on GitHub for anyone who might want to take a look.

I hope to have this project with me this weekend, June 14-16, 2024 at Vintage Computer Festival Southwest. I'll be at table 207 in the Tandy Assemble hall, just across the street from the main exhibit hall.

[commodorez]

Updated! Upcoming Vintage Computer Festivals

Do you like vintage computers, and want to interact with the community at large? Well, here are the upcoming VCF events for the United States in 2023:

Vintage Computer Festival Southwest: June 23, 24, & 25 - Davidson-Gundy Alumni Center at UT, Dallas, TX https://www.vcfsw.org/. This one is returning after about a decade, and is being organized by a new team of people. Vintage Computer Festival Southeast: July 28, 29, & 30 - Marriott Renaissance Waverly, Atlanta, GA - https://vcfed.org/events/otherevents/vintage-computer-festival-southeast/. Part of the Southern Fried Gaming Expo.

Vintage Computer Festival West: Tentatively, August 4 & 5 - The Computer History Museum, Mountain View, CA - https://vcfed.org/events/vintage-computer-festival-west/ Note: event will happen Friday and Saturday this year, due to a scheduling conflict on Sunday.

Vintage Computer Festival Midwest: September 9 & 10 - Waterford Banquet & Conference Center, Elmhurst, IL - https://vcfmw.org/

That's a VCF every month for the next 4 month!

[piflnoso]

Have fun at VCFSW! Dont forget to take pictures.

I recommend checking out Usagi Electic, techav, Nybbles and Bytes, and Forgotten Machines' exhibits in particular. Tell 'em Z sent ya!

Thanks for the message! I didn't check Tumblr notifications again until now, but I did have a blast at VCF. I didn't get many pictures myself, but my husband got a bunch!

[themiserychic]

Have fun at VCFSW! Dont forget to take pictures.

I recommend checking out Usagi Electic, techav, Nybbles and Bytes, and Forgotten Machines' exhibits in particular. Tell 'em Z sent ya!

thank! I didn’t actually know about it until a friend told me there was a MiniDisc con(!) happening at the same event.

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

Join me at VCF Southwest, the 23rd though the 25th of June, 2023.

[techav]

Wrap030-ATX Remembers

No general-purpose computer will do much without a good amount of Random Access Memory for transient storage of code and data. Now that I have confirmed basic operation of CPU, bus controller, ROM, and serial, it's time to turn my attention to main system memory.

Every homebrew computer I've built to date, including previous iterations of the Wrap030 project, has used Static RAM. Static RAM is nearly as simple as peripherals can be — give it an address, assert a Chip Enable and a Read or Write strobe signal, wait a bit, and release. Done, cycle complete. If you don't need to retrieve some data for a good long while, it's no matter so long as the chip still has power. For a small system, SRAM is reliable and dead simple to use.

The problem with SRAM is it is also very expensive. The 2MB of SRAM I had on the previous iteration of Wrap030 cost over $20 — and it's still far from enough to run an operating system like Unix System V, NetBSD, Linux, etc. This is the reason computers generally use Dynamic RAM for primary system memory.

The difference is SRAM uses several transistors to create a flip-flop for storing each and every bit of memory, whereas DRAM uses a capacitor to store each bit of memory. This reduces manufacturing costs and increases storage density, but does come with some trade-offs. Most notably, the capacitors that store bits in DRAM will lose their charge — and the stored data with it — after a rather brief period of time. This means the DRAM capacitors need to be topped off regularly in a process known as a refresh cycle.

Another complication of using DRAM is the bus interface has been changed to allow much larger storage capacities without the physical chip package growing to absurd sizes. Instead of the chip accepting the entire address at once, it expects to be given a Row address (along with a Row Address Strobe [RAS#]) then a Column address (along with a Column Address Strobe [CAS#]), with myriad specific timing requirements for when each signal should be asserted and deasserted.

In short, DRAM is much more difficult to interface with compared to SRAM, so I've never really gotten around to it.

With one of the long term goals of this project being running a *nix operating system though, I'm going to need the larger memory that DRAM affords. So i made provision for a CPLD to serve as a dedicated DRAM controller on the Wrap030-ATX motherboard and added a couple 72-pin SIMM slots. In theory this setup should be able to support up to 256MB of RAM (if rare 128MB SIMMs should fall into my hands...).

So where do we turn when dealing with complicated timing with multiple modes and a bunch of I/O? Why, Finite State Machines, of course! That bit where the DRAM expects a row address for a little while, that's a state. And the following bit where the DRAM expects a column address is another state. And then another state to make sure the DRAM has enough time to write or fetch the data. The round it out with one last state to tell the CPU data is ready.

What about that weird refresh timing? Well, that's just few more states for the state machine. And then one last "idle" state that waits for a refresh timing counter to hit 0 or for the CPU to start a bus cycle. Laid out like that, the DRAM controller became a state machine with 7 or 8 states, a counter, and an address multiplexer.

The logic actually came together easier than expected. Not completely without bugs of course.

There's this note in the datasheets about startup initialization where the DRAM should not be accessed 200μs after power on, and there should be 8 refresh cycles before the first access. Initially I had built this entire sequence into my logic. It consumed a ton of resources and didn't really work right.

I realized that my reset circuit held the CPU in reset for longer than 200μs on power on, so I was guaranteed that first initialization time. So I removed that startup delay from my DRAM controller logic, and made a few tweaks to the state machine so it could do 8 back-to-back refresh cycles after reset.

I was able to successfully write to DRAM and read that data back!

That much proved to be the easy part. The next steps were confirming DRAM accesses worked reliably, that I had the order of my byte select signals correct, that I could identify the amount of installed memory, and that all of the installed memory was working. These are programming problems, not logic problems, and I am not a strong programmer. On top of that, not only am I working with unproven DRAM logic, but I'm also using untested SIMMs that I had picked up from Computer Reset.

I quickly ran into errors, but was it a problem with my logic? A problem with my timing? A problem with the SIMMs?

I had a large back of 72-pin SIMMs, split fairly evenly between Fast Page Mode (FPM) and Extended Data Output (EDO) types. I tried them all. Some would pass the tests for nearly all addresses but fail at the end. Some seemed to have a stuck bit. Some were just plain bad and gave errors everywhere. It didn't really answer the question about whether my logic was bad, but results were consistent enough for me to think that maybe the logic might be ok.

And then finally I came across a pair of HP-branded 8MB EDO SIMMs that passed a simple write-read test without error ...

... right around the time my serial port stopped working. But the memory test was passing, and I could at least see the serial output on the logic analyzer.

The serial port problem was a bit setback. It had been working but suddenly wasn't. Clearly the UART itself was working, I just wasn't getting anything past the level shifter. Well that at least gave me a starting point of where to look. Sure enough, one of the 12V supply pins was not well soldered. Thankfully a quick fix.

Back to testing memory, I started writing a program to identify the size of the installed SIMM and write a register I added to the DRAM controller to configure the specific geometry of the installed memory. See, DRAM has another lovely quirk — chips of the same size may have a different configuration of Row and Column sizes. For instance one chip may have a 9-bit Column and a 10-bit Row, but the next may have a 10-bit Column and a 9-bit Row, and both are the same size. If the DRAM controller just assumes 12-bit Row and Column (the largest supported by 72-pin SIMMs), then there will be gaps in the memory map that will need to be accounted for in software (using MMU, for example). If the DRAM controller knows the geometry of the installed memory, then it can present the memory to the CPU as one contiguous block of memory.

And that's where I found my next bug. The system would just hang when trying to write to that DRAM controller configuration register.

... because I had forgotten to complete that part of the state machine. The result was the state machine would end up in a state for writing to the configuration register, but then it couldn't get out of it. Once I added the missing condition to the state machine logic I was able to correctly identify the geometry and size for my installed memory!

Wow that was long. This has been the biggest, most involved step in the process of bringing up this computer yet. It turns out there are a lot of moving pieces that have to all work together to get the computer running code from ROM and reading/writing DRAM.

Now that I have my main memory working, I should be able to get some software running. I'm hoping to at least have BASIC running in time for VCFSW at the end of June.

[commodorez]

Vintage Computer Festival Southwest - June 23rd-25th

I'll be exhibiting "VICs that are not 20", focusing on more of the oddball VIC-20 stuff in my collection.

If you're there, I'm not hard to find -- just look for the derby hat. I'll have Retrotech Crew stickers and pins. @techav and @ms-dos5 will be there too!

Davidson-Gundy Alumni Center University of Texas at Dallas 800 W Campbell Rd Richardson, TX 75080

More info at vcfsw.org

[techav]

Wrap030-ATX Does Something Useful, Runs BASIC

This is it. This is was my goal, where I was hoping to be in time for VCF-Southwest at the end of this month — my Wrap030-ATX project is running the TSMON monitor from ROM; the monitor is loading BASIC from ROM into RAM; and BASIC is running programs.

I did run into a few problems getting BASIC running because of all the modifications I've made to it over the years for my 68000 project and the earlier iterations of the Wrap030 project (most problematic being my attempt to modify it to use the FPU).

So I went back and grabbed a fresh copy of the source to work from. I converted the syntax from VASM to GNU AS, swapped out the M6850 ACIA UART routines for new ones using the 16c550 UART, and updated the addresses in the program and my linker script for the Wrap030-ATX memory map. It took a few tries to get it running, but I think the results really speak for themselves.

Now that I've met my minimum goal ahead of VCFSW, everything else is extra. I do want to see if I can get the FPU and my video generator working.

[techav]

The Amputated Franken-Plus

Last year I revived an old Mac Plus that had been destructively robbed for parts over the years. I added sockets for the chips that had been removed, gave it a new power supply, added my SE-VGA card for video, and bodged a few broken traces. But there still remained the most heinously destructive part removal that had been committed against this poor board ...

Long before I had mastery of a soldering iron, and lacking the proper tools for desoldering components successfully, I had a project where I needed n 8-pin mini DIN connector. I had this non-functional Mac Plus board gathering dust so I decided to remove one of its connectors. With a knife. By cutting the board around the connector.

I was young ...

Obviously, there's no repairing that. The board has a permanent chunk removed from it.

However, I find myself wanting to be able to use those serial ports now that I have the rest of the board running. There are lots of fun things to use them for, like LocalTalk networking, printers, zTerm, etc.

So I set out to build a breakout board to add the connectors for these serial ports back to the board. I started by digging up datasheets for the RS-422 & RS-232 transceivers Apple used, as well as schematics for the Plus and similar era Macs so I could trace out how the connectors were originally wired. It turns out all of the signals for both ports are routed to some RC filters in a straight line at the back of the board. This made it fairly easy to solder a ribbon cable to the filter pins on the back side of the board.

I've come to like ribbon cables; they're easy to work with. I can just crimp an IDC connector on one end and attach them to some pin headers. The breakout board itself is just some generic protoboard, and has said pin headers and two female 8-pin mini-DIN connectors.

It's not ideal. The ribbon cable wires are fragile and cold easily be pulled off the motherboard. But hopefully this will restore the last lost functionally for this poor tortured Mac Plus motherboard.

I plan to include the Franken-Plus in my exhibit for VCF Southwest in Richardson, Texas this weekend (23-25 June 2023). If you're in the area, definitely stop by; it's shaping up to be a great show.

[techav]

A little preview of something I've been working on the past couple weeks:

A lot of firsts in this project — my first time using assembly service, the largest PCB I've ever ordered, the longest BOM, the most complex schematic ... Basically, it is the culmination of many years of work all brought together.

But speaking of firsts ...

My goal is to have this project at least partially functional and ready to show off at VCF Southwest in June. This will be my first VCF show, and it's the first VCF Southwest show in over a decade. It's shaping up to be a great show and I am excited to be a part of it. I've already reserved my exhibitor table.

[techav]

Come find me tomorrow and this weekend at Vintage Computer Festival Southwest in the UT-Dallas Davidson-Gundy Alumni Center in Richardson, Texas. I'll be exhibiting some of my homebrew projects featured here on this blog.

[techav]

Wrap030-ATX First Tests

The best place to start with assembling and testing a board like this is the power supply. If there's a catastrophic error, like a direct short between supply rails, it's best to find out before wasting other components. Thankfully on this project, I'm using a standard PC power supply so all I need is some basic filtering capacitors. Not much to screw up there except maybe some backwards electrolytics.

Next is generally reset and CPU clock. These are essential for getting the CPU up and running and should be confirmed operational before continuing. Here again I'm using stock modular components — a brownout reset signal generator and a can oscillator — so debugging was minimal.

Finally, the CPU should be tested with these signals to see if it will free run (tie the CPU data bus to a known value, usually something like 0b00000000, and watching to see if the address bus increments freely).

The CPU free run test is an important one. It confirms the most basic functions of the board and the CPU are functional. A board that can't free run at this stage likely has some significant problem that must be solved before anything else will work.

Luckily, it passed this test!

I used the data bus transceiver sockets to attach test wires to, so I could tie all the data bus signals low. On the 68k architecture, $0000,0000 corresponds to the instruction ORI.b #0,D0 which is a 16-bit opcode ($0000) for an OR instruction followed by an immediate constant word ($0000). So for every 32-bit bus access, the CPU is fetching one complete instruction, incrementing the Program Counter by 4, then repeating. The result of the instruction is stored in the D0 register, so nothing is ever written to the bus.

This behaviour can be confirmed with a logic analyzer, but it's easiest to visualize by connecting LEDs to some of the higher address bits and watching them count up in binary (which is what I did here).

On the 68030 there is a bit more to do than just grounding the data bus. In particular, the CPU's asynchronous bus expects peripherals to report they are ready and have placed valid data on the bus by asserting the Data Strobe Acknowledge signals (DSACKn#). In normal operation, the system will delay asserting these signals to give the peripheral device enough time to do its job, signalling the CPU to insert wait states until the data is ready. For free run though, these signals can be tied low to signal to the CPU that the data it's requesting (all 0s) is ready immediately (because the data bus is tied to ground).

Here is where a last-minute addition to my PCB layout really came in handy. I removed the solder mask on these small sections of important signal traces so I would have a clear place to probe these signals on the top of the board. This also gave me just enough room to solder some 30 gauge wire to the DSACKn# and address signals for running the free run test.

Now that I know the most basic functions of the board are working, I can move on to the next step — running first code. To run real code I'll need ROM working, which will also require the bus controller CPLD to be minimally functional.

I am hoping to have this project at least running BASIC in time to exhibit it at VCF Southwest in Dallas at the end of June this year. I've got a lot of work still to do to reach that goal, but passing these first tests does give me hope that there are no huge show-stopping problems with my PCB (at least nothing that can't be worked around with a bodge wire or two)

[commodorez]

will you be going to vcf southwest?

That's the current plan, yes. It's going to be one hell of a drive, but I want to help the revived VCFSW get started. I'll be exhibiting my rarer VIC-20s, including my prototype machines and Japanese VIC-1001.

[commodorez]

VICs that are not 20

My exhibit at Vintage Computer Festival Southwest 2023 went well. It was a major lift to drive it all out to Texas in summer, but the results were worth it. I got to meet a whole different group of the vintage computer community, and share my esoteric VICs with them. Seems like alot of people enjoyed talking with me, trying out the games, and even programming in BASIC. My exhibit even won the award for Best Microcomputer.

Items on display included:

Rainbow label VIC-20

Early American VIC-20

Japanese VIC-1001

Prototype VIC-20 aka the "Brown Board"

Prototype 16K VIC-20 plus a variety of expansions, peripherals, and software. I filled my trunk to the brim with items for my exhibit.

Special thanks go out to @ms-dos5 for helping with setup and breakdown of my exhibit, as well as demonstrating many of my exhibit machines by playing some of the supplied video games. I was glad to finally meet @techav who had the table next to mine, keeping extra sets of eyes on each others tables throughout the weekend.

[commodorez]

@techav's exhibit next to my exhibit at VCF Southwest 2023