Alastair HewittSo there's the easy problem (designing a computer out of TTL) and then there's the hard problem (make it work at 12.5 MHz).
I was close, but not quite there. The RAMDAC was hitting the wall with a dot clock above 21 MHz. I have to simplify the logic that switched between the 16 and 8 colors in text mode. I have to take the ZX Spectrum approach and drop to 15 colors with a subtractive intensity rather than additive.
The instruction decode looked good on paper but I forgot about the 10 ns propagation from the clock to output of the instruction register. I was able to find a solution but the entire decode path barely fits in the 80 ns machine cycle. Too much parasitic capacitance in a PCB layout and things will get glitchy once the chips reach a toasty 70 C.
So I've been shuffling things around and doing some consolidation. I'm back to a solid design, but I will need to redraw the schematic. I'm not spending another weekend doing that by hand, so the next schematic will be a proper CAD drawing. But saying that, it's time to start building and verifying this thing will work at these speeds. Only then is it worth documenting the verified design.
Not surprisingly the first thing to test is the clock and bus control state machine. After that the instruction decode and CPU state machine. I'll then be able to run a simple jump/loop program. It won't be Turing Complete, but if that program runs reliably at 12.5 MHz then everything else will work. I can then start on the fun stuff like adding RAM and the video output. Then the really hard problem (software).
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Not sure I completely follow. Is this HC670 being used in the 40ns cycle? I remember looking at these a while back. You can only get them in the HC series and the propagation delay is quoted in the 50-60ns range. They are powerful, but very slow.
I'm using a 3-stage pipeline in the video output stage. The RAM is 55ns and I have 80ns to read it. This is barely enough time even with the fastest TTL to set up the address (12ns tri-state change) and latch the result (5ns setup, 2ns hold). The result is now in the first cache layer (gc cache) where it can be used for ROM addressing on the next cycle or passed to what I call the RAMDAC (P register). This has a multiplexer to switch between two 4-bit colors in the 40ns cycle. The output of that is then latched again with the dot clock to create a stable video output.
I borrow the RGBI intensity bit in text mode to select between different fonts so I need some logic between the multiplexer and final latch. This was 3-layers deep and taking up to 20ns. I was running out of time from the clock input of the shift register used to select the multiplexer to the clock on the output latch. I dropped the logic down to one layer, but can only support a RGBI palette where I "subtract" the intensity resulting in 2 blacks (15 colors). The worst case clock-to-clock accumulated Tp has now dropped from 49 to 36ns though.
Are you sure? yes | no
Looking in TI datasheet of HC670, in the Features section they say Typical read time 16nS. I could give it a try.
Can you not use faster RAM ? Or is that SMD or 3V3 only ? Not all SMD are diffcult to solder, I think.
And, by using larger RAMS you could remove a few video modes, removing the complexity of switching between them.
Are you sure? yes | no
I always look at the worst case :) Things are likely to get pretty warm at these clock speeds, which tends to slow things down.
I derive the control signals for both ROM and RAM access from the same logic. I have to make it work for the 55ns ROM, so the RAM doesn't need to be faster than 55ns. You also have to go SMD if you want faster than that.
Sticking with the slower chips forces you to follow the same design patterns used in the original early 80's TTL video cards. It's been an interesting learning experience.
Are you sure? yes | no
Hi Alastair,
having a 80nS cycle time and reading a flash ROM in that time can be very difficult indeed.
But you said you might have to change the video display unit. I want to share with you what I now consider for the Kobold computer. Perhaps it is useful for you.
The video system has its own RAM. So video and CPU can both run at max speed because (almost) nothing is shared.
Video runs at 80nS cycles. It only uses RAM and no ROM, so with 20 ns RAM this should be fine.
Video reads 16 bits at a time from the video RAM. Four of these bits will be used for two pixels (40nS pixel time). Each pixel can choose from 4 palette colors. Eleven bits define a new palette color (2048 colors). The last remaning bit determines if the new color is used or not.
So the following data is sequentially read from video RAM:
1) RRRR GGGG BBBF PPNN If F=1, defines palette color 1. PP=pixel, NN=next pixel.
2) RRRR GGGG BBBF PPNN If F=1, defines palette color 2. PP=pixel, NN=next pixel.
3) RRRR GGGG BBBF PPNN If F=1, defines palette color 3. PP=pixel, NN=next pixel.
4) RRRR GGGG BBBF PPNN If F=1, defines palette color 4. PP=pixel, NN=next pixel.
So, the color palette has four entries.
There is no really separate mode for text or color. For text, it is convenient if no RGB data has to be given with every two pixels, so F will be 0 for that, giving 40nS text pixel resolution.
For color images, each 40nS pixel can choose from 4 palette colors. And every 80nS, a new palette color can be defined.
The color palette can be implemented with just three HC670 chips.
What do you think ?
Are you sure? yes | no