Project Logs

Collapse

• Sharing the bus with an Arduino without a latch

  Dave Collins • 01/21/2024 at 02:09 • 0 comments

  REV3 Works and synchronization scales exactly as expected!

  In short, the REV3 prototype is running at 20MHz. All of the underlying functionality is synchronizing, scaled up from 16MHz with zero issues. I am ecstatic and want to thank PCBWay for getting the prototype to a stable state by again covering a 2^nd run of the mini ITX PCB. They have always been a wonderful partner in retro and I would not be able to operate nearly as quickly as I do without their help.
  

  The problem of the REV1 Prototype:

  What we learned from REV1 specifically is, using the AVR to Clock the CPU is bad because we don’t know (inside the context of the code) where the CPU clock is at when we send the IOGNT_ signal as it is interrupt timer driven. Generally the best we can do is guess, and insert a delay (as the AVR in REV1 was clocked at 16 Mhz and the CPU was clocked at 4Mhz). Guessing is bad as there is, turns out – a lot that can happen to delay or decrease the period of time the AVR takes to finish this process. This causes a bit of instability and made it generally impossible to move forward on optimizing things.
  

  How does the AVR share the bus with the HD63C09?

  The bus arbitration was switched from active arbitration (REV1) where delays were used to insure the IOGNT_ was held long enough to prevent MRDY from bouncing, to passive synchronized arbitration (REV2 and REV3).   Essentially what this means is, both CPU's are using the same system clock and so every 4 cycles they finish their current cycle at the same time. To really understand requires some explanation, This all comes down to the specific timing of the 63C09’s decode cycle.

  the following timing diagrams snap to the system clock, this is to show how the clock synchronization works vs actually showing the nS to nS events, some edges happen just before or after they are drawn here so for simplicity sake - please pardon that inaccuracy.
  

  
  

  The 63C09 creates the quadrature clock’s (E & Q) which are 90 degrees offset from each other. In the case of the HB63C09M these clocks run at ¼ the system clock due to a simple internal clock divider that uses a set of J/K Flip Flops (each flip flop divides by 2). The 63C09E (‘E’ for external) generates this clock external to the chip, which opens up some of the 40 pin package for extra signals which are useful for more traditional bus arbitration. Both CPU’s have the option of using a clock stretching circuit which allows the designer to “hold over” or stretch the clock by up to 5uS. This 5uS limitation is to allow the CPU to refresh its internal dynamic registers to avoid data corruption. I briefly went over this in REV1 architecture overview.
  

  While significant changes have occurred within the selection chip set, the request grant circuit remains consistent. In this circuit, the AVR typically keeps the IOGNT_ signal high, except when it intends to relinquish control of the data bus to the CPU. When the CPU reads or writes to 0xA000 – 0xAFFF, this generates an IO request via the address decoder. Once the IO request is initiated, the address decoder generates a low signal that, after passing through an inverter to one input of the NAND gate, sets the output low as long as the leg tied to IOGNT_ is high. This output is tied to the MRDY signal on the CPU and begins a clock stretch. This state persists until the IOGNT_ signal pulsed low by the AVR for exactly ½ cycle of E.

  REV2/3 Decode / Bus Arbitration Circuit

  Simple enough right? But what if we release IOGNT_ before the IO Request ends (less than ½ of E)? In short, we would have a problem. Since it’s just a passive logic circuit it would compute the result and pass it along to essentially the MRDY line causing it to bounce a few nS before the IO request finishes – this may trigger a second clock stretch early, or cause other unpredictable things to happen on the busses or inside the CPU which usually just result in a non working system.
  

  So...

  Read more »

• REV3 Prototype chipset overview

  Dave Collins • 01/04/2024 at 19:58 • 0 comments

  REV3 Board Render (top)

  The Rev3 Board is basically a copy of the hand wired Rev2, itself a retrofit HB6809.   The Hand wired prototype (see below) was more or less the new chip set design, along with a very stable pierce oscillator I built in about 2 weeks time working nights.    What was accomplished  with the REV2 build was considerably faster clock, which clocks both the 63C09 and the AVR simultaneously at 16 Mhz.  The plan is to push the Rev3 to 20 Mhz.   In order to do this it was clear I had to make some tough choices about the chip set.  Looking back at the failings of the REV1 board, one of the biggest issues was chip count and latency.   These things didn't matter as much on the breadboard prototype as it ran an asynchronous clock (similar to the Z80-MBC2) with the AVR clock coming from a crystal oscillator, and the AVR it's self clocking the 63C09 at 1/4 to 1/2 it's clock.  But when I translated that design it didn't seem to work well on the PCB.   This coupled with several mistakes made while documenting the Big mess of wires breadboard, and in the actual routing mistakes the whole board was more or less a non starter.

  REV2 hand wired board

  What I learned from the REV1 board is to fit all of these components comfortably on a Mini ITX motherboard, I needed to reduce the chip count to make all of the connections fit (or go to a significantly more expensive multi-layer board).  In order to do this I had to significantly reduce the chip count, and in the case of the bank selection circuitry I further reduced the space the chips take up by both simplifying the the design and choosing different parts.  A few of you have commented that it might be simpler to just roll together a custom ULA for the design.  I think that this makes a lot of sense, but the trouble with that approach is that it may become harder to find CPLD / GAL parts as replacements.  This is not the case using standard 74 series parts, and as you will see below the design is very simplified to what I could determine as the fewest possible parts to accomplish what was needed.

  New memory map:

  The simplified memory map made using less logic chips for address decoding significantly more obtainable.

  	ROM / RAM Configuration
  Addreses	64K Main Address Space
  B000-FFFF	Upper Fixed Ram 20K Physical Rom Space (
  A000-AFFF	Device Address Space for MCU and Mezzanine connection
  4000-9FFF	Lower Fixed 24K Fixed Lower Ram Bank
  0000-3FFF	Memory Bank Window, set by bank register (16K)
  	128K RAM Chip Layout
  1C000-1FFFF	Bank 7 (16K)
  18000-1BFFF	Bank 6 (16K)
  14000-17FFF	Bank 5 (16K)
  10000-13FFF	Bank 4 (16K)
  C000-FFFF	Bank 3 (16K)
  A000-BFFF	Bank 2 Usable – 8K of usable space 2000-3FFF in bank address
  8000-9FFF	Bank 2 Lower Fixed Ram Bank top 8K of Memory “Shadow”
  4000-7FFF	Bank 1 Lower Fixed Ram bank bottom 16K
  0000-3FFF	Bank 0 (16K) system boots with this bank loaded giving 40k cont.

  “Bank2” selects the ram chip between 8000-BFFF.  When this bank is selected, 0000-1FFF (in the bank) will map to the last 8K of the fixed RAM area (in the 64k address space of the CPU). Whereas 2000-3FFF is available for use for programs. Overwriting the bottom 8K will cause data corruption in the top of the fixed RAM area (in the 64k address space of the CPU), As this is effectively the same area on the ram chip.
  

  In “RAM Only mode” the address range B000 – FFFF is physically writable at that CPU physical address as the ROM is disabled.  This can be configured on the board by removing the “ROM Enable” jumper
  and moving the Ram selection Jumper to “RAM” In this mode the AVR needs to be configured to update the ram from SD at boot. This is not yet implemented
  

  The bank selection...

  Read more »

• REV1 PCB Pitfalls, whats next?

  Dave Collins • 10/21/2023 at 21:30 • 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 4 project logs