Hello,

I am starting this thread to introduce the 65A24, a fictitious "software only" member of the 65-series family that extends the 6502 to full 24-bit addressing with 32 bit registers. The goal of the 65A24 is to improve on the 65816 by removing kludgy features like memory segmentation, reliance on bank 0 memory for important things like vectors, the stack, direct page, etc. and adding extra features to improve ease of use and programmability.

Since I don't have a great deal of documentation on this system yet, I will introduce aspects of it little by little to the community. First I would like to talk about the registers:

Accumulator: Full 32 bits
"B" register: Full 32 bits
"X" index register: 24 bits
"Y" index register: 24 bits
"S" stack pointer: 24 bits, which allows the stack to be located anywhere in 16 megs of memory
"P" processor status register - lowest 8 bits are the legacy 6502 flags, with an extra 16 flags to control new features of the 65A24.

"m" and "x" bits of the 65816 flags register have been removed, and now there are two "am" bits which control the width of the A/B registers. Two "xy" bits in the PSR control the width of the X and Y registers. They are set/reset with the SEP and REP operations which now take a 24 bit immediate operand. They can also be set with the following operations:

AMB, AMW, AMA, AML, XYB, XYW, XYA

These set the am and xy bits to "byte length", "word length", "address length" (24 bits), or "long length" (32 bits). Obviously there is no XYL instruction and xy bits in the PSR set to a 32 bit length would be meaningless, at least for now.

For example, the code:

AML
LDA #$deadbeef

would assemble to: F3 A9 EF BE AD DE.

The 65816's XBA instruction has been retained, which allows swapping between the accumulator and the shadow "B" register which sits behind it.

All of the 65816's Long absolute, long absolute indexed, long indirect, etc. addressing modes have been removed because they are unnecessary - ALL addresses are long now, except for direct page addresses which are still one byte in length and index into the 256 byte direct page which can now be located anywhere in memory. For instance, the following code relocates the direct page to the 256 byte region beginning at $e92000:

AMA
LDA #$e92000
TCD

(or PHA, PLD if the programmer is so inclined).

The 65816's BRL and PER instructions have been removed because all relative addresses are 24 bits now, +/- 8 megabytes of address space. This is selectable between 8 bit relative (+/- 127 bytes) and 24 bits with the new "SSR" and "SLR" opcodes (set short relative and set long relative). These set/reset another flag in the extended 24 bit PSR which controls relative address size. This allows instructions like BCS, BCC, BVS, BRA, etc. to branch a full +/- 8 megabytes if necessary, or the traditional +/- 127 bytes if conservation of memory is the goal.

JSL ($22) has been removed because all addresses are long anyway, and this operation has been re-used as "JRS", Jump Relative Subroutine, which uses the above mentioned scheme for describing a relative address.

That's enough for now, if anybody reading this is curious about this project I would like to invite comments and suggestions. I am trying to gauge interest in this project to see if it is something people want developed into a completed product, instead of remaining on my computer as just another one of my own personal software "toys"...

Steve Sviatko
ssviatko@gmail.com

Looks interesting, Steve! I must admit that I'm asking for partially selfish reasons, but are you ready to share the nuts and bolts of your "Qt"-based emulator for study?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Ah yes, I was going to suggest that an emulator is ever so useful for working out the details of a new machine, and seeing how it feels by writing some code for it. And now I bring in a couple of snippets from Steve's introduction post:

Many people seem to believe that the 65816 would have been better served by prefix codes rather than stateful mode registers. Have you played with, or are you going to play with that model in order to see how it compares, or is that too much of a diversion from 65816 for your design?

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Hello, Steve here again. I'm just popping in to update everybody on my project.

It's been a couple of months and this project has really begun to coalesce into something that could possibly be misconstrued to be a completed, functioning piece of software. The 65A24 emulator is a Qt program currently in development under Debian Linux, and I have tried my hardest to use off-the-shelf Qt features and classes so it should easily port to the Mac and Windows desktop environments. As of right now it consists of a main console window which displays the graphics and text modes of the reference A24 virtual machine. It also captures keyboard events and delivers keyboard data to "soft switches" on the I/O page in memory. This works similar to the Apple ][ with a keyboard register and a keyboard "strobe" which clears the register as key data is read.

For those who are curious, the I/O and ROM region occupies memory from $e00000 to $ffffff. The display buffer is $e00000-$effeff, the I/O region is a 256 byte page from $efff00 to $efffff, and the ROM area is reserved from $f00000 to $ffffff. The A24's vector page is in the obvious place at $ffff00 to $ffffff.

There are 8 display modes, 4 for text and 4 for graphics. These are based on an ultimate screen size of 936x560. I have included a basic character ROM with 9x14 characters, so the text modes are as follows:

13x5 (LORES text)
26x10 (MIDLORES text)
52x20 (MIDHIRES text)
104x40 (HIRES text)

The buffers for these text modes begin at $e00000 and each character is represented by a 16 bit value, 8 bits for the character and 8 bits for background/foreground color info. The 16 default text colors are the same ones used by the Lo-res "GR" mode on an Apple ][. The four graphics modes are as follows:

117x70 (LORES graphics)
234x140 (MIDLORES graphics)
468x280 (MIDHIRES graphics)
936x560 (HIRES graphics)

Each pixel is represented by a 16 bit value in memory starting at $e00000, regardless of the mode. The pixel data is RGB 15 bit with the high bit reserved for future use (sprites, transparency, or ??). At the HIRES mode, this comes pretty close to filling the entire 1 Meg buffer between $e00000 and $effeff.

In addition to the console, the Qt app contains an assembler capable of assembling 65A24 code in a text editor window with full editing features. Newly assembled code can be copied directly into the console's memory region and executed immediately. There will also be a facility to assemble ROM images and have them load and execute automatically when the app is started up. There is also a window to set/inspect registers and set flags and do rudimentary step/tracing through memory.

The source code to the Qt app (which contains the console, assembler, and emulator engine) will be open sourced and posted for the community when it is finally finished. It is my hope that this can eventually become a community supported project, although I will retain all trademark and copyright claims and have the ultimate say in technical steering as things evolve. It's my hope that this will grow into something that people will really like and really want to use.. I imagine games being written for my console environment, and maybe even see this implemented in an FPGA or in hardware as a standalone microprocessor or microcontroller someday!

To answer the most recent question, the 65A24 is being kept as close to its 6502 roots as possible, with some inspiration from the 65816 as well. There are still only 7 registers (A, B, X, Y, D, S, and P) but with a direct page relocatable anywhere in the 16 meg memory space this shouldn't be an issue. Think of the 65A24 as a 6502 with 24 bit addressing, 24 bit index registers, 32 bit accumulator, and 24 bit direct page and stack registers that can be located anywhere in memory. All segmentation issues of the 65816 are eliminated as this is a completely flat 24 bit address space.

Anyway, thanks for everybody's attention and consideration, I'm going to get back to work and I will post more updates as necessary, and I will try my best to field any technical questions along the way.

Steve Sviatko

This sounds really neat. Just out of curiosity, why did you decide to stick with an accumulator-based design? Wouldn't it be a lot more powerful if it were more orthogonal even if that is less like a 6502?

Well, to be honest, I have several other designs for interpreted machine language environments, I just chose to pursue my 65A24 design for now because of my love for the 65 series microprocessors, and particularly, the era of the late 80's "16 bit" 24-bit addressed machines like the Apple IIgs. I am also a fan of the 68000 series and may do a machine language interpreter that is an homage to the 68000 later on.

A huge design advantage the 6502 has over other 8 bit chips is the inclusion of the Zero page (direct page) and zero page addressing modes. Rather than have a multitude of registers on the chip itself, the 6502 essentially has 256 8-bit registers that can be accessed at full speed and ganged together into 16-bit address pointers if needed. They can also be indexed (try doing that with any other processor's internal registers!)... I continued that paradigm on the 65A24 with a relocatable direct page, so a program can pretty much have an unlimited number of 'registers' that can be used as data, 24-bit memory pointers, or can be relocated on top of any data structure in memory and used as if it was a traditional zero page. Never underestimate the power of the zero/direct page(s).

Instead of a selector byte, or selector nibble/bits to determine register size, I am continuing the 65816's paradigm of having bits in the status register that determine the width of the accumulator/memory and the index registers. Instead of forcing the programmer to use the clunky "rep #$30" and "sep #$30" instructions, I have included 7 additional implied instructions to set the widths:

AMB, AMW, AMA, AML (Accumulator/Memory Byte, Word, Address, and Long)
XYB, XYW, XYA (X and Y Byte, Word, or Address)

These set the widths and then the widths stay active until the next such instruction is executed, i.e. they are not needed before every single instruction like they are on the x86-64 or other modern processors.

AMA ; Accumulator/memory is 24 bits in width now
LDA #$02a000 ; Load a 24 bit address
TAD ; Transfer to direct register
LDA #$e00000 ; Load another address
STA $1d ; Now $02a01d contains $00, $02a01e contains $00, and $02a01f contains $e0.

Another feature of the 65A24 that I don't think I have elaborated on yet are the "X INDIRECT" and "Y INDIRECT" addressing modes. I have repurposed the instructions ending in $7 on the 65816 to be 8086-style address pointer instructions. These allow you to use X and Y as address pointers and optionally have them automatically increment or decrement when they are used. There are 4 new bits in the PSR for this purpose, 2 that control X and Y auto increment/decrement, and the other 2 control the direction. Example code:

; Memory move - $1e00 bytes, from $021000 to $e24000
XYA
LDX #$021000
LDY #$e24000
AML ; Move 32 bits at a time
SXA ; set x to auto increment/decrement (set bit 19 of PSR)
SYA ; set y to auto increment/decrement (set bit 18 of PSR)
XAI ; x auto increment (direction ++) (clear bit 17 of PSR)
YAI ; y auto increment (direction ++) (clear bit 16 of PSR)
.move LDA [x]
STA [y]
CPY #$e25e00
BNE .move
RTS

Thanks,

- Steve