Now that the clock-rate seems on target, it’s time to focus some attention on a little "PCB Feng Shui" - IOW, cleaning things up for good karma. Tolerances have become much tighter on the CPU, and it’s only prudent to corral any timing and signal integrity gremlins that might be lurking about.

Let’s take bus timing, for example - I was all over the map on this one, and I suppose early in the process, I could afford to be. Prior to the pipeline implementation, “enable” control signals came rather leisurely from ROM, and drivers, therefore, could hold their values stable on the bus long after the end of cycle - effectively providing ample hold-time for free. Meanwhile, signals to latch data into registers came sharply after the clock-edge, so latching was very reliable.

Now, however, “enable” control signals are dispatched directly from the Micro-Instruction Register just as sharply as latching signals, and they quickly disturb the very bus values we are trying to capture. In at least one case, the latching signal would lose this race predictably with fatal consequences. One obvious solution is to delay enable signals and thereby provide a more comfortable margin for latching. It’s tempting, but we have no such time to spare here - after all, the new data is needed on the bus as quickly as possible for the next operation. Any introduced delay simply hits the critical path of the following cycle. We’ve spent far too much effort hunting down nanosecond delays to start artificially introducing them now!

But other delays were also lurking on the bus unnoticed. A new cycle invariably implies a new driver on the bus, and signals to effect a change-over are delivered largely at the same time. The result is nasty “transient collisions” during the transition, as drivers push against each other until one finally abates and the other is allowed to proceed unfettered. Now, I know this kind of “bus contention” is commonly tolerated without consequence (after all the whole affair is usualy over in a flash, and if brief enough, its effects are quite benign). But, the fact remains that new data necessarily takes longer to stabilize on the bus under these difficult conditions than otherwise - I suspect materially so. Margins are thin, so I felt “waiting-out the storm”, so to speak, was not the best approach if it could be avoided.

Thankfully Dr Jefyll suggested an effective solution as follows: all drivers which share a common bus should be output-enabled for half a cycle only, such that every bus will switch from having a single driver active, to having no driver at all for a half-cycle. This is what a 6502 does externally on its data bus (which it drives only in phase 2). In this case, the approach works well for the W bus at the outputs of the ALU (since it too needs to be active only in phase 2, when the ALU has finished it’s work). But other buses, such as R and B at the inputs of the ALU, need to supply valid data early in phase 1 and hold it throughout the cycle. Initially, I simply could not see how this would work, until Jeff explained that bus capacitance would hold the data on the bus during the “dead period”. Once that penny dropped, the full effect of the mechanism was clear: drivers are always enabled on to a quiet bus, the pesky transient collisions are gone, transitions are smooth and fast, and latching is once again very reliable. Wonderful! As I said to Jeff, the learning never stops.

Now this scheme suffers from the unfortunate consequence that the CPU cannot be paused; since certain drivers are disabled at any one time, those buses would drain their charge and data would be lost - as happens on the NMOS 6502 from what I understand. To protect the buses, the CPU must either not be allowed to stop, or bus-hold ICs need to be installed (i.e., 74ACT1071 or 74ACT1073). I chose the latter option, simply because it seemed the more complete solution and it was dead-easy to implement.

All that remained then was to figure out which buses would be made active at which times - and that proved simple: drivers taking data data from registers to other logic early in the cycle are enabled during phase 1 only; meanwhile, drivers taking data to be latched into registers at the end of the cycle are enabled in phase 2 only. In the paths shown below, drivers to the R bus, B bus and ADL/ADH buses are enabled in phase 1, while drivers to the W bus are enabled in phase 2 (just to be clear, the external address bus, A.BUS below, is left active throughout the cycle).

REGISTER -> R.BUS -> ALU -> W.BUS -> REGISTER
REGISTER -> B.BUS -> ALU -> W.BUS -> REGISTER
REGISTER -> ADL/ADH -> A.BUS

Incidentally, I discovered that I was incorrectly driving the external Data Bus in phase 1 during write cycles - essentially causing collisions when data reverses direction between CPU and memory (Dr. Jefyll explains this phenomenon in a different context here). I doubt this would have caused significant trouble, but it was easy to sort out. The fix was, as with all other drivers, to simply use either PHI1 or PHI2 to gate the enable signals as appropriate. It’s a simple and elegant solution to a potentially nasty problem and I’m glad to have implemented it.

Drass

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

Drass,

I would love to see your Logisim file.

One of the few examples of a microcoded CPU, and also in Logisim that I've found is this :

http://minnie.tuhs.org/Programs/UcodeCPU/index.html

I'm particularly interested in seeing your microcode hardware / strategy.

Mike

Happy to share mstram.

Attached is the Logisim file as well as a RAM image of Klaus Dormann's 6502 Test Suite. To make it go:

1) Load the Test Suite into the ram on the main page (Shown below)
2) Set the RDY and BE pins high
3) Start the clock (/Menu/Simulate/Ticks Enabled)
4) Hit the reset button

The test suite will start to run. Go into the "6502" sub-circuit to see all the blinking lights ... Keep an eye on RAM address $0200 to see the current test number being executed.
Bonus points if you help me find any bugs!


Regarding the "microcode hardware strategy", I'm not sure the Logisim file will tell you what you want to know. The file is not at all designed with presentation in mind, nor optimized for Logisim. It's sole purpose is as a working model to test the hardware - and is certainly more difficult to follow than Warren's RISC oriented CPU in the link you shared. My intention is to eventually clean this up and document it. Hope it's useful to you as is ...

For now, perhaps the following will help:

1) The microcode is vertical - that is, encoded such that it passes through decoders to generate the actual control signals.
2) There are four 8 bit microcode ROMs, two for each card in the physical CPU, forming a 32 bit micro-instruction. All the control signals required in each card are generated by decoding the ROM values local to that card. This is not particularly relevant for Logisim but helps explain why microcode is arranged in the way that it is.
3) A 4 bit "Q" state counter keeps track of the internal machine cycle. Q & Opcode together index into the ROM to fetch a micro-instruction.
4) The design is pipelined so that the fetched micro-instruction is always for the "next" cycle - there is an auxiliary micro-instruction register at each ROM to latch "special" micro-instructions
5) The sequencer is very simple, allowing only for NEXT and END directives, as well as a couple of EXIT conditions. The one subtlety is the INCDPH.C directive which handles incrementing the high-byte during indirect address calculation.
6) There are four versions of the microcode loaded into the ROMs: 6502, 6502 + undocumented opcodes, 65C02, 65C02 + select 65816 extensions. They are selected through the CMOS and +OPS switches in the internal control panel. Plain old 6502 is the default (CMOS=0, +OPS=0).
7) Decoder values for the microcode are described in the attached pdf (which may not be 100% up to date):
Feel free to hit me up with any questions.

Have fun!

Drass

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

Some time ago, we had tinkered with the BCD correction circuitry.

The current implementation uses a modified version of the BCD correction circuitry
from my homepage for Bit 3..0, and Jeff's circuitry for Bit 7..4.

Tried to modify Jeff's circuitry to work for Bit 7..0,
but from the PCB layout I'm starting to think we don't have enough free space left
on the PCB for implementing something like this.
Also, it appears that it won't increase the speed of the CPU.

Since it might be interesting (or maybe even useful) for other people's projects,
I think it would be good to post it here before it disappears into /dev/null.

Without any warranty that it might really work, and absolutely untested on whatsoever:




The basic idea is to have 74283 adders in the ALU with the carry input tied to low
for calculating A+B, A-B.

Then to add a carry to a 4 Bit nibble as late as possible: in the BCD correction adders.

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