It does exactly what it would have done when it was interrupted by the halt. That would have happened at the end of a clock cycle, just as it is when the halt is released. So if that was to fetch an operand, or an address address or to push the PC onto the stack, then that is what it's going to do.

Just as a matter of interest, how slow is the ROM? Are you using EPROM or something else?

_________________
Bill

I'm using the same method on my 65C02 but am only using it for ROM at the moment and haven't had any issues.

Was just thinking though on my system with MRD/MWR gated by PHI2 wouldn't any Wait-stated read/write operations be effectively doubled up? for ROM this doesn't matter because the MRD is only used for OE and the address and CE remains stable. but what about devices like the 28L92 with it's auto incrementing register & certain commands that require X amount of clocks between invocations?

I think I'm confusing myself and I'm nowhere near as knowledgable at this as everyone else here so sorry if I'm just being really dumb.

Hi, guys. Gonna overlook some of the later questions and back up a little. Maybe the authors of the datasheet could've been more clear. Let's see if I can do better... at the expense of being much wordier.

Every cycle (clock cycle, I mean, not instruction cycle) has work to do -- stuff that needs to happen, both internally and of course externally for the memory access that takes place on the buses. Toward the end of every cycle (ie: tPCS before the fall of PHI2 ) external circuitry on the mobo is required to put RDY high if all's on schedule, or pull RDY low if dinner's still in the oven and further baking is required. If all the ducks are in a row we will move on, and after the fall of PHI2 -- ie, during the following cycle -- we will have new work to do, usually involving a new address on the bus. But if RDY got pulled low then things will not move forward.

Instead the following cycle is simply a continuation of the work we already started (and of course the address will NOT change). The continuation can happen once or any number of times consecutively. After the appropriate number of "not-done-yet" cycles the mobo will decide the ROM or whatever has had enough time, and RDY is put high again (meeting the usual deadline of tPCS before the fall of PHI2). Then after the fall of PHI2 -- ie, during the following cycle -- we move on just as if no pause had ever occurred, with new work to do and (usually) a new address. Hope that helps, but if the extra verbiage has only further muddied the waters then I apologize!


One important point. To guarantee an extra cycle will be inserted it's necessary, as noted, to bring RDY low tPCS before the fall of PHI2. But what happens if RDY is brought low sometime after the deadline? The natural assumption is, "either you get an extra cycle or else you don't" -- IOW, only two possible outcomes. But my understanding is that that's incorrect. There's a third possible outcome, namely that the chip could malfunction, subtly or otherwise. RDY is supposed to remain stable from tPCS before the fall of PHI2 until tPCH after the fall of PHI2. If you go changing horses in midstream it's possible some parts of the CPU will proceed and others won't. Not good!

Full disclosure: I have not observed this problem myself, and the odds may be small (and may be different for a 'C02, say, than for an NMOS chip). The threat exists if/when more than one internal flipflops accept input that's dependent on the RDY input. (I'm not talking about metastability, which is an issue that affects one individual flipflop.) Whether that makes sense to you or not, my advice to anyone using RDY who experiences unexpected behavior is to ascertain that RDY is held stable from tPCS before the fall of PHI2 until tPCH after the fall of PHI2 (in compliance with the datasheet). Possibly the figures are conservative, meaning you could cheat a little at one extreme or the other. But there still exists a danger zone in the middle.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Fixed the [what] omission.


I'm using a 55ns EPROM. The EPROM does behave on POC V1.1 running at 12.5 MHz, which is pushing it.

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

55ns is pretty fast. There are 45ns EPROMS that might help. I've only found 128MB versions, but honestly have not looked at anything bigger.

I'm using the 45nS jobs in my project and they are running happily at over 16mHz. Something begins to fail at 16.7mHz, and I'm fairly sure it's the EPROM. Anyway, if it helps they are ST M27c1001-45XFI units.

I think Jeff and I said the same thing. The CPU will move ahead from where it left off.

Without analyzing, or some knowledge of the current instruction, can your circuitry handle consecutive wait states in the same instruction cycle? For instance, the JMP instruction requires 3 consecutive reads from ROM. Others, like JSR have multiple reads from ROM and writes to RAM. So these cases have to be accounted for and the /RDY line cannot be released without regard for the timing of the instruction cycle (over the clock cycle) or the CPU will proceed regardless of the readiness of the slow memory.


EDIT: Corrected EPROM part number.

_________________
Bill

Just what was it you had for dinner?


So if I'm correctly following you, your interpretation is the MPU will have completed the current task at the point where RDY is returned high (assuming proper timing) and the fall of Ø2 following the release of RDY will be the start of a new instruction or the start of the next step in the current instruction.


Yep!

The logic I am using in POC V2's CPLD pulls RDY low as soon as the CPLD recognizes that the '816 is emitting a valid address (VDA || VPA is true) and the address corresponds to ROM or the I/O block. The actual high-to-low transition of RDY occurs on the rise of Ø2. At the expiration of the wait-state period the low-to-high transition of RDY also occurs on the rise of Ø2. Hence timing requirements should be easily met.

Here is the wait-state simulation for POC V2.0's CPLD:


The wait-state starts at vector 12 when the address $00E000 is put on the bus, that address corresponding to high ROM. Recall that the '816 generates a valid address about midway through Ø2 low. So the CPLD "knows" about the address while Ø2 is still low and thus "knows" that a wait-state is going to be needed. Hence at vector 12 the CPLD pin STP, which drives RDY (see bottom trace in the graph), is switched from high-Z to active, which means the CPLD is now driving RDY high—RDY is also pulled up to Vcc through a 3.3K resistor.

At vector 13, the CPLD drives STP low, pulling RDY low and starting the wait-state. Vector 13 is at the rise of Ø2, so the logic easily meets the tPCS setup deadline mentioned by Jeff, as well as the tPCH hold time. The MPU is halted and if one can believe the data sheet, the address bus, VDA, VPA and RWB will remain unchanged. Furthermore, the data sheet indicates the MPU will internally freeze in the Ø2 high state (which infers a wait-state could also be produced by simply halting Ø2 during the high phase—not something I've ever tried, but technically feasible with the POC design).

At vector 21, the wait state expires and the CPLD drives its STP high, a procedure that assures RDY will rapidly return to the high state, regardless of the effects of parasitic capacitance. The data sheet says that with RDY returned high the MPU will resume execution on the next fall of Ø2, which would occur at vector 23. Again the tPCS and tPCH setup and hold times, respectively, would apply. Also at vector 23, the CPLD is done with the wait-state and returns the STP output to high-Z, leaving the pullup resistor in charge of keeping RDY high.

According to Jeff's description, at vector 24 the MPU would either start the next step in the current instruction or enter the opcode fetch phase of the next instruction.

During the wait-state, it is necessary to keep both the ROM's /CS (chip select) and /OE (output enable) control inputs stable. You can see that ROMSEL (ROM select), which is connected to /CS, is asserted at vector 12 and /RD (read data), which is connected to /OE, is asserted at vector 13 (rise of Ø2). Both signals are kept in that state all the way through vector 22.


I did a search for ST MC271001-45XFI and came up empty. What is your source for them?

I do have some Atmel 27C256 PROMs that are rated for 45ns. POC V1.1 will boot at 15 MHz with one of them, but the SCSI hardware can't keep up at that clock rate. So even if a faster ROM would help I still have to accommodate slow I.O hardware.


It should be able to do so.

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

Perhaps it is too early morning for me, but the two timing diagrams presented shows a two cycle delay. The given schematic from Daryl would produce a one cycle delay. According to the circuit RDY would went low on the rising edge of PHI2 and went high on the next rising edge of PHI2 regardless of the state of WS_EN.
Both timing diagrams shows a RDY signal that went low with the rising of PHI2 but then stays low the next rise of PHI2. This would cause RDY=0 to the CPU 2 times, not one.

my 2 cents

Hello,
When reading the text, I would assume the CPU takes care of the logic in such way that it just stops processing. (Like the Q2 clock is not there) and continues when Q2 "flags" another active cycle again.

Somewhat different approach, based on previous experience: Ask WDC / Bill Mensch.
In the (far) past, I have received an answer from him. (Unfortunatelly, I don't have that anymore)

And I think there's also another way.
As the CPU is fully static, it can be clocked at a very slow pace and thus measuring voltages will be ok.
For timing sensitive stuff this would not work at all, but this seems not the case here. It would go wrong at any speed.

BR/
Guus

Hoglet has published a trace of a 65C12 system using RDY:
http://stardot.org.uk/forums/viewtopic. ... 57#p194057
and
http://www.stardot.org.uk/forums/viewto ... 42#p182742

ref: A novel 6502 Protocol Decoder for Sigrok

Hah -- yeah! I, too, noticed the figures of speech that crept into my post. Was gonna make a food-y joke about it, but then later on it was "change horses in mid-stream," and at that point I lost my appetite.

Yes, that's right. For our purposes the following scenarios are exactly equivalent.


BillO made much the same point; sorry I failed to acknowledge this. Guus Assmann also makes a good point. The CPU is fully static, and can be clocked at a very slow pace. That kind of debugging might be the best way to find out what's happening, BDD -- it bypasses the communication challenges that can arise when trying to unravel things by committee on the forum. Maybe the best thing is a "committee" of just one person, charged with reviewing (and verifying) exactly how the CPU and CPLD are supposed to interact. Have fun, and keep us posted!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I got them on eBay back in January from a vendor called: xiaobao_semi http://www.ebay.ca/usr/xiaobao_semi?_trksid=p2060353.m2749.l2754
He doesn't seem to have any left at that speed, but other vendors on eBay do.

I also got the number wrong - they are M27C1001-45XFI - sorry about that.

_________________
Bill

Correct. I added a second flop, which in turn, added a second cycle to the wait-state.

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

Can you elaborate what kind of mis- or unexpected behavior causes you to think about some design error?
Is this behavior repeatable? Can you influence it (e.g. clock speed, voltage, ...) ?

It's an obsolete part, according to ST Microelectronics, and also is not adaptable to POC V2, due to differing package sizes.

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

It's too bad it won't fit.

As to the obsolete thing, I usually don't let that bother me as long as they are still available from somewhere. I never plan to commercialize this. I usually just buy enough for any foreseeable needs of my own. I got 10 of these for about a $1 a piece. For my current project I expect to have one board at 16mHz, one at 14mHz, one at 10mHz one at 4mHz and one at about 2 mHz. This way I can have a common platform that will run interfaces of all speeds. The slower 3 will work with some 70nS EPROM chips I have so I'll still have 8 of the faster ones for future use.

_________________
Bill