65020

[John West]

GARTHWILSON wrote:

Is this the same one as at https://www.ucc.gu.uwa.edu.au/~john/65020.html ?

It's an evolution of that. That was the starting point, somewhere around 1988 or 1989. I've had a lot more experience with a lot more processors since then, and changed my ideas about what's important. But the core idea - extending the 6502 by making memory locations 16 bits instead of 8 - is the same.

And yes, I have continued working on it. Most of it has been around the CPU, building the rest of the computer and writing software for it. The CPU and assembler have had a few bug fixes and some small extensions ("count leading zeros" is the most significant). I should update github. I've been holding back on that because there's one feature left to implement (stack operations should be able to select different registers for the stack pointer), and haven't found a good way to do it yet. And there have been so many distractions.

[GARTHWILSON]

John West wrote:

It's an evolution of that. That was the starting point, somewhere around 1988 or 1989.

So is that page yours too?  Or did you pick up someone else's idea and start working on refining it?

[John West]

GARTHWILSON wrote:

John West wrote:

It's an evolution of that. That was the starting point, somewhere around 1988 or 1989.

So is that page yours too?  Or did you pick up someone else's idea and start working on refining it?

That was me many many years ago.

[janrinze]

John West wrote:

GARTHWILSON wrote:

John West wrote:

It's an evolution of that. That was the starting point, somewhere around 1988 or 1989.

So is that page yours too?  Or did you pick up someone else's idea and start working on refining it?

That was me many many years ago.

I admire how you created backward compatibility. The byte 'interlacing' is really nice.

You also refer to a 16 bit 3op Processor as well on that website.
A long time ago I designed a 16 bit, 16 register RISC processor and I can say that it works a charm.
Surprisingly 128KB (64K words) is a great amount for a retro computer.
Having only 16 instructions does not seem to be too restricting for RISC.
It makes the assembler very readable and easy to convert. And C/C++ compiler is doable too.

Does your 65020 have a C compiler?

[BigEd]

(Welcome, janrinze! Your RISC16 intrigues me - I found some hints over on stardot)

[janrinze]

BigEd wrote:

(Welcome, janrinze! Your RISC16 intrigues me - I found some hints over on stardot)

Thanks. Any suggestion on where I could start a thread on this endeavour? (don't want to hijack this thread)

[GARTHWILSON]

janrinze wrote:

Any suggestion on where I could start a thread on this endeavour? (don't want to hijack this thread)

The "Programmable Logic" section of this forum is the appropriate place for the 6502 version, since you're doing it in an FPGA.  Note that the description of that section, on the front page of the forum, says, "Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL."  If you have a version that's not 65-related, then the sister forum AnyCPU is the place for that.

Garth (moderator)

[John West]

janrinze wrote:

I admire how you created backward compatibility. The byte 'interlacing' is really nice.

Thanks. The byte interlacing is actually the part I consider the ugliest - it's only that way because it was the natural result of "16 bit data + top 8 bits zero = original 6502 behaviour". My favourite is the cheeky re-interpretation of non-indexed addressing modes as indexed with a default index of zero. With this particular method of modifying the default, and this particular numbering of registers, that allows any Y register, stack pointer, or PC as an index for any instruction.

Quote:

Does your 65020 have a C compiler?

It does not, and it is very unlikely that it ever will. I'm not interested in writing a C compiler, and I don't expect anyone else will be sufficiently interested in this processor to provide one.

I did start writing a compiler for a language that I've invented for it, but progress on that is slow. The 65020 is a small part of a larger project - an entire computer, with every wheel getting reinvented by me. There's an infinite amount of work in there to distract me. The wheel-reinventing is why I'm not interested in a C compiler: the only reason I'd want one is so I can compile code written by other people. And why do that when I can spend another few years writing it myself?

The copy on github still needs to be updated. That got postponed until I had it running on an Artix 7, and that's waiting for me to design an adapter PCB so I can plug all the connectors into a new FPGA board. Some time in the next decade, I promise.

[AndrewP]

John West wrote:

SD mode in 74 series? That is hardcore. Much respect.

For what it's worth, I'll attach the latest version of my SD code. Again, it's not directly usable for anyone who's not using my 65020 CPU. But it might be a useful guide to anyone attempting to do this themselves. I finally got around to implementing block_write in this one, and it will re-initialise if it gets a card-change interrupt.

So I've kept meaning to reply to you on my SD card thread but just kind of never got around to it.

I've taken a look at your 65020 design before and really like how it feels a spiritual successor to the 6502.

But I had a pair of concerns that stopped me from really paying attention when I first looked at the 65020. BOTH INVALID BECAUSE I DIDN'T READ THE DOCUMENTATION.

Firstly I'd assumed that because the memory data width was 16bits that the processor could not work on 8bit byte values. But that's not true if I'm reading the docs properly now.

I have a boatload of code that assumes 8bits wrap back to 0 after 255 and didn't think I could rely on that mostly because I assume devices are going to be talking on an 8bit data bus.

Secondly I'd assumed there was no offset register (like the 65816's DP or sort of like the X86's DS register) but if I've understood the docs correctly then all of As and Xs and Z can be used.

I've doodled a few potential 6502 successor designs on paper but absolutely never got any near to turning them into hardware. One of the problems I kept running into was that a 32bit CPU with an 8bit data bus spends far to much time ticking 4 x 8bits in or out. That can be partially alleviated by having 32bit internal registers but at some point something’s going to access memory. In my doodling I went so far as to imagine a 16MByte internal cache memory that could be accessed with a 32bit data bus but still something will eventually need to access external memory. I hadn't really considered using a 16bit data bus which makes memory access a lot more palatable.

[John West]

Working with 8 bit data is awkward. It can do 8 bit memory access, but that only gives you the bottom half of each location. Once in registers, you can do 8 bit operations with no problem. It's packed 8 bit data in memory that's the problem. I mostly work with either 16 or 32 bit data, or waste half of each memory location.

If you're doing operations on 8 bit data, they will wrap (and the top 24 bits of the register will be set to zero). However, indexes are always 32 bit. On the 6502 the zero page indexed addressing mode will wrap, staying in the bottom 256 bytes. Some code relies on that. The one that I ran into was the floating point division routine in Microsoft BASIC, which needed some gentle modification before it would work.

There's no offset register, because there are no non-indexed addressing modes (except for JMP and JSR, which are obsolete with the extensions to the branch instructions). The 6502's zero page and absolute non-indexed modes have been re-interpreted as indexed, but with a default index register that's always zero. You can change that to any of the Y registers, Z, or PC or the stack pointer. With that, and indexing always using the full 32 bits, it's more natural to use a C-like "pointer to struct" style of programming than the 6502's "data goes in fixed locations in memory, and you can use indexing to step through arrays". The base address (the pointer) goes in the index register, and the offset into the struct goes in the instruction. You also get to access parameters passed on the stack without any cost (although I very rarely use that - I pass parameters in registers). Some day I'll add an MMU, and that'll be the mechanism for moving things to other locations in physical memory.

The 16 bit data bus is working well for me. With a decent number of registers, and the register-register instructions using a 16-bit opcode with no operand, my code doesn't spend too much squeezing data through the bus. Working with 8 bit data in memory, and the odd ordering of bytes in 32 bit data, are the main ugly features. And also the fact that you can't use the Y registers as a source in ALU instructions. That's a pain.

[barnacle]

John West wrote:

Working with 8 bit data is awkward. It can do 8 bit memory access, but that only gives you the bottom half of each location. Once in registers, you can do 8 bit operations with no problem. It's packed 8 bit data in memory that's the problem. I mostly work with either 16 or 32 bit data, or waste half of each memory location.

Doesn't that make anything to do with e.g. text somewhat problematical?

Neil

[John West]

barnacle wrote:

Doesn't that make anything to do with e.g. text somewhat problematical?

Not if you store it one character per location, which is what I do. It is wasteful of memory, but I've got 2MB (1M of 16 bit words), so I'm not concerned about that. It also allows a good collection of symbols, PETSCII-style graphics characters, and attributes like underlining and mirroring.
There is no way this design could have been successful in the 1980s, and compact ASCII text handling is one of the reasons. Memory mattered a lot more back then. The only requirement it has now is for me to enjoy programming it. And I do, although it doesn't feel like a 6502 any more - it's more like a quirky and slightly rubbish cousin of the ARM.

[barrym95838]

I have been annoyed and frustrated by 8-bit bytes for decades, and I (perhaps mistakenly) blame EBCDIC and the IBM 360 for polluting the ecosystem. Now there are a bazillion lines of code with obvious and not-so-obvious 8-bit byte dependencies, so otherwise elegant and efficient clean-sheet designs end up suffering as an inevitable result. But I'm just weird that way, I guess ...

[barnacle]

I wondered... but I still wonder how you might import a text file from an external system? Your import converts going in and out of whatever storage you're using?

I've contemplated this problem in the past, and not got around to building anything, but probably working on the basis of a requirement to have 16 or 32 bit variables properly aligned on a 16-bit boundary (or do away with 16 bit variables and make everything processor-side be 32 bits perhaps), and some sort of fast (hardware) shift to allow reading a random byte and have the lower bit or two decide how much it needs to shift into the lower byte of a register. So there would be no penalty for a misaligned byte, but you'd have to read multiple times to get e.g. an ascii stream from RAM into the processor. And of course multiple writes to get it out again, unless you built a wider word and output in one go.

Neil

[barnacle]

@ Mike - not a fan then of UTF-8?

Neil