POC Computer Version One

[8BIT]

To all,

Great news! I figured out how to remove the 2x input clock from my design.

I was then able to run the Core at 20 MHz without trouble. I copied blocks of data from block 0 to block 1,2,and 3, then back to block 0, using offsets from the original address. This ensured the data block was actually moved.

I then wrote a quick nested loop that takes exactly 1 million cycles to complete. I called it 100 times for a total of 100 million cycles. At 20MHz, that should take 5 seconds. As best as I could time it, it took 5 seconds. This test was just to be sure I did not have a bug in my CPLD logic that was somehow slowing it down.

I am using a 15ns CPLD with 15ns SRAM. 20 MHz yields a 50ns cycle time and 25ns half-cycle. Yes, I did try 25 MHz, but it did not work. The one artifact I found at 20 MHz was inconsistant cold startup. However, pressing the reset switch resulted in a proper boot every time.

So, it's evident that WDC's timing specs are conservative. However, my core system has a pretty small footprint and bus loading is very small. I only have the CPLD and the Xicor UART connected to the data bus, and only the CPLD connected to the address bus. The SRAM and ROM are connected thru the CPLD.

More info is here:
http://sbc.rictor.org/sbc31/core.html

Your design's mileage may vary.

Daryl

[BigDumbDinosaur]

8BIT wrote:

I was then able to run the Core at 20 MHz without trouble...I am using a 15ns CPLD with 15ns SRAM. 20 MHz yields a 50ns cycle time and 25ns half-cycle. Yes, I did try 25 MHz, but it did not work. The one artifact I found at 20 MHz was inconsistant cold startup. However, pressing the reset switch resulted in a proper boot every time.

The cold reset problem seems odd. I see that you are using a Dallas 1813 econo-reset. Is it possible that the 1813 is unable to pull the reset line down hard enough to do the job? Also, where's the pullup resistor for /RESET? Is that something the CPLD is doing for you? Perhaps you need to add a small amount of capacitance to the reset line to slow down the rate at which it returns high following the reset.

Quote:

So, it's evident that WDC's timing specs are conservative. However, my core system has a pretty small footprint and bus loading is very small. I only have the CPLD and the Xicor UART connected to the data bus, and only the CPLD connected to the address bus. The SRAM and ROM are connected thru the CPLD.

It is likely as you add more hardware (especially RAM) you will have to add bus line drivers ('ABT versions are available that run in the single digit nanosecond range). However, careful perusing of the '816 data sheet, along with some E-mail exchanges with WDC, leads me to believe the fanout on the '816 is better than one might think.

I think key to ramping up the clock speed and at the same time supporting more bus loading is the use of a 4-layer board. With VCC and GND now on separate layers, you don't have to worry about routing those two circuits on the outer layers, permitting you to make the layout more dense. A denser layout means shorter traces and less stray capacitance to sabotage timing. Not having VCC and GND in traces also reduces problems with ground bounce and noise in general. Plus the separation of the top and bottom layers by the power and ground layers greatly reduces crosstalk between traces that coincide on opposite layers.

I see you are using ExpressPCB's mini-board for your core. They also offer a 4-layer mini-board, complete with silk screening, which would probably work well for you, albeit at extra cost.

My "POC" design that I am building includes an RTC, as well as a dual ACIA, using discrete logic. Obviously, discrete logic takes up more room than a single CPLD, but for a first design I didn't want to add the complication of a PLD. In order to get all that stuff on the board plus have room for two RJ45 jacks (EIA-232), a standard power connector, and a jumper header for testing an RTC feature, I decided to do it using the 4-layer ProtoPro service. The cost is higher, but so be it.

[8BIT]

I had designed the "Core" before ExpressPCB came out with the 4 layer mini-boards. I agree, using that will help with noise and cross-talk.

The DS1813 has an internal 5.5k pull-up resistor. It may be that I have too high a tolerance part and the power supply is not stabilizing fast enough. Either way, if I back the clock down to 16 MHz, it runs well so that will be my target speed.

I am going to try and modify my CPLD code on the SBC-3 to allow the video to pull data at the 7.159 Mhz rate (every other clock cycle) and the CPU to run at 14.318 Mhz. That would be a nice improvement!

I agree with using descrete logic to get started with. My SBC-1 and SBC-2 did and worked very well. I don't think I will go back that way, as using CPLD's (even GAL16V8's) significantly improve propagation delay and reduce the required footprint.

Good luck with your project(s)!

Daryl

[BigDumbDinosaur]

8BIT wrote:

The DS1813 has an internal 5.5k pull-up resistor.

The 5.5k spec is average. It can be as high as 7.5k, which is definitely too high. It sounds as though the reset line is being lazy about getting back up to Vcc. In such a case, the MPU may be getting confused about when reset has cleared. Slobber a 3.3 k resistor from reset to VCC and see what happens. The 1813 should have no trouble sinking it, provided your reset connection to the CPLD is not being pulled high by the latter.

Quote:

It may be that I have too high a tolerance part and the power supply is not stabilizing fast enough. Either way, if I back the clock down to 16 MHz, it runs well so that will be my target speed.

More likely, the 1813 isn't holding down /RESET long enough for some reason.

Quote:

I agree with using descrete logic to get started with. My SBC-1 and SBC-2 did and worked very well. I don't think I will go back that way, as using CPLD's (even GAL16V8's) significantly improve propagation delay and reduce the required footprint.

As I said when I started this topic, it's best to build the single-engine light plane before tooling up to build the four-engine wide-body airliner. The primary purpose of POC is to enable me to develop properly working drivers for the 2962 DUART and 1511 RTC. Once those are done and I've verified a few other things I'll work on a new design with a PLD instead of discrete logic.

Quote:

Good luck with your project(s)!

Daryl

Thanks, although when it comes to electronics I don't consider luck to be a factor in most cases.

[ElEctric_EyE]

Sounds interesting. What will the UART control?

[BigDumbDinosaur]

ElEctric_EyE wrote:

Sounds interesting. What will the UART control?

Port A will drive a dumb terminal and port B will be used for importing code. The purpose of this particular design is to develop tight code for running the UART and to get real familiar with the DS1511 RTC. I ultimately have a more grandiose system in mind that will use those parts plus other (e.g., an NXP 2698 octart). This relatively inexpensive "proof of concept" version will give me something on which to test a BIOS before moving on to a more complicated design.

[fachat]

BigDumbDinosaur wrote:

In such a system, you should be using a prioritized interrupt circuit that identifies each interrupting source. Each source should have a specific front end whose first job is to read (and clear, if necessary) the interrupt flag register and store the contents. Once that front end has done its work, it can dispatch the MPU to the relevant event handlers (e.g., timer A underflow).

Only this IRQ frontend makes the stuff more complicated, as say, all CIA interrupts have to share it. For a VIA I can provide completely independent device drivers.

Remember, my OS can run on a number of 6502 systems (including PET) even without CIA, so providing such a shared IRQ frontend makes it more complex, use more memory, which is always tight...

Quote:

The .byte $2C (and .byte $24) trick, although lamentably common with 6502 machine code, is usually bad practice, precisely for the reason you described. I recall years ago describing the sequence as a "harmless BIT instruction." Obviously, if it BITs a register, it's not harmless. I have to admit having used that technique now and then but generally have stayed away from it. If someone who worked for me did that I'd have to castigate him for writing booby-traps into his code.

BTW, all C-64 I/O hardware appears in the $D000 range.

Outch. I should have known. Now I know why these address values didn't sound familiar....

[GARTHWILSON]

Quote:

The 5.5k spec is average. It can be as high as 7.5k, which is definitely too high. It sounds as though the reset line is being lazy about getting back up to Vcc. In such a case, the MPU may be getting confused about when reset has cleared.

The MPU has a schmitt-trigger CMOS RST\ input, so it shouldn't be bothering the MPU itself if the RST\ line is coming up really slowly. In fact, you can use a simple RC. A slowly rising RST\ signal may be a problem for other parts though.

Quote:

More likely, the 1813 isn't holding down /RESET long enough for some reason.

It may be that the one oscillator is taking longer to stabilize than the other-- maybe different brand, slightly different design, or whatever.

[BigDumbDinosaur]

GARTHWILSON wrote:

It may be that the one oscillator is taking longer to stabilize than the other—maybe different brand, slightly different design, or whatever.

That may be it. I've seen instances where oscillation takes several hundred milliseconds to start after power on. The DS1813 holds reset down for about 150ms, which may not be long enough if the oscillator is slow to start—e.g., the MPU would be ready to go but a stable Ø2 clock would not be available. Subsequent pressing of the reset button would restart the MPU but by then Ø2 will be stable, so the system boots without incident.
——————————————————
Additional Thoughts 11/03/2009

In studying the DS1813 data sheet a bit more, it is clear that the nominal 150ms period in which reset is held low after Vcc stabilizes could be extended with a simple RC delay circuit. A resistor would be placed in series with the Vcc connection on the DS1813 and a capacitor placed across the DS1813's Vcc and ground connections. This might be less a hassle than using a 555 timer to handle the reset sequence.

My theory is based on the fact that following initial application of power, the DS1813 maintains reset low. Once Vcc at the DS1813 rises to approximately 80 percent of the device's nominal Vcc rating, the 150ms "timer" is started and only when that time has expired does the DS1813 allow reset to go high. It would stand to reason that anything that extends the apparent rise time of Vcc should have the effect of extending the amount of time that reset is held down.

The current drawn by the DS1813 is very low (30-40 µA), so a reasonably-sized resistor will have negligible effect on the voltage seen by the device. For example, a 3.3k resistor and a 220µF capacitor would produce a time-constant of about 0.72 seconds, with the resistor causing a nominal 0.13 volt drop, well within the DS1813's tolerance. Or, you could use a 2.2k resistor and a 330µF capacitor to achieve about the same time-constant, but with less voltage drop.

A bit more than two time-constants are required to get pin 2 of the DS1813 high enough to start the 150ms sequence (the actual time depends on which version of the DS1813 you use). Therefore, the total reset period at power-on would be around 1.6-1.7 seconds using the above values. If the Ø2 oscillator isn't stable by then it should be replaced with a better device.

A small signal diode (e.g., a 1N4152) should be connected across the series resistor, with the anode connected to the junction of the resistor, capacitor and pin 2 of the DS1813. The purpose of the diode is to provide a low resistance discharge path for the capacitor when power is removed. Otherwise, short-cycling power to the computer would prevent the DS1813 from executing another reset cycle due to the time required for the voltage at pin 2 to decay. Also, an external pullup resistor is required on the reset line with this configuration (2.2k to 3.3k is good). In any case, the DS1813's internal pullup should not be relied upon, as it varies widely in value—as high as 7.5k, and even if at the nominal 5.5k value quoted in the data sheet, is too high.

[fachat]

Quote:

Quote:

Imagine even the usual ".byte $2c; label: LDA #$CC" in a C64. The code executing the "$2c" opcode is actually a "BIT $CCA9" - what register is that in the CIA's mirrored register file? Accidently reading the interrrupt register and clearing them is not good. (I've made the address values up, too lazy to look them up now but you get the idea)

The .byte $2C (and .byte $24) trick, although lamentably common with 6502 machine code, is usually bad practice, precisely for the reason you described. I recall years ago describing the sequence as a "harmless BIT instruction." Obviously, if it BITs a register, it's not harmless. I have to admit having used that technique now and then but generally have stayed away from it. If someone who worked for me did that I'd have to castigate him for writing booby-traps into his code. :)

BTW, all C-64 I/O hardware appears in the $D000 range.

In fact the 6502 itself is a "bad" CPU when it comes to illegal address memory accesses. That's to the fact that there is no external signal that indicates a valid address, but all cycles are memory accesses.

From wikipedia:

Quote:

The NMOS 6502's indexed addressing across page boundaries will do an extra read of invalid address. This can cause issues by accessing hardware that acts on a read (e.g., clearing timer or IRQ flags, sending an I/O handshake, etc.). This defect continued through the entire NMOS line, but was fixed in the CMOS derivatives, in which the processor does an extra read of the last instruction byte.

The 6502's Read/Modify/Write instruction at effective address does one read and two write cycles. This can cause issues by twice accessing hardware that acts on a write. This defect continued through the entire NMOS line, but was fixed in the CMOS derivatives, in which the processor will do two reads and one write cycle.

IIRC it's not that critical tho, as the illegal addresses mostly come from high address byte being off by one (overflow from adding/increasing the low address byte).

And you should not use RMW operations on I/O registers...

André

[BigDumbDinosaur]

fachat wrote:

In fact the 6502 itself is a "bad" CPU when it comes to illegal address memory accesses. That's to the fact that there is no external signal that indicates a valid address, but all cycles are memory accesses.

To some extent, that issue has been addressed in the 65C816. It should be possible to set up true hardware memory protection, although trying to do so in discrete logic would be a timing nightmare.

Having jacked around with computer hardware since the days when an "interactive environment" meant pounding very terse commands on a Tele-Type keyboard and waiting several seconds for something to happen, I can tell you that all processors have their annoying quirks. Considering the age of the 65xx architecture and the circumstances in which it was developed, it's not bad, and is better than some of its contemporaries (the Intel 8088 by way of example, is a horse-**** design that reflects accountant-mentality thinking).

Quote:

And you should not use RMW operations on I/O registers...

That goes without saying, eh? Only an assembly language programming newbie would make that sort of boner.

[BigDumbDinosaur]

Having reviewed my POC computer schematic and printed circuit board layout for the umpteenth time, I've concluded I've either eliminated all errors or cannot see the ones that are present. Accordingly, I have placed the order for PCBs, which should arrive by the end of the week. If you should happen to see a large mushroom cloud arise over the Chicago area, it is probably the POC computer detonating following power application.

One of the challenges I will face in assembly will be soldering the SRAM, which is an SOJ32 package, to the board. Unlike some of you other guys (and gals?), I'm at Social Security age and don't quite have the hand-eye coordination that made me such a killer on video games 30 years ago. 50 mil pin centers will be interesting to work with. However, I have watched some videos on hand soldering techniques (as well as read Daryl Rictor's travails with SMD slobbering...er...soldering) and am prepared to give it a go.

I do have a fall-back plan if I can't manage it. My oldest grandson is very skilled with small parts soldering and, being a hell of a lot younger than me, has much better hand-eye coordination. I'm prepared to swallow my pride and let him take care of the SRAM if need be. It'll be humiliating, to be sure, but that's what happens when you are old enough to be referred to in your family as a "geezer geek."

I will link to some pictures as soon as I have the first unit built.

[ElEctric_EyE]

Good luck! I am very close to making a board too, maybe a month or two. I'm still in the wirewrap stage. Looking forward to some pics, you have a very nice compact design.

[BigDumbDinosaur]

ElEctric_EyE wrote:

Good luck! I am very close to making a board too, maybe a month or two. I'm still in the wirewrap stage. Looking forward to some pics, you have a very nice compact design.

In days past, when reasonably good PCBs in small (i.e., hobbyist) quantities cost a left lung and a right arm, I wore out several wire-wrap guns. With the advent of services such as ExpressPCB, the wire-wrap gun is breathing a lot easier these days. If the density is low and circuit speeds aren't in the clouds, I'll do wire-wrap or point-to-point (soldered wire-wrap sized wire) on a perf board. I decided the POC computer was too dense to do well in wire-wrap, so PCB it is.

I originally was going to size the layout to fit ExpressPCB's miniboard service. That, however, would have meant having the connectors hanging off the board from wires, adding to potential problems (especially with trying to connect leads from the MAX238 to the closely-space pins on the dual RJ45 receptacle. So I decided to use the 4-layer ProtoPro product. It costs more but will make assembly less difficult, as well as give me four boards to ruin instead of three.

[Nightmaretony]

If you can find a place to manufacture cheap from Gerbers, may I recommend Kicad? Tis open source, FREE and not too bad a learnign curve. Tis a little zany at times. but it does a pretty fun job and uses actual netting. I am using it for circuit layout but have yet to submit a Gerber series from it, though...