Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
|
BigDumbDinosaur wrote: plasmo wrote: BDD,
I'm pretty good with fine pitch soldering down to 0.5mm pitch SMT and I have a hot air tool to remove SOJ. I live in New Mexico. I'm happy to replace your RAM and help you build up SMT portion of 2nd board free of charge.
Bill
Thanks for the offer.
I'm not at the point where I can conclusively condemn the SRAM and after working on this problem some more last night, I temporarily set it aside so I could work on something else that had been languishing since last year.
Last year, I had started development of a new unit in the POC V1 series, one that would have the features of V1.2, but also would make use of the upper half of the 128KB SRAM with which all my POC units have been equipped—POC V1.0 and V1.1 have 52KB of addressable RAM, and V1.2 has 48KB.
As things went, I couldn't devote much time to hobby computing for a while and the new design gathered dust. Things have improved since then and the machine is done and runs.
Ladies and gentlemen, meet POC V1.3.
Attachment:
File comment: POC V1.3 Top View
poc_v1.3_top.jpg [ 1.76 MiB | Viewed 72736 times ]
V1.3 is basically the V1.2 circuit, but with a stretchable clock generation circuit for wait-stating ROM and I/O accesses, and a latch to generate A16, thus giving access to almost all of the SRAM. The range $00C000-$00FFFF is I/O and ROM—the rest is RAM. That arrangement works out to 112KB of addressable RAM, of which about 110KB is available for user code and data—the firmware "owns" the remaining 2KB. The entire $010000-$01FFFF range is available for user code and data.
Like its predecessors, V1.3 is entirely discrete logic and all but one piece of it is SMT. There is slightly more propagation delay in the logic due to the generation of a signal that indicates when a bank $00 access is occurring—the purpose being to avoid having I/O and ROM mirrored above $00FFFF. The method I used to generate that signal is not super-efficient. However, it does the job—V1.3 worked properly on the first try.
Initial boot-up was using V1.2's ROM, which of course didn't know about the extra RAM now available. Once I saw a successful POST, I modified the firmware to do a non-destructive RAM test above $00FFFF and report the results. Here's the POST screen for the new machine:
Attachment:
File comment: POC V1.3 POST Display
poc_v1.3_post.jpg [ 1.85 MiB | Viewed 72736 times ]
Here's the schematic:
Attachment:
File comment: POC V1.3 Schematic
pocv130.pdf [344.54 KiB]
Downloaded 168 times
What follows are some detail photos of the unit.
Attachment:
File comment: POC V1.3 Panic Buttons
poc_v1.3_detail03.jpg [ 1.43 MiB | Viewed 72736 times ]
Seen in the above photo are NMI and reset push buttons mounted on the board for those times when some boneheaded programming causes the unit to get stuck in the mud, or go off the road and smack into a tree.
Attachment:
File comment: POC V1.3 Power Connector & Status Indicators
poc_v1.3_detail04.jpg [ 994.93 KiB | Viewed 72736 times ]
Seen in the above photo (left to right) are the yellow IRQ "heartbeat" indicator, a feature introduced in V1.2 (but with the LED correctly hooked up this time), power input connector (3.5" floppy disk Berg connector), green "power good" indicator, and red reset indicator.
Attachment:
File comment: POC V1.3 Serial I/O Hardware
poc_v1.3_detail02.jpg [ 1.96 MiB | Viewed 72736 times ]
Like V1.2, V1.3 has four, high-speed TIA-232 ports, with a pair of NXP 28L92 DUARTs acting as a virtual QUART—the driver is the same as in V1.2. A change I made to the serial I/O circuit was to replace the two MAX238 transceivers used in V1.2 with a single MAX248. Although the combination of a single MAX248 and its socket (PLCC44) costs slightly more than a pair of MAX238s in SOIC, the MAX248 requires only four charge-pump capacitors to handle all four channels, whereas the MAX238 pair required eight total. Also, I can easily solder a PLCC44 socket, as the pins are on a 100×100 mil grid. Soldering anything SMT has become very difficult for me.
Attachment:
File comment: POC V1.3 Clock Generation
poc_v1.3_detail01.jpg [ 2.12 MiB | Viewed 72736 times ]
Above is the clock generation hardware.
Due to the use of a 74AC573 latch to generate A16, both Ø1 and Ø2 clocks are needed. The clock circuit in V1.3 uses a 74AC74 C-D flop to generate the signals, and a 74AC109 J-K flop to wait-state ROM and I/O accesses. A wait-state is produced by stretching the Ø2 high phase an additional cycle, with a corresponding stretch of the Ø1 low phase, a principle which I wrote about here. The AC109 acts as a timer to stop the clock for one Ø2 cycle, using a circuit illustrated by Jeff.
As both clocks come from the same AC74 flop, they are exactly (within a fraction of a nanosecond) 180 degrees out of phase. Therefore, the 573 latch closes within a few nanoseconds of the rise of Ø2. This mess works fine at 16 MHz, but is unstable at 20 MHz. As soon as time permits, I will hook up the logic analyzer and have a gander at the timing.
Oh, about those two resistors sticking up by the clock oscillator... 
Originally, there was a two-resistor SIP at that location (RN1 in the schematic), the resistors' purpose being to dampen ringing on the clock signals. During testing to check for clock signals, voltages being present, etc., I was dismayed to discover the Ø1 and Ø2 signals coming out of the SIP were distorted, with slow edges and rounded corners. The signals were okay on the "upstream" side of the SIP, which led to me concluding the SIP had too much capacitance and was munging up the signals. So I removed it and scabbed in some 100 ohm carbon film resistors from my parts supply. Now I had proper-looking clock signals.
Hmm..._________________ x86? We ain't got no x86. We don't NEED no stinking x86!
Last edited by BigDumbDinosaur on Sun May 30, 2021 4:54 am, edited 1 time in total.
|
|
Login
Register
FAQ
Search
