• VAPID Mods

    Steve Toner • 03/03/2023 at 06:48 • 0 comments

    VAPID: Vector Adorned Programmed Instruction Decoder

    Added a new output device: 3 channels of D/A conversion using a Burr Brown DAC7624.  This chip provides four 12-bit D/A converters, but I'm only using 3 and only using 10 bits to make the interfacing simple.

    The implementation is a bit of a kludge, as the original STUPID computer was designed with only a single I/O device so there is no clean way to specify which I/O device to use.  The solution used here (for output only) is to have the high bits of the AC (which holds the value to be output) specify the device.  Four 8-bit devices and 3 10-bit devices are supported.  If the high-order 4 bits are all zero, the TTY is indicated.  This makes the mod backward-compatible with existing code, as only  8 bits are used when outputting to the terminal and the high bits are always zero.  They didn't absolutely have to be in the original implementation, but no existing code uses the high bits for anything.  One additional instruction, OUTPUT,  is defined as the existing PUTC instruction waits for the UART to be idle before sending the byte.  The new instruction sends the data directly without checking whether the device is ready for it, so any necessary checking must be done under program control.  But again, for backward-compatibility, the PUTC instruction is retained (just don't try to use it if any of the high bits of the AC are set...)

  • Diagnosing the Monitor Problem

    Steve Toner • 09/03/2020 at 03:51 • 0 comments

  • STUPID Goes to VCF West

    Steve Toner • 08/17/2018 at 16:12 • 2 comments

    ...and on that note, this project will be taking a vacation so I can work on other projects.  I still have to figure out what's going on with the serial communication (and will use that as an excuse to pick up an old HP Protocol Analyzer somewhere down the line).  There are many other things I could do as well, but as  Proof of Concept (which is the most fun part of any project imo), it's done.

  • STUPID Meets OOD

    Steve Toner • 06/22/2018 at 21:18 • 0 comments

    Evil plan starts to come together...


  • Case

    Steve Toner • 06/15/2018 at 17:44 • 0 comments

    Almost complete...  Case of Aluminum and acrylic.  Still need to install the serial cable.

  • Logo!

    Steve Toner • 06/14/2018 at 23:15 • 7 comments

    Just to make sure nobody asks if it's a Raspberry Pi or a 6502...

  • Updates

    Steve Toner • 05/28/2018 at 03:47 • 0 comments

    I added a new instruction, break, which halts the processor after incrementing the program counter.  The halt instruction does not increment the PC before halting, so it is not possible to continue (or single step forward) from a halt.  When debugging a program through the front panel, it is handy to be able to stop execution (to allow examination of registers or memory) but allow the program to be continued.


    Uploaded the microcode.  I can't believe I didn't put this up before now.  Also uploaded rev 0 of the assembler and the Fibonacci number assembly language program, for those who are curious what a STUPID program looks like in assembly language.


    I still need to update the schematics and upload the latest version...


  • Assembler

    Steve Toner • 05/15/2018 at 16:12 • 0 comments

    When it's too much to toggle in...

  • Weirdness

    Steve Toner • 04/04/2018 at 03:56 • 0 comments

    OK, let's see if anyone can explain this:


    After making the changes shown in the previous log, I fires it up with the same microcode that was in before the changes (changes are fully backward-compatible), and everything seemed to work fine.  So I put the decrement back in the microcode instead of the workaround I had and...it failed miserably.  Couldn't even make it through the power-on self test.  The most common failure mode had it branching to E2F when the microinstruction said to branch to E1F.  Bad build?  I reassembled and burned the Flash again and...same thing.  Maybe the counter chip's gone bad (very low probability, but easy to check).  Swapped chips around.  Same thing.  Verify input signal is valid & setup time OK.  But the middle counter (there are 3 cascaded 74F161 counters providing a microcode address) was already at 2 - I can't tell if it's failing to load that counter, or if it loads the 1 and then increments it.  Well, what does the clock signal look like?  Attach an oscilloscope probe to the clock input of the counter chip and...everything works.  And the clock signal looks fine.  Just a small amount of ringing.  Well, this is the end of a run (clock drives 6 loads across 3 boards, so it's not a true bus).  Try Thevenin termination.  No change.  Fails without scope lead attached, works with it attached.  Let's see...the scope adds capacitance, which will slow the rise time of the signal.  74F chips have a very fast rise time.  Let's try a 74S instead.  They're fast but from what I've seen, don't have as fast a rise time on the leading edge.  No difference.  Well, how about a 74LS?  Fails miserably in a different manner than the F & S chips. 


    Hmmm, I've got a 74HC chip here, let's try that... Everything works! wtf???


    The signal I'm looking at is CLK2.

    There's no pullup on the input to the other half of the flip flop (pin 12), which is driven by a 74S374, but that part works fine as well.  The MIR9 signal is not connected to any other inputs, so it's not seeing much of a load.  So really just reduced noise immunity there, which, as I said, is not (currently) showing up as a problem.

    So what's going on?  It doesn't seem like a reflection issue, as terminating the signal line should have at least helped with that.  The hardware change was in the ALU, which is on another board and does not see the CLK2 signal, though the CLK2 signal is present on that board (clocks the "result=0" flip flop).  Crosstalk causing a glitch on the clock signal?  Enough to trigger the counter but not the logic analyzer?  Scope probe capacitance filters it out, and higher output voltage of the HC chip keeps it from crossing the logic threshold levels?  And why did it work OK until I changed the microcode???

  • A Few Changes

    Steve Toner • 04/02/2018 at 18:20 • 0 comments

    Don't know if I'm going to have time to do a video for this, so will try it the old fashioned way...

    Progress:

    • Added U95 XOR gate to allow inverted branch conditions.  MIR11 (bit 11 of the Micro Instruction Register/Microcode instruction)  determines whether the condition is inverted or not.  This necessitated another minor change.  The /DRR (Data Ready Reset) line to the UART is asserted when the character is read from the UART.  This requires us to know whether an apparent reference to the UART (register 3 on the B Bus) is an ALU operation and not a branch.  Since an ALU operation may assert MIR11, there are two possible cases for an ALU operation: branch condition = 0000/MIR11=0 & branch condition = 0111/MIR11=1.  Fortunately, I chose to use a comparator (74LS85/U88) to generate the signal, so all that was necessary was to change the B1, B2, B3 inputs to MIR11 instead of ground.  This mod, of course, is just an optimization but it cleaned up the microcode nicely I think.
    • Updated the microcode to use the new inverted branch conditions.  This eliminated over 20 microinstructions.  The most common case was branch-if-non-zero <target> replacing branch-if-zero .+1/branch <target>. 
    • Added some wire wrap pins to the board for the Micro Instruction Address to make hooking up the logic analyzer easier. 

    These signals are not carried out to the bus, so required the use of grabbers to access.  With the pins, the leads can connect directly.  The pins are mounted upside down so they stick up from the top of the board.

    • Added the Moving Inversion Memory Test to the main microcode.  If you hold the EXAMINE switch when pressing RESET, it will run the test continuously.  Press RESET to get out of test mode.

    The Moving Inversions Memory test does occasionally fail, but it's not a memory problem.  It always fails on the reverse test when it is decrementing the memory address.   Example failure: MemAddr = 8FF, expecting a pattern of E00 but seeing a pattern of C00.  Memory locations 0-7FF contain E00 while locations 800-FFF contain C00.  This appears to be a carry propagation time issue with the ALU.  Assume MemAddr was at 800 and was decremented, but we latched the output before the high 4 bits settled.  Then, instead of 7FF we have 8FF.  Have not been able to confirm this with the Logic Analyzer because it is so infrequent, but changing the decrement instruction (MAR <- --MAR) to 3 instructions (MAR <- ~MAR/MAR <- ++MAR/MAR <- ~MAR) eliminates the problem.  Looking at the '181 data sheet, a difference operation does take slightly longer than a sum operation (on the order of 1-2nsec), so it appears that it is running right on the edge.  Which is odd, because I calculated the worst-case delay for a microinstruction as something like 88 nsec, which is well within the 100nsec cycle time.  Either I calculated wrong somewhere or the chips I'm using didn't read the data sheet...

    Anyway, a couple of solutions come to mind:

    1. slow down the clock.  Substituting an 8 MHz oscillator for the current 10 MHz one would add 25 nsec to the cycle time, which should be more than adequate.
    2. add a 74F182 carry lookahead generator and leave the clock alone.  This should gain, I dunno, maybe 10 nsec for ALU operations which would bring it back in line.

    Since I have some '182 chips, I'm going to try solution #2.  The only problem is that the ALU board is full.  But there are some individual pads down by the bus lines (you can see in the lower left in the picture above) where it can be put - they're the pads that the power input connector is soldered to on the microcontroller board -  just won't have the niceness of 3 holes-per-pad...  I think once this chip is added, the hardware will be done.