6502.org

I haven't looked closely enough at places like visual6502.org but I think because of the way the 6502 loads and executes instructions, the minimum number of cycles per instruction is always 2. I may be wrong (I was hoping I am -- one-cycle NOPs would definitely come in handy e.g. for timing adjustments).
What I was trying to say there is that my project should (and will) at least be compatible with the Rockwell 65C02 as well as the WDC 65C02S, because someone might want to use undocumented opcodes as part of some hardware emulation project. And if the original hardware that they want to emulate, contained an NMOS 6502, they can probably emulate the hardware by using a CMOS 65C02 with my project (obviously with resistors in the circuit to convert 5V to 3.3V) because the 65C02 allows you to stop it by stopping the clock, which is what I have to do for short periods of time, e.g. while the main cog is switching between normal operation and "DMA mode". I wasn't talking about using those undocumented opcodes in my own code: we already established that it's better if I don't.

===Jac

Looking at http://visual6502.org/wiki/index.php?ti ... 56_Opcodes, it seems that opcode 0x80 (among others) is a 2-byte and 2-cycle NOP: that would presumably increment the address in each cycle, so it kind of works like a pair of 1-cycle NOPs.

Of course, the C02 designs might well work differently.

In short:

• The control cog runs an assembler program that loops around, getting instructions from the main program. Instructions are things such as "download bytes to SRAM", "upload bytes from SRAM", "run" and some other ones that are mostly for debugging. When it runs the main "run" loop, it clocks the 6502, generates signals (RESET/IRQ/NMI/RDY/SO) from a hub storage location, and activates the SRAM chip according to the R/W line, and it checks with the previously mentioned algorithm if another cog wants to stop it. It also optionally keeps track of the number of cycles executed so you can tell it to e.g. run 6 clock cycles after a reset. Normally exactly one of these cogs is needed.
• A memory control cog builds a lookup table from a memory map, and overrides the RAM control from the control cog, so that the SRAM chip doesn't get activated for any areas that I want to designate as ROM or external hardware. In most cases, exactly one of these is needed but it's optional if no memory areas need to be read-only and if all hardware is emulated by an I/O cog, see below.
• A hub mapping cog maps any contiguous 6502 memory area to hub memory, and disables the SRAM chip for that memory area. For some functionality such as a video buffer, this cog can map the same area for input as well as output. But for most I/O emulation (e.g. a 6850 ACIA where writing to a location means something other than reading from the same location) two or more cogs are required that run this code, with different configurations.
• Optionally, a trace cog can be used to log which locations the 6502 reads from and writes to.

The reason why I had to divide the work this way is that with all the glue logic, I need about 17 instructions per cycle to turn the chips on and off and clock data through the D-flipflops. I had to use a spreadsheet to figure out how to get the timing right, because I also have to take propagation delays into account. I can possibly make it work a little faster but then I'd need even more cogs: a system with some I/O chips and a video buffer such as the PET or the OSI Challenger/Superboard/UK101, will require up to 5 cogs to control the 6502 and SRAM chip, plus 2 cogs for the video and keyboard driver, plus one cog for initialization and I/O emulation.

For more complicated systems, it's possible to connect multiple Propellers "in parallel". This is an idea for later, but one that I definitely want to prepare for when I design the new PCB.

===Jac

BDD, we seem to have contradicted one another in regard to the W65C02S. Probably you meant no discourtesy, but you do seem to have a penchant for presenting your inferences as fact.

Of course, even the suspicion I presented ought to be supported, and I apologize. I've now located the reference that eluded my memory earlier. It is WDC's own data sheet for the W65C02S, and the second row of Table 7-1 describes Execution of invalid OpCodes.

• listed as 2 byte, 2 cycle are 02,22,42,62,82,C2, E2
• listed as 1 byte, 1 cycle are X3,OB-BB,EB,FB
• listed as 2 byte, 3 cycle is 44
• listed as 2 byte, 4 cycle are 54,D4,F4
• listed as 3 byte, 8 cycle is 5C
• listed as 3 byte, 4 cycle are DC,FC

Folks who find such minutia interesting may wish to visit this page of my site. I've documented not just the bytes and cycles, but also what the undefined NOP's actually do (on the Rockwell 'C02). Edit: later tests show that WDC's W65C02S cpu behaves identically except that it features WAI and STP, thus reducing the number of undefined NOP's by two.

Something I'd like to know is whether the one byte, one cycle NOP's delay interrupt acceptance. Edit: they do. Interrupts will not be recognized while a one-cycle NOP (or a string of such NOP's) is executing. Interrupts are recognized on the first non-one-cycle instruction that follows. More info here.

-- Jeff

[Edit]: Rockwell 'C02 -- not '02.
[Edit]: fix link. WDC cpu. Interrupt acceptance update.

I agree that what I've reported seems strange in light of the way the 6502 loads and executes instructions. It occurs to me that, to achieve the one-cycle NOP's, maybe they just jimmied the logic somehow so that the opcode fetch is artificially lengthened, discarding the first byte fetched (the one-cycle NOP). IOW, it doesn't really "execute." This is a case where that sort of cheap kludge is quite acceptable. After all, the one-cycle NOP isn't required to do anything (except advance the PC).

Thank you, Jac. Surprisingly, I've read just enough of the Propeller docs' where that brief explanation makes sense (lol).

I'm still on the uphill side of the learning curve with this puppy so I haven't quite figured out how one might synchronize twenty instruction cycles in one cog to twenty cycles in another cog, not to mention syncing each cog to their own four cycle hub access slot, but I'm sure that will come to light.

Cheerful regards, Mike

I have worked with many different processors and microcontrollers and though the Propeller architecture is very strange compared to most (if not all) of them, it's pretty easy to understand. Synchronization can be done by letting multiple cogs wait for the same value of the clock counter, or by waiting for a pattern to appear on the I/O pins.

Most instructions are 4 clocks except for hub instructions, wait instructions and conditional jumps when the condition is false. Hub instructions take 7 to 23 cycles because cogs get access to the hub every 16 cycles (not four): if the instruction is timed right, it gets executed at the exact time that a cog has hub access, and it takes 7 cycles. Otherwise it has to wait for up to 15 cycles and takes one extra cycle to set up the waiting.

Timing a loop that has hub instructions and combining the timing with other cogs is kinda tricky but not impossible. What makes it even harder is that I had to take propagation delays into account so the loop starts out with enabling the address bus buffers, and then doing something else for one instruction (4 *12.5ns = 50ns) while the address bus value appears on the input ports. I'm planning to write an article one day on my website (and perhaps a generic version on the Parallax website) to explain how I did that.

===Jac

PS I'm sorry about hijacking this thread so much, it should be about YOUR project, not mine.

Jac, I don't feel you're hijacking the thread and I hope no one else feels that way. It's related material and I appreciate everyone's comments and suggestions. Jeff actually outlined my RAM loader process in a thread I started a year ago, though I was already aware of the process when he mentioned it.
I was speaking in terms of instruction cycles. That is, if I synchronize cog/hub access I could potentially perform a hub access once every four instruction cycles, if necessary, and, yes, I realize that consecutive cog hub access windows are staggered 1/2 instruction cycle apart. This implies, as you mentioned, some heavy duty planning, too. For example, if I need to pass data between two cogs via the hub and I need to rely on precise timing for the transaction during a 1-usec 6502 clock, I need to pick two cogs with hub access windows in the right place. This also implies that I need to run the Propeller clock at 80-MHz rather than 100-MHz to keep each cogs hub access window from "rolling" (shifting slightly) during each 1-usec 6502 clock cycle. Jeesh!

I apologize for the confusion. I tend to think in terms of instruction cycles when writing isochronous code, rather than clock cycles.

More later...

Hi there,

GREAT work! Is there any chance to have the PIC source code? Here at our Computer Museum we really want to make a sort of Apple 1 mini prototype (or something else!)

Hi asbesto, IW9HGS. Welcome to 6502.org!

I hope to post the PIC firmware and documentation in the SBC Forum when the project is a little more complete. I'm designing a couple different PCBs and still adding features to the PIC firmware. Please be patient.

Very 73, Mike, K8LH (Michigan, USA)

Not sure how that W65C02S got in there. I must have been typing like a fiend and automatically added it.

There are no single cycle instructions in the W65C816S, which fact may be gleaned by studying the instruction operation tables starting on page 38 in the data sheet.

All "undocumented" W65C02S instructions are NOPs of varying lengths and by inference, do nothing to the registers, other than advance PC.

Odd that you'd mention it only by accident, as the entire thread is about the 'C02. Anybody's allowed to make a mistake, though.
Do nothing to the registers other than advance PC, yes.

OTOH, memory (and I/O) don't see all the undefined codes as NOP's. That's because some of the NOP's do a Read operation (as explained here). Although the CPU discards the data it read, the possibility that IO might get touched can create "destructive read" problems for those IO chips susceptible. But no problem with the single-cycle NOP's. They don't read anything except their own opcode!
Now I do consider this as confirmed. A few days ago I successfully ran a WDC 'C02 in the KimKlone -- a machine which uses the undocumented NOP's, and would fail to boot if they differed from those of its original CPU (Rockwell). Although the boot process doesn't exercise all the undefined NOP's, all those used worked, and all the byte & cycle counts listed by WDC agree with expected behavior.

I'm kind of excited to have a WDC chip running in the KK. Among other things, it'll allow me to run tests to clarify or glean more-detailed information when needed.

cheers
Jeff
[edit: update link]

I want to put a 65C02 in my version of Mike's design. My cunning plan is to put a 65C02 into a 40 pin DIP socket from which pin 1 has been removed (to stop VPB shorting to the 6502's VSS) and put a wire link between pin 40 (RESB) and pin 36 (BE).

This should make the 65C02 compatible with a socket wired for a 6502. Can anyone see anything I've missed?

When the PIC boots I'm going to execute a dummy JMP ($00FF) and see which address is accessed for the high byte ($0000 = 6502, $0100 = 65C02) to determine the processor type.

Sounds good, Andrew. Just remember other manufacturers' 'C02s are pin-exact replacements, made to drop straight into an NMOS '02 socket. IOW your adapter idea has relevance only if you're intent on using a WDC chip. Also, the WDC wouldn't need any adapter if you tied BE high and just cut off pins 1 and 5 (VPB and MLB). I admit the idea makes me cringe, but those rather esoteric signals are unlikely to ever get used.

The WDC will output a low on RDY should a WAI instruction ever be executed, so ideally you should insert a current-limiting resistor in series. But in an adapter scenario that won't be easy to do, and I myself wouldn't bother. I believe the risk of permanent damage to the chip is small -- and it's further minimized by the unlikelihood of a WAI executing in the first place.

BTW an alternative way of isolating CPU pin 1 from pin 1 on the board is to simply bend the CPU pin sideways about 45 degrees so when you plug it in it doesn't engage the socket on the board. You might also want to check that pin 5 on the board is indeed a no-connect (per NMOS), and hasn't been co-opted as a via or something. The WDC '02 outputs MLB on pin 5.
Nice idea, detecting the NMOS $6C bug -- but are you serious? Do you really want to be able to detect an NMOS chip??? Don't answer; I don't care if you are joking -- it's a fun little problem to solve!

The $6C instruction is one clock slower on the 'C02, and that could be detected by monitoring SYNC. Conversely, the 'C02 is one clock faster for a Read/Modify/Write instruction absolute indexed in same page. Or you could stage a write, and see if pulling RDY low produces any effect... The list of NMOS/CMOS differences goes on!

cheers,
Jeff

Not especially pretty but it works. The green wire is the connection from /RES to BE.

I've modified the PIC firmware to determine if the device in ZIF socket is a 6502 or a WDC 65C02 and load a different boot ROM for each.

A few days ago I put in an order for some PCBs like this. I will be putting SIL sockets on the board so I can fit either chip. There are headers for a PL2303 USB connection and an SDCARD module. My PIC firmware emulates an ACIA and an SPI65.