Project Logs

Collapse

• REV1 PCB Pitfalls, whats next?

  Dave Collins • 6 days ago • 0 comments

  Reflections:
  

  General reflections from last time
  

  Well you read the title here, so its not hard to guess what the outcome from the first PCB run was.  In short, the 1st PCB design has issues.

  I tried working evenings for the last week to get it to come to life, however there are a ton of stability and possibly further routing mistakes that meant that all scaled into very bad ringing, noise and timing issues.  To be clear, none of this is the manufacturers fault. All the issues and pitfalls in this design lie solely on my shoulders.  I have plans to fix the issues, but its going to take some time and a step back to really understand  the problem.

  What is next?
  

  I want to take a step back and look at the design in pieces.  I still have a handful of boards left over from the HB6809, There's ample prototyping space on there for me to experiment with.  This weekend I want to start by building a very simple but very stable Pierce oscillator,  and see if I can get the CPU, RAM and ROM to come up on a 16Mhz base clock.  Once this works I will work to add subsystems and to a much better job of documenting the build up as I go. 
  

  On the firmware side over the next two weeks I want to focus on getting the RAM to stage on the breadboard build without using the latches.  I think I can use the CPU to stage it's own ROM space by feeding it one byte of machine code at a time running in peripheral mode (I discuss this in the architecture overview) .  This will further get the chip count down, which is important because the end goal is to have a computer that is built on 10cm x 10cm boards (or less) and currently they are 170x170 so we need almost a 50% reduction, or to switch to a mini frame design with expansion headers that link the boards together.  I also DO still want a 68C09 motherboard that just drops into a PC case, because that was the whole idea in the first place, but a lower cost version would also be nice in terms of making the design more accessible.

  PCB review how they hold up to rework: 
  

  Speaking of the PCB's, I wanted to share my thoughts on the boards produced by PCBWay, what you get in  terms of cost for a large format board like this as well as what it's like to rework a two layer rapid turn PCB like this with manual tools.  

  First, and I've touched on this before, PCBWay does a higher than average job on masking.  If you wanted to make a short run of boards with ENG or even Lead Free HASL, for commercial sale these boards really do hold up.  Nothing peels with normal handling, and it stands up to even the highest level of abuse.  The edge finishing is top notch, nothing is left with a sharp edge (unless you specify that, of course!) and I never felt like if I handled the boards without gloves that I would be cut or that the edges would catch on the work surface.  Other manufacturers in China do not take the time, as PCBWay does, to really get this right. 
  

  As an example, the 14 pin socket had to be completely removed to rework trace mistakes that were made in the design files using just manual tools (which always require a level of care), I was able to remove the socket and replace with only minimal mask removal, and all of this was around pins which tie into board planes.   If I had a a reliable way to preheat the board none of this would have even been an issue given the finishing on the PCBs.
  

  On average, PCBWay is more of an expense.   But all of these touches are a value add, and I believe given the blazing fast turn around to North America, the quality really is worth the expense.  I would have no problem recommending them over the other producers in China, they do a great job with what you pay for. Additionally they don't over charge for shipping and have several options depending on your required turn around (which all obviously scale with the price.)  They also continue to offer a low price...

  Read more »

• The architecture overview

  Dave Collins • 10/10/2023 at 03:25 • 0 comments

  As I wait for PCB's to arrive from PCBWay's factory in China, I thought I would spend a few moments to go over the general architecture of the computer.  We can start with a simple memory map:
  

  The computer consists of a single 128K low power SRAM, a Hitachi HD63C09 (internal clock version), an AVR ATMEGA32 micro controller, Latches, buffers and decoding logic.  The current plan is to load the memory from the micro controller while the system is in a halted state, and enter the reset vector on the system reset which is triggered by the AVR.  The 63C09 does all the heavy lifting and currently is clocked at 4 or 8 MHz, which provides an E strobe of 1 or 2 MHz.  No emulation, just 8 bit muscle applied in all the right places.  The AVR does NONE of the code of the computation this is solely a computer that can run native 6x09 machine code. There is some down the road planning to expand the CPU clock to a faster speed but there's a few hurdles to jump before we can get there.

  Sharing the bus the AVR as a peripheral:
  

  There's a number of little computers out there that operate along side a micro controller in various ways, sharing the bus in different ways.  The Z80-MBC2 (which shares a lot of design language with my project) uses a wait / grant architecture to make sure that only one CPU accesses the bus at a time.  For the fully static Z84C0010 - a modern Z80 variant, this is no particular difficult chore, as you can stop the CPU for even a long time and hand data off to the CPU via the bus, before it's latched and the CPU carries off on it's merry way.  The very popular Agon light uses an esp32 to produce VGA signal and communicates with the main system over a 1Mbit serial connection, now that seems like it might hamper performance, but for processors of the day with full speed parallel access to video memory that's faster than most 8 bit bus's of the era.

  Our build uses a similar request grant architecture to the Z80-MBC2:

  Just two gates, and a 138 decoder IC. A very basic circuit lifted from Brad Rodriguez's Scrounge master design, though due to reasons he lays out in later in his series on the scrounge master, he ended up going another way.  For us the circuit is perfect as the AVR solves most of the limits set by the original design, and we don't need the extra latch he uses for clock synchronization.   Essentially, the bus decoder waits until it see's a request in the Io-range of 0xB000 to 0xB3FF.  Once it is triggered it sends a signal to the two gate request/grant circuit which will send the output (mrdy) to a low state. This holds the CPU to the point in time right before it's data latch. The AVR controls  state of /iogrant and holds it high unless it is sending a 'grant' signal.  Once the data is either read from, or written to the bus the AVR sends /iogrant low which sends the output (mrdy) high.  A high signal on the mrdy signal lets the CPU pick up where it left of and it latches the data as 'E' falls.  This set up has three pitfalls.

  1. The CPU can not be held off longer than 6uS per its data sheet, it's registers are dynamic and need to be refreshed.
  2. The AVR has to control the low state of /iogrant using a timing delay generated by no-ops to prevent mrdy from 'bouncing low' before the request cycle has completed.
  3. the AVR can not 'be in two places at once' - that is; it can not control the timing on the grant signal AND clear the bus of the data port at the same time.

  We solve these problems thusly: First every operation has to be kept to 6uS -- this is 100% achievable using careful coding - even with C, however every opportunity to quit to the exit of the current poling loop must be taken.  Second, we carefully time the delay using an analog scope to properly calculate and test the exact delay, through testing this is approximately 500nS at 2 MHz and 1us at 1 Mhz. NOTE: this delay is not a part of the 6uS limitation...

  Read more »

View all 2 project logs