Yup! That aspect is pretty cool. But dynamic logic makes debugging harder because on one -- or both, depending on the design -- phases of the clock you're obliged not to stop. (A minimum speed is in effect; if you stop you'll lose data.) Edit: stopping *is* possible if you include active terminator ICs on the buses in question. TI makes some suitable parts -- see the attached datasheets. These ICs make some otherwise challenging designs readily doable. You're no longer relying on capacitance to hold the value. "The feedback path on each internal buffer stage keeps a bus line [...] at the last valid logic state [...]"


Wow, Dieter, you're fearless when it comes to wading into the deep end! These details can be really tricky to pin down. But that raises an important point. Is there an authoritative reference you can rely on, Roberto? It strikes me that undertaking to implement the NMOS undefined operations is very ambitious indeed. Klaus's test suite won't help you here. Unless Dieter revises it for NMOS! Hmmm...

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

I have to agree: (1) Dieter is totally fearless, and (2) this is all very ambitious, at least for me! Candidly, the whole project has been a series of "deep ends", one after another, and I have to say a whole lot of fun as well! I take the point that the "unofficials" present a greater challenge, but it certainly feels like the work is worth while. Dieter is doing some amazing analysis and it would be great to see it through. (I just hope I can keep up ). As ever, lots of work remains ...

The current design is cycle-accurate for most undocumented opcodes already - those that can be done in microcode. I believe these can be reasonably tested and the cycle counts verified. In cases where there is ambiguity or "instability", we have used a combination of a real 6510, the VICE emulation and the Visual 6502 to settle the issues. Not sure this would count as authoritative, but it seems to be working well for the moment. I certainly agree that a test suite for unofficial opcodes would be a worthy project!

At this stage, two key issues remain:

1) how to deal with the "ANDing" problem on the bus
2) implementing ARR in decimal mode (from Diether's tests, binary mode looks fairly straight forward)

Admittedly, these will all require significant changes to existing circuitry, but "completeness" seems a compelling enough goal to warrant a solid attempt at it. One hesitation here is that I don't want complicate the basic design with too much specialized circuitry (not sure what to make of that seeming contradiction at the moment). There's lots of work ahead either way, but as Dieter puts it "we're not in a hurry"

Cheers.

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

Spent some more thoughts about the open_collector bus concept.

When trying to implement something like this, I think that the best approach
would be to use a 74AC541 with the data inputs tied to logic high
for injecting a maybe 30ns charge into the bus after the falling edge
of PHI2 for driving the bus lines high while all the pull_down drivers
on the bus are disabled.

This might work because the CPU isn't pipelined and the microcode ROMs
need more than 45ns to emit valid data after the falling edge of PHI2.

It's just that from what I know, nobody seemed to have built something
like this, so you can't be 100% sure that it would work in a reliable
way after making some more experiments...
as 4 layer PCBs don't tend to be inexpensive.

BTW: would say, that some care should be taken when choosing/placing
the bypass capacitors at the VCC pin of that 74541.

;---

On the other hand, my suggestion of having a "register" on the R bus which emits (A & X)...
from the microcode point of view, this would _look_ like another register...
and another "register" on the B bus which emits (DPH+1) wouldn't require
much modifications to the (already pretty crowded) register PCB.

And if the required circuitry for this modification won't fit on the ALU & CU PCB,
there still would be the option to build a CPU with two PCBs where the undocumented
opcodes won't be cycle exact (as quite a few of the "end users" probably won't
need to have them cycle exact, when using the 65C02 microcode for instance),
and to plug a "kludge PCB" which contains the required circuitry for making
them cycle exact between the register PCB and the ALU & CU PCB if required...

;---


When I was active in hobby electronics, I had to find solutions to problems which were worse.
BTW: wading into the deep end might be less difficult than making it back from there.


Considering that this is your first CPU project, you really made it far.
And it's nice that you still enjoy this journey...
most people probably won't have the time and the patience to go for such a project.

BTW: you could try to make calculations for both variants:
for the open_collector bus,
and for my approach for sending (A&X) into R bus and (DPH+1) into B bus.

When I toyed with my C64, it really was (H+1), not just H.

;---

To me, ARR in decimal mode provides quite a problem.

Modifying the BCD correction circuitry of the CPU to match ARR in decimal mode
would be pretty hard.
Don't know how to do this... now... but I think this has the potential to slow down
the rest of the CPU.

The alternative would be building a "correction circuitry" only to be used with ARR
in decimal mode, but this would take:
2*74151, 2*74283, 1*74541...
and this probably won't simplify the flag evaluation circuitry.

Need to spend some more thoughts on this.

;---

Flag evaluation still is a topic, too.
Because in decimal mode, it still doesn't correctly replicate the incorrect NMOS 6502
flag evaluation.

When taking a look at Hanson's block diagram, to me it somehow looks like
the BCD correction circuitry seems to be "part" of the accumulator,
and the flag evaluation checks the ALU output before it enters the BCD
correction circuitry.

But the circuitry that detects $XA..$XF and $AX..$FX at the ALU output
(for controlling the BCD correction circuitry) somehow seems to be "part" of the ALU,
generating a carry which goes into ALU Bit 4 and ALU output carry.

;---

We _assume_ that the innards of the 6510 resemble the innards of the NMOS 6502
in most parts... but we don't know.

We don't know until somebody sliced the silicon of different 6510 versions,
made a transistor level simulation of it, and figured out how it works in detail.
And this probably won't happen in the next time.

Point is, that just "assuming" something in the world of hardware design
could be going to be quite expensive in terms of time and money sometimes.

I would put a little money on the 6510 being a 6502 core inside, if it matches cycle counts. The main distinction between cores is whether decimal mode takes an extra cycle (which is a patent avoidance tweak.)

Can you perhaps run Bruce's decimal mode test on your 6510
http://www.6502.org/tutorials/decimal_mode.html
and see if it's just like a 6502? That doesn't prove anything about ARR but does say something about the mechanics of flag generation.

IIRC, the V flag comes from the ALU, prior to decimal adjust. The N and Z flags are computed from the internal databus, which is after the decimal adjust. As for the C flag, it seems it must be produced after decimal adjust, but I can't find the appropriate signal right now, either in visual6502 or Balazs' giant schematic.

Thanks, will try to run Bruce's test program in 'Appendix B' on my C64 in the next few days.

Addendum for the open_collector bus:

;---

Using a 74541 for directly driving the bus lines high by a short pulse after
the falling edge of PHI2 makes the bus faster, but it has two disadvantages:

When stopping the CPU clock, we need to have a weak pullup resistor at the bus line,
to prevent the charge on the bus line from "slowly" flowing out of the bus
because of the weak input current of the CMOS inputs at the bus line.

After the falling edge, the address inputs of the microcode ROMs change,
so in theory we could expect to have a glitch or such at the ROM outputs
that control the read decoder... and this accidentally might enable
pull_down drivers on the bus that shouldn't be enabled...
while there is no strong pullup, what might corrupt some Bits on the bus.
To prevent this, the 74138 read decoders should be gated...

And a reliable implementation of that "decoder gating" would affect the bus setup time,
slowing down the CPU.

;---

Another idea would be placing resistors between the outputs of that pre_charging
74541 and the bus and to give the chip an output enable for a somewhat
longer period of time...
active until the possible glitches from the outputs of the pull_down drivers
on the bus have settled down, that is.

But because of the resistors and the bus capacitances the bus lines would reach
logic high level a bit slower, what again would affect the bus setup time,
slowing down the CPU.

;---

@Jeff:

One could build a "bus hold device" with output enable by not resorting to "exotic" chips.

For instance, when taking a 74541, placing resistors (SMD resistor network) between
the inputs and the outputs, then connecting the inputs to the bus.

...So the output of a bus driver that wants to set the logic level on the bus to a different
state would have to "push/pull current" against those resistors.
Had plans to use this trick as an active bus termination in my TREX project.

Just for completeness - I've now found the appropriate bit of logic, using this simulation. What I was looking for was
which is made here as a NOR of two signals:
which are, respectively, the binary and decimal carries from the top bit.

I'm still blank on finding this in Balazs' schematic.

Yup. It's possible to create the bus-hold function yourself, as you say. More fun, too. But the advantage of the purpose-made ICs is space saving. Even a 16-bit bus-hold IC is just a 20-pin chip! (It would be 18-pin but they've doubled up the Gnd and Vcc pins.)

You make a good point about precharged nodes not tolerating glitches. Before the "open collector" (or diode equipped) bus driver IC's output is enabled it's imperative that the data at its inputs has settled down.

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

Did run Bruce's decimal mode my 6510.
http://www.6502.org/tutorials/decimal_mode.html

It appears that the 6510 passes the NMOS 6502 decimal ADC\SBC test
when it comes to accumulator and C flag,
but the code doesn't test the flags N,V,Z.

;---

Appendix B, version: June 28, 2009.

The subroutines SUB1 and SUB2 calculate the predicted accumulator result
for decimal mode and save it to memory.

But the predicted carry result for decimal mode is not saved to memory,
and I think that's a bug.

Had to insert three instructions to make the SBC test work:

I'm very surprised if Bruce's code isn't complete and correct, but I (still) haven't had a chance to check.

In a decimal subtract the carry (and all other flags) is the same as if you would do a binary subtract. The only difference is, that a decimal correction is not applied (the accumulator would not be the same). In the subroutine SUB the flags of a binary SBC are already stored in the variable HNVZC. There is no need to do it again!

All flags are checked! For an SBC they are checked against the binary flags, for an ADC V, C & N are calculated in subroutine ADD and Z is binary.

By the way: I have made a configurable version of the test and you find it here: https://github.com/Klaus2m5/6502_65C02_ ... l_test.a65

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I finally got the opportunity to spend some time on the project after being away. It's amazing to see how the discussion has evolved!

First off, I should mention that I was able to confirm that the existing CPU can in fact support all the undocumented opcodes with little modification, but requiring extra cycles for certain operations (I should say all undocumented opcodes except, of course, ARR in decimal mode). Adding a latch at the output of the ALU which in turn feeds the B input of the ALU enables AND operations between two registers. With that and enough cycles, the various opcodes can be executed (generally, I required two or three additional cycles to do the job). So, this approach remains an option.

Wrt a cycle-accurate implementation, the very cool and authentic open-collector option is likely a little more that I can manage at the moment. It's very appealing, but the timing seems tricky, and the required circuitry probably beyond me at this stage. By contrast, I can readily see how using some shadow registers with dedicated AND circuits can work. I suspect it may be possible to fit all the required logic for this second approach on the existing PCBs, which would be great. I'm going to spend some time fleshing this out to confirm. if I can get this implemented easily, it may be the preferred approach.

Beyond that, the behaviour of the flags in decimal mode remains an issue, and of course, there is ARR which looks daunting to say the least. So, no shortage of challenges to dig into.

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

I'm only a hardware guy, and not much of a coder of course.

Nevertheless I felt a need to write a little bit of test code
for decimal ADC\SBC and binary\decimal ARR for the 6510.
It seemed to have worked on my C64.




;---

If you got hands on a C64 (or maybe VC20),
but you lack a floppy drive, a monitor program and such,
and you need to test some machine code,
there still is CRUDEMON.



;---

BTW: at some point, we started to call the "undocumented" NMOS 6502 Opcodes
unforeseen opcodes (by the designers), or short UFOs...
with ARR being the "UFO mothership".

...could we please return to hardware related topics ?

It's finally time for an update: I've been working on the new logic for the BCD flags and the undocumented opcodes (or "UFOs" as we have come to call them) and reached a nice milestone this weekend.

For the decimal mode flags, Dieter suggested that tapping into the ALU after the adders but before the BCD adjustment would produce the right values for the flags in decimal mode. The net effect is that the flags reflect the binary result for both binary and decimal mode ADC/SBC - with the notable exception of the carry which uses the result after the decimal adjust in decimal mode. Unfortunately, this meant complicating the flag logic since the normal flag inputs are required also (for non-BCD operations and for 65C02 decimal mode). In the end, a second set of Z Flag Detection NOR gates was necessary as well as a couple of additional multiplexers to select the right inputs for the other flags. All in all, the changes seem well worth it to remove this particular incompatibility. One further complication is the fact that certain NMOS undocumented opcodes affect the flags in unusual ways. But that's best left for another day.

For the moment, I have finished testing the NMOS BCD flag evaluation logic. I used the configurable version of Bruce Clark's decimal mode test which Klaus mentioned above. I set the test to included all values for operands and to check all flags. I'm happy to report that the whole test ran without errors - albeit very slowly. Logisim manages only about 850Hz when running the model, so the test takes quite some time to run (more or less 4 days, actually). As it stands now, the flags reflect the correct values for binary and decimal mode for both 6502 and 65C02 microcode, including implementing an additional cycle to complete flag evaluation for the 65C02 in decimal mode. It feels great to have that done

Wrt the UFOs, it's still a work-in-progress. I wrote a simple test program to exercise them - nothing fancy, just going through them sequentially checking with only single input values. It's been a few decades since I did any 6502 programming, so it's nice to try a few things. I'm just about half-way through and making some nice progress. The "shadow register" approach seems to be working so I'm optimistic. More on that later.

Cheers for now,
Drass.

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

I've made some progress on the undocumented opcodes (UFOs) and I'd like to just report on the current status.

First off, the following opcodes behaved as expected on the Visual 6502 and I have tested them on the Logisim model of the TTL CPU. They are cycle-accurate and passed all my tests.

KIL ($02, $12, $22, $32, $42, $52, $62, $72, $92, $B2, $d2, $F2)
LAX ($A7, $B7, $AF, $BF, $A3, $B3)
NOP ($1A, $3A, $5A, $7A, $DA, $FA)
RLA ($27, $37, $2F, $3F, $3B, $23, $33)
RRA ($67, $77, $6F, $7F, $7B, $63, $73)
SLO ($07, $17, $0F, $1F, $1B, $03, $13)
SRE ($47, $57, $4F, $5F, $5B, $43, $53)
DCP ($C7, $D7, $CF, $DF, $DB, $C3, $D3)
ISC/ISB ($E7, $F7, $EF, $FF, $FB, $E3, $F3)
SBC ($EB)
SAX/AAX ($87, $97, $83, $8F)
SHX/SXA ($9E)
SHY/SYA($9C)
AXS/SBX ($CB)
TAS/XAS ($9B)
AHX/AXA ($9F, $93)
ANC ($0B, $2B)

In addition, there are the multi-cycle NOPs (or as Dr. Jefyll calls them, "LDD" for Load and Discard). They effectively go through the exact steps required to perform a Load instruction for a given addressing mode but then discard the result. All worked as expected on both the Visual 6502 and the Logisim model and are cycle-accurate:

LDD # ($80, $82, $89, $C2, $E2)
LDD zp ($04, $44, $64)
LDD zp,x ($14, $34, $54, $74, $D4, $F4)
LDD abs ($0C)
LDD abs,x ($1C, $3C, $5C, $7C, $DC, $FC)

*** I should point out that I am taking some liberties here since Dr Jefyll used LDD strictly in context of the 65C02. The opcodes above apply only to the NMOS 6502 and do not all match the 65C02 LDD's Dr Jefyll refers to in http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_opcode_mapping.html. I have merely borrowed Dr Jefyll's mnemonic here because it perfectly describes the function of these opcodes, and, well, I like it a lot. Please let me know if this ends up being confusing ***

Then there are 4 "unstable" opcodes which did not perform as expected on the Visual 6502 . I have tested these on my VIC 20 and have confirmed they behave differently on each system (see http://forum.6502.org/viewtopic.php?f=8&t=4164). I have implemented the VIC20 behaviour (which seems consistent with what others have found for the C64 6510 as well) in the Logisim model and tested against that spec. They all test correctly and are cycle accurate as follows:

*LXA (ATX) $AB imm 2 2 NZ A,X <- (CONST | A) & B : where CONST= VIC20($FF), Visual6502($00)

*ALR (ASR) $4B imm 2 2 NZC A <- A AND (CONST | Imm), A <- LSR A; where CONST= VIC20($00), Visual6502($FF)

*XAA (ANE) $8B imm 2 2 None (CONST | A) & X & imm -> A; where CONST = C64($FF), VIC20($FF), Visual6502($00)

*ARR $6B imm 2 2 NZCV A <- A & (CONST | Imm), ROR A; where CONST= VIC20($00), Visual6502($FF)
Special Flags Handling (Binary mode only): C <- A.6, V <- A.6 XOR A.5.

Finally, there is LAS, which behaved very strangely indeed on the Visual 6502 and I have yet to test this on the VIC 20. I am hoping LAS is reasonably well-behaved on the VIC20 and I can settle that one in short order.

*LAS (LAR) $BB abs,y 3 4* NZ A,X,SP <- MEM(adr) & SP
Visual6502: correct values loaded to A, X, SP. Then reset and A0.3 and A4.7 are incremented
VIC20: Needs to be tested on the chip

According to http://visual6502.org/wiki/index.php?title=6502_Opcode_8B_%28XAA,_ANE%29, $8B (AXX/ANE) is stable on the 6510 and on several MOS 6502s. No tests on the VIC20 are shown but I am hoping all the above opcodes will also prove stable there. More testing will tell.

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