[ Home ] [ Up ] [ New Stuff ] [ Minix Port ] [ Magic-2? ] [ Overview ] [ Photo Gallery ] [ Construction ] [ Technical Info ] [ My Other Projects ] [ Links ]

Diary entries for 2004

Warning - this really is a diary.  Here's where I'll be jotting down random thoughts, progress reports and things of little interest to anyone but me.  I find that by writing ideas down, it helps me find the problems and will also serve as a record to remind myself a year from now why I did things the way I did.

This project has been going on for quite a long time, and only in the last few years have I been using this web site to keep track of it all.  My running diary has gotten large enough that I've broken it down into years.  Here are the past entries

2003 Diary

2002 Diary

2001 Diary 

4/10/2004 through 7/23/2004

I stopped updating the diary during the bring-up process, as the bring-up log pretty much captured everything I would have said here.  I think I'll go back to occasional diary entries during the next phase.  My construction and bring-up logs can be found at:

4/9/2004

Getting close.  Very, very close.  I repaired the mistake in the backplane and instead of doing the right thing and finish beeping out the alu/register card I had to try a power-on test.  I populated the alu/register card just enough to increment the memory address register after an instruction fetch.  It was just going to be a quick test before I started beeping, but I ended up debugging until close to 2 a.m.  Good news, though: it successfully incremented after fetching.

Along the way I found a few problems: one snapped wire, a mistake in my printed circuit board for the EPROM daughter card, a couple of chips inserted backwards, and a couple of missing chips that I needed for increment.  Those backwards chips burned up, and that nasty sweet small of fried chips lingered in the air all night making me nervous that I was frying more.  Fortunately, my bench power supply sobered up from last night's wine-spill binge so I was able to use it.

The biggest problem of the night was the lack of space for probes in the card cage.  It was really difficult to debug signals that were local to the card.  My cage is so tight that I have to insert the cards in one and only one order.  The best I was able to do was carefully attach a probe to the component side of a board, and then tape it down to enable me to insert it in the cage.  If I should ever be insane enough to try another project like this, I'll leave more room.

Anyway, it's getting very close to D-day.  Next up (really this time!) is doing another full beepout of the alu/register card and soldering in the bypass capacitors.  After that, I try to bring up the machine with the real microcode and a fibonacci sequence generator in the boot rom.  When Magic-1 is able to compute fibonacci(10), I will declare it working.  That could happen within the next couple of days.  Damn.

4/8/2004

Prematurely attempted to bring the machine up today.  No luck.  Can't rush things - need to take it steady and methodical.  I ran into power issues today.  The first problem happened when I knocked over my glass of wine onto my bench power supply.  I didn't think any got inside, but apparently I was wrong.  After wiping things up, it appeared the power supply was working OK.  It just so happened that I was getting the new front panel hex displays finished up, and when I powered things up my voltage dropped by half.  I assumed a short, and spend the next half an hour searching in vain for it.  I finally realized that my power supply was switching from constant voltage to constant current when it shouldn't.  I also found I could no longer reliably adjust CC mode.  I did find, though, a bit of wine dripping out of the current adjustment knob.  My best guess is that I soaked the 10-turn pot for CC mode adjustment and caused to power supply to wander off in a drunken haze.  I'm hoping it will sober up when the wine dries.  May have to disassemble and clean it.

I then dug out an old 5V switching power supply from my parts bin and hooked it up.  While double-checking currents and voltages, problem number two became apparent.  I knew I had a poor power distribution scheme on my backplane, but had hoped I could get by with it for awhile.  Not sure I can.  I'm showing 4.96 volts at the backplane connector, 4.87 on the power and ground planes of the control card, and 4.79 volts on the temporary front panel assembly.   I've planned for some time to address this via custom circuit boards for power/ground sandwiched on the backplane, as well as a separate power jack for the front panel.  Might have to accellerate those plans.

The other big problem I had was that there is almost no room to attach probes.  My cardcage is very tight.  Backplane sigals are easy to get to, but it's going to be a real challenge to debug non-backplane signals.  I may need to construct some custom clips. 

3/30/2004

For months now, I've been focusing on contruction issues - so it was a bit of a change today to start thinking about the design again.  The prompt for this was getting ready for the first test program.  I don't know if it's universal, but everywhere I've been it's traditional to use a fibonacci program as a major milestone for microprocessor bringup.  I've already had one of these running in simulation for a while, so I'll burn a new version of the boot rom to go right into a generation of fib(10) and then halt.

This brings up an issue of testability.  I'd expected to have the real front panel at this point, but it's looking like that's going to lag for a bit.  Very tight budget here in the Buzbee household, so it will be awhile before I can free up money for an enclosure.  My current temporary front panel doesn't yet have the ability to display arbitrary register contents, which would be nice to have when bringing up the machine.  I'll probably add that capability.

The next issue is where I start getting back into interesting architectural (or microachitectural) issues.  I wrote a pretty comprehensive validation test suite a while back for the simulator.   Using those tests would be a natural next step after attempting fib().  I realized, though, that I'm going to have to do a some modifications. The way things work is that when the machine is turned on, it starts up in supervisor mode, paging and interrupts off, and all memory references address device space (physical memory 0x0000 to 0xffff in device space).  I have 0x4000 through 0x7FFF mapped to SRAM, and depending on a front panel switch, 0x0000 through 0x3FFF is mapped to either ROM and SRAM.  Execution always starts at 0x0000.  The 4MB of main memory can only be accessed with paging is enabled, and the memory attribute bit is set in the associated page table entry.

The simulator didn't simulate device ROM, just device SRAM.   It runs tests by loading an Intel hex image of the program into device SRAM.  So far, so good - I can easily burn device ROM to match.  The issue is the tests that write to local static variables in the test.  Obviously, with ROM that won't work.  I think when I did this I assumed that I'd just set up the data segment to load in device SRAM, but I never got around to adding this capability to my assembler.  So, the simplest thing to do is to rewrite the failing tests to move the test data region to somewhere above 0x4000.  This isn't difficult.  What is difficult, though, are the tests that exercise the fault and interrupt handling. 

The way I designed M1, the interrupt vector is hard coded to live at address 0x0000.  This isn't necessarily a conflict with the power-on start of execution also at address 0x0000 for a couple of reasons.  First, there can never be a fault for vector 0.  Thus, I always can use the two-byte first entry to hold a short branch instruction to jump around the interrupt vector.  However, my real intent was that I would set up the interrupt vector at some arbitrary physical location (at the beginning of a page), and then map it to virtual address 0x0000 of the supervisor mode page table.

I'm rethinking this decision.  First off, it will be useful to take interrupts with paging off.  I could do this the way things are, but my interrupt vector would be nailed down in the boot ROM - unchangeable.  That's what I realized today when I took a look at my test suite.  Many of the tests swap out interrupt vectors for testing, but in ROM they simply won't work.

The good news here is that there is a very simple fix.  I don't have to wire the vector to 0x0000.  It has to be fixed, but I could fix it just about anywhere.    The interrupt vector address is constructed in the fault/interrupt circuitry from the output of the priority encoder with high bits that a currently just wired to ground.  I could just as easily tie them high as low, in any combination.

In my very first versions of M1, I had an interrupt vector base register that could be set on the fly.  I later eliminated it for simplicity - which  I still think is the right choice.  Pegging it at 0x0000 is somewhat more elegent, but putting it at 0x7F00 (or something like that), might make life easier.

3/19/2004

Finsihed beeping out the control card.  Found a couple of disturbing cases of wires that were broken inside of the insulation.  I don't think this happening at wiring time, but ratherwards due to pressure on the wire.  I'm going to be especially careful on the alu/register board to leave slack and not route too many wires through the same posts.

I've started on the alu/register card with the layout, and have all of the wire-wrap IDs I'll need.  I'll probably start board prep this weekend.  First, though, I'm going to cut a plexiglas replacement for the top cover of the card cage.  The card cage guides are starting to bow out, but I don't want to put the old cover back because it seriously limits my ability to probe the top card.

3/18/2004

Taking a bit more time than I thought to beep out the control card.  Haven't found any new problems, but it's really slow going.  Because there are so many odd connections (as opposed to busses), I have to do a lot of searching to locate the chip/pin targets.  There is so much wire the device numbers on the ID tags are obscured, so I have to refer to the chip layout diagram.  I really hate this part.

Went ahead and did the layout for the ALU/Register card to give myself a break from beeping.  Should finish beeping by sometime this weekend, and will start with at least ALU/register card prep.  I'm debating whether to go ahead and wire up power/ground for all of the devices at the beginning.  I did that for the first card, and decided it was a mistake (because it blocked channels I would need later for wire routing).  However, with dense cards it is a bit difficult to put power/ground in after the fact.   Also, with this card I'd like to do some testing on a partially complete card, so I'd have to do some power/ground anyway.

At the moment, I'm thinking I'll go ahead and wire up all the power/ground during board prep, but will take special care to leave enough slack to avoid blocking channels.

3/14/2004

Didn't finish off the control card this weekend as I had hoped.  The wiring is complete, but the checking of each connection with a continuity meter is going to take another few sessions.  I really hate beeping out the wires.  I generally enjoy wiring, even though it is also tedious.  But beeping out the connections is simply painful.  Perhaps it's because I inevitably find bugs.  I beeped out the connections on the fault/interrupt sheet and found two problems.  Both were the same: a run of wires missed the correct pin and wired up an adjacent one.  On the bright side, those mistakes tend to involve the top wire in the two-wrap post, but at this point removing the bad wire can be very difficult if it travels through any tight bundles.  In the more difficult of the two bugs tonight, the bad wire made 3 90-degree turns, and all of the turns were tight.

3/12/2004

Getting close to finishing the wiring of the control card.  Overall, it's gone pretty well.  I was afraid that this card would be extremely difficult to wrap, but it has turned out to not be bad at all.  I think this is due to a couple of things:  First, my floorplan worked out very well.  Most wiring was done between devices only a few slots away.  Secondly, there were much fewer cases in which I needed to put two wraps on the same pin.  Those 2nd level wraps continue to give me a lot of trouble.

Now I think the most difficult card will be the alu/register card.  That was my original assumption, but I changed over to fear the control card because of all of the odd wire routings  which turned out to not be bad.  On the alu/register card, almost every device slot is taken, and because it is mostly a mass of busses there will be two wraps on the vast majority of pins.  On the bright side, bus wiring can go faster because it's easier to get in a rythm.  We'll see.

What's left on the control card are the rest of the edge sensitive signals, which I'll do in red wire (so long as my small supply doesn't run out).  Oh, I've also got to wire up the proms.  Right now, it's just the eprom daughter card that can supply the microcode bits.

3/6/2004

Need to put this somewhere - it's not in the schematics.  Wiring list for the daughter-card header:

3/3/2004

The wrapping is going a bit better than I thought it would.  Dealing with busses (which mean a lot of two-wire-wraps on posts) really did slow things down a lot.  The wires I'm putting in are much less regular, but it's rare now that I break one.

On the website front, I added a guestbook.  I've been getting increasing traffic lately, and I'm curious who is stopping by. 

3/2/2004

Wire-wrapped about half of the fault/interrupt circuitry.  Whereas my other cards had lots of busses and regular wiring, this one is going to mostly be 1-shot wires.  The good news is that I'll have fewer places where I have to have two wires wrapped to the same post, but it's going to be a lot more time consuming and error-prone to keep track of which device/pin I'm going to.  I find that one of my most common errors is to correctly place the first end of the wire, and then, between looking at the routing and other distractions, attach the other end of the wire to the correctd pin number - but on the wrong device.  Had one of those already today.

Updated the links page with a pointer to Dennis Kuschel's MyCPU, and pictures of John Doran's awesome D16/M homebrew.  If M-1 is half as functional as Dennis' MyCPU and a tenth as pretty as John's D16/M I'll be happy.

2/28/2004

Progress has slowed considerably the last couple of days - catching up on chores around the house and getting ready for the new job I'll be starting on Monday.  Did manage to prep the control card (added bus power/ground, caps and a header for the EPROM daughter card).  The biggest immediate task is coming up with the floorplan for chip placement.  This is going to be a bit tricky, but it's starting to come together.  The control card was pretty dense to start with, but since I've decided to allocate enough space in case sometime in the future I need to replace my 20-pin microcode PROMs with .6 28-pin EPROMs it's become extremely tight.  In looking things over, I've managed to elminate one of the 74244 bus drivers, which helps. 

Not counting the PROMs, I now need to place 61 devices.   The basic layout I've chosen gives me space for 62.  The layout is somewhat irregular.  The top two rows consist of slots for 6 14-pin devices, 1 20-pin device and the PROM column (20/28).  The bottom 8 rows have 2 20-pin columns, 3 16-pin columns, 1 20-pin column and the PROM column.  I hope I don't have to add much logic to fix any late bugs I find.  Worst case, though, I can abandon the EPROM safety net and free up 5 device slots - more than enough for any problem I might encounter.

The rest of the weekend is going to be pretty busy.  I'll be happy if I complete the layout by Monday.

As far as construction plans go, I'm doing to do this board a little differently.  The other boards were largely completed before I attempted any power-on testing.  That fit in with my build plan of putting in the edge-sensitive signals next to last, and the power/ground last.  This has worked out well on the last two cards.  By waiting to wire in power/ground, I've avoiding blocking channels to run other wires.  And, when I do put them in it clamps in loose ones.

However, for this card I'm going to build/test in two stages.  First, I'm going right for the microcode sequencer logic.  This will involve wiring in the PROM, come glue and most of the trap/interrupt circuitry.  I'll build this section to completion, and test it as soon as I can.  The reason for this is that this is such a dense board, any rework will be difficult.  The sequencer is the complex part of the board, and the most likely to have a defect requiring significant rework.  I want to find that out soon.  Once the sequencer is proven to work, I can add in the field decode logic.

2/26/2004

Finished up testing of the device card today - and did quite a bit of rework.  When I wrote the simulator, I chose not to attempt to simulate the front panel LEDs and devices.  That was probably a mistake.  I've had to do a lot of rework on the device card to fix problems that would certainly have been caught in simulation.  The last (I hope) fix dealt with the device decode circuitry.  In my written microarchitectural specs, I called for dedicated devices at the top end of the real-mode (device) address space (0 .. 0xFFFF).   This is where the POST code displays, the serial ports, real-time clock, IDE interface, etc. go.   When I did the schematics, however, I put the devices at the top of the physical address space (0x3FFFFF).  The upshot of this would be that I would not be able to access my dedicated devices without enabling hardware address translation & paging.  So, I fixed the address decode on the UART sheet to correctly put them in the low 64Kbytes.  It involved eliminating one package (U16), and adding a couple more.  I pulled the chip for U16, but left most of the wires in place to avoid having to rip out and replace a section of the address bus.  It's a bit messy, but not too bad.

Otherwise, it's looking good.  The machine is sitting on the kitchen counter blinking away.  The blinking is coming from the clock, and I've got the address switches selecting the seconds output of the real-time clock.  It's getting close to being a computer.

Next up is the layout of the control card.  That will take some time, and care.  I had hoped I'd be able to get a significant chunk of the control card built this week, but it just didn't work out.  I'll probably start construction within a few days, but will have to fall back to working on it for a couple of hours two or three evenings a week.  I'd guess it will take 3-4 weeks to build.

2/24/2004

Had a bit of a scare today.  I'm just about at the point where I'm going to need to be using the card cage for further testing.  I got it out and starting inserting my 3 completed cards (front panel logic, memory and device), and realized I had a space problem.  The ribbon cable headers on the front of the front panel logic and device cards stick up too high for the next higher card in the case to be inserted (the wire-wrap terminals collide).  Turned out not to be too big of a problem, though.  All works well so long as the cards with the ribbon headers are inserted last (and they may not be next to each other.  I guess I'm going to have a fixed order in the cage.  Starting from the bottom: front panel logic, memory, device, register/alu and control.

2/22/2004

Getting rested up, and am back to making good progress.  I had hoped to be done with the device board by now, but I'm at least a few days off.  I'll probably complete it tomorrow, but still have to beep out all of the connections with my continuity probe - and then I have a lot of work to do on the temporary front panel.  Finally, testing will occupy several sessions at minimum.  Doubt I'll start the control card until late in the week, if not the weekend.

Cost myself too much time on this board with mistakes.  The two big ones were getting the pin numbers wrong on the HP hex displays, and a similar mistake for the real time clock.  I knew the real time clock was in an 18-pin package - I remember being quite careful in determining package sizes during layout.  However, when I put in the wire-wrap IDs, I used a 16-pin ID.  I didn't realize my mistake until I went to wire up pin 18.  The RTC was right in the middle of the data bus and address bus chains, but luckily only the data bus wires were affected.  On the bright side, though, my wire wrapping skills are much improved these days.  I still have runs of broken wires, but I now understand that in about 80% of the broken wire cases, the problem is that the gun is not exactly perpendicular to the board. 

Am done with the old job, and a week from tomorrow will start in my new one at HP Labs in Palo Alto.  It's interesting stuff I'll be working on.  I'm looking forward to getting in to it.  Just hope I can get this project over the hump before the new job consumes all of my free time.

2/20/2004

Fatigue and lots of cleanup activities associated with the old job (had my last day today), so not much progress on the device card.  In fact, I've gone backwards.  I did spend a little time putting together the EPROM daughter card, and discovered that I has misread the HP hex display datasheet and wired the pins backward.  Unfortunately, I made the same mistake for the POST code displays.  This means I'm going to have to rip out a pretty good chunk of the data bus - probably 32 lines in all.  Oh well, at least I caught it early.

2/16/2004

Fairly brutal wire-wrapping session tonight.  About 3 hours to run 50 or so wires to complete the address bus.  Didn't really have too many broken wires or bad wraps - just a lot of odd wires and difficult routings. Lots of checking, double-checking and tricky 2nd-level wire wraps.   Continuing to push hard, probably too hard, to finish this board before my week off.  I've probably got two wrapping sessions to go, and then I'll need two or three hours with the continuity meter to beep out all of the connections before I apply power for testing.  I also have a lot of work to do on the temporary front panel.  I need to run another 60-line ribbon to it, as well as put in dip switches for the address and data busses.  I don't intend to put in all of the LEDs, but will probably do at least 8 for the data bus.

Very tired.  My last days on the old job continue to be hectic, and will only get worse as the week progresses.  I may end up needing to sleep during my week off instead of working on the control card.

On the good news front, Ken Sumrall burned a test set of my microcode proms.  The prom burner I located was unable to burn MB7124H 512x8 proms, and would only partially burn 74S472s.  I ended up destroying 5 of my proms in the attempt, but Ken was able to salvage two 72S472s by burning in the missing bits.  We went ahead and programmed three of the 7124s with his professional universal programmer at work to give me a complete microcode set.  I'll end up throwing that set away eventually - it's inconceivable that I've made no microcode mistakes, but I wanted to make sure I could do proms.  It will still be useful during early bringup testing.

I'm now left with 10 blank 512x8 proms, and these things are getting hard to find and expensive.  I've ordered 10 spares from some website, but the last time I tried that it turned out they really didn't have them at the listed price.  However, I'm comfortable with the proms now.  I'll be using EPROMs on the daughter card during bringup and until the microcode is stable.  I shouldn't need to burn too many sets - and if I find in the future that I can't get any more of these devices, I can just go back to the eprom.

2/11/2004

Although the next card to build is the device card, I've mostly been thinking about the control card.  I want to work on that during my week between jobs.  It will be perhaps the most difficult card to build.  Not quite as dense as the register/ALU card, but much more irregular.  The other issue is that I want to be able to use EPROM for the microcode during bringup.  That brings us to my latest agony.  I've been hoarding what I thought were 74S472 512x8 PROMs.  In fact, they are a similar prom by a different manufacturer.  I finally tried to program one to test my eprom burner.  It is supposed to work for 74S472s.  It did not work with my substitutes (MB7124).  I also had a few real 74S472s, and tried those.  I got partial programs - about half the bits burned correctly (and it was a fairly regular pattern for the dead bits).

In scanning the web for additional 512x8 proms, I find few - and those that I do find are very expensive.  I've got 16 MB7124s, which is enough for three sets of microcode (assuming I can locate a burner which can program them).  This is causing me some concern.  I've been toying with the idea of not using PROM, but just using 70ns 27C256 EPROMs.  The speed is good, but the package is .6 28-pin.  My proms are 20-pin .3 packages.  There isn't room on the card for both.

Anyway, I think my options are:

At the moment, I'm leaning towards the last option.  A friend of mine works at a company with a super universal eprom programmer that claims to be able to handle my MB7124.  He's going to do a test programming in the next couple of days.  Assuming that works, I will have a minimum of 3 prom sets.  Going with the last option, I'd be fundamentally using the eprom on the daughter card.  When I am convinced the microcode is correct, I can burn a set of proms, put them on the board and remove the daughter card.  The layout to allow for eprom even though I'm using prom is insurance.  If, in the future, I need to burn new microcode but am unable to locate the proms, I can just do some minor rewiring and replace the proms with EPROMs.  This assumes my friend's test burn is successful.  If it is not, I don't think I want to spend a fortune finding proms which might not burn anyway.  In that case, I'm likely to go with dumping the proms and using eprom directly on board.

2/7/2004

The fix ended up being a bit of a pain.    Replacing U18 and U19 with 74F245 bi-directional bus drivers was the way to go, but the pinouts were different than the 74F244 - so I ended up having to do a lot of rewiring.  It's done now, and have checked each wire with a continuity meter.  Fixed a couple of bugs along the way, and decided not to fix another.  It seems I transposed my bit ordering when wiring up the address bits for the page table memory.  I decided not to fix it, because it really doesn't matter.  I could have a random transposition of those wires, so long as I'm consistent.  The only time it might matter is when I'm doing debugging with the logic analyzer.

I'll do powered testing over the next day or two, and have already started thinking about the device card layout.  The biggest issue will be the outgoing cables:  I'll have a 50-pin ribbon cable to the front panel, a 40-pin IDE drive cable, and two 9-pin ribbons for the two serial ports.  I'll also have a couple of TIL311 LED displays for the POST code device, and those need to be put where I can see them.

2/7/2004 (morning)

Scanning the schematics for the page table over coffee this morning, trying to plot out a testing strategy.  Found a disturbing, significant error.  A while back I noticed that I was not buffering the output of the page table memory before it reached the address bus.  I corrected this by adding some 74F244 bus drivers between the page table memory data pins and the address bus.  So far, so good.  However, I failed to notice that this fix worked in one direction only.  It successfully buffered data leaving the page table SRAM, but it completely cut off the ability to store page table entries!  The way I set up data to store into the page table was to bridge the L bus to the A bus (which previously was directly connected to the page table SRAM I/O pins.

I think I got lucky here, though.  I added the buffering by introducing an internal bus, the "AX" bus on the page table schematic sheet.  I believe I can fix this problem by changing the L->A bus bridge into a L->AX bridge.  This means quite a bit of rewiring, because it involves redoing a chunk of my A-bus wiring, but that's where I believe I got lucky.  It just so happens that the current L->A bridge (devices U4 and U5) is the last element in the A-bus wiring daisy chain.  That means fewer wires have to be removed and redone.

I've found that I frequently introduce new bugs when I fix old ones immediately, so I'll put things away for now and see if I still see the same problem and solution this evening.  I introduced this bug fixing the unbuffered page table output bug by not considering all of the implications.  Don't want to add yet another bug fixing this one.

Update - just had a thought, perhaps I can fix this with little or no wiring changes.  Will it work to simply replace the 74F244 bus drivers with 74F245 bi-directional bus drivers?  I assume the pinouts will be the same, would have to make sure that the direction control of the 245 sends the data in the correct direction if used with the output enable signals from the 244.  Ponder it for a while.....

Update2 - This is going to require quite a bit of rework, and the addition of another 74F244.  I need to change U18 and U19 from uni-directional 74F244 bus drivers to bi-directional 74F245s.  Unfortunately, the pinout is different between the two (the 244 has two independent halves pointing in different directions, whereas the 245 all goes in on direction).  Also, I had been using one half of U18 as part of another circuit - so I'll have to add another 244 just for that. (oh, wait - it looks like U2 has an unused half, perhaps I can use that instead of adding an additional device).  Anyway, bottom line is that I need to remove most of the wiring going into U18 and U19 and redo it.  That will have some cascading effects.   Need to think on this more.

2/5/2004

Short, but fun session today.  Between finishing up an assignment for the paying job and household chores I only had a few minutes to play with Magic-1.  Decided not to attempt to solder down the bypass caps.  Instead, I tried out something new.  When I was searching for my short last night, I did remember that included in the HP logic tools set I bought on eBay was a current tracer.  I'd never used it before, but was vaguely aware that it is just the tool for the sort of problem I had.  I ended up visually discovering my problem, but during the day today I began to regret not getting a chance to try out the tracer.

So, I got a bit of wire and re-introduced my error of last night.  Next, I got out the current tracer along with the logic pulser.  The current tracer works by inductively sensing rising and falling electromagnetic fields.  The idea, then, is to locate the short by injecting pulses into the circuit and then follow the current with the tip of the tracer (which lights up when it detects something).  The setup was as follows:

It was really cool!  I had to adjust the sensitivity of the  tracer a bit, but it immediately located the bad wire that caused the short.  Of course I knew where the wire was, but even if I didn't, it wouldn't have taken me more than a minute locate it.  I'm not unhappy that I spent a bunch of time visually looking for the short (and I did exaggerate, it wasn't two hours - more like 45 minutes) because I really ought to be giving each board a close visual once-over anyway.  Next time I have a short, though, I'll know what tool to reach for.

2/4/2004

Ack - have to be more careful and diligent!  I expected to complete the memory card tonight.  All I had to do was wire in power/ground for each device and then solder in the bypass caps.  I spent a hour or so wiring ground, and when I finished I pulled out my multimeter and did a continuity check to make sure the power and ground weren't shorted together. 

They were.

I then tried to remember when I last did a continuity check against power/ground, and realized I had never done one on this board.  This is a simple check that should have been performed at each step along the way, but here I am with the board nearly complete and only now do I find a short.  Idiot!  So, instead of finishing off the board, I spent nearly two hours visually tracing wires, looking for flecks of metal in bad spots and generally worrying that it was even possible that the board was shorted to start with (given it was cheap surplus, a real possibility).  Finally I discover a mistake in the wiring of the bus power/ground feeds to the card.  One of the bus power lines was connected to the card's ground plane.  Corrected it and the short went away.  I'm still really ticked off at myself, though.  Those bus power/ground lines were the very first thing I did on this card, and to not have done a continuity check at that time was incredibly foolish.

Lesson learned, I hope.

I then tried to finish up the power lines using green wire, according to my color scheme.  However, I finally had to give up.  The green wire was regular wire-wrap wire - not cut/strip/wrap wire.  I thought I could get away with using it for a small number of things, but I think I was getting good wraps in about 1 out of every five tries.  Went back to the good blue wire, and quickly completed without a single bad wrap.  Guess I'll have to modify my scheme - black for ground, red for edge-sensitive signal lines and blue for power and everything else.  Decided to put off the soldering until my next session - either Thursday or Friday.  That will set me up to do some testing over the weekend (providing I can convince the wife to let me monopolize the kitchen table).

2/1/2004

Ended up with more project time that I'd planned, and got a couple of really excellent wire-wrapping sessions in.  The last one lasted a bit more than an hour, and I think I had only one snapped wire.  A couple of tricks seem to really help.  First, I decided to try to make things more uniform by always wrapping in the same orientation relative to me, the gun and the wire.  This means I end up rotating the board quite a lot, but the time lost to doing that is vastly less than the time to clear a bad wrap.  The second thing is to make sure I am holding the gun absolutely vertical over the pin by lifting it slightly up and down prior to pulling the trigger.  If I don't get it right, there's friction between the gun and the pin on the way up, leading to snapped wires.

So, I have now completed wiring up all of the busses on the memory card - which is the great majority of the wires.  All that's left are a couple dozen control logic wires.  Then, I need to add power/ground to all the chips (and tie a dozen or so pins to either power/ground).  The last step will be to solder in the bypass caps.  Could be ready to start testing by mid-week (assuming my wife and kids don't mutiny over the amount of time I'm spending with my silly toys).

1/31/2004

Continuing to make rapid progress on the memory card.  Still have way too many snapped wires, but I think my wrapping technique is improving.  I think one of my big issues is the amount of tension to apply to free end of the wire.  Too much and it snaps.  Too little and I get a bunch of insulated wraps around the post (and sometimes snaps as well).  Also ran into a problem related to my wrapping order.  For the SRAM, I ran the busses first, which worked well.  However, I didn't leave enough slack and the bus lines formed a tight cord against the few unwrapped pins.  I discovered this when I went to wire _WR for the SRAM.  I needed to do two layers of wrap on each post, but the bundle of wires was too tight to allow the bit to fully seat on the pin.  This could have been very bad, but I discovered that my old hand wrapping tool was much smaller than the electric tool bit.  I had to wiggle it a bit, but was able to seat the hand-wrap tool and wrapped those problematic pins manually.  I'll keep manual wrapping in mind whenever I get into a particularly rough spot (and try to leave a bit more slack as well). 

Had lunch with Ken Sumrall the other day and discussed my soldering blob problem as well as the difficulty I had soldering in the decoupling capacitors.  He suggested that perhaps my soldering iron doesn't generate enough heat to overpower the heat-sink behavior of the ground/vcc planes.  Makes sense to me, so I picked up a cheapo Radio Shack 40 watt iron (just for the decoupling caps - I still like my old Ungar iron).   Should I make a similar soldering mistake again, I'll try the hot iron with solder wick (and if that doesn't work, a Radio Shack desoldering iron with a suction bulb).

Been thinking about testing of the memory card.  My first thought was that I wouldn't be able to test much of it, but now that I think of it there is a great deal I can test.  Have to be diligent about testing, and the logic probe/logic pulser combination proved to be exceedingly useful when testing the front panel logic card.  A nice feature of the HP logic probe is that it shows three states: high, lo and unconnected.  I'm presuming that last state will help me test the 3-state drive logic for the address bus.  At this rate of construction, I should be ready to test by next weekend at the latest.

Also starting to think a bit about the microcode portion of the control card.  I'm going to be using old bi-polar PROMs for the microcode store, but obviously don't want to burn too many of those during bringup.  So, I really want to be using EPROMs to hold a series of test microcode images as I incrementally bring up the control logic.  I had hoped that I would have room on the control card for both the PROM and EPROM, but I don't.  So, I  think I'll do a daughter card.  It will hold 5 28-pin ZIF sockets, plus a couple of TIL311 hex displays and a few LEDs to show the currently addressed microcode instruction.  As far as construction, I'm toying with the idea of having a circuit board made.  I've always wanted to try that PCBExpress place, and I don't relish the idea of point-to-point soldering all of those address and data lines.  Have to try to track down typical layout for a small memory card using a 2-sided board.

1/28/2004 (evening)

The L_MDR_LO and L_MDR_HI on the page table schematics sheet should be XL_MDR_LO and XL_MDR_HI.  This is a name change that happened when I freed up some bus lines, and I missed these instances.

Had a great session wire-wrapping.  When it goes well, it's quite relaxing (and when it goes bad, very frustrating).  Anyway, I started wiring up the address and data busses on the SRAMs.  Very  repetitive, with fairly short wires.  Out of the first 100 or so wraps, I didn't have a single bad one.  Then, I snapped a wire and broke my streak.  Interestingly, I also snapped the next two.  Stopped, got up and took a break.  When I started back again, I had another good streak.  I should probably make a point of stopping for a while whenever I have a few bad wraps in a row.

Still expect this card to take another week or so to build, unless I find a lot more time than I usually do.

1/28/2004

Note to self: I'm using L_MDR_LO and L_MDR_HI on the page table card in the computation of the MEMREF signal.  This doesn't seem right, as these signals have already been combined with CLKS.  This means that MEMREF would only be accurate following the leading edge of CLKS.  Shouldn't these be using XL_MDR_LO and XL_MDR_HI?

1/26/2004

WooHoo - front panel logic card is fully built and tested.  Call it done and ship it!

Decided to move on to the memory card next.  Will need to spend a while thinking about the layout before I dive in.

1/25/2004

The testing of the fp logic card is almost complete, so it's time to start thinking about what's next.  Originally, I'd planned to go with the device card next.  Between it and the fp logic card, I could test reading and writing to device memory.  I may still do this, but at the moment I'm leaning towards doing the memory card next.  The reason is that I believe it will be a simpler card to wire-wrap, because so many of the lines are bus lines.  I want to improve my wire wrapping skills before tackling the more complex stuff.  There's very little that I would be able to test on the memory card, but it would be good wire wrapping practice.

Finally bought a decent bench power supply (on ebay) - an HP E3610A.  Up until now, I've been using my old Heathkit microprocessor trainer as a bench supply.  Incidentally, the fp logic card draws 5V @520 ma.  When this thing is completely done (with my 100 or so LEDs as well), its going to draw a fair amount of power. 

1/22/2004

The wire wrapping is fickle.  I seem to have good runs, and then hit a wall where I have to redo the same wire three or four times before it looks good.  Anyway, tonight was a good wrapping session.  I used the cooper tools bit and wire, and it all went pretty well.  Only 24 wires left until the wrapping portion of the card is complete.  I should finish tomorrow night.  Then, I solder down the bypass capacitors and start testing.  The testing should consume at least the weekend (or what portion of the weekend I can devote to this project).  I intend to test every signal that leaves the card.  For reset, clock stop and the clock toggle I'll use the logic analyzer.  For all of the front panel LEDs, I'll use my logic probe and logic pulser.

Did run into a bit of a problem tonight.  When wiring out to the ribbon cable, I misread IRQ0 and IR0.  I then proceeded to wire in the interrupt request LEDs to the positions reserved for the instruction register bits.  I didn't catch the mistake until I went to wire up the IR.  I decided to take the easy way out.  I did not correct the wiring, but merely reallocated these lines on the ribbon cable to match the way I did it.  If this had been the backplane, I would have ripped out the wires and done it again.  But, these are just for LEDs - so I figured I could live with the awkward numbering on the ribbon cable.

Still collecting my thoughts on wire wrapping and layout so I can do a better job with the next card.  The biggest change (aside from the added width of the vertical channels) will be the handling of clocked signals.  When I'm wrapping, it seems almost required to bundle the wires to keep from ending up with an unmanageable rat's nest.  Electrically, though, bundles are bad.   My compromise position is to bundle all normal signal lines, but break out anything clocked and run those wires to avoid the bundles.  I'll use red wire wrap on those to help me keep things straight.  My theory is that noise in the non-clocked lines is okay because there will be enough time for things to settle down.  Where I don't want noise are the clocked signals.  Those will be routed to avoid the bundles, and will be exempt from the layout rules that will send wires through predefined channels.  To make life easier, I think I will wire this up normal signals first along the grid, then clocked signals avoiding the grid, and finally the power/ground connections for each package.

More though on wire wrapping, but will wait until I have time to organize the thoughts and give them a separate page.

1/21/2004

Find myself being tormented with wire-wrapping problems.  I just finished a 2+ hour wrapping session, and had a large number of snapped wires.  It gets harder as the board gets denser.  When an adjacent pin already has a wire wrapped on it, there is a little friction between the bit and the wire from the next pin.  This interferes with the lifting of the gun as the new wire wraps, and I get frequent breaks.  I'm using  my blue AD-wrap wire.  Interestingly, when it switched over to the black OK KSW wire, I had 20 or so wraps without a single failure.  Unfortunately, I don't have much of the OK red and blue wire (and the OK white wire is the worst of the lot - snaps almost every time).

Well, just need more practice, I suppose.  Anyway, I'm 80 wires away from completing the front panel logic board.  Too tired to do it tonight, but should be able to finish it within the next couple of days.

1/19/2004

Almost done with the front panel logic card.  It's been a great learning experience re. layout and wire wrapping.  I continue to have wire wrapping problems, but it's getting a little better.  Thinking quite a bit about how to apply what I've learned for the next card - mostly stuff on layout and wrapping order - will write something up when my thoughts are a bit firmer.

Back to work tomorrow after the long weekend, and am expecting the formal offer for the new job to arrive any time in the next couple of days.   Still planning to take a week between jobs - and expect to get a lot done on this project in that time.

1/13/2004

After sleeping on it, I came up with a good (I think) solution to my placement problem.  There are pin sockets for power and ground running parallel to the chip runs on my wire wrap cards.  I had originally planned on using those for decoupling capacitors, but found that the socket holes were unusually large - too big for any capacitor I could find.  However, if I solder down the caps, everything should be golden.  Alternately, I could just shave down the large packages (thanks again for the suggestion, Ron).

I will, however, redo the layout of the other cards to put two spaces instead of 1 between my 20-pin chip buckets.  To keep my required 10 rows of 7 chips buckets, I'll have a single column for 14/16-pin chips in the middle.  It will go like this:

10..10..10..8..10..10..10

The ".." is a 2-pin space, and the above all totals up to the 80-pin wide cards I have.  I can then use that 2-pin space as a vertical channel to route my wires on the wire-wrap side (and to give me some chip puller space on the component side).

Extremely busy week at work, so I'll probably have to wait until the weekend to test the clock logic.   How irritating that the paying job keeps getting in the way of the really important stuff :-).

1/12/2004

Finished the clock generation wire wrap on the front panel logic board, and discovered a problem significant enough to trash it and start over.  When laying out the board, I allocated a single pin pair for the decoupling capacitors.  I had tried this out earlier using some random chips I had, and it was tight but fit.  However, when populating the board for testing I realized that many of the chips hang over the edge far enough that things won't fit.

Not sure what I'm going to do.  Although I've put a week or so into building the front panel logic card, I'm okay with tossing it and starting over.  I'll just consider it wire-wrapping practice.  The real issue is that I had assumed a max of 70 chips per board, based on my allocating 20+2 pin areas.  20-pin devices are very common for me, particularly on the high-density alu/register card.  To be sure things fit, I would need to allocate a 6-pin area for my dip capacitors, and that would drop my capacity to 60 20-pin chips. Both my alu and control cards exceed 60 chips.   Of course, not all of my chips are 20 pins, so perhaps I can still get things to work okay by dividing the board into 20-pin regions, 16-pin regions and 14-pin regions - or something like that.  I do like the idea of having regular buckets - that gives me nice vertical channels to run wires, so I think I want to retain the plan of dividing the board up into regular regions.

Need to think about this.

Shit.

1/10/2004

Caught it early, but ended up losing a session of work.  My wire-wrap cards have some the pins already connected to power and ground.  I've added others, and have arranged it so that both the left and right sides have the same power and ground.  For those pins not hardwired, I need to connect to power/ground.    Anyway, when I used my continuity tester to list out which pins were already connected, I got left and right confused.  So, I ended up wiring incorrectly.  For the most part, it just meant redundant wires, but missing ones as well.  I went ahead and removed them all, and will redo them.  Good lesson - be extra careful with orientation, and test even what seems simple as soon as possible.

Also running into wire wrap issues again.  After a long run of perfect wraps with red and black OK wire, I tried my white OK wire and had a run of snapped off wires.  The white wire does feel just a bit different, but it also may be way I'm holding the gun.  On these snapped wires, I was trying to use a different color with my first long wire runs.  So, instead of wrapping just beneath my eyes, I was reaching a bit.  Jury's still out - need to practice to long runs, I think.

Here's the info on the hardwires pins:

Here's the info the pins I need to wrap on each card:

1/8/2004

Getting into a nice rhythm now.  I finished wrapping all of the power and ground for the devices and 0.1uF bypass capacitors.  Not a single bad wrap, and only one insulation jam.  The touch with the OK Industries gun is coming back.  Whether or not I decide to junk my first backplane, it was worthwhile doing just for the practice of ~1,600 wraps.  I'm also comfortable now with my solution for preventing spinning of the insulated wire around the posts causing too little slack.  Among the things Gil game me was what looks like a dental pick, and another similar plastic tool.  I use one of these to pull some slack in the wire before applying the second wrap.  Works well - nice and neat.

I spent about 45 minutes wrapping.  I think that's about all I am going to want to do at a sitting - and just the right amount to clear my mind and unwind my thoughts before heading off to bed.  That's the plan for the next few months: three or four nights a week, spend about 45 minutes or so wrapping wires (with debugging breaks whenever there's something to test).  Debugging with the oscilloscope & logic analyzer is likely to only happen on weekend evenings after the kids are asleep and I can commandeer the kitchen table.

Fun stuff!

1/7/2004

Okay, well maybe the world isn't going to end after all.  After more experimentation, I found a combination that seems to work.  I have two wire wrap guns - the one Gil gave me (special Cooper c/s/w run that has a relatively slow RPM) and the 220V OK industries gun that I got from HSC for $25.  It seems that my OK industries gun (with 115V adapter) with Gil's old bit works pretty well.  I couldn't get the new bit to work in anything.  Also, the best wire for my working combination was the OK industries KSW wire.

I'm a bit torqued about wasting all that money on the new bit, but there are a few more things to try.  I'll try to clean it using a solvent - it appears to have some insulation residue in the channel.  Perhaps that's what is causing the wire to bind.  Also will try lightly lubricating it.  It doesn't turn as well as I think it ought to.

If that doesn't work, I think I'll have to try ordering yet another bit/sleeve set - this time from Standard Pneumatic instead of Cooper tools.  Gil's old bit is allowing me to proceed, but I am getting insulation jams, and with as many wires as I have to wrap it isn't likely to last for the whole project.

I found some wire-wrap techniques tips on the internet, and will try to follow as best I can.  One good suggestion was to avoid daisy chains.  If I need to go A->B->C->D, I should first wrap A-B, then C-D and finally B-C.  The point here is that if I make a mistake, I will only have to unwrap at most 3 wires.  This also implies that all wires are on the same level.  In other words, if one end of the wire is the first on a post, the 2nd end of that wire should also be the first on a post.  This does mean I will need to put a bit of thought into planning my wire runs, but I need to do that anyway.

After doing a bit of real wiring on the front panel logic card, I think the main thing I have to work on in getting the right amount of slack.  I have a problem in which the gun will pull the free end of the wire around the post.  To stop this, you have to pin down the free end, by holding it or some other way.  It's easy for the first wrap of a wire, but I'm having some difficulty with the second wrap.

Oh well, just more practice, I guess.   I have several spare wire-wrap card, and one of them has a few broken pins.  I'll do some practicing on that.

In other news, it looks like the new job is going to go through.  The CTO gave his approval this morning, so all the signatures are in place.  There will be a week or so of HR processes to go through before an official offer can be made, and then a couple of weeks for paperwork after that.  I'm toying with the idea of taking a week of vacation time between the two jobs to "clear my head."  In other words, to work on this project.

1/6/2004

Uh-oh - problem.  I finished off placing the IDs and soldering down the ribbon-cable sockets & caps.  That was all I planned on doing, but decided to go ahead a do a single wire-wrap.  Got out my new cut-strip-wrap bit and the 3 brands of special cut-strip-wrap wire (Cooper, OK Industries and something I got off eBay). 

I am not getting it to work at all. 

I was  running about 1 of 10 tries for a successful wrap.  Wire keeps snapping off in the bit.  I got out the old bit, and it actually works a little better (and oddly enough - the best combination so far is the old worn-out bit and my eBay special wire - good wraps more than half the time).  Still, I can't afford even a 1 in 50 failure rate.  With as many wires as I have to wrap not only would it take too long, but I'm sure to miss a snapped wire.

Arrgh!

I'm putting it away for now.   I guess I need to do a lot of practicing to see if it's an issue of technique - but I'm not hopeful.  The wire doesn't slide in the bit very easily.  Might try making sure I don't have a little shaving or something in the bit channel.  There's also another company that has a current business making these bits, and it makes a point of selling matches bits & sleeves.  The pair I had doesn't seem to fit as well as it could.  Hate to pour more money into this - but this is crucial.  If I have to use pre-cut and stripped wire, I'll end up with a rat's nest.  If I have to cut my own, I'll not only go a little crazy, but I will have a lot of slack around short connections (with cut/strip/wrap, I can pull the slack through the bit before wrapping - or at least that was my theory).

Damn.

Off to Google to search for old articles on wire-wrapping techniques.

Shit.

1/5/2004

Fiddling a bit with the package layout on the front panel card.  The spacing on the card is very tight, and it dawned on me that the oscillators I've seen (and have) are a bit wider than normal - wide enough that I can't have anything immediately beside them.  So, I moved them into a less dense area of the card, and also allowed a bit of space between the oscillators and the decoupling capacitors.  Also, I originally had space for half-size cans.  I changed that to support either half of full cans.  I can wire it up so either will work.

Stopped by Anchor to pick up some 10uF tantalum caps.  Each card needs two, where power comes in.  Have to remember to be especially careful to observe polarity during testing.  Also got some nice pins for test points and extra wire-wrap IDs.  Next up is to solder in the caps and the 50-pin ribbon cable sockets.  Perhaps tonight.

On a side topic, the possibility of that new job has arisen again.  Keeping fingers crossed.

1/3/2004 (evening)

Hard to believe, but I think I'm really ready to start wrapping wires.  I've put the finishing touches on the schematics and assigned packages on the front panel logic card.  I'll hold off on assigning packages for the other cards.  It is going to be a bit of art, I think, to do a good job physically locating the packages in order to get decent routing of the wires.  I hope to learn while doing the front panel card, device and memory cards before I get to the ridiculously dense control and alu/register cards.

I probably won't actually start for a few days (might have to wait until next weekend).  The barrier now is clearing a workspace.  I have a desk in the master bedroom, but there are boxes of junk blocking access to it at the moment.

As far as construction procedure, I plan on using wire-wrap IDs for everything.  So, first thing is to label and place the ID tags (these are little plastic templates that go on the wire side of the board to show package and pin numbers).  Next I'll wire in all of the bypass capacitors.  I plan one for each active package.  After that, power/ground for all devices (followed by lots of testing).

I haven't yet decided on the order of construction after that - but I'll probably start with the oscillators and work outwards towards the busses.

1/3/2004

Completed rework triggered by my signal use/def/fanout analysis.  Had to correct an earlier "fix" - I discovered that the page number portion of the address bus generation was not buffered.  So, I added buffering - but I added on the ramrom sheet because there wasn't much room on the page table sheet.  Wasn't thinking - the ramrom sheet is part of the device card, not the memory card.  So, I managed to shuffle things around a bit and squeezed the buffering on the page table card where it belongs anyway.

I went to do the simulator update, and can declare that it's updated.  Though, actually, I ended up not changing any code.  All of the changes involved moving clocked signals generation onto the control card.  However, in the simulator code latch signals are handled specially - computing them at the place where they are needed rather than on the host card.  So, no changes needed.  The simulator is current.

Next up - assigning devices to the front panel card.  Perhaps tonight.  Also need to restructure this web site a little.  I'm going to replace the Photos page with "Construction" - or something like that.  There I'll have links to pages showing pictures of the construction of the backplane, cards, etc.

1/1/2004

Making a pass over the schematics to verify resistor values.  The most interesting ones were the pull-downs for the page table base.  The idea here is that when in supervisor mode, the PTB is fixed at 0x00 - otherwise it takes the value of the page table base register.  The PTB register was a 74f374 octal D flip-flop with 3-state output.  So, I'd control the 3-state output with the mode bit.  If we were in supervisor mode, I'd disable output, and then my pulldowns would snap the state to  0x00.  If not, the output of the 74f374 would overpower the pulldowns and it's value would be used.  However, I was having a bit of trouble deciding on the correct resistance values for the pulldowns.  I've mostly done pullups - so I understand those a bit better.

Anyway, I decided to change the pulldowns to pullups - so 0xFF would appear on the PTB output when in supervisor mode.  I could just change the documentation to say that 0xFF is the page table base for supervisor mode, but that seems somewhat inelegant.  0x00 feels more correct.  So - nice solution: there is a variant of the 74F374 that inverts its outputs, the 74F534.  I'll use that instead, so as far as the world is concerned, 0x00 is still the supervisor PTB.  However, the base will be inverted internally and the opposite bits will actually be addressed in the page table SRAM.  The only time this inversion will matter is during hardware debugging.  The 74F534 is a bit of an odd device, but Mouser has a bunch at $0.85.

Click here for 2002 diary entries