Image Map Image Map
Results 1 to 8 of 8

Thread: GW-A680-RAM1, a New Universal RAM Board for the Altair 680

  1. #1
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,093

    Default GW-A680-RAM1, a New Universal RAM Board for the Altair 680

    PREORDER LINK: https://services.theglitchworks.net/...t=gw-a680-ram1
    IMGUR ALBUM: https://imgur.com/a/iQ3IH

    In February 2017, I posted about Altair 680 prototying board availability. This protoboard was designed to facilitate creation of a new universal RAM board for the Altair 680. It started as a project over on the Altair Owner's listserv, based on an initial design by Chris Elmquist. The first protoboard prototype was mostly completed months ago:



    It has...many wires:



    The prototype was key to figuring out a few things. First, how to deal with the front panel, since MITS doesn't assert VMA when the front panel is in operation and I wanted to use PHI2*VMA to qualify memory access. Second, how to make front panel access work with Ferroelectric RAM (FeRAM), which is basically core on silicon. FeRAM is super handy when debugging, especially on a front panel machine. Both of these issues were solved, and recently I've had time to actually do the layout for a production board. The prototyping phase of the PC board is now complete. Here's the results:



    From the front. As you can see, there's a lot of prototype space on this board! Dan Roganti and RetroHacker_/Sark pushed for a simpler design and prototype space, rather than a board that tries to be everything to everyone. I think that was ultimately the best possible decision. It also means the board didn't take *another* year to be completed



    There's a jumper area to select whether the board's Vcc is taken from the +5V rail on the Altair 680 bus, or derived from a local regulator supply. Which you choose will probably depend on whether or not you have the original MITS single-transformer power supply. The +5V regulator runs hot enough as-is with the original supply. I don't have a machine with an improved supply to test with. Of course, if you've switched to a modern regulated switcher, you'll want to use +5V from the system bus.



    The prototype required only one serious fix, as seen above, made with yellow wire. The polarity of the clock to the main data bus latch was inverted. A spare NAND gate was used to correct it.



    I built a lamp register in the prototype area, mainly to test out the provisions on the board for user-implemented circuits that use board facilities.



    The TI 74L00 in the middle of this image is where the intermittent machine pin socket is. I ended up soldering the IC directly into the socket to fix the problem.



    Wiring on the back side. Yellow is data bus, blue is address, green is control, and red is everything else (interconnects).

  2. #2

    Default

    Looks very nice glitch!

  3. #3
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,093

    Default

    Quote Originally Posted by alank2 View Post
    Looks very nice glitch!
    Thanks! One slight SNAFU, I thought I'd better go back and stress test it with FeRAM installed, since I'd only minimally tested with FeRAM. Good thing I did! Turns out it has write timing issues. In an odd twist, it seems that the write cycle is too long for FeRAM -- the datasheet hints at this, saying that there's a maximum *CS active time, but fails to state it! Anyway, I ended up using a 74LS123 to set up a one-shot to shorten the *CS pulse. Here's the logic analyzer:



    RAMCS0 (third from top) is the original *CS line. Note that it and phi2 are slightly over 1 microsecond long! The bottom trace is after the one-shot, it's about 630 nS which appears to be totally fine. It doesn't affect data readout since data is latched earlier in phi2 time.

    I didn't catch this earlier because, once again, everything works totally fine from the front panel. Reads from the monitor also work totally fine. But, writes of some data patterns will be corrupted. I usually quick test with 0xAA and 0x55 patterns, and those always write correctly! I suspect bus capacitance is holding the data a little past the end of the erroneous second write cycle in that case. Anyway, it's been churning away on Martin Eberhard's memory test for a while, and seems to be fine now.

    I'm tempted to leave this as an optional user fix in the manual. I suspect the vast majority of people will be using the GW-A680-RAM1 with static RAM, not FeRAM.

  4. #4
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,093

    Default

    Here's the real fix I came up with last night, and implemented today:



    I'm generating a synchronized modified phi2 clock using a 74LS74 D-type flip-flop. PHI2MD (second trace from the bottom) is the new signal. It's 500 nS long and both lags phi2 start and finishes before phi2 end. Being 500 nS, you could quadruple the CPU clock and still be OK with the slowest of 32K SRAMs I have on hand. I doubt the rest of the Altair 680 design would stand up to that

    But, why is this necessary anyway? Isn't the Motorola 6800 bus cycle supposed to be locked to phi2? Shouldn't it be fine to use it to demarc your bus transactions? Maybe, if we were using the phi2 that the CPU actually sees:



    I believe the above is our real culprit here. The top trace is phi2 as it goes into the 6800 CPU. The bottom is what the bus sees, after a buffer element. Notice that the lower trace starts to fall about 40 ns after the top trace. So, phi2 that the expansion bus sees ends 40 ns after the real phi2 time. That probably matters for fast memories.

    Does anyone know why MITS would've driven the CPU with the non-buffered clock? Their clock circuit is another weird one, with discrete transistor output drivers...not sure why they're doing that, I would appreciate any insight!

  5. #5
    Join Date
    Sep 2006
    Location
    Silicon Valley
    Posts
    1,520

    Default

    Quote Originally Posted by glitch View Post
    Their clock circuit is another weird one, with discrete transistor output drivers...not sure why they're doing that, I would appreciate any insight!
    NMOS processors of that era required higher than TTL output voltage levels on their clocks. Z80 required a MOS clock driver as well.

  6. #6
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,093

    Default

    Right, but a goofy transistor driver doesn't seem to be the way to do it -- the bus buffers are in fact CMOS, swinging nearly full Vcc as seen in the oscilloscope traces. 6800 spec sheet says Vcc - 0.6V.

  7. #7
    Join Date
    Jan 2011
    Location
    Vancouver, BC
    Posts
    3,312
    Blog Entries
    1

    Default

    I must compliment you on your work. Always amazed!

    Can you only produce boards if you have an original to scan? I'd really like to build a replica of the digital group's first 'tv typewriter' video card... but all I have to go on are photos of the front and back.

  8. #8
    Join Date
    Jan 2010
    Location
    Central VA
    Posts
    4,093

    Default

    Quote Originally Posted by falter View Post
    I must compliment you on your work. Always amazed!
    Thanks! I try to do a good job

    Quote Originally Posted by falter View Post
    Can you only produce boards if you have an original to scan? I'd really like to build a replica of the digital group's first 'tv typewriter' video card... but all I have to go on are photos of the front and back.
    It's possible to lay it out again, but especially with no physical board to trace out, the probability of making a mistake goes up. Plus then you don't end up with the "vintage layout" feel of the board, since it'd be done in a modern CAD package, with everything snapped onto a grid, etc.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •