• Please review our updated Terms and Rules here

RAMdisk under CP/M 2.2

Doug, well I reconfigured things as what I posted snippets of yesterday and same old, same old.... What is weird, is that these noise/spikes wind up on the actual address buss (A0-A2). Reset the system and things are back to normal. From looking at the schematics, I can't see how in the world that is getting generated. The CPU cards uses all of the 'x0' to 'x3' and 'x8' to 'xF' ports. Not ideal, but it is what it is. Anyway, here are all of the schematics for my entire system. I'm obviously looking right at the problem, but I certainly keep overlooking it...... Maybe better eyes than mine can see the 'error of my ways'......
 

Attachments

  • BusDriverv4.pdf
    20 KB · Views: 3
  • single-board-wires-schematic.jpg
    single-board-wires-schematic.jpg
    1.9 MB · Views: 4
  • SerialACardv6.pdf
    85.2 KB · Views: 2
  • Printerv1.pdf
    108.5 KB · Views: 2
  • MemoryDiskv7.pdf
    87.2 KB · Views: 7
  • FrontPanelv1.pdf
    37.9 KB · Views: 2
Or maybe the write then read code is too tight? Maybe I need a slight delay between writing and reading the same address repeatedly?
1682704701618.png
 
The fact that RESET stops the noise (is that what you're saying?) is odd. The other side to that is important: what causes the noise to start? If there is noise on A0-A2, how can the system operate at all? Or else, what additional signals/conditions are required to see the noise? Perhaps need more detail on what you are observing.

Noise on A0-A2 would certainly translated to noise on the select signals out of the '138.
 
Doug, the noise & spike never show up until I try to run a program that uses the RAMdisk. But the CPU card still works, so that noise/spike garbage are not making it onto the CPU card. Yes, it is very weird. And yes, a reset stops the garbage and the signals go back to normal. What has always concerned me is that the CPU board design does not decode the upper four bits of the I/O port address, which is why I am left with only ports x4 thru x7 available for my use. But that is more than enough.
 
OK, so if I understand correctly the noise is appearing on address lines *outboard* from the CPU - i.e. on the other side of the BusDriverv4 circuitry? So it may be related to interaction between the bus drivers and any/all of the I/O boards plugged in to the bus? Doing some I/O to your MemoryDiskv7 board causes some sort of self-sustaining oscillation between all those boards/chips that requires a RESET to clear? Perhaps taking a look at all the things affected by RESET outboard of the bus drivers.
 
Yep, pretty much. and I pulled the dual port serial card and the printer card so all that remained was the Bus Driver, Bus Display, and the RAMdisk card....... I may try to change the port address of the RAMdisk card this weekend, just for giggles....... And maybe something shows up after that.
 
Hi Myke

Can you check PIN2 of the 74LS04 of U08 of the bus driver ( drives the tristate bus buffers between the CPU and the address bus ) to see if it's oscillating when the bad READ oscillations occur?

Some kind of connection between READ and the input to this gate, via a resistive or other load-dependand connection (could also be through an IC) along with bus fanout could result in read ( or another signal ) causing the bus to oscillate, as it would enable/disable/enable/disable the bus, with resonance at the natural capacitance for the open but on these lines, and would capable of generating the response you're getting at the kinds of frequencies you're observing.

Regards
David
 
David, in all honesty, that Bus Driver board was designed back when I had an idea of having a shared memory space such that the Bus Request & Acknowledge would be needed. That seems a moot point now, so after I test what you suggested, I am going to look into re-designing the Dir control circuitry such that it is only able to 'read' the data when the address range is between 'x4' and 'x7'. I could get rid of U09 & U10 and replace them with a single 74LS21 and have the G1 input of the 74LS138 be controlled by the write signal being high.
 
I've done a bit of re-thinking the Bus Driver board, and as you all said several times about it being 'outside the RAMdisk board', I see that my old design left a lot to be desired. So, digging out my old TTL Data book, I think this will be a whole lot cleaner. The only time I would ever need to have the data bus of the peripheral cards in a read state, is when I'm trying to read data from any of the 'x4' to 'x7' ports. All other ports are reserved by the CPU board. So, I think this version will be much more efficient.
 

Attachments

  • BusDriverv5.pdf
    20.3 KB · Views: 4
Out of curiousity about the architecture, why the double buffering? You're pushing a huge amount of potential current there through multiple buffers - eg, One for the CPU, and one for each card.

The z80 can push a few milliamps - the datasheet says 1.5 high and 2.5 low IIRC, or thereabouts, but that seems related to thermal dissipation rather than actual limits. In the ZX Spectrum architecture, it directly drove against signals at 3.5 MHz with a load of 330 Ohms where they were used as bus separators ( rather than using a buffer where it was actually needed to separate busses ), or around 15 mA at 5v - both high and low. Looking at the signals on a scope tells you it's feeling the load, and the CPU gets warm, but it handles it, even though this is clearly operating at a low duty cycle, but it has a lot more push than most people realize.

You're interfacing with CMOS RAMs, and other similar chips, so the z80 itself probably wouldn't even blink at the requirements to drive around 20 chips directly from the bus, and if using the bus buffering, you're pushing around 12 to 25 mA per output line within data sheet specifications ( 74LS244 ) - so the extent of buffering may not be necessary.

I know some other systems buffer everything from the CPU, but mostly on systems that share data and address lines, so there was a need for external latches and buffers to separate this information in the time domain.

If you're buffering the cards directly, the z80 could easily handle a half-dozen slots without needing a local bus buffer. Hence I'm curious as to the buffer near the CPU and a buffer at each card as well.

I have seen z80s fail, but it's pretty rare. The larger chip surface area gives pretty good cheat dissipation at lower clock speeds so it really makes me curious as to how many cards the architecture is designed to take?
 
cj7hawk said:
Out of curiousity about the architecture, why the double buffering? You're pushing a huge amount of potential current there through multiple buffers - eg, One for the CPU, and one for each card.

The z80 can push a few milliamps - the datasheet says 1.5 high and 2.5 low IIRC, or thereabouts, but that seems related to thermal dissipation rather than actual limits. In the ZX Spectrum architecture, it directly drove against signals at 3.5 MHz with a load of 330 Ohms where they were used as bus separators ( rather than using a buffer where it was actually needed to separate busses ), or around 15 mA at 5v - both high and low. Looking at the signals on a scope tells you it's feeling the load, and the CPU gets warm, but it handles it, even though this is clearly operating at a low duty cycle, but it has a lot more push than most people realize.

You're interfacing with CMOS RAMs, and other similar chips, so the z80 itself probably wouldn't even blink at the requirements to drive around 20 chips directly from the bus, and if using the bus buffering, you're pushing around 12 to 25 mA per output line within data sheet specifications ( 74LS244 ) - so the extent of buffering may not be necessary.

I know some other systems buffer everything from the CPU, but mostly on systems that share data and address lines, so there was a need for external latches and buffers to separate this information in the time domain.

If you're buffering the cards directly, the z80 could easily handle a half-dozen slots without needing a local bus buffer. Hence I'm curious as to the buffer near the CPU and a buffer at each card as well.

I have seen z80s fail, but it's pretty rare. The larger chip surface area gives pretty good cheat dissipation at lower clock speeds so it really makes me curious as to how many cards the architecture is designed to take?
Click to expand...

Well, that is kind of a holdout from my original plan, similar to the S-100, but on the STD bus. That Bus Driver card was to shield the CPU card from the bus, so if something bad happened on the bus, then it wouldn't mess up the CPU. And I had intended to have a card that could directly address some shared memory for easy loading of software & data. And given a 6 inch ribbon cable, the lines from the ribbon cable, and the length of the STD bus motherboard, I was trying to keep the overall length under control. I'm going to make those changes to the Bus Driver card and see if that changes anything.
 
Plasmo said:
RC2014’s Z80 is driving boards on the backplane without any bus buffers (no address, no data buffers) at 7.37mhz. This post shows that 12 boards can be driven directly.

I wonder how many devices you can get on a single RC2014..

groups.google.com groups.google.com

in my own setup, Z80 drives 6 boards without any buffering at 14.7mhz, CF disk, RAM/ROM, serial, CPLD, video/keyboard, and sound.
Bill
Click to expand...
Bill, I almost went with the RC2014, but the guy who makes the CPUville kit lives about an hour from me, and it seems to be a good all around board. His build instructions are great. Even down to getting CP/M configured and operating. As for the bus driver stuff; that explanation is what I replied to David with.
 
I'm curious about your RAMdisk problem that I ported the schematic you posted 4/25/23 (MemoryDiskv7(test)) to CPLD schematic. The idea here is to emulate your physical design in CPLD to make sure it works logically. Could you check to see if I've capture the design correctly? The CPLD library does not have 74245 so I emulate a 74245 with collection of logic.

Assuming you don't mind my intrusion, I like to implement the design on a CPLD prototype board and add one or more 32K RAM to see whether I also encountered the same problem you described.
Bill
 

Attachments

  • RAMdisk_VCFED.pdf
    21.5 KB · Views: 3
Plasmo said:
I'm curious about your RAMdisk problem that I ported the schematic you posted 4/25/23 (MemoryDiskv7(test)) to CPLD schematic. The idea here is to emulate your physical design in CPLD to make sure it works logically. Could you check to see if I've capture the design correctly? The CPLD library does not have 74245 so I emulate a 74245 with collection of logic.

Assuming you don't mind my intrusion, I like to implement the design on a CPLD prototype board and add one or more 32K RAM to see whether I also encountered the same problem you described.
Bill
Click to expand...
Bill, go for it. This is certainly no intrusion. You all are absolutely open to use whatever I post here. Most all of the stuff I put together is borrowed from other places anyway, so use as you see fit.
 
Well, after a small bit of redesign and rewiring of the Bus Driver board, I ran the tight loop test again, and nothing has changed. The noise/spike are still present when the bus transceiver enable line goes low during a read.... I've been staring at the schematic on and off this evening, and I'm thinking about taking a second look at the /G2B enable signal on the CS decoder. Right now, it is gated whenever the data read/write enable line is active low from the port address decoder. I'm questioning the need for that chip select decoder enable line..... Guess a test is in order tomorrow.....
 
I'm wondering if the problem might not be the card Myke - I think your other boards have the same problem on read, only it's not manifesting in testing because you're using buffered latches on the output, which can respond to a read peak within a few nanoseconds, so wouldn't be affected by a strobing 7MHz read line, since it would respond in time.

Meanwhile, RAM requires a stable RD signal for around 150ns or so, which it's not going to get most of the time from the signals it's being presented with the strobing RD signal.

I think it would be worth putting the scope on your RD lines to your other cards and seeing if they *do* exhibit the same behavior -

Also, I'm wonding if you've gotten a short between BUSAK and RD or WR... Since that would cause the problem you are seeing. Especially if it's from the buffered side of the RD to the unbuffered BUSAK -- That would cause self oscillation of the type you're seeing and result in read causing all bus signals to oscillate.
 
Well, the BUSAK signal is completely out of the circuit except to drive an LED on the Front Panel board. The Enable lines for the four '244s chips and the single '245 chip are tied directly to ground. The Dual Port Serial card uses a '138 and a couple '04s from the /Read signal on the bus to drive enable and direction lines on the '245. I used that card to load a file and didn't see any noise or spikes. The Dual Serial Port card and the RAMdisk card are almost identical in design with how they get data on and off the bus.

I took out the port 44 enable on the chip select decoder (circuit 'C' on the drawing) in the off chance that was having an effect. Nada, same as before. My next test is going to be to put a very slight delay between the write and read commands. Past that, my last idea is a change in port addressing from 44-47 to 54-57. At this point..... But the other cards on the same bus work fine and show no signs of generating ant noise or spikes when in operation......
 
I keep whittling away at reducing the circuitry down to the bare minimum. I read through the Z-80 manuals for the 1000th time and noticed how the address is stable for much longer than the /IORQ and the /Read lines, so I configured the address decode '138 to only look at address lines. The /IORQ and either the /Read or /Write controls lines run through an OR gate, and then to either the RAM chips of to the latch pins on the three '374 chips. I'm also going to get rid of the defensive circuitry before the '138 chip select decoder. I've also been looking at a few other things, that in retrospect I think a better design would have been to use an 8255 for the three address latches. oh well, there is always the S-100 version of this at some point.
 

Attachments

  • MemoryDiskv7.pdf
    85.6 KB · Views: 4
You must log in or register to reply here.
Back
Top