Commander X16

9 hours ago, jbaum81 said:

the wave goes from ~2.5v to 5.0v

 

2 hours ago, Wavicle said:

I more strongly think you are seeing the result of stray capacitance on the scope

Here is my speculation: It's the low impedance of the scope probe.  Try switching to 10x mode.

2 hours ago, picosecond said:

 



Here is my speculation: It's the low impedance of the scope probe.  Try switching to 10x mode.

The datasheet says the output current of the part is 16mA, so I'd think that a 1MOhm probe wouldn't have a significant effect... but I'm honestly not sure. It sounds like the circuit wasn't working when not being probed, but maybe there are two different problems going on here. Very interested to hear if switching to 10x mode fixes the problem.

14 hours ago, Wavicle said:

The datasheet says the output current of the part is 16mA

Read the datasheet before answering.  Good idea...

yeah, it's probably not the probe.  Maybe a bad ground?

Nope, I cooked the Oscillator ? , I must have hooked something up backwards, Ordered a new 8mhz oscillator and it's fine.

Also figured out the issue with the flipflops on the banks. I was sending the clock signal to the flipflops when the address was set and clock went high, but for some reason the datelines were not ready fast enough, which doesn't seem consistent with 65c02 data sheet?!?. None the less I changed the programming of the PAL to send the clock pulse to the FlipFlops on the falling edge instead, where I could tell the data and address is held at least for a few NS. This did work, but does have the negative effect of sending two clock pulses per cycle to the flipflop but even if it does mess up the address lines for the ROM/ HiRAM it's okay since the lines are set right at the completion of the cycle prior to any attempt to read / write from ROM/HiRam. 

Incidentally I did order a couple SST39SF040's ROM's which are rated at 70NS,  and was able to run the clock up to 14.75MHZ overnight and was stable. 15mhz did produce some corruption haha. This is on a breadboard so the theory is that on the printed board it should be awesome at 8mhz... But wait, not so fast!! 

I did order up a batch of boards, I did forget the pullup resistor on the reset line ?.. Can't find any other issues with the board, but it doesn't run :(. I'm using Ben eaters Arduino monitoring and it looks like data lines are floating ?? I pulled the PAL's ran a more simple addressing scheme (Ben's) through some NAND gates jumped over on a breadboard and it was stable. Running a much much slower clock I'm on occasion able to get it to behave for a while just flashing some LED's back and forth on the 65c22, but it's by no means stable. Thinking I screwed up the board I soldered up another and same stuff. It's a 4 layer board with really small traces that go between pins so I'm worried something may have gone wrong somewhere there. Need to run through the logic chips and check for continuity issues maybe with an address line somewhere? I'm really not sure at this point, I can't find anything wrong in my CAD software. If anyone is interested in providing an extra set of eyes, I have no issues sharing my files, just PM me. I'll update back when i find the issue. 

1 hour ago, jbaum81 said:

Nope, I cooked the Oscillator ? , I must have hooked something up backwards, Ordered a new 8mhz oscillator and it's fine.



Also figured out the issue with the flipflops on the banks. I was sending the clock signal to the flipflops when the address was set and clock went high, but for some reason the datelines were not ready fast enough, which doesn't seem consistent with 65c02 data sheet?!? ...

Now THAT seems like it makes sense, even to a software hand ... if it happened to be an HCMOS crystal oscillator circuit in the can, fry the inverters, which are the source of the VCC input, and seeing the crystal oscillation instead of a square wave seems likely, since the inverters are what squares up the wave.

But anyway, that's second timing is what the August 2018 datasheet says on page 26 ... the fourth line in the timing chart is the write data ... it begins with the data written the previous cycle, which should be valid tDHW after the start of the new cycle with the PHI2=0 transition ... it then crosses over since it is indeterminate until it crosses over again tMDS after the PHI2=1 transition for the rising clock cycle. So the valid write data is from tMDS (max 25ns[+]) after the rising clock cycle until tDHW (min 10ns) after the falling clock cycle. With a glue logic latch, data can be latched on the fall of the clock after the part is selected, as long as the latch is effective within 10ns of the falling clock.

_________________________________

[+ At +5VCC, 40ns at +3.0/3.3VCC, 70ns at +2.8VCC, 140ns at +1.8VCC.]

DANG IT!!! 

Found the last issue, Labeled the RW pin RWB in on the main sheet and RW in the logic sheet. Had to run a bodge from the RW input on my PAL to RWB net and now the board runs stable at 15Mhz!! woot!! 

Already started the 2nd revision with a few other enhancements like an LED array to show activity on the devices. It will be helpful when running slow and a cool light display when running full out. 

 

3 minutes ago, BruceMcF said:

With a glue logic latch, data can be latched on the fall of the clock after the part is selected, as long as the latch is effective within 10ns of the falling clock.



_________________________________

[+ At +5VCC, 40ns at +3.0/3.3VCC, 70ns at +2.8VCC, 140ns at +1.8VCC.]

Yup, that's essentially what I'm doing, just using just switched out the logic in the SPLD to trigger the clock pin on the latch on the falling edge.