Cactus: 6502 Homebrew Computer
The Project:  Motivations  Specifications  Current Focus
              Front Panel Logic  Cards
Events:       VCF East XIII  VCF West XIII  DEFCON 26  VCF Midwest 13
              VCF East XIV  VCF West XIV  VCF Midwest 14
The Future:   Want a Cactus?

Cactus Project Logs

Contained here are various posts I've recorded as I've worked on the Cactus. Progress has sometimes been slow and frustrating, but I think it's important to show that it's not all gravy. One of the reasons I gravitated towards Quinn Dunki's Veronica was that she showed that the designing and building of a computer from scratch was not necessarily a linear one. Setbacks and mistakes happen, and not everyone is going to get it right the first time around. If anything, it made the challenge feel all the more attainable because perfection was no longer expected. So that means I could make my own computer.

Fair warning, my language contained within is not censored. It is also missing images that initially went with all of the posts, but that wasn't well-archived.


June 5, 2024
The new Cactus Integrated SBC has arrived, and is being assembled and debugged. The new board has a few faults to work out, but I'll figure it out soon enough. So far, there are atleast 7 changes to be made to it. The front panel PCB has yet to be ordered, I want to check a few more things before that's sent off, as it's not going to be a cheap board to manufacture and I'd rather not take any changes.

I've also designed a simple video card, based on the OSI-440/600, which I intend to test sooner than later. It's not going to be pretty or high resolution, but it's a start. I have not included any provisions for a parallel keyboard input at this time. I've got a few ideas I'd like to add to the base design before I consider it viable, but I haven't yet decided which ones will be implemented, and which will be shelved.


Late May, 2024
Finally making progress again! KiCad PCB design has been progressing on a few boards. The first is a switch fitment test board. The second boards is a first prototype of a consolidated front panel PCB. This board combines the functionality of the Data Control Card, Address Control Card, Status Control Card, Front Panel I/O card, and Address Debug Card into a single board, plus omits all of the cable harnesses present on the prototype. The layout is finished, pending satisfactory tests from the fitment PCB. The third board is another attempt at a combined CPU/RAM/ROM/serial board to pair with the front panel PCB. Circuit design has been completed to incorporate features and bug fixes from the prototype, and layout is in progress. The latter two cards should be compatible with the prototype's bus configuration.


- 2021 -


March 9th, 2021
Cactus interface card improvements:

C-35 to Glitchbus adapter glue logic updates

SAA-1099 sound card audio jack installation


- 2020 -


March, 2020
I've built an 8K FeRAM board from, you guessed it, a Glitch supplied component. It's the first to use a new variety of address latching and read/write qualifying circuit, which has the unfortunate side effect of not being compatible with the front panel logic. This means that while the CPU can use the FeRAM just fine, when the front panel takes over, it fails to correctly latch an address to read the contents. I intend to modify the front panel to maintain compatibility before long.

I've also constructed an adapter card to bridge the C-35 bus with Glitchbus. The idea is hopefully use existing Glitchbus expansion boards witthout any hardware modification. I'm actively debugging this circuit, and attempting to control an 8255 parallel I/O board.

For the past 2 months years, I've been procrastinating on improving my first PCB layout containing the core elements of the Cactus. The first run has demonstrated a few problems, but taught me alot about the process of PCB design. With the help of experienced friends, I'm improveming the design to create a more robust and expandable design than my first attempt. The final result will eventually be ready for distribution, but we're nowhere near ready for that just yet.

An optimized, condensed version of the front panel logic has been digitized and is moving toward the layout stage as well, but that board is even farther off. Glitch has been given one of my first generation built it up to a functional state, pointing out where I can improve.

I've given up on the 6551 serial card experiments for now. I've also continued testing with the new C-35 backplane, which thus far has been performing just fine. I was working on modifying the serial card for interupts, and the software to take advantage of that. Reason being, every time I dump BASIC programs or pre-assembled programs in over serial, I usually have to crank down the speed at which data is passed. BASIC in particular takes too long to tokenize complex statements, and so the beginnings of new lines get overwritten if I haven't added upwards of 75ms of delay per line. Rather than hard-code a delay, I would rather the software be able to slow down the data flow dynamically to minimize delay per line. Figuring out how is going to take time.

I've ported an extended version of WOZMON to work on the Cactus with the help of my friend, TangentDelta. It currently works with the 6850 serial card and it's nice to finally have a monitor.


- 2019 -


October 9th, 2019
The Cactus running ZNEK at Vintage Computer Festival Midwest 14


August 25th, 2019
Sometimes I think about the progress of the Cactus, and how I go through bursts of disillusionment, or I focus on something else and donít want to work on it. I eventually come back to it, sure. Disregarding those breaks, and compounding together all of the time I actually spend focused on the project, Iím aware of just how much longer it takes me to accomplish any of the milestones.

I look at other, more skilled, experienced, or younger and more productive vintage computer hobbyists and homebrewers and think about how much time it would take them to reach the same points I have. How much faster they could get through the stages of development. A few would have produced a viable product for market in a few months, or perhaps weeks rather than the years Iíve taken.

You know what? That really isnít the point of making it. Itís been for me to learn about these concepts. To explore the process of building and designing a machine and constructing it using primarily methods and components that would be right at home in the 1970s homebrew computer scene. Something that could have been brought into the homebrew computer club and not looked out of place or anachronistic. But more importantly just to let me do it all at my own pace and time.

Itís my computer, and Iím not beholden to someone elseís standards of progress. Iím building it my way, piece by piece, wire by wire.


August 16th, 2019
VCF West 2019! MOnSter Cactus 2: Revengence!

Last year, I got to connect the Cactus to the MOnSter 6502. You know, this thing?

Well this year it was a plug-&-play deal, no messing around with breadboards and jumper wires. We bolted one of the two MOnSterís on display at Ericís table into my homebrew, and started computing right away. We ran BASIC, EWOZMON, a

larson scanner, kill-the-bit, and a few other brief experiments. I had a blast!


July 18th, 2019
Look at these beautiful timing waveforms on the Cactus, as I debug the 6551 serial card. That last one is kinda fucky though.


July 16th, 2019
Back to debugging the busted 6551 card on the Cactus. So far not so good. Try as I might, my 4 channel analog scope is not a suitable stand-in for a large logic analyzer.


June 2nd, 2019
With the help of a friend, I was able to port and assemble extended wozmon to the Cactus. A ROM monitor is something Iíve needed for quite awhile, so itís good to finally have that capability. It includes some serial transfer routines which will cut down on development time.

Now that I have cc65 installed, I should try writing some C for the Cactus.


May 24th, 2019
Behold, the Cactusís fancy new software front panel I/O card. It grantís the CPU access to both a bank of 8 front panel LEDs and the status of the 8-front panel flip flops. It also replaces the glue logic that controls the data control card.


May 1st, 2019
New CMOS CPU card for the Cactus


March 29th, 2019
You have no idea how much I want to throw a certain Sony 32K SRAM chip out the window for crimes against cactuses.


March 26th, 2019
Data Control Card Mk. II


March 19, 2019
Data Control card mk II prototyping.


March 1st, 2019
Yeah, Iím still working on the Cactus. Slowly.

Today with a bit of help from @spinneretsystems, I found a wiring fault from when I assembled an experimental mezzanine board to fix the Status Control card. It adds in a one-shot circuit using a D flip-flop to make sure every key press of Examine, Examine Next, and Deposit Next is captured by the logic chain and follows through to completion. So many times, I witnessed ignored key presses, which drove me up the wall.

Itís re-introduced another problem where the clear signal is failing to zero out the registers in the data control card. Now I have to figure out why.


- 2018 -


November 27th, 2018
That is precisely what is happening.

When the CPU is halted, the HALT state permits a series of tri-state buffers on the status control card to close, taking control of certain status signals on the bus from the CPU. The result is that the Phi2 line feeding devices a master clock from the CPU is pulled high, and this is intentional. The RAM and ROM are unreadable during the low portions of the clock cycle. Thus, the clock needs to be locked high for front panel DMA to work.

The problem comes from the single clock pulse that is sent during single step operation. The clock never gets a chance to go low!

It all makes sense now.

I just have to put something between the Step switch and the Step side of the source selector that will cycle low then high ONCE.


November 23rd, 2018
Wait...

What if this whole time, single step mode has been unable to send a complete clock pulse from the 6502 out to the bus. It would explain precisely why serial and parallel I/O fails during single step mode, but why is RAM unaffected? I bet the bus clock doesn't go low. The RAM responds when the clock is high. I need to throw the scope at it when I get home.


September 10th, 2018
The Cactus has a sound card

I built a crude card around an SAA-1099, which is what made the Game Blaster/Creative Music System a thing.

Sure, itís only playing random noises for testing for the moment, but I like what Iím hearing. It sounds like victory.


August 29th, 2018
HAHAHAHAHAHAHAHA

[Insert photo of the Cactus on IRC]


August 23rd, 2018
The Cactus is getting software controlled switches!

I wasnít sure how feasible it would be to bolt 6522 inputs to the outputs of the Data switches. Especially when I discovered that one of my buffers was incorrectly passing bits, causing the SET lines to drop below 5V when the CPU was active. Then I started rearranging things...

Iíve made a few fixes to the sequence generator on the Status Control card, and to the Data Control cardís clear functionality. Iíve added an additional CLEAR stage directly preceding the Load Data Bus signal. The result is a revised flip-flop clear circuit, and moving one buffer into a different part of the logic tree. Seems to have fixed the SET line voltage problem, and reduced the instances of malformed clear signals to the 8 flip flops

I really need to draw up digitized, revised schematics.

The first test shows that Iím getting proper input signals, so now all I have to do is add 8 additional pins to the Data Control card, and bring them over to the 6522 card. Then I need to write some assembly to play Kill The Bit, like all other classic front panel machines can do.


August 21st, 2018
I had the honor of connecting the Cactus to the MOnSter 6502 at VCF West XIII.

For those of you unfamiliar, the MOnSter 6502 is functional transistor-scale MOS 6502 replica. It uses 3218 transistors and 1019 resistors, plus quite a few LEDs to produce an amazing lightshow the likes of which the world has never seen before. You can observe the inner machinations of the microprocessor at work and really get a sense of whatís going on at the die level. The MOnSter had only been run with designs specifically tailored to itís unique limitation: speed. It can only run at a maximum of 60KHz, with 50KHz being the more ideal clock rate to my understanding. This means that many 6502 computers simply canít use the MOnSter due to dependencies on higher frequencies.

Eric Schlaepfer and I discussed the prospect of combining our projects in a brief abomination of science in the weeks leading up to VCF West. I set to work building a board that would work specifically with the NMOS parts, adding in additional buffers to account for the lack of a Bus Enable pin. I wasnít sure if it would work -- I tend to miss something in my designs.

We had our first integration attempt on Saturday, using my dedicated NMOS CPU board for the Cactus. There was bus contention on the R/W line causing issues, so we had to abort and I had to think of a way to solve the issue with my minimal kit of parts.

The next day, Eric supplied me with a breadboard, some jumper wires, and a few parts (namely tri-state buffers) from which I could cobble together a fix for the R/W line bus contention. A test run with an original Commodore NMOS 6502 at 50KHz proved that I had fixed the problem, so we hooked in the MOnSter and turned on the power. Success! We got a BASIC prompt!

The Cactus is the first third-party computer to use the MOnSter successfully, and the third machine overall to run with it. BASIC ran really slowly, but it was fun to watch how much processing occurs each time the enter key is pressed when entering text. Blinkenlights of this scale have probably not been seen in computing since an IBM System/360 Model 91 was in service last.

Thank you Eric for working with me to create the quick fix that made this Frankensteinian abomination possible. And a thank you to Lenore and Windell of Evil Mad Scientist Laboratories for putting up with my goofiness.

This was a fun experiment that I consider the highlight of VCF West for me.


August 20th, 2018
I exhibited the Cactus at VCF West on August 4th & 5th in Mountain View California, at the Computer History Museum.

A few weeks prior to the show, I discovered that the MOnSter 6502 would be in attendance, along with the good folks at Evil Mad Scientist Laboratories. I reached out to its creator, Eric Schlaepfer, and asked if he would be willing to combine our two machines in an experiment. He was interested, letting me know that as long as I adhered to the NMOS specification and clocked down to 50KHz, the two should be able to work together. Normally, the Cactus relies on the 65C02's Bus Enable pin to halt the CPU and allow the front panel logic to take over to provide the user with direct memory access. I built a new processor card with additional buffers to account for the lack of such a pin on the NMOS variant, and tested it with an original Commodore 6502 from 1983.

Once at VCF West, our first attempt on Saturday pointed out that I had neglected to buffer the Read/Write line, resulting in bus contention. On Sunday, Eric brought me a breadboard, some additional jumper wires, and a few tristate buffers from his stockpile. After splicing an additional 74LS245 into the NMOS card, and testing with an NMOS 6502, we decided to try again. Lo and behold, the Cactus and the MOnSter 6502 successfully booted into BASIC, and ran at 50KHz for about half an hour, creating a spectacular fusion of blinkenlights. That makes the Cactus the third machine to use the MOnSter 6502, and the first one that wasn't made by Eric. Needless to say, this was the highlight of my weekend.


August 6th, 2018
VCF West XIII Closing Thoughts

This weekend was pure awesome. Today in particular.

I met Jeri Ellsworth for the first time since I was 16. She's an absolute wizard.

I played Space War on a PDP-1 computer.

I took a picture with Jason Scott and the Cactus. That guy is a legend, and the fact that he knows about me and my work is oh so nice to know.

I ran into Brian Benchoff of Hackaday, and finally got to show him my computer. He digs it. Even made a SECOND Hackaday post on it. Nice.

I got to meet Marc of Curious Marc on youtube, and thank him for his efforts to share history.

I watched an IBM 1401 computer from 1959 run a program, where it took my name on a punch card and printed out a giant page with it on an IBM 1403 Line Printer.

I saw a real OSI-300 again, and was given massive diagrams & schematics by the guy who brought it to the show (who found it in his garage just to show me). That was really nice of him.

I saw a real Data General Nova on display. This is the machine that showed Woz that you could creatively cut down on hardware and achieve the same results. This concept was taken to heart with the Cactus. I kinda want one more than I did before.

I won second place for Best Demonstration.

Met alot of really nice people from parts of the community I had never interacted with before.

I talked kit building with Oscar Vermeullen, the guy responsible for the PiDP-8 and 11. He gave me good advice.

I met another former Commodore employee.

I managed to fix damage the Cactus incurred during transit using minimal parts and tools.

I scored the entire year of Byte magazine issues from 1977.

Erik Klein of the Vintage Computer Forums (among other things) was kind enough to lend me a Televideo 910 terminal to use while I was at the show. It worked great!

A robot is delivered me oreos in my hotel room.

But the best thing of all? Eric Schlaepfer and I combined the MOnSter 6502 and the Cactus.

That's right. It's now the third machine to interface with the MOnSter, and the only computer not made by Eric himself to run his processor. I was honored to have the experience. The Cactus had a special NMOS board constructed just for this situation, which required minimal tweaking to get it to work right. We ran it at 50KHz for about 20 minutes - pictures are coming.


July 25th, 2018
Two for one upgrade special!

The 6551 board works now! And the improved 6522 board helped me get there. I was able to dump the contents of the ACIAís status register to a bank of LEDs on a little breadboard, and see where the fault was. Invaluable! So I decided to give it a more permanent home on some protoboard, with its own little header. I have it running a Larson Scanner program in BASIC as we speak!

Iíve spent alot of time writing 6502 assembler, and programming with the front panel to test all of this fun new hardware. Iím starting to feel more comfortable with this language. I was able to modify Grantís serial routines for the 6850 to work with the 6551, which includes different register locations, bitmask adjustments for reading the status of stuff, and new chip initialization statements. Iím surprised it worked -- on the first try too! But I have a long way to go before Iím remotely proficient.

Adios, 6850 board.


July 23rd, 2018
The 6551 has fought me at every turn while I work through the process of wiring it up and testing it. But the 6522 is playing nice, and using it as a status register readout has helped me figure out where Iím screwing things up. Turns out Iíve had a few pins incorrectly connected on this new serial card. But hey, it works now.


July 20th, 2018
For too long now, itís been a pain to debug cards on the bus of the Cactus, due to them being packed in tightly. I decided it was time to throw together a right angle bus adapter to save myself some trouble. Itís a bit of a hack, but it works.


July 20th, 2018
I really like using the Cactusí front panel interface. You would think it gets tedious, but I think itís fun!


July 18th, 2018
Iím finally working on the third generation serial card for the Cactus.

The goal is to have two 6551 ACIAís with onboard MAX232 level conversion.

Below is the card it aims to replace, using a single 6850 that has in internal baud rate circuitry, and relies entirely upon external frequency dividers for precise baud selection. Jumpers will be replaced with software.


July 14th, 2018
Itís a bout time the Cactus got something new. This time, itís a simple parallel I/O card, using a 65C22 Versatile Interface Adapter. Right now, only the A port is wired to anything, and for the moment itís hooked into an external LED for testing.

Whatís it do? Blink. Thatís it.

But it does prove that the hardware is correctly operating, which is nice. Hereís the test code, if youíre interested. Special thanks to techav for helping me wrap my head around some of the instructions.


July 13th, 2018
Vintage Computer Festival West 13

I will be exhibiting the Cactus at VCF West on August 4th & 5th in Mountain View California, at the Computer History Museum. Feel free to come and try your hand at using the front panel, or perhaps program in BASIC. This will be my first time at VCF West, which means flying the Cactus cross-country.

DEFCON 26 Hardware Hacking Village

I will be giving a talk & demonstration at the DEFCON 26 HHV at 4PM on August 11th, in Las Vegas Nevada at Caesers Palace. Come learn about the Cactus, the machines that influenced it, and the build process. Attendees will be free to try the machine for themselves after the formal talk.


June 17th, 2018
I keep getting asked by people ďwhere did you get your switches [for the cactus]Ē? Theyíre talking about the big colorful paddle switches. The short answer is electronic goldmine, and I bought out the remainder of their surplus. All 19 switches!

It turns out that while they do make that type of 7000 series switch, the J4 and J5 paddles (either of which would be acceptable for cactus use) havenít been in production for a very long time. Thatís why theyíre so hard to find. The good news is that NKK decided to start manufacturing a direct replacement for that switch/paddle combination.

From left to right: C&K turkey switch C&K 7205 dual momentary switch with the elusive discontinued J4 paddle NKK M2018 dual momentary switch with H paddle designed to replace the C&K TEC Inc. 1201 toggle switch DPDT NKK M2012 toggle switch DPST

Switches are expensive, and they make so many different variations on what outwardly appear to be identical. Good quality, well-suited switches for a task are worth the time to research. Fun fact, the NKK M2018's are clickier than their C&K counterparts.


June 6th, 2018
Iím hitting a motivational rut, and Iíve got to get out of it soon.

Thereís potential for at least one, if not three different events this year where I would have to bring the Cactus long distances. That means flying. I want something more polished by then, and that means moving on to custom PCBs, a metal front panel, etc.

I need to do the following before then:

Fix the single step issue by adding a riser board to status control and one more logic gate section to the CPU board. Build a new serial board for the 6550 UART and program for it accordingly Write up the current generation schematics Make PCBs of the critical finished boards and order them. Select new switches because the current ones are 7205's are unobtainium with the J4 and J5 series paddles. Design and order a front panel to accommodate the changes Program something worth playing during demonstrations Write the ROM monitor

Iím... not making the progress I need to right now. I need to fix that.


June 4th, 2018
Cactus development over some french toast. I'm determined to figure out single step.


June 2nd, 2018
Iím waiting on a few parts before I continue work on the Cactus.

I thought I had single step worked out, and while Iíve fixed the bus arbitration issues, I havenít gotten the clock pulsing right. Itís lead me to think about how clock control is handled for the Cactus. I want to add in more options:

Run (full speed) Step (user = clock) Slow (adjustable rate 555 timer)

Iíve scored a cassette player for program storage, but I need to build a proper interface for it. Thatís where those parts en route come in.


May 26th, 2018
I figured out why the Cactus was acting funny. I had my front panel ribbon cables switched between two cards. Thus, it acting funny.

I can hit the single step switch, and the bus arbitration issues are solved, but the single clock pulse doesnít seem to operate the way I expected. I have a hunch, but nothing substantial yet.


May 25th, 2018
Note to self: check Phi2 during single step mode. Five bucks says that it is not correctly cycling between low and high, and thus the 6502 is not treating it as a complete clock cycle.


May 24th, 2018
I feel like Iím so close to getting the Cactusís single-step working...

Before I get back to VCF East XIII photos, first letís see what I waited to tackle until after the event was over. My concern was that I would start trying to fix the single step circuit, and break everything without enough time to rectify my changes before the event started. Iím glad I waited.

So it seems that my single step circuit has been very much wrong this whole time. I had several versions all on paper, and thinking I only had to change two bus signal lines to create distinct RUN/HALT and CPU ASSERT lines, Iíve proven that it really isnít that simple. Time to re-adjust, and connect the proper chip type, as well as make the functional circuitry match the diagrams.


May 14th, 2018
Non-Volatile RAM!

Iíve attached 2K of NVRAM to the RAM card. Anything stored there is battery backed to stay there, which is cool.


May 10th, 2018
No more masking tape!

I finished making the Cactus logo graphic, and ordered a brass nameplate to put on the case. Damn, that looks good.


May 2nd, 2018
Itís only taken a pile of paper, weeks of time and effort, plenty of research, and help from a handful of friends and acquaintances, but my homebrew 6502 build is in progress.

While the design is heavily based on Grant Searleís 8-chip 6502 computer design, with inspiration from Quinn Dunkiís Veronica, the front panel logic is very much original work. The result is going to be a colossal pile of wires

that may just be able to compute something. Time to get into the real serious assembly!

I wrote that a few months ago. Hereís the updated version:

It started out as an idea. Itís taken a pile of paper, months of time and effort, plenty of research, digital logic simulations, design revisions a-plenty, and help from a handful of friends, acquaintances, and strangers, countless failures, and the sacrifice of sleep to get this far. While the design is heavily based on Grant Searleís 8-chip 6502 computer design, with inspiration from Quinn Dunkiís Veronica as well as a slew of 1970s front panel interface designs, the front panel logic is very much my own original work. The result is a colossal pile of wires that may just be able to compute something useful. But it computes. The Cactus runs. There is so much room for improvement in both functionality and construction methods. The wire used is intended for wire wrap sockets, rather than being cut to length and soldered in place. However, this method of construction is time consuming. I would like to get boards manufactured but thatís a process that Iím not versed in -- yet. There are memory and I/O additions I would like to make, not to mention all kinds of useful software that needs to be written or ported. So much work to do...


April 30th, 2018
Cactus Updates!

#1: RS232 works well enough that the H89 considers it a viable signal

#2: A shipment of parts arrived a day early, so I replaced all of the remaining non-74HCT series logic. It also meant I got some stuff to play with like EEPROMs and a 2K NVRAM chip.

#3: I converted a copy of the text based lunar lander game for BASIC for my purposes. This game is brutal, I keep slamming into the lunar surface at high speed, or running out of fuel when I think Iím doing well... DAMN IT!


April 29th, 2018
Seems that I do have a functional RS232 to TTL adapter. Iíve hooked the Cactus up to my computer for easier serial interaction via PuTTY.

For fun, I wrote a little hex dump program just to see if I could. I should get to work on writing a ROM monitor in assembly, because this method is slow and tedious. Assembly is something I have very little practice in. Now that I have the Cactus running, I have no excuse not to learn it again.

I should totally play the classic text based lunar lander game.


April 28th, 2018
It works.

The Cactus now can run instructions from EPROM or entered into RAM via the front panel toggle switches. Not only that, it can run BASIC!

The R/W line has signal contention caused by the data control card not allowing the CPU to write back to memory. I rearranged some wires on the status control card, hoping to fix the issue and that did fix the issue of R/W not going low. However, there was alot of ringing on that signal line, as shown by the oscilloscope image. I added in a tri-state buffer that would go high-Z when the machine was set to RUN (and thus the 6502 was in charge). I also moved the pull-down segment around, and all the sudden, the CPU could write to memory. A test program showed that it could even run a simple program that deposited a value at a specific address. I didnít believe it. So I tried another program, this time toggled into RAM by hand, and it ran fine. Then I changed the values around, and it once again did what it was supposed to. I tried one more program, and... sure enough, memory was changing correctly.

So I played around with it for a bit before socketing the OSI BASIC EPROM and trying to run it through the serial line. It took a few attempts before I saw text. It responded to keyboard input, but it would incorrectly calculate available RAM before going into a loop. A few more experiments later, and I realized I could manually tell it 32K of RAM was available. Running programs in BASIC is feasible!

The Cactus is going to be ready for Vintage Computer Festival East XIII


Apr 28th, 2018
The Cactus just ran its first 3 programs correctly. One from EPROM, the other two from RAM. Iím in shock right now.


April 27th, 2018
The Cactus is running a few instructions! There is a catch though. The CPU canít seem to write back to the RAM.

I suspect the 7400 series chip that handles decoding the RAM address & read/write control is to blame. I canít confirm that at this time, but itís the best lead I have.

Right now Iím trying to run:
    A2 LDX
    05 0x05
    8E STX
    00 0x00
    00 0x00
    4C JMP
    00 0x00
    C0 0xC0
And the address lights seem to be staying in the correct address range, which is amazing. I tried a similar program, starting right at address 0x000, running from RAM instead of EPROM, and sure enough itís doing the same thing: staying in the address block that the code exists in, but failing to write a value into RAM.

Still, this is a MAJOR breakthrough. I have some 74HCT series chips en route that will hopefully solve this issue, but who knows fore certain. Hell yeah.


April 25th, 2018
Remember that breadboard 6502 computer implementation I put together some time ago as a test article? I soldered it down on a prototype board.

The idea was that I could socket it into the Cactusís CPU board, knowing that it was a self contained functioning unit, and see if I could interact with the bus through the DIP 40 socket. Nope. It didnít like that... It ran fine separately, and then I managed to break it.

Not sure what I did wrong, but I think I damaged the wiring. Iíve replaced all of the ICís, and Iím getting a steady clock signal so... oops. Now I have to figure out where I fucked up.

Still, enjoy a Mandelbrot set rendered in ASCII, generated from a 6502.


April 23rd, 2018
Iíve had a ROM card jumper set wrong this whole fucking time.


April 20th, 2018
Two steps forward, three steps back.

Swapped some chips, eliminated some gates, and hopefully alleviated a contention situation. Improved the front panel wiring to clean up some signal wires. I thought everything was making progress.

Examine and Examine Next arenít clearing the data control card flip-flops before moving on to the next byte, resulting in each byte being ORed with the previous ones seen.

Deposit keeps dumping 0x00 onto the bus for 0x01 through 0xFF.

Motherfucker.

Maybe I should put it back the way it was before, then make the modifications on the Status Control card instead... There are many ways to theoretically solve this.


April 19th, 2018
Iíve made great strides in fixing the issues with the front panel logic.

I figured out why the Memory Protect toggle and LED were malfunctioning. Resistors can change alot. So can checking your solder work for obviously disconnected bridge joints. I also fixed the Read/Write bus indicator, which was wonky as hell for awhile there.

The step signal is now debounced correctly (I think), and the Run/Halt toggle seems to lock out certain front panel functions correctly, to prevent meddling with the bus while the CPU has been handed control.

Testing the complex sequenced features, like Examine, Examine Next, Deposit, and Deposit Next seems to be 70% working. Deposit works fine, since itís an un-sequenced event.

Whatís not working is the ďLoad Data BusĒ signal, which is the last action performed by all the three different sequence chains. When the LDB input on the Data Control Card is pulled high with 5V, it works fine, and copies whatever byte is on the data bus into the front panel register for user manipulation. However, when the Status Control Card is given control over that signal, the signal doesnít approach 5V.... it goes from 0.25V up to 0.55V max, and then thatís it.

The key word here is contention. I think I have a situation where an OR gate should have been employed on the Data Control Card, and wasnít. This will take a bit of rewiring, but I think I can eliminate a gate from the Status Control Card and another from the Data Control Card in the process. It means I have to replace the 7404 with a 7402, and rewire accordingly. Iím sure there are more improvements that could be made here, but I need to take this one step at a time. Besides, the revision 6 (and now 6B) of the Data Control Cardís logic will likely be replaced with the revision 8 down the line, and that one will be more part economical.


April 16th, 2018
Overhauling the Address Control card Old & Busted: 74244's New Hotness: 74245's It seems to work much more reliably now. So thatís cool.

The address LED resistors now live on the debug card. The lines running to the front panel for the address bus are buffered now, with the goal of eliminating interference. Oh, and the data and address buses now both have terminating resistors, which is cool.


April 13th, 2018
I re-purposed that first failed attempt to make a serial card into a simple diagnostic board. Itís useful for monitoring the data bus directly, and with a minor tweak, it can hard wire the data bus into specific instructions. The only reason to do this is with NOP, which is fine.You can see the address bus moving through the entire 64K of addressable space, which is cool. See where all the address signals jump low at the same time? Thatís the end of the 64K! Itís starting over from zero. Right now, this is proving helpful in proving certain aspects of the Cactus arenít totally fucked.


April 12th, 2018
Look at that beautiful reset vector on a 6502.

First we hop to 0xFFFC, then 0xFFFD, and see what address the first instruction is sitting at. It happens to be 0xFF00, which is the starting address of the serial routine in ROM.


Apr 7th, 2018
OpenBench Logic Sniffer

Iíve got myself a better tool for watching whatís going on with the Cactusís bus, and hopefully figure out whatís going on. It arrives with 16 pins connected, but if you want to use the other main bank of 16, or any of the other bus-specific inputs, you have to attach your own pins. I picked this model because it could watch 32 digital logic signals, which is great since the Cactus bus has 35 total lines (one unused, one for ground, and one for power).

For those of you interested in such a product, I must warn you that this is an older design, and thus it lacks the website documentation that it once had when it was new. Not to mention, it runs in Java. The upside is that it seems to have good operating system support all around. That, and itís cheap. I donít know if youíve looked at logic analyzer prices before, but they tend to be expensive.

So whatís next for Cactus development? Iíve got to figure out how to set up conditional sampling triggers, such that the logic sniffer begins recording when certain addresses are visited, or when the reset line dips low (which sounds alot simpler to accomplish). Then Iím going to come up with a baseline understanding of what my breadboard machine is doing so that I can compare it to the Cactus proper and hopefully diagnose its issues.


April 5th, 2018
I want you to step back in time with me and see just how many design revisions the data control card logic has been through. The first two are future designs, followed by the current design, and then moving backwards to my first ideas on paper. Initial ideas were inherently flawed, and failed to do all of the things I needed the circuit to be able to do. As time has gone on, Iíve been able to slowly reduce the number of gates, chips, and wires required.


April 3rd, 2018
I canít get the Cactus to boot in minimal chip mode, and diagnosing it isnít going so well. So I bought myself a USB logic analyzer, which should be mailing soon. I intend to compare the bus signals of the Cactus to the breadboarded ďCactus SeedĒ and see where the discrepancy is.

In the meantime, Iíve noticed that the Western Design Center 65C02's do something different with pin 1 (VPB). Itís not a second ground pin, but rather something specific to their implementation and thus I should leave it floating. I need to throw it on the bench and desolder the lines going to it, just to be on the safe side. It probably wonít solve the problems Iím having, but it doesnít hurt to try and eliminate factors, right?


March 30, 2018
I decided to see if the CPU, RAM, ROM, and serial boards would just... run. I mean, this is the one part of the Cactus Iím directly copying. So when that doesnít run, I find myself particularly frustrated.

I would love to have a proper digital oscilloscope or some way to probe the bus during that short burst of time after I reset the CPU to see what the hell is going on.


March 27th, 2018
The CPU card is finished.


March 23rd, 2018
One serial card, complete with 10 different baud rate choices. Another step forward in Cactus development.


March 21st, 2018
I wanted to try something related to Cactus development... something Iím surprised I didnít try sooner: breadboarding Grant Searleís minimal 6502 machine design. It took some time to get the EPROM, serial, and stuck data line business

sorted out, but as you can see Iím programming in BASIC on that breadboarded machine. Iím programming in BASIC on a machine I assembled. Thatís not sinking in quite yet for me.

I got some new Western Design Center CMOS 65C02Sís in the mail, which have some fun features and functionality improvements over the old MOS NMOS 6502's. They have a fully static core, meaning that losing memory while halted or while single-stepping is now no longer a concern. They added a Bus Enable pin which allows you to put the address and data buses into a high-Z state (which eliminates my need for 74245 bus transceivers, and thus associated wiring). Plus, these things can be clocked up to 14MHz! Holy fuck!

Iíve got additional EPROMs, ACIAís, and other components in the mail too. I received some spare RAM already, along with those 65C02's, both of which are in this... Cactus seed on display here. Iím also testing a clock frequency divider which is helping the 6850 UART generate 9600 baud for the serial connection, as well as 1.2MHz for the CPU.


Mar 17th, 2018
Hey. That approach is working. Itís not as frustrating now, because Iím isolating the problems to the individual card rather than jumping directly into integration testing. I am making progress.

To Do List:

Assert Phi2 while the machine is halted, to allow access to RAM. Take it from /Q on the RUN/HALT toggle. Figure out where multiple clear signals on the data card registers are coming from. Sometimes clearing one bit will end up clearing multiple bits. Add the RESET and STEP momentaries to the debouncing circuitry. Add the sequencing orchestrator to the RESET line. Figure out why there are crossed lines between the R/W line and the /PROTECT line. Check the RUN/HALT line too, why not. Re-add the memory protect feature to the RAM card. Build the serial card. The layout is almost ready. Design and build the CPU card.


March 16th, 2018
Another step in the right direction...

The data control card isnít as fucked up as I thought it was. I can perform a deposit to the bus. I realized that I need to make the deposit command pulse Phi2 automatically, rather than me holding it high the way Iím doing here.

This will mimic what the CPU will do later on to write to the RAM. Otherwise, nothing will ever be stored in RAM.

This means a few things are happening correctly:

While the machine is in the HALT state, it can load from the data bus and deposit back to the data bus. While it is in the RUN state, it defaults to following the data busís actions immediately, so you can see what the CPU is doing. Yeah, I could have done this with another set of 8 LEDs but this is my computer and thatís how I designed it.

Deposit is happening correctly. That means all 8 registers are passing their data through C and D buffers

Load Data Bus is happening correctly. Which means that the clock inputs on those registers are clearing bits, and the A buffer is sending whatever value is on the data bus back up to the ďsetĒ side of the registers, so you can then see it on the front panel LEDs. Youíve effectively copied that byte from memory into the front panel, and can modify it there before sending it back into memory.

Keep in mind that the data control card is incredibly complicated, and took the most time to develop into the state itís in now. What's feeding signals like "clock" and controlling buffer's A, B, C, & D are all one set of collective gates. So for example there may be 8x "B" buffers (one per bit of the data bus), but there is only one inverter controlling the bank of them from the RUN/HALT signal.

During testing, I noticed something strange. While RUN signal was asserted, the B buffer started showing me whatever was hard-wired to the data bus. However, if I set it to 0x00, and moved my hand closer to the card, the LEDs would wink on, one by one. Sure enough, during testing that means the bus will require pull-down resistors.

ďBut what about when testing is done? If you remove the resistors-Ē When the CPU card is finished, whenever the RUN state is asserted, the 6502 will be able to bring the values low correctly. Until then, yes I will have to pull the lines low by hand. Whenever the data card is performing a deposit, and both C and D buffers have cleared the path for it, they can pull the data bus high and low correctly. When one of them is in in high-impedance mode (aka high-Z), which is any time theyíre not performing a deposit, then some other device on the bus will be sending data, and thus in charge of the bus at that moment.

So, whatís next? Adding a way to make Phi2 go high on a deposit, and figuring out why the hell Iím getting some phantom multiple clear signals. Sometimes clearing one bit will end up clearing multiple bits. This doesnít happen with setting bits though... curious.


March 16th, 2018
Round 3, asshole!

So I figured out what the the address bus control card was doing. It wouldnít let me load the two bytes from the address panel switches, but instead an ďexamineĒ command would show you 0xFFFF every single time. You could increment an address no problem, but you couldnít hop directly to an address you wanted to see.

So, I threw it on the test stand, played around with it a bit, and discovered that the 10K pull-down resistor bank for those front panel switches wasnít lowering the voltage past 0.4V, which is insufficient to be considered a zero when using the 74193's preset function. Solution? Wire the opposite side of the address switches to ground. Down is 5V, resulting in a 1, up is ground, resulting in a zero. And that makes the resistor bank superfluous, so itís been removed. So now that works. So I got that going for me... which is nice.

I think itís time I took a crack at the data control card, and see whatís going on there. One problem at a time, I will fix this.


Mar 16th, 2018
The 32K RAM cardís write protect circuitry has been refusing to unlock. ďWull Ďereís yer prablem.Ē Iíve bypassed it, and now I can deposit and read bytes of data to it. Well, thereís another problem down. NEXT?!


Mar 15th, 2018
The more I explore the Cactus, the more I realize my front panel design is flawed. Things donít do things that Iím expecting. Signals behave erratically. Circuits that were tested piecemeal now fail to cooperate with other signals.

I have no idea what Iím doing. Every time I start checking on one signal, the next thing I know, Iím bouncing from card to card rather than staying focused on one problem. Itís strange, but I should be able to do simple memory deposits.

I can force a few bits on the bus high, send the write signal as I assert Phi2 high, andÖ nothing. Nothing gets committed to memory.

So maybe thatís where I start. Figuring out one assembled chunk at a time.

Start with the RAM chip, hard wire an address and a byte of unmistakable data, then try writing it followed by reading it. I may have bad RAM.

Then I need to figure out why the hell the address banking will let me count, but not load a value from the front panel. I donít need to do that with anything else involved.

One. Piece. At a time. One frustrating piece at a time.


March 14th, 2018
I overhauled the 32K RAM card...

Meanwhile, thereís so much baffling shit going on in the Cactus right now. For example, why the fuck is the data bus floating at about 1.2V, except when I deposit a 1, when it drops to zero?!?

Oh. Wait. I can explain half of that.

The data control card can read from the data bus, but the output buffer (the red one marked ďDĒ is a tri-state buffer. Right now, itís supposed to be in a high-impedance state. So where is all that voltage coming from? I need to hard-wire some 1's on the bus for testing purposes, see what happens.


Mar 14th, 2018
Iím going to be doing alot of bitching about the Cactus, my homebrew 6502 computer project. That being said, I want to express that Iím actually pleased that it didnít blow up, and now I have a fun challenge to tackle. This is my design, so I have nobody to blame for it but myself.


March 13, 2018
Letís get this over with...


March 13, 2018
The First Power-On Test Of The Cactus: It didnít explode. Or melt.

It also didnít do all of the things it needed to do. There are some malfunctioning parts that need work. It doesnít even have a CPU yet, but the bus is stand-alone in the sense that it can operate without the CPU around. So far, Iíve found atleast a dozen problems to be fixed.


March 13th, 2018
To do list:

See about connecting the RESET signal to the address counterís CLR inputs, the sequencing generatorís /MASTER RESET line, and anything else that could probably use it. It will probably need to be added to the debounce circuitry.

Reconfigure the protect toggle to have the LED and the bus line to follow Q.

Change the RAM card to have a 7408, and correctly block against the RAM protect line. Probably change out that crappy socket too. Might as well overhaul the whole card.

Resolder Address lights #3 & #9.

Make the pull-down 10K resistor on the R/W line optional for debugging.

Double check the 74193's inputs are pulled high/low respectively. Maybe this thing needs to be replaced.

Check the address input switches toggles are on the correct side of things. Maybe theyíre bass-ackwards.


March 12, 2018
Cactus Progress:

I finished the status control card! It interfaces a few things with the bus, and passes along a few other signals to the CPU card. It also orchestrates the complex sequences of examine, examine next, deposit, and deposit next with the address and data control cards.

Next, I have to build the new serial card since the old one was an incomplete design. After that comes the CPU card, which will contain the system clock control.

Before I actually build either of these cards, I want to hook up the power connectors for the bus, and see if I can read or manipulate some memory.


March 6th, 2018
Iím just about ready to start soldering the status control board.

I had to confirm which rainbow ribbon cable lines went to which switches and LEDs. This card is gonna be denser than I anticipated. The good news is that there are quite a few unused gates on each of those 7400 series chips. However, in this situation, I canít consolidate down to a smaller chip count -- everything is too specialized. Either way, this will declutter the wiring a bit.

One thing that surprised me about this board is just how little interaction it has with the bus. Ground, +5V, Run, Reset, Step, Memory Protect, and Read/Write signals will all be broken out here, but no data or address bus lines will be touched. There will also be 4 special lines running to the data control card and the address control card that will not be traveling on the bus. Oh well, thatís not too bad...

Do you think I can get the Cactus ready in time to submit for VCF East 2018 as an exhibit?


March 6th, 2018
I screwed up the serial board and Iím basically going to have to start over on it. In the meantime, I can work on the last of the front panel interface cards: the status control card. I finished the schematics last night, and now Iím deciding on the board layout. The Cactus is coming along!


March 5th, 2018
I painted the switches on the Cactusís front panel.

Some folks may not like the color scheme I picked, and to that I say, ďwhen you make your own home brew front panel, you can paint it any color you like.Ē


February 28, 2018
The serial board for the Cactus is coming along!


January 9th, 2018
New Soldering Station

It was about time I upgraded my soldering setup with modern conveniences. I have no excuse not to work on my 6502 homebrew computer at this point.

Remaining boards to be built: status control board, CPU board, and dual serial board. Oh, and a power supply -- I still need to wire that up.


- 2017 -


October 16h, 2017
The data entry & modification board is complete!

This board has the most complicated wiring of the entire machine. But itís done... good. Next comes the status control and sequencing board that ties this and the address control board together.


October 13th, 2017
Status Update!

I made some major progress on the data bus control board. The bank of D-latches have been connected to the pull up resistors and front panel connectors. Thatís quite a few of the signal lines right there.

Next comes the ďsetĒ lines being connect to the data bus buffer, along with additional lines to connect the indicator line to the data bus, and the output buffer chain. This is the single most complex board on the entire machine, so it will take some time to finish and confirm my wiring.


October 8th, 2017
The address control bus card is finished.

There were a few snags along the way, but nothing too terrible. The criss-crossing wires, significant bit order reversal between the bus and the control switches, the part where I almost forgot to add pull-down resistors... minor things. I should probably test it...

The upper connectors are for the switches, while the lower connectors are for the LEDs. The tiny little red connector is to hop over to the status control card, which will send over two different signals: load the address selected on the switches, and increment the current address value.

Three cards down, four more to go. I started work on the data bus control card, but I need to review my wiring scheme because Iím pretty sure Iíve already made a few mistakes. Not to mention, I need to adjust for 2x4 pin front panel connectors, rather than the 2x8 pin versions I was initially anticipating.


October 3rd, 2017
I decided to work on the address control board for a bit. So much computer left to wire...

Also, I may or may not have to remove a bunch of wiring from the data control logic and correct a few mistakes.


September 26th, 2017
The front panel logic board for controlling the data bus slowly takes shape.

I decided against integrating the logic for the control switches and status lights into the data bus and address bus cards to avoid excessive wire clutter. This means that the examine/deposit sequencing logic, latches for run/halt and protect, and the run lockout logic is all going to be located on its own dedicated card.

Oh, and the turnkey switch is finally mounted on the front panel.


September 24th, 2017
One freshly finished 32K EPROM card for my homebrew 6502 machine.

The three pins up top are to select the upper or lower bank of 16K, as the memory map will only allow access to 16K at a time.

Note: I think this is about when I decided to call it the Cactus.


September 22nd, 2017
Hereís the current general idea of how the cards will be laid out on the bus of my 6502 homebrew machine.

Top left: processor board, w/ 6502, clock, single step circuit, and bus protection
Top center: dual serial card (with 68B50 ACIAís)
Top right: EPROM card w/ ZIF socket
Bottom left: front panel logic, mainly address bus control
Bottom center: front panel logic, mainly data bus control
Bottom right: finished 32K SRAM card

Iíve got a shipment of parts inbound today which should help me continue my progress. Iím making this machine happen!


September 19th, 2017
Digging around on the internet has unearthed some interesting information about the 6502.

The first image is the official MOS recommendation for how to single step a 6502 from the 1970s. Itís... complicated to say the least.

The second image is Thrashbargís approach to the same problem in 2006. I think I may have found a winner. You can read more here: http://forum.6502.org/viewtopic.php?t=895

The third image was my idea of how to perform single stepping on the bus. It wasnít nearly as well thought out. I think Iím going to adjust my strategy, and put the wisdom of others to good use.


September 21st, 2017
72 signal lines

16 address switch wires
16 data switch wires (8 set, 8 clear)
10 control switch wires
16 address LED wires
8 data LED wires
4 status LED wires
+5V
Ground


I still need to terminate the other side of these ribbon cables.


September 18th, 2017
Wiring the front panel has begun!

Iíve already wired up more than half of the switches and LEDs, but there were a few setbacks. I had a dead LED, and a switch that got mangled by the heat and a solder blob I couldnít control.

Yes, those are VIC-20 cartridges holding up the panel as I work.

Soldering up the cable harnesses



September 18th, 2017
I modified the 32K RAM card to allow for the Protect signal line to actually disable the CPUís ability to modify the contents of RAM. Maybe I should start work on more of the Cards soon...


September 17th, 2017
6502 Homebrew Machine To Do List:

Figure out the best way to but a bi-directional tri-state buffer/transceiver on the CPU to isolate it from the data bus. 74245 has potential, but the direction line will have to be tied to read/write. Is it fast enough to do the job?

Have the enable line attached to the HALT state.

While the machine is in the HALT state, in order for the STEP signal to actually allow the CPU to work, certain lockouts need to be lifted but just for the CPU. In the HALT state, everything else should be free game on the bus. That means that depressing STEP will have to be the switch that unlocks the CPUís ability to talk to the bus just before, and just after each individual clock pulse. I mean, youíre only sending one clock pulse, right? Step mode is going to be dangerous in the best ways.

Where in the memory map should a second ACIA go? One serial port would be lame. This is a late-game addition that should be properly thought about before I get that far.

Right now there is an Examine and an Examine Next. One checks the front panel switches for which address location to load into the front panel register (if you can really call it a register). The other increments from the current address location. That means if poll the current address location, modify a bit, forget what the hell you put there, you need to set the address switches to the current location, and perform another Examine. You canít just hit examine again, you may lose your place and thatís going to probably be annoying. Should I add another switch? Examine Immediate? It would only mean one more debounce circuit and a lockout during the RUN state, but it would also require another front panel switch. Screw that, Iíll deal with the lack of such a switch. Might add one in for debugging the D-latches sequencing though.

In order to implement Protect, I need to add another gate to the RAM to lock out the WRITE line going into that chip. I also need to pick which signal line on the bus is going to signify memory protection. I donít even know if such a feature will be useful. Iíve got it! I can steal one of the inputs of the NAND being used as an inverter, and tack that to the Protect line. A D-latch to keep an eye on that feature will have to exist on one of the front panel interface cards.

Based on current ideas on how I put this beast together, the front panel interface will require two entire logic cards to house all the interface chips. They wonít be small ones either. As of right now, chip counts look like:

7404 Hex Inverter x1
7414 Hex Schmitt Trigger x1
7474 Dual D-Latch w/ Preset & Clear x5
74157 Quad 2-to-1 Line Multiplexer x1
74193 Synchronous 4-Bit Binary Counter x4
74240 Octal Buffer, 3-State, Inverting x1
74244 Octal Buffer, 3-State, x6
LM555 x1

If I play my cards right, the D-Latch chain for Deposit Next, Examine, and Examine Next will only take one or two more chips tops... Thatís still being figured out however. 21 chips ainít bad based on that estimate. A few arenít even being used completely, so there may yet be some creative optimizations I can perform.

My single step circuit is using a 555 as per Quinn Dunkiís Veronica, one of my major influences here. Iím seeing the 74123 being used in a similar capacity on the Altair 8800's front panel, and I havenít ruled it out as an option just yet. Technically, that one will live on the CPU board. (lets see how coherent this is in the later afternoon)


September 16th, 2017
Late night progress on the clock sequencing, single stepping, Examine sequencing, and Deposit Next/Examine Next sequencing.

Iím going with Schmitt trigger RC circuits for debounce on the momentary buttons for these events, which solves one issue. I have daisy chained D-latches to move through the more complex front panel operations, which looks like it will solve another problem. This means that the front panel is going to have its own slow clock to trigger those D-latches, one at a time.

Iím having some trouble getting the Deposit Next/Examine Next sequencing to allow me to jump into the chain of events part way through. I could separate the two events, but if I can avoid using more parts, I will


September 12th, 2017
This weekend at VCFMW, I got to talking with one of the youngest exhibitors on record about phone phreaking and vintage computers. Long story short, I mentioned the front panel logic of my 6502 homebrew project, and it turns out heís very good with logic gates. He made a few suggestions on how I could simplify my design with the hopes that I would be able to implement them.

After rigging up a demonstration circuit on my breadboard, and a bit of adjustment, I was able to eliminate a large number of logic gates. All of the NOR and OR gates were removed, a bank of tristate buffers were exchanged for their inverting counterparts, and a single additional inverter was added to the mix for a net reduction in 23 logic gates. Iíve gone from 15 chips down to 9! Iíve also started adding in buffers to lock out certain switches while the machine is running.

My next task is designing sequencing system for front panel operations like Examine Next and Deposit Next.


September 5th, 2017
It works! It really works!

Designing the data control card logic

Hereís what youíre looking at:
Blue: Run
Red: RAM status
Pink: front panel indicator
Yellow: front panel latch set low
Green: front panel latch set high

Halted state, w/ RAM, front panel indicator, and latch set to zero
Halted state, w/ RAM, front panel indicator, and latch set to one
Running state, w/ RAM & front panel indicator both set to one, latch bypassed and locked to zero
Running state, w/ RAM & front panel indicator set to zero, latch bypassed and locked to zero

I had to make a few changes to account for misrepresentations of the real world logic gates within the simulation. The D-latchís clear and preset require negated input, so I swapped the initial OR gates for NOR gates. The ďblueĒ 74244 Octal 3-state Buffer/Drivers required an inverter for their input lines.

It will take 8 of these circuits to effectively observe and modify data within the machineís main memory. All told, it will take 15 chips, and one of them wonít even be fully used by this section of the front panel circuitry. Plus another 6 chips for the address traversal circuit brings it up to 21.

Next comes the selection circuitry for selecting halt/single step/1MHz clock, memory protect lockout, and examine next/deposit next sequencing. My goal is to pull off the whole thing in 25 chips.


September 5th, 2017
The 6502 sits dormant while the 6810 and the front panel demo logic tries to demonstrate a successful deposit. At least the D-latch seems to be working.

Iím glad that things are actually coming along!


September 5th, 2017
Problem Solved, in theory.

I threw in a D-latch with preset and clear, and had that act as a makeshift RS flip-flop, tying the D to ground, and hooking the clock into the examine line. Time to test!


September 4th, 2017
Iíve been able to revise the simulated circuit a bit and solve some issues. I have a RAM model that actually matches the way my RAM will work in meatspace. Iíve reduced the chip count for a full 8-bit data bus from 18 to 14 total chips by swapping out the AND gates for buffers.
Panel | RAM |  Examine
  0   |  0  |   0
  1   |  1  |   1
  1   |  0  |   1  
  0   |  1  |   0
Iíve also alleviated one of the problems where pressing Examine would favor the panel over the RAM, specifically when the RAM had a 1, and the panel had a 0. Now I need to do the same for the inverse.
Panel | RAM |  Examine
  0   |  0  |   0
  1   |  1  |   1
  1   |  0  |   1  
  0   |  1  |   1
I could make the RAM send a ďclearĒ every time it moves to a new address, effectively clearing the bit, then setting it if thereís a 1 present. Iíve also thought about using different memory gates to replace the RS flip flop Iíve got currently storing the front panel bit.


September 4th, 2017
Iíve got two conflicting signals causing a problem: the RAM and the output of the last AND gate from the modify/display circuit.
AND   RAM   Examine
 0     0       0
 1     1       1
 1     0       1
 0     1       0
Performing an examine will incorrectly show the contents of that RAM bit, and instead show me whats happening in the modify/display circuit. The RAM should take priority, unless youíre performing a deposit command, in which youíre putting the RAM into write mode, and having it assume the state of the modify/display circuit...


September 4th, 2017
Finally making some progress on the 6502 homebrew front panel logic. I tested a half-sized version of the address access/increment logic, then drew out a more detailed view on paper for the full sized version.

Iíve also simulated the data entry/access/alteration logic for a single bit. Now Iím testing/debugging it in meatspace, with real chips.

Iím learning a few things:
Iím not all that skilled in wiring up actual 7400 series logic chips
Theory and practice arenít as close as I expected here
I can still make progress and figure out what Iím doing wrong
Donít reverse the polarity on a chip, then touch it. You will burn yourself.
Logisim is cool
Never leave an input floating
Pull up/down resistors are your friend



May 14th, 2017
This is the prototype front panel interface for that 6502 homebrew machine Iíve been putting off for awhile now. I laser cut/etched the panel layout last week, after putting it off for too long. I need to put in some LEDs and start wiring them up to begin building the logic. The black switches are dual momentaries, and the metallic switches are toggles.


May 12th, 2017
NAND gates to the rescue.

There are no good 7400-series RS flip-flops with enable. The only RS flip-flop chip they currently make has a gang reset, rather than individual reset lines for each bank. I need all of them to be independently set/reset. Both the JK flip-flop and the D latch are both unsuitable for the task.


- 2015 -


May 2nd, 2015
I scored some more parts recently to make up 3 new boards and plenty more sockets for my project. My DPDT switches came in today, and I wasnít expecting to see them until Monday.


Desert Skyline


Have a question? Want to know more about the Cactus? Know of another 6502 machine with a front panel? Email me:

email



HomeCactus Main Page
This page was last updated on 6-15-2024