I did mean stack pointer. I was trying to say that a B (and maybe C) register which operates like an eval stack isn't also meant to be shadowing what's happening on the PHA/PLA stack. But I've gone off this auto-push idea a bit.


Indeed, it is a source of ideas. But there is no open source verilog or VHDL for it, so it isn't any kind of starting point for an implementation.

I fired up Xilinx's free tools the other day and was able to read in Rob Finch's verilog 6502 fairly easily. It synthesised OK to gates, with a few warnings one might want to fix up, but it didn't place and route - probably something wrong with my installation. It only took a couple of hours to get that far. So if we can start with a good quality 6502, there's enormously less work than if starting from scratch.


There might be some use in a version which only brought out 24 or 28 address bits?


I hadn't thought of these flags. Mask is AND with $FF and sign-extend is compare and SUB $100. If a LDA is followed by those ops, does that sort out the flags? It costs almost nothing, because the LDA has to slow down to 1 or 2MHz whereas the other processing could happen at full speed.

just realised: both 65Org16 and 65Org32 are intended to have loads of RAM and not to conserve it.

so using lookup tables for some purposes starts to make sense: even as large as indexed by 16bits. That could make for a rapid multiply, without any hardware support.

this idea inspired by Rob Finch's previous thread on enhancing 6502

_________________
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?

That's the idea - but only 64KB if you have big bytes! For multiply I'd imagine coding a long multiply on 16-bit digits using a table for low and high result. For square root and transcendentals one might use polynomials (so everything depends on multiply). For divide and squareroot I think the favoured approach is an iterative converging algorithm which uses a table to get a starting point.

As for the exact flavour of the 6502s out there, I'm not sure. The 2002 one from Bird Computer (Rob Finch) says it is an original. So, if it was important to have the 65c02 enhancements, they'd have to be written (and tested!) But the T65 one may be what you'd want: my notes say it includes a 65816. If so, and if it's good enough quality, and fits on the device OK, it does mean the '816 is a reasonable starting point after all.

You're quite right that if you've got a fast peripheral then my argument that sign-extending in software is no time cost fails. I still wouldn't worry about this though: using a macro makes it easy, code density is no concern, and if I/O performance matters then hardware can do it. (One might allow for an input pin which let the peripheral signal a byte-wide access, and the memory interface can do the sign extension. No change to the cpu core itself.)

Fast peripherals are also handy if they remove all need for changing clock speeds.

You had an earlier idea about bootstrapping by different means to avoid lots of ROM: I like that. The 816 project I'm involved in hopes to use a serial EEPROM for this.

I should point out that doing bytewide/shortwide access on a 32-bit bus requires only a single multiplexer, which has 7 possible values. You're inevitably going to have quite a lot of muxes in your design anyway.

I should also point out that, despite what it may sound like, pipelining isn't difficult. The most complex part is the interlocks - of course, you can not implement these and have the assembler error if you try and violate the require delays.

As for branches, I have 21-bit PC relative branches (+-1MB - I can't ignore the lower address bits as I have a "dense mode" in which instructions each take 16-bits but only have two operands - and it's enabled by the LSB of the address). If you need to branch further than that, I imagine the linker will replace it by an indexed jump (Something like JMP register, index where the register points to a table). Indexed jumps will of course be slower due to pipeline delays.

Of course indexed jumps have the issue of you overflowing the index - but I have a feeling that programs very rarely require 32k far jump locations - as generating that many probably involves equally many functions, unless you have over 250k instructions per function!.

I agree that the wiring for unaligned or bytewide accesses isn't a major problem, but you need to assign opcodes, design and debug the decoder (which means writing lots of test cases) and then extend the assembler.

It's all possible. But a 6502 takes 1500-2000 lines of HDL, and the further you go, the more to design, test, debug and support. Which is why I advocate a series of small steps. If you have the hardware design skills to produce lots of tested code quickly, that's great - but I don't.

I wouldn't go so far as to say pipelining is easy: it's easy on paper - even easier on a whiteboard - but remember you need to get from an idea to a documented and debugged implementation. I'd imagine it would double the amount of work. edit: and why not get something working first, then get it working fast?

I see there are 6000 lines of test code in Mike's py65.

Sorry if that seems very negative. The start of this thread was about ideas for improving the 6502, but it became a thread about implementing an improved 6502, which is hard. On the positive side, several forum members have in fact done it (at least Ruud, John West, Rob Finch, Sprow: apologies to others I've missed)

To be a bit more positive: if you speak python, how about adding support for your proposed modes/operations/registers into py65 and seeing how it works out? Or if you speak C, add it to run6502 or lib65816. Or if you speak HDL, well...!

edit: must resolve to be more positive and encouraging! I had a quick look to see how hard this stuff is supposed to be. This 3rd year undergraduate course www.ee.ryerson.ca/~courses/coe608 has 40 hours of instruction and estimates 24 hours of lab time. About a quarter of the instruction is on pipelining-type stuff (technical term!). So if your brain is half the age of mine, you could have this done before the clocks change.

_________________
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?

As a side note that came to my mind when I read about the pipelining:

The original 6502 (and even 65c02 and IIRC up to 65816) can not "roll back" an opcode in case of an error (say bus error like non-existing memory, or write to a read-only page).
So for example a read-only memory can not trigger an interrupt (rolling back the current opcode), in the interrupt fix the read-only problem, and restart the opcode that then succeeds.

Implementing support for this would require implementing a set of shadow registers, that are updated with the new values when the opcode "finishes" (whatever that means in the context).

In my CS/A design I actually used a second (auxiliary) 6502 to take over the bus in these occasions while the main 6502 was halted using RDY.

So I'd like to see such a feature in the new CPU if possible.

André

P.S.: bus error condition inputs wouldn't be bad either :-)

_________________
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?

It's more a matter for systems with an MMU. For example, a page may be mapped copy-on-write; the bus error input would be asserted to roll-back the instruction and cause the bus error exception handler to be branched to, which would then copy the page, update one of the page tables to point to the new page, and mark it writable in both process' address space. The processor then returns from the exception handler which restarts the instruction.

In the case of a pipelined architecture, errors cause the instruction, plus any in any lower pipeline stages, to be nullified (I.E. they will not cause any processor state changes) and emit a signal which indicates to the control unit that an exception has occurred. In the case of multiple stages firing exceptions simultaneously, the highest stage (I.E. first instruction in sequence) has priority.

_________________
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?

Does the 65816's ABORTB pin do this job? It says that the instruction completes but without any register updates, then the machine takes an interrupt. So the interrupt handler can fixup and restart the instruction.

I'm not sure how hard that is to implement but I see the timing on the 816 demands that it must be valid before the rising edge of phi2 - that must be a clue.

The nice thing about an FPGA implementation is that the memory decode can be on-chip and therefore more easily fast enough to respond within half a cycle.

Similarly, it seems to me that a memory interface on chip could handle niceties like prefetching and aligning (and sign extending), if necessary using RDY to hold up the core. It still has to handle reads of locations not yet written back, and handle uncacheable writes to peripherals, so it interacts with the memory decode, but maybe it's a distinct unit separate from the core.

edit: fixup sense of ABORTB and RDY

Relevant to the subject of incremental enhancements, a historical note:

The 6516 has been mentioned in a previous thread. It was never made, but was floated by Synertek as an enhanced 6502.

There's an article about it (from 1980) on page 36 in issue 23 of Micro
http://www.6502.org/documents/publications/micro/
and some reader comments on page 62 of issue 26.

On the subject of implementations: I have a fondness for the unreasonable idea of putting something 6502-like on a CPLD, but if you take a practical view and choose an FPGA, you'll find capacity is not a problem at all. They are all surface mount though, and the higher capacities are not in socket-friendly packages.

But it turns out that there are suppliers of DIP-mounted FPGA boards, which promise to make breadboardable design possible.

For example, OHO have a Spartan-3 XC3S200 plus 512kx8 SRAM on a small module 23,5x47mm with a 24 pin DIL plug. (EUR 70)

Also Enterpoint have a series of 100k gate or 500k gate FPGA on DIL28 to DIL40 with 5v tolerant I/Os (GBP40 to GBP60) and by way of illustration there's an 8088 replacement available on such a board.

So for pincount up to 40 there's a very usable way forward.

There's a whole set of interesting modules at Trenz

(All these happen to be UK or Germany, but I imagine similar things can be found elsewhere or these ones shipped.)