I think something simple like delay stages in one leg of a OR gate may introduce sufficient asymmetry.
Bill

PS, ignore the curved diagonal line at right side of the picture. It is the envelop flap.

That's interesting - I guess it wouldn't affect the base frequency, so you'd want to start from a frequency that doesn't quite run stably, then try this to increase stability.

I've actually just been trying something a bit similar - feeding the output of a 74AHCT74 through a chain of inverters, and tapping its set and reset signal from different points along the chain to form an oscillator. With 74HCT14 as the inverter, the fastest stable frequency I got was by putting two inverters in a row after each of the 74AHCT74's outputs (inverted and non-inverted) and feeding that back into the appropriate set/reset signals - this frequency was about 24MHz. Choosing asymmetric taps changes the duty cycle.

I replaced the inverter with 74AHCT04, and the frequency increased to 56MHz. The propagation delay is small enough that it feels like it could be used to fine tune the duty cycle much better than with the HCT inverter.

I also thought that, given a two-phase clock, you can drive a flipflop's set and reset inputs to copy the clock (with a slight delay), and if you then used inverters to delay the set or reset signals, that could also allow adjustment of the duty cycle. I guess there are a lot of options!

Edit: Now I seem to have made a 33MHz clock with 35% positive duty cycle, and the computer is working quite well with that. So it looks like skewing the duty cycle towards phase 1 is needed. I still don't really have enough control to tune the duty cycle and propery experiment with it.

Edit 2: here's a scope of PHI2 and A0, it is barely ready by the time the clock rises. It is being measured about 4cm from the IC pin, at the RAM. On a PCB this may be better.



Edit 3: and here's a write cycle - green is RWB going low, red is a data line just about reaching its target by the time the clock falls... It will be interesting to see how this looks on the PCB.

Yesterday evening I expanded the prototype's address bus to the full 16 bits, so that it can run more proper 6502 programs now. I'll develop some tests, maybe port the Dorman suite but it seems not quite what I need here. The RAM read/write stress test I already wrote ran fine overnight, for over 12 hours, at 25.175MHz.

Wiring wide buses is the one thing I really dislike doing on breadboards.

I started making the fast bus capture circuit to help with debugging, and got sidetracked by feature creep, wanting to add a frequency meter to it - this is where it got to so far:



There are four 74ACT163 counters, a RAM chip that's not wired up yet, and an LED display driver (MAX7219). The ATMega328 (in an Arduino Nano at the moment) polls bit 15 if the counters as part of its work managing the bus capture process, and just counts the rate that is changing, as for every falling edge 65536 CPU cycles have passed. So it can calculate the effective CPU frequency, which in this case depends how much ROM or I/O it is doing. It's interesting to see, for any particular 6502 program, what the effective clock rate is.

It should only need a few more glue ICs and some better Arduino code, then it will be able to record the bus data.

Wow George. Those are some of the worst breadboards in existence. That makes your successes doubly impressive in my book!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Haha have you tried them as well? I'm not sure where I got them from, they were probably very cheap at least - they were certainly a disappointment though.

Yes, I bought one from Ali Express a while back. I think it cost $8, including shipping. I was hoping that I might be able to mount some nicer breadboards on the back plate, use the spring clips to bring power on board, etc. Sort of make a nice custom breadboard rig. Even that didn't go anywhere; the spring clips melted internally the first time I touched them with a soldering iron!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

This evening I wired up a WDC 65C22S as per the schematic I posted a few weeks ago, to check that was all correct, and it seems fine. Wiring it in was fairly routine - it goes on the I/O bus rather than the CPU bus, and sees the I/O clock as its "phi2", and most of its other signals are shared with the ROM which already worked. The only subtlety, really, is that the I/O management PLD needs its clock to be inverted with respect to the VIA's clock, so that it can prepare the chip selects etc ahead of the rising edge of the VIA's clock - the main thing I wanted to test here was that that works.

I've just realised this was using a 16MHz oscillator, a bit out of spec for the 65C22S, but it seemed happy enough. I don't really intend to keep it at that rate though, I don't see much point in overclocking the I/O!

As part of the test I set it up to communicate with an Arduino Mega, using 8-bit transfers on Port A, as that had been discussed recently on another thread here, especially how handshaking works. This worked well. It was strange to see the 6502-based computer hugely outpacing the Arduino in the communication - when the Arduino acknowledged receipt of bytes, the 6502 got the next one ready to send before the Arduino could finish its acknowledgement (about 5us) and this highlighted some race conditions (bugs in my Arduino code) that I hadn't anticipated. But I guess it's to be expected, as they are running at similar clock speeds and the Arduino code was not well-optimised, while the 6502 code is very lean and direct.

George,
I have a dim memory of running W65C22 to 24MHz, but I can't find the documentation. W65C22S6TPG is the same 0.6u technology as W65C02S6TPG so it is not too surprising that it can be overclocked like W65C02.

ROM is the weak link; if there is a way of serially bootstrap or a way to copy ROM into RAM at slow clock or a way of getting data into battery-backed fast RAM, the resulting RAM+W65C02+W65C22 without glue logic may run at very high clock with no wait state.
Bill

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think it might well be worth trying the Dormann tests.

I had interesting experience trying to get a Rockwell R65C02 running in a Model B that turned out to have marginal memory timing.

Memory tests and Elite worked fine, but the Dormann test suite failed on just one case: SBC #$FF

Here's a short trace:

It looks like the carry out of SBC is being calculated incorrectly, due to the incoming (immediate) data arriving too late (violating the 6502 setup time). This kind of path through the ALU tothe carry is likely one of the longest in the 6502.

Appart from this one isolated failure, this machine seemed perfectly stable, and would run Elite for hours without crashing.

More details here:
https://stardot.org.uk/forums/viewtopic ... 61#p193061

Dave

That's good Yes I'm not worried about overstressing the parts, just curious what they can do and what kind of support circuit is needed to get there. This design isn't a good one for fast I/O speeds because it deliberately puts the VIA on a slower bus, but if the 6522s are similarly capable to the 6502s then what plasmo suggested makes more sense, just putting the 6502, RAM, and 6522 together with an appropriate bootstrapper, and running them as fast as they'll go with no need for any clock stretching or slow buses (all I/O can go through the 6522).


Interesting, I was wondering about this kind of thing - there must be certain worst-case paths through the CPU, and specific instructions or CPU states could be harder to support than others. It would depend on the specific CPU being tested. I keep remembering a case for early ARM CPUs where one of the output signals is usually ready quite early in the cycle, except for a specific sequence of conditions which leads to it changing state later in the cycle.

The Dormann suite looks quite thorough regarding CPU functionality testing, I will have to work out how to compile it! My prototype does have a 16-bit address bus now so code size is no longer a constraint.

I went ahead and did that this evening, and it was indeed worth it as it uncovered a lot of issues, if somewhat indirectly!

I rigged up a crude serial output port using the four-chip circuit I built about a year ago - 74HCT594 + 74HCT166 + 74HCT74 + 74HC40103 - and used the VIA's T1 to time the gaps between 115200 baud bytes. And fixed the off-by-one error you pointed out last year

That allowed setting up the Dormann suite's "report.i65" module to send readable reports to the serial console rather than just hanging when tests fail. This is an optional component to the tests which you can enable and customize if you want/need such output - the core tests are designed to be run from a monitor or emulator that allows breaking and inspecting the program counter and memory, to figure out what's wrong when they get stuck.

I then spent several hours reattaching the bus capturer and logic analyser and running the decoder to try to work out why on earth it wasn't working. The decoder was very useful here - it revealed a lot of cases where the CPU was reading values that were different to what was meant to be in the EEPROM. It wasn't obvious at first that this was happening, because the decoder was happy to report that the CPU was acting exactly as expected given the data it was receiving - the decoder didn't know what was meant to be in the EEPROM. Perhaps that'd be an interesting feature to add - preloading the memory for its verification system to run based on.

Eventually I realised that the transition from $80FF to $8100 wasn't working properly. The oscilloscope revealed what looked like faint echos on the A8 line - pulses only reaching about 1V, while other pulses were at the full 5V. After checking for correct power and ground on relevant ICs (as that's usually what I suspect when a digital signal is not at the right voltage) and then just blaming a transceiver being faulty, eventually I realised that I had miswired the EEPROM and shorted two of the address lines together, and mixed up a few of the others. So then I felt sorry for the innocent transceiver!

I think this wiring error didn't show up previously because I was using a smaller EEPROM and basing the code at $E000, and as such a lot of the address lines were high anyway, meaning I guess when they were shorted together nothing bad happened. The Dormann suite is over 16K though so it needed the full 32K EEPROM.

With that fixed, the 6502 tests ran without problems. The 65C02 tests are failing though and I don't have the energy at the moment to decipher the format of the error message it displays - I'm going to leave figuring that out for another day! Edit: Oh, I get it... the first number is a memory address (e.g., near the top of the stack) and the numbers after that are the next few bytes from that address. So it failed at $2581 and we can see some data from its zero page and data segment. Still a mystery for another day

That's failed on test case 0F (shown as address &202)

The test case number depends on the test options you have selected:
- wdc_op (defult = 1 = no test)
- rkwl_op (default = 1 = full test)
- skip_nop (default = 0 = test as nop)

With the defaults I think test 0F is:

My best guess is that it's a TSB instruction failing due to an incorrect Z flag:
https://github.com/Klaus2m5/6502_65C02_ ... a65c#L1883

To be sure you would have to post your assembly listing, and a better still a trace of the failure.

I'm glad this was a useful exercise. I love digging through failed Dormann tests!

Dave

Ah that's good to know - I didn't see a good reference on what the memory was used for, so wasn't sure what to make of it! I approached from a different direction - judging by the report code, the stack is showing the register contents at the time of the failure, in the order listed in the first line, plus finally the return address, and from the listing file the return address was within the "tsbt zpt,0" test case (line 1918), reporting a failed Z flag test as you suggested (line 1883).



I did look a bit further at this last night. The tbt1 loop at line 1897 is looping over all combinations of Y and zpt+1. We see from the stack contents that in our case Y=0, and from the zero page memory dump, zpt+1=&7B. The test setup is meant to store Y at zpt (line 1866), but that doesn't seem to be the case for us - zpt = &7B, same as zpt+1. It's also meant to store flags at zpt+2 (line 1902) - this is ANDed with the zero flag's mask (2) so the value there ought to be 0 or 2, but it is also &7B. zpt+3 and zpt+4 both look fine.

I couldn't work out how they could get in those states, aside from memory corruption in one of the earlier test cases in this group, so thought I really needed a decoder trace of it - however my capture device only supports capturing a 32K window after a trigger condition (usually reset, but I also wired it to a VIA output pin), and the exact point of failure seems inconsistent. I should add support for continuous capture, stopping when the trigger condition occurs, so that I can put the trigger in the reporting code and see what happened leading up to the failure.

Does it only fail at high clock speeds?

If it fails at 12MHz (say) then you might be able to capture a synchronous trace with the FX2 dev board.

Dave