• Please review our updated Terms and Rules here

RAMdisk under CP/M 2.2

Other than the CPU card, yep, all my design. I tried to stay true to the STD buss as well. With the aid of all of you here at VCF, some tweaks have gone into the designs for the various boards, and the software that runs on them. I maybe the one melting the solder and twisting the wires, but I kinda consider this a 'VCF Community' effort. You all are free to use the designs and software for anything that you find of interest. Wish there was a 'project repository' here I could put all that stuff......
 
Well, I cobbled a quick test to write FF into the first 32K block of the RAMdisk, then read it back and store it in memory, and it was gibberish. I had cleared out a good chunk of the memory it was to be stored in so I knew the program was doing something. So, it looks like the issue isn't my test code, but a hardware design issue. So, it looks like it is time to start some rewiring to match what Doug helped me with yesterday. Now I have to come up with a mental plan on how to go about implementing that change. Oh well, all part of the fun.
 
Well, the re-wire has been done, and I have run the same exact test code, and gotten the same exact results. So I am at a complete loss at this point. It is just weird, that as the more bits are set to a 1, the more likely the errors are in occurring. This has got me completely stumped......
 

Attachments

  • MemoryDiskv7(test).pdf
    91.7 KB · Views: 7
Well, I dug out the scope, and pulled this waveform. Red is the pin 1 Direction signal to the 74LS245 and yellow is the pin 19 enable for the 74LS245. If both are low, it should be reading from the memory chips, and if enable is low and DIR is high, it should be writing to memory. This does not look right....

1682194260394.png
 
I see you are using a bidirectional buffer now, rather than the LS244 you previous had for read - You could also eliminate the 244 at U14 if you extended the circuit, but I'll leave that decision for the future. I assume all of the latches are holding correctly, and you've already confirmed through pattern testing that there's no cross-talk there or false setting of a latch.

Right now, you have a fair bit going on. Some troubleshooting tests you can consider;

1) Write a ROM with a test pattern or just data and replace a RAM chip with a ROM chip - You might need to make up a socket to adapt the different pins, and program in a 16K pattern 4 times into a 27c256 or 8 into 27c512 due to the A14/A15 mismatch, but that's enough for a test... This way you can test reading of a chip with certainty. If you can read back the ROM chip correctly, then at least you can be confident it's not a read issue. Don't forget to remove the other RAM chips from the board first, as a faulty RAM chip can interfere with operation. ( I assume likewise you are only testing with a single RAM chip to avoid the possibility of a faulty RAM or a ram with enable issues interfering with the bus )

2) Get a logic analyser - you can record several seconds of interactions with the chips and zoom straight into the output to see what is going on - They cost about US$7 for an 8 channel model that comes with excellent software and will run at up to 24 Msps, which will give you sub-clock timing for a z80... At around 12 Msps, you can probably record for several seconds of testing over a USB. A problem with data stability is very hard to troubleshoot without a logic analyzer. I recently bought the Hantek 32 channel analyser and it works great.

3) Once you've confirmed you can read a ROM in a RAM socket reliably, then you only need to focus on the WRITE operation testing. You can also do this with just a two channel scope by triggering on the MEMORY select line from the 138 (U12) on the negative edge, and examine what other signals are doing at the same time since the recent circuit changes made sure that the memory chips are all enabled by this line. You can check data lines ( all set to what you're putting out) and other signals such as buffered RD/WR, direction, etc and make sure they are all where they are supposed to be.

This should be enough to find the exact cause of your problem. Without narrowing down the cause, then you're struggling to guess where the issue is. Now that you've eliminated them, the previous race condition and multiple chip enables were clearly not enough to stop the design from working, but there's only so much desktop troubleshooting you can do without a better way to look into what is going on :)

Regards
David
 
I made s few changes to the scope, and ran the same tight write/read loop on a single address. I captured scope traces for each of the three possible configurations. One thing I don't get is the garbled signals on the yellow (enable) signal of the 74LS245..... I still believe the problem in read and timing related. I tried a test before where I used a BASIC program to read the data back after I had run a machine code program that left all FF's in memory, and that seemed to be able to read things just fine. I will re-run that experiment tomorrow.
 

Attachments

  • Config1.JPG
    Config1.JPG
    61.4 KB · Views: 9
  • Config2.JPG
    Config2.JPG
    62.9 KB · Views: 9
  • Config3.JPG
    Config3.JPG
    60.8 KB · Views: 9
Something definitely doesn't make any sense in that trace - What are the timings per division on the scope?

Generally, you should see a long break between accesses, and an access should be a single pulse of several hundred nanosecondsalong with lots of control signals on the other trace - IORQ and the correct address sequence shouldn't be occuring that much during a cycle - It will only occur when accessing board memory and nowhere near that frequency, since inbetween, the CPU will be executing instructions and doing other stuff. Something is definitely wrong with the select - might be glitching in the 138, but from what I can see, the address should be valid and stable long before the IORQ line drops to indicate it's an I/O address, so the output on the MEMSEL pin should never go low until all conditions are met... In basic, it will be hundeds of milliseconds between accesses.

For most reasonable scope settings, you should never see more than one IORQ generated pulse on the output of the 138 in the scope image.

Faulty 138? Incorrect wiring to system bus? Missing wires? Short circuit to another pin?

I would suggest focussing on why the select signal looks like that first - The scope is most likely working, so something around that 138 isn't right. BTW, pertinent question, what is your z80 clock speed?

David.
 
Vertical is 2.0 v/div & horizontal is 1us/div. System clock is 2MHz. Yep, I was thinking that something weird is going on with the output of that 74LS138. I want to scope the other pins on that tomorrow to see if something shows up. I think I'll swap it out as well after I check the other pins.
 
As a side thought, since the oscillation on the scope is way above the clock speed, check the three input gates to the 138 with the oscilloscope and make sure they are all clear 0s or 1s and transition correctly and regularly...

A bad gate input might cause a high impedance input being affected by the PSU or just about anything that could explain the outcome. Also check the A6 since it seems the most likely from your schematic.
 
This thing just gets weirder all the time. I took screenshots of the various lines of the 74LS138 (U12) and attached them. Interestingly, the enable line of the enable pin on the 74LS245 (U17-P19) only contains the noise/spikes when performing a read from a given memory location, and the more 1's in the value being read, the more noise/spikes there are. Oddly, the write signal is picture perfect. Call me whatever, but I'm sure thinking this is some kind of induced noise, but the question is how, and from what, and why only during a read.......
 

Attachments

  • Slide1.JPG
    Slide1.JPG
    76.4 KB · Views: 3
I decided to run a few more tests with looped write/reads from a single memory location...
1. with no connection to 74LS138 (U12-P11), Port 44 decoded, the waveform is picture perfect.
2. with U12-P11 connected to 74LS138 (U1-P05), memory chip select decode, the waveform is picture perfect.
3. with U12-P11 connected to 74LS245 (U17-P19), bus transceiver enable, the waveform read pulse is full of noise/spikes, but the write is picture perfect.
4. swapped out the 74LS138s and the 74LS245 and got the same results.
 
What does the rest of the architecture look like - do those address lines and IORQ go straight back to the z80 or do they go to a buffer output between the z80 and your board? And what other cards are installed? Something is strange, because at first the signal is clear, then it starts to degrade...

Could be something weird like a faulty z80 - I can't recall seeing a specific fault like this before, but then I'm also not sure of the whole architecture from the CPU to the Memory.
 
I'd suggest you take a closer look at the actual hardware as-built (not as shown in schematic). That kind of oscillation is likely caused by faulty wiring somewhere - including bad power/ground connections.
 
David, just for flips and giggles, I found a couple of unused NOR gates and fashioned them in to back to back inverters to see if I could isolate when that noise if coming from during a read cycle. And it seems to matter what I connect between the '138 decode and the '245 transceiver, the noise shows up. So that rules out any odd interaction between those two chip types. And since this is only happening internal to the card, far from the buss, and only on a read cycle, I'm kinda lost on it being something external.

1682342222224.png

Doug, yep, that has been a nagging concern I have trying to put out of my head. This is what I use for all the boards in this system; Vector 4610-2. My plan today is to fire up that tight write/read loop and scope every buss signal that board uses, and to place the scope probe across the power and ground pins of each and every chip on that card. Maybe something pops up.

1682342074713.png
 
Well, I ran the tight loop test again and scoped the board power, IORQ, Read, Write, and all of the address lines. Each of them show noise of some sort noise. Other than the buss to CPU interface and the buss display card (has clock and terminators) the other two cards (dual port serial and printer) were pulled. The question I ask myself next, is that noise coming from this card, or from something else. The serial card has a similar decode and transceiver design. I should be able to run a tight write/read loop test using a port on that card, to see if I get the same kind of noise. Guess I need to get that setup to test. I attached the waveforms I got this morning. All of the waverforms are set to 2us sweep.
 

Attachments

  • Slide1.JPG
    Slide1.JPG
    41 KB · Views: 1
  • Slide2.JPG
    Slide2.JPG
    46.8 KB · Views: 2
  • Slide3.JPG
    Slide3.JPG
    43.1 KB · Views: 0
  • Slide4.JPG
    Slide4.JPG
    50.1 KB · Views: 1
I ran the same tight loop test on the serial card (port 24 instead of port 44), which uses the same '138 & '245 decode and data buss transceiver, and those signals looked clean with no noise or spikes. So, I guessing the problem is internal to the RAMdisk card itself. I looks like I can pull all but five chips from that board and still be able to run that tight loop test. If the issue goes away, I know it will be something related to one of those chips.
 
Pulling chips was another no go. I'm starting to run out of alphabets; I'm up to 'Plan M' I think. I do have another blank Vector protoboard, so I'm going to duplicate the exact same design, using the minimum number of circuits and re-run the test. If that works, then I will add more to the circuit until I either see the problem come back, in which case it is a design flaw, or I get something working with this new board build. But, if one of you has the 'eureka' moment that has eluded me, feel free to bop me on the head.....
 
I'll just throw this out there, for what it's worth. The wire-wrap projects I worked on (years ago) were ones where the manager was very strict about quality. He used something akin to this: https://www.digikey.com/en/products...TCBcDaIG4FMDGAXA9gJwAQCMCuAzlgShgJYAOBIAugL5A for making Vcc and GND connections. He also had war-stories about ground loops and the havoc they would cause (they certainly could cause something like what you're seeing). I see that at least some of your power/ground connections are made by wire, and I can't see if there's any that could result in ground loops (I'm no expert on that, anyway).

It also appears that you are using a hand-wrap tool, as your wraps are not all the same direction (CW vs. CCW). I know the powered wrap tool I was trained on only wrapped one direction. I'm not sure if the hand-wrap tools are truly bi-directional, but hand-wrapping is more prone to bad connections than powered wraps (when used correctly).
 
You must log in or register to reply here.
Back
Top