Since the schematic above of the BCD correction circuitry might look a bit odd and confusing
to some of the readers, I think I should clarify what brought me into drawing them.

If you are using FPGAs, your best bet for implementing BCD correction would be "flipping the Bits"
with XOR gates, like the NMOS 6502 does as described on the homepage of this guy.

Don't mind the odd notation for some of the signals,
this article was written some years before there was Visual6502.

;---

If you are not using FPGAs, but maybe TTL ICs instead,
implementing a BCD correction depends on some more factors,
like which "function blocks" already are in the binary part of the ALU,
which parts you are able to buy and how they could be wired up,
how this fits into the PCB layout, etc.

Since the binary part of the ALU in OurCPU makes use of a carry skip adder topology,
we already might have 4 Bit adders with their input carry tied to low.
To describe the concept more into detail:

For 4 Bit, there are two 74283 adders with their A,B inputs tied together.
One adder has the carry input tied to low, the other adder has the input tied to high.
A 74157 2:1 multiplexer then switches between both adder outputs according to the carry
that is supposed to go _into_ those 4 Bits.
The multiplexer tends to be faster than the adder when it comes to the propagation delay
from carry input to carry output. (Note, that you would need another multiplexer
controlled by the carry input that switches between the carry outputs of both adders
for generating the final 4 Bit carry output.)

;---

So it was tempting to tap into the outputs of the adders with the carry tied to low
for feeding the BCD correction circuitry to avoid the propagation delay of those 2:1 multiplexers.

The logic which decides whether a BCD correction is neccessary or not becomes a bit more complicated, of course.

If you have an 8 Bit ALU consisting of 4 Bit "chunks" with a complete and intact carry chain,
for SBC, you just test the binary adder output carry of a nibble, and do a correction if the output carry is 0.
For ADC, you just test if the adder result is >$9, or if the output carry is 1.

If you _don't_ have a complete and intact carry chain, but just two 4 Bit binary adders with the carry input
tied to low, "floating in nowhere", then detecting if a BCD correction is neccessary becomes more complicated.

For ADC, you have to test if the adder carry output is 1,
if the carry that goes into the nibble is 0 and the adder output is >$9,
or if the carry that goes into the nibble is 1 and the adder output is >$8...
because the adder won't "see" the input carry, of course.

For SBC, it's a bit more complicated, because you have to test the input carry...
and depending on it, you might have to test if the adder output is $F.

As a last step during the "BCD correction", you have to add that input carry to the nibble of course.

;---

BTW: The circuitry in the schematic makes use of 74CBT multiplexers for deciding if a correction is neccessary.

TI 74AC151 propagation delay: select to Y output 4.7ns to 16.5ns, data input to Y output 3.5ns to 12.3ns.

TI 74CBT3251 propagation delay: select to output 2ns to 5.5ns, data input to output 0.24ns maximum.

So the idea is to stack a "pyramid" of 74CBT multiplexers, and to make the time critical signal ripple through the multiplexers
from data input to data output.


It was Jeff's idea to use such a circuitry for the BCD correction of Bit 7..4.
What eventually brought me into drawing the schematic above was that Jeff seemed to have doubts
that his circuitry could be "expanded" to handle all the 8 Bits instead of only Bit 7..4.

I hope, this description was helpful to the readers.

Drass seems to be away for the moment, so I'm adding a bit "historical" info.

Back in 2002, there had been a TTL CPU running 6502 machine code:
http://6502.org/users/dieter/m02/m02.htm

This probably explains, why OurCPU appears to be a "sandwich" built from two PCBs.

The old CPU from 2002 lacked BCD mode, and it wasn't cycle compatible or timing compatible to the 6502
...you recognize the pioneer by the arrows in his back... but it already had a 24 Bit address bus.

And the question is: can we recycle some part of this old project for having a 24 Bit address bus in OurCPU, too.

;---

This brings us back to Kludge24.

Conceptually, Kludge24 is sort of a "function block" to be attached to a "standart" 6502 core.
Kludge24 has some microcode ROMs on board, and the microcode of the 6502 core would have to be changed of course.
Also, Kludge24 would need to disable the constant generator in the 6502 core which places $00 on A15..8
for zero page memory access... for being able to place the DH register on A15..8 instead.

The end result is something like "a poor man's 65816" without the 16 Bit.

Point is, that if you want to have, for instance, colored graphics with a resolution better than 320*200,
64kB of memory won't do at some point.
Resorting to odd bank switching tricks between CPU and memory might give you quite a headache later.
And trying to build a complete 65816 with all the bells and whistles won't be exactly a beginner's project.

Kludge24 just is a "step stone" between 6502 and 65816.
The basic idea is to give a 6502 a 24 Bit address bus, and most of the 65816 instruction set (except MVP and MVN)
so the CPU can make use of a (nearly linear) 16MB address range...
and when taking a little bit care, chances are good that Kludge24 machine code might run on a 65816 later
without that this requires too much changes to the code.

Bit 7..0 of the 16 Bit direct register always are 0, so it's possible to use any of the 256 pages
in the lowest 64kB of memory the "zero page", since the 'zero page' tends to be a very crowded place
in Commodore computers.

Kludge24 uses the same interrupt vectors like a 6502 (or a 65816 in emulation mode).
When a 6502 responds to an interrupt, it pushes PCH, PCL, P on stack. RTI pops P, PCL, PCH from stack.
When Kludge24 responds to an interrupt, it pushes PBR, PCH, PCL, P on stack. RTI pops P, PCL, PCH, PBR from stack.

The C64 Kernal would work with Kludge24, but there might be an incompatibility with monitor programs which use RTI
for starting a user program.

Since we have plans to be able to switch between different microcode sets by software, and I think we can live with that.
Changing the CPU design for having something like the 65816 E flag turned out to be too much fuss...

6502 (red) plus Kludge24 (blue) register map:


(Initial\preliminary) Block diagram of OurCPU with Kludge24 attached:

TBR is a temporary register for address calculation.

In my previous post, I had written "A (nearly linear) 16MB address range", because there are some limitations:
The 16MB break down into 256 banks 64kB each.

Incrementing PC will stay within a bank.
Branch instructions will stay within a bank.

Most addressing modes will stay within a bank,
except when calculating the effective address for a data read/write when it comes to: absl absl,x [ind],y

;---

Now a list of how I think Kludge24 should place something on the address lines A23..16:

A23..16 = $00 //page 0

• vector fetch: RES, NMI, IRQ, BRK
• stack push/pull
• data read/write: addr.mode: z z,x z,y d,s (d,s),y
• pointer read: addr.mode: (ind) (ind,x) (ind),y (d,s),y [ind],y
• pointer read: JMP(abs)

A23..16 = PBR //program bank register

• program memory read
• pointer read: JMP(abs,x) JSR(abs,x)

A23..16 = DBR //data bank register

• data read/write: addr.mode: abs abs,x abs,y (ind) (ind,x) (ind),y

A23..16 = TBR //temporary value for 24 Bit addressing modes

• data read/write: addr.mode: absl absl,x [ind],y

Any comments or suggestions about this list from somebody with 65816 experience ?
Problem is, that I never have used a 65816 in native mode.
My info was from the manual: Eyes & Lichty: Programming the 65816.

;---

BTW: the idea is that empty microcode locations in the microcode ROM on the Kludge24 PCB
(all Bits '1') won't modify registers while placing $00 on A23..16,
to ensure compatibility with the NMOS 6502 and 65C02 which are supposed to only use memory bank 0.

Kludge24 is supposed to be either in NMOS6502 or 65C02 mode after a RESET.
Also, a RESET clears PBR (program bank register) to $00 by hardware...
...I'm not sure, if we should clear DBR to $00 at RESET, too.

Switching between different sets of microcode could be done with a two Bytes instruction, I'd suggest using $42. //WDM
Some Bits of the second Byte are used for selecting the microcode. //immediate addressing mode, that is.

In NMOS 6502 and 65C02 mode, A23..16 is supposed to be $00.
The address decoder in the CPU for the 6510 I\O port is supposed to check for $000000 and $000001.
In a "C64 environment", the memory address decoder outside the CPU would have to decode the 64kB address range
$00xxxx (bank 0) like in a C64, and all the other 255 64kB pages of the 16MB memory as RAM or such.

;---

But in a C64 environment, this now brings us to another odd idea:

It might be possible to have programs which (from the 64kB address range) won't like each other,
like a game, an assembler and a text editor or such,
to place them into different 64kB bankss of the 16MB address range, and to jump between those programs
during run time by just pressing a button.

Let's say, we take one of the unused Bits as a "configuration Bit" to change the CPU behaviour
in NMOS 6502 or 65C02 mode like this:

The address decoder inside the CPU doesn't check A23..16 and places the 6510 I\O port at the start of every bank
in memory: $xx0000 and $xx0001.

The "configuration Bit" also has to be routed to the memory address decoder outside the CPU,
which then would place the C64 ROMs, CIAs, SID etc. into every 64kB bank in memory.

The CPU would emit PBR on A23..16 for program memory read and NMI,IRQ,BRK plus JMP(abs) vector fetch,
and DBR for the rest (including stack and zeropage access).

Then to have some switches (debounced with 7400 NANDs or such).
Pressing a switch triggers a NMI.
Since the CPU emits a /VP signal, we could trick the memory address decoder into placing
a different NMI vector and a "special" NMI service routine into every 64kB bank of memory.

The NMI service routine then saves return address, DBR and PBR somewhere in bank 0...
together with a copy of the CPU internal 6510 port output data (defining the C64 memory map),
the CIA I\O port that sets A15,A14 of the VIC2 memory access, the complete set of VIC2 registers etc.

Next, the NMI routine checks which button is pressed, then reads some values according
to _which_ button is pressed for writing a different set of values from bank 0 into
6510 I\O port, the VIC2 related CIA port, the VIC2 registers etc...
and then resumes a different user program in a different 64kB bank from there.

We would need to make the VIC2 accessing different 64kB banks too, of course...

;...

Won't probably work with 100% of the C64 software out there.

I know It can be done, because in 1988 my C64 had 320kB of DRAM and 5 such buttons.
Unfortunately, the hardware and the software are long gone, and there are no schematics.

After digging through the basement at the weekend, all I found was the casing:

35 years of hobby computing... and only one of my projects had a casing.
Five buttons, every button had a LED to indicate which 64kB page was active.

I remember that I tried to push the envelope back then:
Pressing a button twice made a program in a 64kB page running in the background,
what was indicated by a blinking LED.
Pressing the same button twice stopped the program running in the background again.
Buttons and LEDs were tied to a 6522, which also generated a NMI required for the
"multitasking" between different 64kB pages.

Making sure that programs running in the background won't modify the VIC2 registers
or use the disk drive was in the responsibility of the "end user", of course.

But the contraption crashed when sprites were enabled, I think there was a timing problem...
I just was unable to complete the project because at some point the C64 power supply
suddenly died with giving out over_voltage, schematics were a mess of hand drawn papers,
hardware was a lump of PCBs, components and wires... so it all went scrapped.

But enough of those old stories: Looking forward to see, what Drass could make out of this stuff.

There: "virtual consoles" and "multitasking" on a C64.

LOL!! -- too funny, Dieter! I'm sure this remark will resonate with many forum members. You're not the only one whose creations go "au naturel"... Nice to hear about your project.

-- Jeff

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

Thanks, Jeff.

See, for many years I had wondered why electronics gizmos need a casing at all,
because this only slows you down when you have to repair or to modify something.

Back in 2009, another hobbyist eventually had explained it to me:
If your creations have casings, piling them up in your workshop is less fuss...


Nevertheless, I still wonder what a casing for a TTL based "C64 compatible" computer may look like.
I still vote for a "tiled stove".

Remembered some more technical details about my old C64 project:

5 SPDT switches debounced with 7400 (one could use 7474 or 7406 instead).
Signals were routed to a 6522 I\O port and a 7430 gate,
which then fed a CAx (or was it a CBx ?) input of the 6522 for triggering a NMI.

The 7430 also did set a flipflop.
When the CPU tried to read the memory addresses relatd to a NMI vector
and the flipflop was set, some circuitry disabled the C64 address decoder
and placed a NMI vector on the data bus generated by two (8 Bit) DIP switches
and two 74245 (74257 probably would have been a better choice).

After the CPU did fetch the forged NMI vector when the flipflop was set,
SRAM was mapped into $C000..$CFFF, it contained the code and the data
required for switching into another 64kB memory bank.

After the software in the RAM did its job, the SRAM was removed
from the memory map again.

;---

Because the 6510 lacked signals like SYNC and /VP,
this required quite some odd circuitry and some odd tricks, and I don't remember this part.

OurCPU has those signals, with Kludge24 it also has a 24 Bit address bus,
and since we are going to have enough 64kB memory banks, tricks like
inserting a SRAM into the memory map for the page switching software
won't be neccessary if it would be possible to keep software plus data
required for that page switching in the lowest 64kB bank of memory.

;---

Don't get me wrong:
I'm not insisting to implement something like my old C64 "bank switching trick" in Drass's project.
I'm just suggesting to have the circuitry in Kludge24 to make implementing something like that possible.

It’s been a while, but I finally had an opportunity to spend some time on the project. When I left off, I was busy routing the ALU & CU Card, which may finally need more than the 4 layers I was hoping for. We’ll have to see about that …

In the meantime, Dieter posted his Kludge24 (K24) addition, and it certainly looks interesting. Reading up a bit on the 65816, I can see how K24 provides for a reasonable implementation of Emulation Mode - supporting a 24 bit address bus, 8 bit registers and nearly all 65816 instructions. That’s exciting. I also clearly remember thinking about “partitions” on my C64 many years ago, and I was excited to see Dieter's version of just that above! A few mods and some microcode is all it would take to make K24 compatible with the existing TTL CPU. After kicking it around with Dieter a bit, I decided to get K24 done now while it’s all still fresh in my mind, and return to the thorny layout issues thereafter (good thing we're still not in a hurry ).

K24 is very similar to the Registers Card so it didn’t take long to get my head around it. So far, I have:

• Added the microcode pipeline mechanism, making sure that the default “All Zeroes” control word works properly
• Changed the naming of signals and encoding of ROMs to be consistent with the other cards and simplify things a bit
• Added the “bus collision” management scheme - R and ADX busses are enabled only in Phi1, and the W Bus only in Phi2
• Added inter-card connectors and clock buffers
• Added logic to manage the 6510 port being mapped into bank 0 in “K24 Mode”, and into all banks otherwise
• Added external connections for two useful control signals: /K24MODE (low when K24 microcode is selected) and /K24BNKH (low when Bank > 0 in K24 Mode)
• Added a Configuration Register (CFG) to enable programmatically switching the current microcode and setting various operating options (see below)

After reviewing the microcode required, I made the following compatibility notes:

• K24 will not be cycle accurate.
• The Direct Page register is 8 bits (called "DH") and points only to page boundaries. We can still have PHD and PLD push and pull 16 bits on the stack just for compatibility (with $00 as the low byte).
• The A & B accumulators cannot be combined into a 16 bit C register. TCS, TSC will use only the A accumulator (low-byte); and TCD, TDC only the B accumulator (high-byte). (btw, I refer to the B Accumnulator Register as “BAR” in the schematics to distinguish it from the B input of the ALU).
• SP is 8 bits, so all opcodes which push or pull values on the stack will wrap on a page boundary. Other rules for crossing bank boundaries, however, can be applied correctly (e.g., Abs,Y [Ind],Y)
• The ABORT and COP Interrupt Vectors and MVN and MVP opcodes are not implemented.
• Opcode $42 (WDM) is replaced by a CFG instruction, which will exchange the contents of the A accumulator with the CFG register.

The K24 Microcode will manage the upper 8 bits of the 24 bit address bus dynamically to reflect various addressing modes, as Dieter described above. Meanwhile, the 6502 and 65C02 microcode will restrict addressing to the current Program and Data banks (PBR and DBR respectively) - each bank can then work as an independent “partition”, with the additional flexibility that the Program and Data Banks need not be the same. As expected, interrupts set PBR to 0 in K24 mode but leave that register unchanged otherwise (which means that an external address decoder has to map interrupt vectors across the various banks for both the 6502 and 65C02 microcode. The /VP signal on the 6502 Pinout Connector is useful in this regard and can be activated for all microcode options via a jumper on the Registers Card).

The CFG Register is formatted as follows:

CFG bit 0-1: Microcode Select (6502+UFOs, 65C02, 6502+NOPs, and K24)
CFG bit 4: Enable 2-Cycle-BCD
CFG bit 5: Enable BCD-Flags-Valid
CFG bit 6: Enable Interrupt-CLD

If the K24 Card is not present, jumpers on the ALU & CU card are used to select the microcode, and the other CFG options are set accordingly by the hardware (2-Cycle-BCD, BCD-Flags-Valid and Interrupt-CLD are all enabled for the 65C02 microcode and disabled otherwise). On RESET, the K24 microcode zeroes the CFG and Bank registers, which defaults the CPU to NMOS 6502 compatible behaviour running in Bank 0. To enable microcode switching, $42 will also implement the CFG instruction in the 6502 and the 65C02 microcode (replacing a KIL illegal opcode in the first, and a 2 byte NOP in the second).

To illustrate how the K24 microcode might work, here’s a first cut at microcode for ORA [ind],Y (Direct Page Indirect Long Indexed with Y - 65816 opcode $17):


8 cycles rather than 6, but so be it. Trying to be cycle accurate for K24 is too much of a stretch for the current design.

That’s it for now. K24 schematics as ammended are below …

Cheers,
Drass.

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

I managed to get the Logisim model updated with the K24 mods. To test it, I wrote a little task-switching monitor akin to what Dieter described above. It runs in bank 0 in 65816 mode and takes control of the CPU on an NMI. It saves state and cycles through the active tasks one at a time. The tasks use either 6502 or 65C02 mode and run in their own 64k bank protected from each other. 65816 mode becomes a kind of "privileged mode" in that case.

In the test, a counter triggers an NMI every 256 cycles, Bank 1 is running the Klaus Dorman 6502 test suite, Bank 2 the 65C02 test suite and Bank 3 runs Bruce Clark's Decimal mode test. The CPU switches the active microcode on the fly and jumps between the programs. Watching Logisim task-switching was kind of cool ... time-compressed video below just for fun

https://www.youtube.com/watch?v=lAg8Xb1xNF8.

Next up is a whole lot of testing and then back to routing PCBs

Cheers!

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

I've been focused on testing lately, particularly the K24 65816 microcode. Absent a test-suite, I've relied on "unit testing" only - working through the opcodes one by one. Logisim lets me see the microcode's work on every cycle, which is great. I can exercise all the boundary conditions and see the effect immediately. There is little entirely new logic per se on the K24 Card, and I'm now fairly certain the new circuitry is doing what it should. Still, it's going to be pins and needles when it finally comes time to order the boards

Speaking of the PCBs, I have once again started a layout of the ALU & CU Card. Frankly, it's a little daunting. Not at all sure it's even possible to route it as is. We'll have to see how that plays out.

Top and bottom layers below.

Cheers for now,
Drass

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

Make sure you use the smallest possible vias to make routing easier.

Also, it is possible to snake 0.006 inch traces in between SMD pads that are on 50 mil centers, such as with SOIC14 and SOJ36 packages. I did that on POC V2 in wiring up the two SRAMs (SOJ36, with 34 connections) to the CPLD and the address and data buses. It worked out fine.


Above is a graphic of how traces were run in between the SRAM pads (red is the top layer). Right below is the actual PCB before the SRAM was attached. An adequate amount of solder mask was present between the pads to prevent bridging while being manually soldered (done by Garth). The finished product looked almost like it came from the boarding stuffing house.

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

That board looks beautiful BDD! I'll have to figure out how to do that come soldering time
I take your point regarding trace width. I can definitely fit signal traces between the pads of a SOIC package. Curious, what size vias are you using?

Arlet, I recall you had suggested I was perhaps being a little too cautious when using the VCC layer for signal traces on the last board.
It's likely I won't have the luxury of a clean VCC plane this time around in any case - in fact, I'm considering doing away with the VCC place altogether on this board and running 24mil traces for VCC lines. I'm imagining power rails along the horizontal edges of the board with vertical VCC traces to reach ICs (or maybe it should be vertical power rails with horizontal traces?). Anyway, that should give me lots of additional room on that layer. Does this sound right?

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

Rather than taking a lot of board space making the Vcc lines so wide, I would just put bypass capacitors with the shortest possible connections from Vcc pins to the ground plane. The current peaks you have to worry about for AC performance will go through the bypass capacitor, not the traces.

I did the soldering above with a 30W 1/8" chisel-tip soldering iron, .032" 60/40 rosin-core solder, and no additional flux. IOW, the commonly preached rules aren't necessarily absolutes. Or, as my boss (of all people) once said, "Rules were made to be broken."

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?