http://6502.org/users/dieter/x02/x02.htm

It's very fresh. He PM'd that link to me just this morning. I have almost no hope of completely understanding what he was doing there, at least with my current level of knowledge, but it pleases me that you were able to gain some insights.

Best wishes,

Mike B.

Ah, that explains it!

Glad it's up. I found the proposed TTL sequencer and state machine fascinating - no microcode! I had thought doing that was going to be totally impractical and dropped it. Very exciting to see it in X02. Probably well beyond my reach as well but interesting nevertheless.

_________________
C74-6502 Website: https://c74project.com

Looks like the NMOS 6502 puts the low byte of the operand through the ALU: it comes out in the right cycle to be used as the low address byte and to be loaded into the PCL.

My core also holds the PCL byte in the ALU for a one cycle delay. The nice thing is that all the muxes are already there for other purposes, so it only needed proper control signals.

The projects ttlworks has done over the years are amazing! It'll be no surprise if you're able to refine your design by studying some of his. Meanwhile here are some rather pedestrian improvements to the wiring you posted already.

The left side of the diagram below shows the S register and two tri-state buffers that allow its contents to be driven onto the R bus and the ADL bus. On the right we see the job done with 2 chips rather than 3. This same pattern appears in two or more places in your design.
The next mod is minor. It saves a 74xx04 inverter section and may be slightly easier to understand. Below we have the least-significant section of a 16-bit adder, whose job is to take the A operand and increment or decrement it. The B operand is hardwired. The revised version is slightly simpler, and directly establishes the B operand as either 1 or $FFFF -- ie; -1.

Two little footnotes. Earlier in the thread you mentioned initializing S to $FF upon reset. That's probably harmless but it's not authentic -- a real 6502 doesn't do that . Also:Yes, 7 cycles when there's no page crossing means the standard NMOS 6502 wasted one cycle. It makes sense that your machine is capable of doing the job in 6.

Interestingly, the wasted cycle of a Read-Modify-Write instruction combined with absolute-indexed mode, no page crossing, got "fixed" in the 'C02 CMOS CPU -- but only partially! ROL ROL ASL & LSR got fixed but INC & DEC didn't. And the partial fix is inaccurately documented by both Rockwell and WDC.

cheers,
Jeff
[edit: last paragraphs]

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

Thanks for the comments gents.

An ADDER output hold register is interesting to me and I can see how it facilitates this operation. That said, I'm convinced I'm still failing to appreciate fully the implications of this approach. I certainly see how having latches in the data path can be beneficial (given that the ALU is likely the critical path in the processor). For example, I latch memory reads into the input of the ALU so that a memory read can be performed in one cycle and the ALU operation in the next (during an ADC abs, for example). In all other respects, however, the ALU is a pass-through, from source register through ALU and back to target register in one cycle. The same is true for the INC16 circuit. Somehow, this approach seems more intuitive to me and the delta in propagation delay of going to the target register directly vs. an ALU output latch seems small. I was reassured to note that Dieter's X02 also seems to dispense with an ALU output hold register (and employs uni-directional buses as well by the way).

Lot's of different approaches here so more study ahead for sure ...

On that note, I was excited to discover some inefficiencies in my BCD logic when looking at Arlet's core. The key detail was that my Half Carry was fed directly from the low-adder to the high-adder, rather than being OR'ed with the BCD carry (i.e. a BCD half-carry needs to be generated when the low-nibble has been BCD adjusted). I suspect my confusion came as a result of having split the low and high nibble BCD adjustment over two cycles (because it just took too long otherwise). In any event, my logic was more complex and slower.

The improved circuit still requires an extra-cycle to complete though ... uhmm, hold on ... could this be the pay-off for an ALU output hold register?! i.e., enabling better pipelining to spread ALU operations over more than one cycle but still keep to the NMOS 6502 cycle count - it's good motivation to continue to explore.

By the way, I've also been spending some time looking at the state machine in Arlet's core - very nicely arranged, and it clearly illustrates common steps in various instructions types. If I ever get the opportunity to revisit my original gate-level instruction decoder and sequencer, this will prove an invaluable guide. I need to read up on Verilog some more as well - such a powerful tool!

_________________
C74-6502 Website: https://c74project.com

On the contrary Jeff, I've spent many hours trying to figure out how to connect these things together and it's been far from obvious. I'm learning a lot from these pointers and very much appreciate them.


Love this. I simply would never have thought of it - every instinct as a programmer would argue against having two copies of the same data, but here there is no risk of sync issues here, it saves a chip and lowers propagation time as well. Nice.

The original INC16 circuit was designed to work in units of 2 also by manipulating the input carry. I managed to re-write the microcode to no longer need this but didn't realize the inverter is also no longer required.


Agreed. Once the circuits are complete, I intend to tidy up the microcode and should do this then. BigEd made some good suggestions for legibility which I want to follow-up on as well - like using PCL and IR rather than PCl and I.


Oh my ... I'll need to check all this carefully. My objective is to be authentic relative to the NMOS 6502 I think, so I'll want to add the "wasted" cycles. Again, a job for the microcode tidy-up to come.

Many thanks for your comment and thoughts.

Best,
Drass

_________________
C74-6502 Website: https://c74project.com

Arlet's core synthesises to a very small implementation - it is very much in the spirit of the 6502 in decoding and in executing. One interesting case is JSR: the machine needs to keep hold of the first operand byte while it stacks the current PC. As stacking means using the ALU for decrementing - both Arlet and the original use the ALU for every operation other than incrementing the PC - the low byte of the destination address needs to be stored somewhere other than the ALU output. The answer is to use the stack pointer to store this byte, for the crucial 4 cycles.
http://www.visual6502.org/JSSim/expert. ... loglevel=4

That is incredible to me ... not only that the low-byte of the target address can go to S temporarily but also that S itself is available at all. In effect, S is not required during the stacking procedure since the result of the ALU is stored in the Adder Hold Register and can be decremented from there - and the Hold Register is itself connected directly to ADL to address the stacking operation without any further fuss. Wonderful!

Arlet, I know you mentioned you have the same cycle count as the 6502, but BigEd's comment suggests you go further and actually replicate many of the same internal steps to execute instructions. Is that right?

_________________
C74-6502 Website: https://c74project.com

I didn't really replicate the NMOS 6502, because I didn't know exactly how it worked internally. All I used was Hanson's block diagram, and the MCS6500 Microcomputer Family Programming Manual. The manual has some good detail about the bus cycles, and the diagram offers many clues, but there was still a lot of guesswork left. At the time I didn't know about the visual 6502 project, or maybe it didn't exist yet, I don't know. I think that my plan to use the ALU for all internal calculations (following the diagram), and to keep everything as simple as possible, lead to similar paths as in the original.

Regarding the clever use of the stack register to temporarily hold the PCL, I must admit the trick wasn't mine. I had a separate PCLHOLD register in my original code, whose only purpose was to hold PCL during RTS, JMP, and JSR. BigEd told me about the trick to use the S register, and it happened to fit on my core, with a minimum of modifications.

Note that a deviation between my core and the NMOS 6502 is the register file and the tristate buses. I have all 4 registers in the same file, and instead of internal buses, I have a bunch of muxes (modern FPGAs don't support internal buses).

That makes sense ... I did not rely on the available block diagrams simply because I didn't understand them - I'm beginning to now. As a software guy, I started by "pseudo coding" microcode, treating registers as "variables" and then working things out as I went with Logisim. It's very eye-opening to see the different approaches now.

In any event, I continue to make progress and I'm close to having the CPU schematic completed (with the improved BCD circuit). Here is what I think is the order of operations:

1) Finish testing the BCD logic in Logisim, including the flags ... (I think Bruce Clark's articles can help here)
2) Clean up and finalize the schematics & microcode, validate cycle counts and timing
3) Design the supporting circuits ... clock, power, front panel, blinky-lights, etc.
4) Figure out how to layout all this on actual boards!

#4 is another ball-game so I'm looking forward to that. With some luck, I'll get the CPU schematic posted up shortly.

Cheers!

_________________
C74-6502 Website: https://c74project.com

I just re-read through Bruce Clark's description of the behaviour of the NMOS 6502 flags in decimal mode. I have to confess to not paying close attention before. Since only the carry is "valid" in decimal mode, I had decided to just let the other flags be set as usual after the BCD adjustment was complete. In going back now to review and consider replicating the invalid behaviour, I am reluctant to do it. I just can't see adding additional logic, for example, to purposely clear the Z flag after:

So much for authenticity.

I have not taken the trouble to implement illegal opcodes either, so my 6502 will be quite "inauthentic" in fact. I have no idea how prevalent the use of either illegal opcodes or invalid decimal mode flags really is out there. As a C64 programmer back in the day, I can say that no one on our team used these features, but obviously that was not the case everywhere. There is a list of unofficial-opcode-using-games here: http://wiki.nesdev.com/w/index.php/CPU_unofficial_opcodes, for example and I've read that lots of implementations go to some lengths to support the "unofficial" features. Be that as it may, I think for now I'll take my chances and move on.

_________________
C74-6502 Website: https://c74project.com

I think either way - doing it or not doing it - is fine. If you do all the extra work, you get some fraction more authenticity. But for a practical working 6502 you don't need it.

Agreed. Going back to the original objective, I want "a fully functional processor accurate enough to be genuingly called a 6502". I think it gets there without the undocumented features.

And with that decision, I think I can declare the overall architecture and design final!

A nice place to get to by the end of the weekend. I've reviewed everything and functionally I'm happy with were things ended up, including cycle counts and the structure and speed of the data path. Thanks for all the help along the way.

The focus now is squarely on the schematics ...

Cheers!

_________________
C74-6502 Website: https://c74project.com

It's still authentic because the original 6502 designers didn't implement illegal opcodes either. They just happened to do something.