Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
|
BigDumbDinosaur wrote: I have restarted design work on POC V1.4...I will soon be posting more about it. POC V1.4 is an evolutionary update of POC V1.3. Here’s the schematic:
Attachment:
File comment: POC V1.4 Schematic
pocv140.pdf [365.63 KiB]
Downloaded 103 times
...and here’s the printed circuit board:
Attachment:
File comment: POC V1.4 PCB
poc_v14_pcb.gif [ 408.57 KiB | Viewed 167694 times ]
V1.4’s bank $00 memory map is somewhat different than V1.3. Each I/O device occupies 128 bytes of address space, compared to the 256 bytes that older POC versions have used. Also, there is no mirroring in the I/O block. So instead of I/O extending from $00C000 to $00CFFF, as it did in V1.2 and V1.3, it now occupies $00C000 to $00C3FF. As a result, previously-inaccessible RAM from $00C400 to $00CFFF is now exposed, for a total of 3KB. That RAM will be “owned” by the system firmware, and will have enough room for direct page (256 bytes), the hardware stack (256 bytes), the serial I/O queues (2048 bytes), and BIOS kernel and M/L monitor workspace (512 bytes). Everything in bank $00 below $00C000 will be unencumbered, as will be the case with bank $01 RAM. ROM will continue to be visible from $00D000 to $00FFFF.
One of the benefits of the new memory map is applications can set the top-of-stack and start of direct page anywhere below $C000 without interfering with the firmware. That gives applications 48KB of contiguous bank $00 RAM for their direct pages and stacks. As firmware API calls are via software interrupts, applications can run equally well in bank $01, which makes possible having TSR programs loaded and readily available when needed (a feature also possible in POC V1.3, although with less bank $00 “elbow room”). This capability is made possible by the relative ease at which 65C816 programs can be made relocatable.
Hardware-wise, there’s the GAL, an ATF22V10C, to replace all of the discrete address-decoding logic used in the old POC versions. I was able to get hold of the somewhat-elusive 7.5ns part, so I’m not expecting any timing contretemps (famous last words  ). As the 22V10 has only 10 dedicated outputs, I am still dependent on some discrete logic, namely an OR gate to produce a valid address signal (VADR, which is VDA | VPA) for the GAL’s benefit. Since it is the only use of an OR gate in the circuit, I designed around a LVC1G part, which economizes PCB real estate consumption. Plus the LVC1G part is slightly faster than AC or AHC logic.
Clock generation is completely different than that of V1.3. V1.4 uses a synchronous counter (74AC163) to produce Ø2, which is an approach I tested in V1.2 (which was stable at 20 MHz), that having been derived from Jeff’s clock-stretching circuit. As a Ø1 clock (inverted Ø2) is needed to gate the bank bits latch, and the counter doesn’t have a complement to its QD output, a 74LVC1G04 inverter that is driven from QD does the honors. The inverter introduces approximately 3 to 4 ns prop time (a bit less than with 74AC or 74AHC logic), but as an experiment, I skipped the series resistor I usually have in clock circuits to suppress ringing. Ø2 continues to pass through series resistance, which introduces a small amount of lag in the signal (apparently 2-3 ns, from observations made on POC V1.3). The result is the two clocks should be very close to being 180 degrees out of phase. The logic analyzer will tell the tale when I get this thing built. If this works as I hope it will, I should be able to clock the system at 20 MHz.
Construction-wise, V1.4 will be built on the usual four-layer board. I’ve included a lot of test points to facilitate observation, include the entire address space, data bus and some other signals. I’m also using a slot for expansion, which is more reliable than the pin arrangement used in older POC versions. One other change I made was to mount the real-time clock on the main board in its own socket. Previously, the RTC had to be mounted on whatever was going to be plugged into expansion, which was inconvenient from a design standpoint. Reserving space on the PCB necessitated an increase in board size to get the clock to fit. The increase is negligible.
I’ve got parts on order and as soon as I get them, I’ll verify clearances on the PCB and then get it made._________________ x86? We ain't got no x86. We don't NEED no stinking x86!
|
|
Login
Register
FAQ
Search
