I am pleased to announce the first public draft of my 65k project: A project to extend the 6502 with larger registers (up to 64 bit), a hypervisor mode for a secure operating system design and an MMU.

Please find a discussion of the design and the first programming specifications on http://www.6502.org/users/andre/65k/index.html

André

P.S.: It will be there in a few minutes so I can put a link to this post on the pages
Edit: Done, pages are available :-)

I have some resources to add to your efforts:

More than a few FPGA's of different sizes. Spartan 2, 2E, and 3. 208-pin QFP and smaller. I would have to acquire some 16-bit wide ram and EEPROM and adapter sockets. Not a problem.

All I would be able to promise are regular updates... Although this may not be what you're looking for, I offer it.

Have you fitted what you've come up with so far to any particular device?


EDIT: I didn't see the link before I wrote this. I see it now though... Reading.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Oops I should have noted here that currently there is only specification - no VHDL code so far!

It's up for discussion - I'm looking forward to your comments

André

ARGGH. So this "1st chapter" is going to be the 65002? which is 8-bit external data bus?

Wouldn't it be easier starting with a 16 bit foundation? Which begs the question should this new version of yours be backwards compatible with the NMOS6502.

Would be nice to add a polling feature to this forum for questions like these.

I for one would like to see a TRUE 16-bit 6502, forget backwards compatibility. Also add more registers, up to 16? maybe more?

Add 1 more accumulator, maybe add another ALU to support it.

True 16 bit would mean a 65K zero page? MAKE IT INTERNAL to the FPGA.

Also, more importantly, will it be a 5V core? 3.3V? SRAM & EEPROMs currently available and prices need to be considered... 5V is dying quickly. If it can fit onto an older Spartan 2, it could run @3.3V and still have 5V input tolerance, (5V output tolerance is claimed by some on Xilinx forums). Thus one's choices of RAM & EEPROM are expanded, although in the wrong direction (less memory).

Quick lookup on Digikey, 1Mx16 RAMs are available for $40 each. (2Mx16 are only available in BGA packages). Note that most of these types of "wide" RAM's only come in 3.3V.

Also, (forgive me for rambling on), but I don't think it would be too difficult to have some dedicated memory I/O for built in interface standards (think of the 6510). You could start straight off with USB/I2C/PS2, maybe even EIDE. And need less than 255 dedicated registers.

This is what I am asking Santa for. This is WAY too much to ask for isn't it?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

If you forget backward compatibility, you have to write a completely new toolchain as well. No program written for the 6502 will run on it. Without backward compatibility I'd rather use an 68k derivative or even a PowerPC or ARM instead. They also have more registers and so on.

My first approach was exactly this - add new wider register (16 bit Accumulator). But the result was that it looked like two processors molded together, the 6502 and a 16 bit processor. So I decided to use the approach I wrote down in the 65k.

Extending the 6502 has been much discussed, even in this forum, but no one has come forth with an actual implementation except for Gideon's 65GZ032. Which I consider a RISC CPU with a 6502-to-native code translator built in. And even he did not give up 6502 compatibility.

So if you so absolutely want the 6502 of your dreams, build one yourself. I'll happily learn from your experience and your decisions.



The 65k will so far be a VHDL core. Just use your own selection of FPGA, add your own I/O areas with dedicated on chip USB etc.... you're free to do that.

You can only make it right for so many people at the same time - so I decided to make it right for me. You can see what and why I decided on the features in the (lengthy...) feature discussion page linked from the 65k main page.

André

Hi André
Great to see your thorough investigation and write-up! Haven't read it all yet.


You're right, on all counts. And we can learn from your experience too: a good implementation will also be a good platform for experiments.

I encourage you to use an explicit and standard open source license for your implementation.

Cheers
Ed

The C32 (Cross-32) assembler from Universal Cross Assemblers (which may be under a different name now), which I have, not only comes with the tables for lots of processors so you don't have to buy another assembler for every processor you want to use, but even allows you to make your own. Then you'd have a nice macro assembler for your invention. It was $200 when I got it perhaps 15 years ago, so it wasn't all that expensive as non-free assemblers go.

My TTL6502 has it already implemented. And my RB6502 doesn't show it yet, but being based on my TTL6502, it can be expanded as well. The idea is quite simple, or better the two ideas:

1- Use one of the KILL opcodes to tell your CPU to go into another mode. For my TTL6502 it meant an extra register and using bigger FlashRAMs. Only the size of the FRAMs limited the number of extra modes. Having a big one on my Godil, FPGA doesn't have this limit (so far).
Disadvantage: you have to switch back to the original mode to run native 6502. But that is the same as with the 65816, thus should be acceptable.

2- Use one more of the KILL opcodes as pre-opcode. So $A9 $12 means LDA #$12, $02 $A9 $34 $12 could mean LDA #$1234 and $03 $A9 $78 $56 $34 $12 could mean LDA #$12345678.
Disadvantage: an extra byte to load, but already the 16-bitter still only needs two cycles to read the (now) four bytes.
Advantage: you can run native 6502 code in the middle of your 16- and 32-bits code!

I think that idea #2 is the one that fits nicely in your ideas!

_________________

Sorry I wasn't aware of your RB6502 already extending the 6502.

Yes that was also my reasoning with the 65k.

André

You don't have to say "sorry" as it isn't really visible. There is only one things that shows it: my Opcode Counter is prepared for opcodes taking more then seven cycles.
My original code had 16 bits registers but having trouble to get the VHDL code working, I decided to step down. And removing that extra counter bit was too much work :)

But as mentioned before, I want to put the Godil on an old IBM AT board. And there these 16 bits registers come in very handy because sometimes I have to read/write 16 bits in one go: 16 bits I/O operations like reading/writing the harddisk.

_________________

I think one huge problem you have is you have not defined your goals yet.

Without a clear understanding of your high-level goals, it is difficult to give input on your design.

For example, I've skimmed the design, and iti doesn't seem very suitable for compiler code generation. If you are intending this to be programmed primarily in assembly, then this is obviously not a problem.

Toshi

Toshi's got a point. At some stage you're going to have to start choosing between feature A and feature B (because of lack of room in the FPGA, or because of conflicting requirements) and having a very clear idea of exactly what you want makes those sorts of decisions much easier. As a bonus the entire design will be a lot more coherent since all parts of it will be contributing towards a small definite set of goals.

Hallo André,

It was able read to read the features part of your 65k project last evening. My first comment on your 65k project: I liked what I have read and I really hope we can expect more. I also hope that I can add to the project and to learn from it as well; virtualization for example.
I would like to add one item to your requirements: readability. Anyone should be able to understand the code. The T65 core is used in many designs. It does it job perfectly but the code is very hard to understand. Gideon's core for the 1541 Ultimate is even harder to understand. The worst part is, both are written to minimize the load for the FPGA. Which is understandable. But expanding the insruction set will be a hard job.
65k opcodes: "push/pull "state", i.e. all registers". Do you mean to push/pull ALL registers, not just the Status register? The 6800 does this as well. But they changed this with 6809, with reason. Something to discuss IMHO.

What is "branch never" ?

"Total new opcodes > too many" Why? Good opcodes are always welcome. You (we?) have to decide what is considered "good". The ones you have proposed are good enough IMHO. But some can be improved, I think :)

"Number of Register": shouldn't it be : "Registers"? Extra registers won't hurt. About register sets, I'm used to it while working with the Z80. Nice idea. But for complex situations, like virtualization or multi-tasking you would need more. And 1) I wonder how to keep track of them and 2) how much space do they take in the FPGA. But it sure is worth a discussion.

"Alternative 2: Prefix Bytes":
"Program size (and thus fetch speed) .... - (longer for each operation)". Yes but the advantege would be great. But as I mentioned before, a 16-bits bus reads four bytes in two cycles + example; no loss of speed. Another example: JMP $1234 = three bytes -> prefix byte, JMP, 32 (!) bits address = three cycles of two bytes, again no loss of time.
The 16-bits version permits us the use of just one prefix byte otherwise we would lose speed. No proof, just based on the given examples. You mention 105 free opcodes. I prefer, for the moment, to support the runnable illegal opcodes as well. That still leaves us with 50 free opcodes? (I really have no idea) Not too much but I think enough.
A very interesting thing is that we only need one prefix byte for the 32-bits mode: the second byte can serve as actual prefix byte, then followed by the opcode. Or a prefix byte plus a two-byte opcode. The sky is the limit :)

Address Expansion:
First to be honest, you lost from "PowerPC Address Translation" on. Maybe some "explantion for dummies" could help?
MMU is nice (I loved your idea about using MMU to turn a CBM into a 1541) but isn't suitable for multitasking (looking to CP/M 3 or at the way EMS is used on a 8088). Then I rather would prefer the segmentation as used in the 80286. But this worked fine for COM programs (read: native 6502), but not for EXE, programs that extend beyond the 64 KB barrier. That's why Intel introduced the lineait addressing in the 80386. But to be honest, I have no idea how multi-tasking etc. is done here. AFAIK the MMU in the 386 is certainly is used for EMS but if it has another role as well ???
The 256 KB project for the C64 published in the 64'ER just pops up in my mind. Maybe you remember it? Especially targeted on multi-tasking on the C64 using some common areas that could be dis- or enabled at choice. But certainly not suitable for programs > 64 KB.
I think we have to look for a combination of lineair addressing and the bank registers used in the 65816's / the segmentation of Intel, but with 64 KB stepping instead of the original 16 bytes.

IN?/DE? immediate:
I like this idea! But what operand; byte, word, double-word? IMHO a byte should do. Which brings me to another idea. Being a new opcode, a prefix byte is needed. Prefix + opcode + operand = 3. For a 16-bits system 2 cycles would be needed. Then make use of the unused byte by adding e second prefix, saving the original poole of free opcodes.

Interruts, RTI:
What about using extra vectors, like the 65816 and 6809?
I wouldn't use bit 5. I would use an internal register set by an extra opcode. An opcode that would be needed anyway to handle bit 5 (LDA %xx0xxxx PHA PLP is dangerous IMHO). With at least 8 bits at our disposal, we can be more flexible. At startup this register would be set to "native mode". The OS sets this register according its needs. When in 16-bits mode (or whatever) the interrupt pushes the extended registers to the Stack. If running a native program in multi-tasking mode, the OS then updates the private Stack for this program by copying only the bytes that would have been used by an original 6502 from the main Stack.

"Branch Subroutine":
BRA(L) and BSR(L) makes it easy to relocate programs to ANY address. But then someting has to be found for "LDA $xxxx" etc. like "LDA PC+offset". I think you already mentioned this, but just to be sure.

"Unfortunately the wide reads and writes are not always aligned with the memory width."
Two ideas:
- What about aligning prefix + opcode + operand to the width of the bus?
- Using an internal cache is another option. When reading unaligned instructions the surplus bytes are stored in this cache. And therefore they haven't to be read anymore for the next instruction. Jumps, branches, subroutines, loading/saving from/to unaligned addresses will cost cycles. But this could be solved by taking care that these are placed on aligned addresse by the compiler.

This covered your "features". Now I can start reading the rest :)

_________________

Hallo André,


Implementation Specs:

"16 bit - ... the PC stays 16 bit": If I want to replace the 80286 of an IBM AT or the 68000 od an Amiga with your 16

-bitter, I need more addresslines.

"MMU Option": Could give me the 8 extra address lines but I rather prefer at least the capabilities of a 65816.

"LongLong - equivalent to Q, deprecated": I tried Google etc. but cannot place 'deprecated'. Please explain.


"bit5 set to 0"
: Why, what is the advantage?

"Prefix Overview":
- Please explain the role of Prefix1 and Prefix2; should both be used or just one? A later example just shows one. But how are you going then to combine certain features ???
- Do we need an offset register?
- I don't see the need for a zero-extension bit. Using your own example:
LDA.W #$1234 = the 16 bits instruction
LDA.Z #$56 = lda #$56 of the original 6502. No Z-bit needed.
IMHO the RS0/RS1 covers the item. "STA32.B $12345678" only overwrites the address $12345678.

My view: The 6502 opcodes don't need a prefix byte. So you need three to tell wether it is a 16, 32 or 64-bits action. Add three to support another 256 extra opcodes/prefixes (which can cover the ideas you want and I don't understand :). Add six that cover the privileged mode. That totals twelve, multiply with four for RS0/RS1 and you get 48.

You see I discarded the AM bit. ZP stays ZP ie. just one byte. Absolute is the width of the addres bus. If you say "LDA $1234" on a 32-bitter, what are the highest 16 bytes? If you mean zeros, then use "LDA $00001234". OK, it will cost some extra memory but, hey man, you don't create a 32-bitter that can address up to 4 GB and then want to save a few bytes? :)

"Offset":
Use a new opcode for instructions like LDA P,$1234 or LDA (P,$12),Y. You just got 256 new ones from me :)

"Quick Opcodes":
Why don't you use prefix + two bytes? Costs one byte more but gives you a range from 1 to 255.

"Interrupts":
- What about using a 8259 or equivalent as interrupt collector? No extra pins needed.
- Why is the standard word wide vector not good enough? If the 64 KB it covers isn't enough, just simply use a long jump outside the original 64 KB.
- Why didn't you keep the original order IRQ / RESET/ NMI for the three highest vectors?

_________________

Well, I should probably have written them down more explicitely.

1) Make it 6502 compatible - be able to run existing 6502 code and start from there

2) Advanced features for new computer systems and operating systems, like memory management and virtualization

3) extend the register / ALU / address width to more than 16 bit to be able to linearly address more than 64k memory

All this under the condition to extend it "naturally", i.e. basically not make a new processor that interprets 6502 code, or something like that.

And of course just my personal education :-)

What is not on the list like specifically support compilers or such. My question in this respect is, why do you think it isn't well suitable for compilers code generation? I think the stack/PC/offset register-relative zp and abs addressing modes provide a good base for compiler implementation - just maybe not like they are "normally" built today with CPUs that have many registers.

André