Hi all,

I want to put on the table a questions (may be stupid, pardon to me in this case).

I still see a big interest around the 6502, from C64 fanatics to Automitive system companies. A wide range of designers are still using this glorious processor.

I also got evidence of many attempts to give a future to this processor, designing new core at 32bit (RISC like) with the capabilities to emulate 6502 original instructions (tyically not clock accurate or to complex to be validated). None of these had a lot of success I believe: validation problems, maturity, new tools chain to be designed, etc...

On the other hand, I have to admit that having a 6502 with larger memory space and a 32bit access could be quite useful (just for fun, I like to immagine a C64 with the processor replaced with an FPGA with inside new peripherlas and lot of memory).

Giving, that I was thinking about the possiblity to design a wrapper (instead of a new processor) around a generic 6502 (one of the already sythetizable cores) to give it 32bit access capabilties and a 4Gbyte of memory space. This modified 8-bit processor should use the already available tools (assembler).

The advandage of this approach would be:
- easy to verify (the core is still an already working 8bit 6502)
- 4 Gbyte of memory space (segmented)
- 16 bit Code Segment (64 K segments of 64Kbyte each)
- 16 bit Data Segment (idem)
- 16 bit Stack Segment (idem)
- 32 bit General Pourpoise Register (for 32bit access)
- Automatic Code Segment switch (context) on JMP, JSR, INT, NMI and BRK
- compatible with already available 32bit peripherals (see www.opencores.org to have an idea about availability)
- unmodified original ISA
- compatible with standard tools
- fully backword comaptible with 6502 binary code

The wrapper would have a 6502-like pipeline working in parallel to the 6502 one. The wrapper pipeline will execute only the new instructions.

Of course, it must not be intended as a project to originate a powerfull processr but, instead, a funny project to enlarge original 6502 capabilities may be running a simple uCLinux (may be slow but ....)

I would appreciate your comments in order to know if I'm going to wast time or if I'm going to do something that could be useful at least inside the 6502 fanatics community

Thanks anyway to be so patient to read this long email.

Cheers
Pipettas

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I think this subject is quite a bit out of scope for "6502.org". I do not think anybody reading this forum has the means to design new MC chips. And no chip designer would design a new chip having as main market the hobbyist reading this forum! But obviously, dreams are allowed!

Anyway, for "main computers" the world is obviously on the Intel (Pentium) track (including software compatible competitors)! This I personally think is unfortunately as for example the basic Motorola architecture ( which is the architecture of 6502) is quite a bit more elegant. The Intel developments were always hampered by the need of being backwards compatible with earlier models and this resulted at the end in quite strange designs. But also these designs work and has now a "quasi monopole" all over the word (MS + Linux systems). This development is not reversible! Possibly (hopefully!) will the (excellent!) Sparc processors from Sun find a durable place in the market but to enter this market with a new design would be complete madness and no management controlling a sufficiently capable company is "completely mad"

As everybody knows, this is all a result of the IBM decision to for its first PC use an Intel processor (and to let Micro Soft write the operating system). They could have chosen Motorola instead but they did not.

I mostly agree, but I would say it's not out of the question if done with programmable logic, probably meaning an FPGA. The per-processor price may be quite high ($25? I really don't know) and the power consumption may be too high for any commercial products, but it's certainly doable for a serious hobbyist.

Hi,

first of all let me apologize with all of you, this doesn't seem the right forum were to discuss about this item. I supposed that 6502.org was a good place were to ask opinion about new ideas around 6502 cores. You should be 6502 user specialists, hence the right guys to be asked.

Let me clarify also that my proposal was aimed to address only hobbistic applications where FPGA are used. More and more guys are today using cheap FPGA to build in system. There is no intention to make a product or to compete with Intel, is just a modest idea to increase fun with the scope to donate the synthesizable RTL code.

Giving that, since you can easily find at least two or three synthesizable 6502 cores on internet that are perfectly working (tested on silicon), I was wondering whether to extend these cores to be 32bit capable (without reinvent the wheel) can be useful for 6502 based designers or not. That's it.

I hope that now the scope is clearer.

BTW, I want to thanks Garth Wilson for his suggestions. You are explaining a philosophy close to my one and to the intention of my proposal: "keep it simple, stupid" = KISS. I was initially attracted by the 65GZ032 project too (probably a very good processor) but to far from the original 6502 simplicity.

You are basically considering 65xx improvements in three directions:
- 32bit data bus access
- 32bit data management
- performance
- ISA extension

Well, with my proposal I'm going to address the first two topics. Performance are achieved exploiting FPGA speed: a 6502 implementation into an FPGA can easily reach 50-60Mhz. ISA extension is for the moment not considered just to keep things simple and don't involve new tools designing like assembler and compiler.

These 6502 core modifications will give you the possibility to easily manage the 4Gbyte of memory as segments of 64Kbyte each, inside of which the standard 6502 ISA works. JSR, JMP, NMI, BRK opcodes/events will be intercepted and they will cause segment switch according to a 16bit Code Segment register content (opportunely loaded before jump invocation).
The address and data busses will be 32bit large even if the core is 8bit based. 32 bit accesses will be done with a single instruction thanks to the 32bit data bus and a dedicated 32bit registers (memory will be 32bit large and 8bit accessible). Then, this register will be managed 8bit wise by the core. You will have the possibility to preload also a Data Segment and a Stack Segment register in order to keep data and stack in different segments. Finally, a second Data Segment register should give the possibility to point a second data zone in order to make 32bit memory-to-memory data moving very fast. There is also the possibility to remap the zero page (direct page) and to have one direct page for each segment.

The possibility to directly access 32bit memory (like a RISC processor) allows 32bit peripherals reuse. You can find many of these peripherals on internet (mem controller, USB, Ethernet, VGA Controller, etc....).

When all of these things are working a potential second step is to add 16x32bit registers and a 32bit ALU in order to allow 32bit data manipulation and 32bit load-store from/to memory using single instructions. At the end, the new core will have 8bit and 32bit computational capability to be used according to the specific application.

If my previous email was long, this email is a sleeping pill

Thanks again

http://www.opencores.org/pnews.cgi/list ... o_loop=yes

Yes, that's right, a complete RISC engine (that looks really juicy too! Has many features from MIPS and PowerPC, but is unique in its own right), fully open source, and fully sythesizable in either FPGA or VLSI.



As with Motorola's designs (which are not based on the 6502; the reverse is actually more correct, but even here, the 6502 departs heavily from the 6800 and 68000 lineups). Anyone trying to port an OS from a 68020 to a 68040 to a 68060 will tell you a few horror stories.



Unfortunately:

* Sparc is completely mad, because all member companies are, well, companies.

* Sparc is an inferior architecture compared to PowerPC, which itself is now also open (or at least WAS) in the same sense as Sparc. All those register windows? Have you any idea how long it takes to perform a thread switch because of those (potentially hundreds) of registers?

I would much prefer a completely open source design, based on a high-performance interconnect like Wishbone. My vote is for OpenRISC.

But, why invest all those transistors for a register-based machine when you can use a stack architecture instead? I'll posit that a 64-bit stack machine will use about the same number of transistors as a 32-bit register-based machine, and can run software faster (no pipeline to stall, instantaneous interrupt response, etc.).



That was Motorola's fault. As usual, Motorola dropped the ball by (a) not having a stable supply in time, and (b) not believing enough in the market to give a damn. Not only that, but IBM had stock in Intel, so it was a natural no-brainer.

This is like saying "Why don't we eliminate memory, because then we can eliminate memory latency".

I would really recommend you read Hennessey's book on computer architecture.

Toshi

Oh, you mean that book I have sitting on my shelf? Yeah, the one that describes the MIPS-I clone in a low-level detailed fashion. The one I read three times over when I first got it. How about this instead: I recommend you read "Stack Computers, a New Wave" by Philip Koopman.

Your response was wholesale non sequitor, and utterly out of line, I'm afraid. I stand by my arguments.

Just face it -- stack CPUs take less resources to do the same amount of work. Period. Smaller instructions makes for smaller RAM consumption (so, for a given bus width, higher effective instruction throughputs are possible). Fewer transistors makes for smaller power consumptions.

The laws of physics cannot be broken, and the math doesn't lie. I really don't know where you came up with that memory strawman -- you're free to defend a flawed architecture if you wish, but if you feel the need to, please do so with cogent arguments.

This is a slight tangent, but there's a straightforward way to extend the 6502's addressing without using messy segmentation: simply add new addressing modes which use 3 (or more) bytes for an address. The existing modes would continue to address the lower 64K of memory. No need for new registers, new modes, or anything - very simple and elegent.

For code density, it would also be desirable to have PC-relative addressing modes (at least jsr/jmp).

VBR, the things you're talking about are a couple of the already-existing attractions to the 65816. It has a lot more too though. See the second post near the top.

VBR, first of all thank you for your feedback.

Yes, you are right, the possiblity to address linear memory space is always to be preferred but this would require to add new addressing modes and to enlarge instructions (up to 4 byte) and this is just wath I would like avoiding to do. Since I'm designing this core to be used in FPGA or ASIC project, code density and core simplicity is a must.

Memory and data will be addressed using address or data extension registers (like the DBR and the PBR of the 65816) but the instruction and data bus will be 32-bit wide, allowing real 32-bit access to the memory ( this is the real advantage). This way, the external address seen by peripherals will look like a "liner" address. Blocks of data could be moved on a "per word" basis increasing by a factor four the data troughput at the same clock speed. At the same time, system bus will be locked by the CPU one fourth of the time with respect to a normal 6502, leaving the bus free for other master like a DMA.
Having a 32-bit bus (no data/address multipled) will give you also the possiblity to save the whole 6502 registers bank (A, X, Y, P) into the memory in one clock cyle (single memory access) with abvious performance gain during subroutine call and context change.

The memory segmentation will give you the possiblity to manage each 64Kbyte segment independently form each other, so, for example, you will have local "zero page" and local data stack for each segment.

The other advantage would be the possiblity to use 32-bit peripherals available on internet for free (see www.opencores.org) and assembling standard platform using RISC peripherals.

In the first version the ALU will remain 8bit wide (even if memory access is 32 bit capable) but in the second version also the ALU will be enlarged to 32bit in order to gain a factor four also during data handling. A set of 16 registers (32bit each) will be added as well in order to minimize as much as possible memory accesses.

Cheers,
Stefano

This is getting a bit O.T., but are there any stack processors in production now? I kept a magazine page from 20 years ago, kind of a description but not an ad, of a SBC using a Harris RTX-2000 that routinely did 16MIPS @ 12MHz (peak MIPS was more), with a maximum of four clocks of interrupt latency and 0 clocks for return-from-interrupt. Incredible performance for the day, with a rather simple processor.

Pipettas, it's hard for me to tell how well you know the '816. It still sounds like you might be dreaming of things the '816 already offers (except, of course, that it does not have a 4-GigaWord address space).

On the matter of registers however, I would mention that when someone says, "The 6502 is very limited in registers!", I just respond that essentially all 256 bytes of zero page (or the relocatable direct page for the '816) is processor registers. The way it is set up makes for much faster interrupt response time and context switches than the processors with lots of registers can deliver. For this reason I'm not too fond of the idea of having 32 processor registers. The exception I would like to see is where the registers are used in onboard stacks for a stack processor so it does not have to go out on the bus(es) for stack operations. The 6502 is quite efficient at multitasking in Forth, although its ZP and page-1 sizes for data and return stacks are small enough that you'd have to be careful with stack space if you had more than about four or five tasks set up at once.

GARTHWILSON, thank you for your replay.

I believe that 65816 has a lot of of improvments w.r.t 6502 in fact but it is still a 16-bit processor. Offering real 32-bit access things should go faster, is'n it?

Can some one tell me the performance improving moving from a standard 6502 to a 65816 (same clock speed)? It should be very interesting form me.

My indirect-threaded '816 Forth is two to three times as fast at the same clock speed as my 6502 Forth. (As usual, the exact speed difference depends on what you're doing.) The '816 allowed more optimization.

PTSC-1000, by Patriot Scientific. Intelasys multi-core arrays (so-called SeaForth) as well.

Nowadays, with the sheer simplicity of stack architectures, I doubt they'd actually sell well because it's so easy to reverse-engineer a competing design and stuff it into an FPGA.



Having all those registers is OK for embedded environments because you need only save/restore affected registers. For desktop use, however, context switch overhead can be substantial.

The IA-64 architecture (aka Itanium) actually had status bits in a control register that indicated which (sets of) registers have been modified since last context switch, so it could intelligently write them back into RAM. Most RISCs don't bother with this scheme of course.

Also, most RISC ABIs (Application Binary Interfaces) map out various registers for various purposes. Not all registers may be written back to a thread's state (for example, some registers may be reserved JUST for ISR use, some JUST for kernel use, etc). This mapping is, as you might expect, 100% analogous to a systems software designer attempting to create a memory map of zero-page.

For example, compare a hypothetical zero-page layout like this:



to a typical, but still hypothetical RISC ABI register usage convention like this:



Knowing the ABI's preferred register layout allows you to optimize context switching by saving only those registers that are really important.



I prefer in-RAM stacks, but backed by specially engineered data caches to achieve the same level of performance. Although this requires more circuitry (and hence, more bus interface complexity inside the chip), when it comes time to do a context switch for multitasking, you don't end up having to write out both data and return stacks explicitly. Also, doing this stack flush will necessarily require two data stack elements to hold the memory base address and index. Therefore, if your chip has 16-deep stacks, you can only reliably support 14-deep stacks in a multitasking environment. Yucky.



With an external MMU that detects and re-directs accesses to $00xx and $01xx to other pages, multitasking becomes even more trivial. Commodore 128's MMU could do this, for example, but for the life of me, I'm not sure why nobody has, to date, employed this capability.