Sorry, probably bad memory, or my memory was confusing gates and transitions from a page other than https://en.wikipedia.org/wiki/Transistor_count. CMOS gates are double the transistors than NMOS or PMOS gates. Wikipedia says 25,000 *transistors* for the ARM 1, and 11,500 for the WDC 65C02. The NMOS MOS6502 was 4,528 transistors.

Thus the 65C2424 would be roughly 15,000 transistors while an NMOS 652525 back in the late 1970s would be only 6,750 or so transistors.

Digging a bit online, I found out that the PDP-11/45 introduced the split instruction/data spaces to the PDP-11 series, according to https://gunkies.org/wiki/PDP-11/45 and tangentially mentioned by
https://www.computercollection.net/pdp11/index.htm.

I managed to get dasm https://github.com/lunarmobiscuit/dasm to handle addresses above $FFFF, and to output the A24 prefix code when referencing addresses above $FFFF. But adding variable register widths to that assembler didn't look easy.

I'm much more of a C than assembler coder, and while playing with https://github.com/lunarmobiscuit/izapple2/ and it's 6502 emulator https://github.com/lunarmobiscuit/iz6502/ to create an emulated "Apple ][4", it seemed easier to write an assembler/compiler that mixes C-like blocks, ifs, loops, and variables with assembly mnemonics than to stick solely with assembly or jump all the way to C.

The result of that is https://github.com/lunarmobiscuit/pomme/. So far it's just an assembler, but with {} blocks for subroutines and data. https://github.com/lunarmobiscuit/pomme/blob/main/compile/test.pom will offend both assembly coders and C coders in its style, but I like where it is headed.

Meanwhile, in terms of the 65C24T8, it is a working assembler, including every address mode, address size, register size, and every opcode I've described prior in this thread along with a few that seemed likely to be needed once I start playing with 16-bit and 24-bit registers: shift left/right 4, shift left/right 8, A+=x, A+=y, A=X+Y.

The number of mnemonics doesn't rise by much, and the opcode space still has quite a few holes, but the number to total possible instructions jumps past 600. See https://github.com/lunarmobiscuit/pomme/blob/main/compile/opcodes.pom for every possibility and https://github.com/lunarmobiscuit/pomme/blob/main/compile/opcodes.lst for the generated machine code.

The iz6502 emulator currently implements all of those up to SWS (set stack width). I'll add the others soon.

(Hmm, is that perhaps a private repo?)

It was, but that is now fixed. And the bug fixes through the three levels of assembler, CPU emulator, Apple2 emulator are committed too.

Having bugs possible in all three layers makes this an interesting project to debug. That was the driving factor toward writing pomme in go, as iz6502 and izapple2 were written in go.

Meanwhile... the functionality of Apple2four.pom now matches the functionality of Apple2four.asm. The only difference so far is that the .pom version uses a few 16-bit and 24-bit registers for accessing the screen. The first few learnings:

- Data tables of addresses are a lot simpler. What was:

becomes:


- Pomme doesn't have < and >, as e.g.:

lda #$FF ; hard-coded to $FF as dasm doesn't have >> to grab the 3rd byte
sta $06[/code]
becomes:


In this 480 lines of 6502 assembly, the original compiles into 1,355 bytes of code. All the /**/s and {}s grow the assembly to 490 lines, but it compiles to only 1,318 bytes of code. So despite the prefix codes, the handful of lines of code loading and storing 16-bit and 24-bit addresses saved 37 bytes.

And the two tiny optimizations I made clear the screen two bytes at a time and scroll the screen two bytes at a time. Both of those make the code longer, as I have to iny, iny twice per loop, but in terms of cycles, those loops only have run loop half as many times. 20 times per row instead of 40.

Finally, the only bug introduced in these changes was in pulling the address from that TextScreenBase data table. In the original, X held the row number, and TextScreenBase,X pulled the correct address from the byte-sized table. Now X needs to be twice the row number. So like in ClearScreen, where writing two bytes at a time requires the Y index to be iny iny twice, the X index in the ClearScreen loop needs inx, inx twice too, and the cpx #24 changed to cpx #48 to match.

Which then makes me wonder... given a 16-bit 6502, does it then make sense to have a prefix code to make ,X and ,Y double the value in X or Y prior to using it as an index? That is simple to implement in hardware, as it's just bits 6:1 of the register with a zero in the lsb. But then similarly, for 24-bit operations, a prefix code to pre-compute X*3 and Y*3 would be just as helpful, and computing X*3=X<<1+X is an extra cycle. That seems a slippery slope to head down, so perhaps just xsl, ysl as more orthogonal to asl, lsr and more generally useful

That's an interesting question. You of course would want X and Y to be able to be used regularly for non-indexed use, such as a loop control variable. With respect to indexed use: Do you do byte reads from 16-bit memory or just word reads, which might require the LSB to distinguish between first and second byte in the word? Is that perhaps tangential to the question at hand, since the LSB could be ignored in address generation and only used for routing one byte or the other to register.

I'm still using the premise from the original post in this thread, that this 652402/65C24T8 design is something that could have been created in the late 1970s. I've thus stuck with an 8-bit data bus to keep the number of pins <= 48 and to make it possible to drop this chip into a next iteration Apple ][, Commodore, Atari, BBC Micro, etc.

The registers are 1, 2, or 3 bytes wide, but the state machine ends up iterating over extra cycles loading the extra bytes.

Thus lda.w $00 issues two memory reads: $00 and $01. A ends up with the little endian value [$01][$00]
Similarly lda.t $1234 issues three memory reads with the value [$1236][$1235]$1234] stored in register A

With an 8-bit bus, there is no concept of word alignment as seen on the 68000 or RISC chips. You can store to $1234 and then load 1, 2, or 3 bytes from $1233 or #1235 if you want.

I can see that being a problem if some later version of this chip moved to a 16-bit or 24-bit wider data bus, but by the 1980s the CPU clock speeds were faster than memory speeds, and thus by then one would expect a cache between the CPU and memory, and the cache could deal with unaligned requests, as the cache would be loading more than 2 or 3 bytes per load.

Thanks for sharing! Interesting ideas indeed.

Over on http://forum.6502.org/viewtopic.php?f=2&t=7304 we're talking about whether zero page would be treated more like addressable registers if the assembly mnemonics treated them like registers instead of 8-bit addressable memory. In testing out those ideas, I whipped up a bubble sort that sorts 24-bit values. Which, of course, makes me want to see for this thread what happens if that algorithm is coded up with 24-bit registers.

The traditional (non-optimized) 6502 version is:

53 lines of code (including the six labels), 108 bytes of machine code

To create the 24-bit register version, I just took the code, added a few .t's, and took out all the parts that iterate over the three individual bytes. In debugging I did notice that the traditional version is comparing big-endian values instead of little-endian values, but I didn't fix that bug.

Only 28 lines of code and only 60 byes of machine code.

The choice of 24-bit values certainly helped in that comparison. 16-bit values would have been the smaller for the traditional version and the same 60 bytes for the larger registers, but 32-bit values or wider would require comparisons in chunks for both CPUs, but in 16-bit or 24-bit chunks for the 652402.

I chose bubble sort as it's a whole page of code in length, and as the memory swap can't be done with just A, X, and Y. That swap requires either using zp or the stack. It thus shows off how much more efficient a 6502 can be if such operations can be done 2 or 3 bytes at a time, even if underneath the machine code the CPU is actually just iterating over bytes on an 8-bit data bus.

My assembler doesn't count total cycles, but the wider register version is certainly going to be fewer cycles, as if nothing else it eliminates all the branches in comparing one byte at a time vs. three bytes in one shot.

I'd love to see this same unoptimized algorithm in 65C816 assembly too for comparison. Can someone who knows it post it?

After coding a few thousand lines of assembly for an emulated 652402, I've found one oddity that could use some advice.

LDA.w $(zp),Y does what you would expect, loading a 16-bit value from the indirect indexed address. There is no question that having 16-bit and 24-bit values makes coding realworld code a whole lot easier.

The problem is, sometimes you really just want one byte. Like when you are processing ASCII or when you are copying a buffer that can be an odd number of bytes. The problem is LDA $(zp),Y is ambiguous when it comes to the size of the address hiding behind $zp and the size of the Y register that is added to that address.

What I realized in debugging a buffer copying loop is that the size of X and Y in all the indexed address modes must be defined by the width of the addresses in those instructions, not by the specified width of the registers. So it's LDX.w $1000 to load 16-bits into X, but then it's LDA.a24 $F0000,X to load one byte from $F1000 and LDA.a24.t $F0000,X to load three bytes from that address, in both cases the .24 suffix ensuring that the absolute address is 24-bits as is the X register.

That works fine when the address in the instruction is absolute or indirect, but the $zp modes are 8-bit addresses, not 16-bit or 24-bit. I've not found a way to make this work in a way that feel elegant. And the more code I write, the more I find the ($zp),Y address mode useful and irreplaceable.

Do you see an better solution?

Meanwhile... what became more and more obvious as I get used to this odd CPU is that I'm often moving addresses into zp for use in that ($zp),Y address mode. Most often these are addresses stored in tables. Given I can load 24-bits into A, X, or Y in a single mnemonic, it feels like an extra step to then save to zp rather than just use X and Y as a base address and index directly.

Today I added three new addressing modes LDA XY, LDA (XY), and LDA (X),Y. The latter specifically to replace ($zp),Y. XY just adds X+Y to create the target address. [b](XY)]/b] adds X+Y and indirectly loads the address from that address. [b](X),Y]/b] loads an address from X, then adds Y, then loads from that aggregate address. All three can be 16-bit or 24-bit addresses, and like before, the width of X and Y are driven by that choice, separately from whether the value being loaded is 8-bit, 16-bit, or 32-bit.

The only code I've written so far for these are tests to make sure the emulator is working correctly. Next up is refactoring all my code to replace zp with (X),Y. I'm curious to see if the other two modes will get much use, but with an emulator in Go, it just takes a few minutes to add in an instruction to play with.

Thoughts? Does this stray too far from the 65xx mojo or does this feel like a natural extension to a never-built 652402 in my alternate reality where the 68000 didn't disrupt the 8-bit world?

It feels reasonable to me - as a matter of ISA design - once a register can hold an address, to be able to use it as an address.

In fact once you've done that, you might find you have less need of indirection through memory.

Whether this is 6502ish is another question!

I haven't been following this thread in detail, and I am not as familiar with your CPU as you are. But I would question this.

On the 65020, I have the index registers always adding 32 bits regardless of everything else. And I very often turn the 6502 indexed addressing upside-down: instead of adding a small variable offset (the index register) to a fixed base address, it's adding a small constant offset to a variable address. Routines that access data in memory don't need it to be in a single fixed location, but can take a pointer to it in a register.

This re-interpretation of indexed addressing has meant that I have not needed to use the indirect modes at all. If I did, (zp, X) would be the useful one.

My CPU is rather different from yours. I have a lot more registers, for a start. That means it's possible for code to keep data in registers, which means I'm not using memory as a scratchpad. This approach might not be as practical on yours.



My solution does. The 65020 doesn't feel anything like a 6502. It's a quirky early RISCish processor (if you ignore the half of the instruction set that I never use) that happens to be able to run legacy code.

Oh, I see. So LDA $aaaa,Y becomes the equivalent of LDA ($zp),Y with $aaaa as a pseudo-immediate offset. That is one of those assembly language patterns that is totally obvious once it is pointed out.

My immediate reaction is to modify the compiler to make that upside-down format right-side up, adding a syntax like LDA Y,+vvvvvv using the + on purpose to make it obvious that it's an offset, not an address.

As I refactor my code to swap out the LDA ($zp),Y's, I'll try a few your way and try a few with LDA (X),Y and see if having the offset makes the loops easier to write and later, read.

Thank you.

Turns out all that is needed is LDA XY.
LDA XY is the same as LDA (zp),Y but without the need to STA into zp.

Any further need of indirection can be done by LDA XY, TAX, and another LDA XY
But mostly the pattern I need is LDX from, LDA X followed by LDX to, STA X to move a sequence of bytes from one place to another, sometime with the same Y index and sometimes with LDY grabbing the matching index for each sequence.

And while LDA $0,X is equivalent to a LDA X mnemonic, avoiding having to LDY #0, I had enough cases where I would have used a LDA X instruction that I traded off the one opcode and added that to my CPU emulator rather than having the assembler turn it into LDA $0,X. That makes the code one byte smaller per use and avoids having to leave #$00 in zp $00.