RISC on 8 bit mostly means: One cycle per instruction

[commodorejohn]

C16with64K wrote:

Apparently cardridges for video consoles could not keep up with the speed of CPUs and the 6502 in snes needed to be throttled down.

They could, it just cost more so not all games did it.

[RichTW]

Dr Jefyll wrote:

According to one line of reasoning (BigEd could provide the references for this) the 6502 was originally intended to have two accumulators. But they found this would've resulted in too large (and hence too expensive) a chip. So a brutally ruthless decision was made. The chip got very rudely downsized quite late in its development -- leaving some gaping holes in the opcode map.

That's an interesting theory I've never heard before. Ed, can you provide references for this?

[barrym95838]

By my rough count, there are about 75 opcodes in the NMOS map which use register A as a source, implied source, or destination. This seems to imply that it is at least plausible (if not practical) that a full-featured register B could have been added to the NMOS map ... and maybe even a tiny bit of room would have been left over for a few 'c02 enhancements like BRA, PHX, PLY, STZ ...

Maybe it would have been more practical to just add a simple XBA instruction ... lots of bang for the buck there ...

Mike B.

[BigEd]

I'd forgotten the reference which Jeff picked up, about the two accumulators, but with a little prompting I've found it, and quoted with permission over here:
viewtopic.php?p=58458#p58458

[White Flame]

I wonder if their 2-accumulator design had "A = A op B" style instructions. If not, then yeah a XBA would cover plenty. (And you might as well go for XAC, XAD, XAH, XAL ... )

[Dr Jefyll]

White Flame wrote:

I wonder if their 2-accumulator design had "A = A op B" style instructions.

Maybe, but that's a different theory than the one posed by Segher Boessenkool. "My strong suspicion is that originally the 6500 had *two* accumulators, and the instructions with low bits 11 were like those that now have 01, but for reg B instead of reg A."

White Flame wrote:

If not, then yeah a XBA would cover plenty. (And you might as well go for XAC, XAD, XAH, XAL ... )

Yup. And yup.

[Dr Jefyll]

Quote:

My strong suspicion is that originally the 6500 had *two* accumulators, and the instructions with low bits 11 were like those that now have 01, but for reg B instead of reg A.

For my own interest I started marking up the NMOS opcode map to get a sense of this. And I might as well share the result for any others who are also interested.

All the instructions in the "low bits 01" columns involve accumulator A (and I copied these into the "low bits11" columns). But a few instructions involving A are not in these columns. I marked these using a different color. It's not obvious what the corresponding B Accumulator opcodes would be, but things may've gotten juggled after the B Accumulator was deleted. Segher's theory remains plausible, I'd say.

[Aaendi]

C16with64K wrote:

DRAM refresh cycles are driven by the VIC-II in the C64. It's the basis for the arrangement. The CPU runs at half the speed of the memory in order to let memory access appear instantanous. This saves circuitry for arbitration. I still think it's a bad idea that the VIC can steal memory cycles from the CPU. For wide words a faster clock means better utilisation of the transistors doing the grunt work. But clock generation and distribution comes at some cost. Also some chips from MOS were prone to overheating. I am sure that a basically low clock rate allows lower supply voltage and higher resistance in the pull-up resistors keeping the current consumption low. If we would use the 6502 in an embedded application, it would be nice to add DRAM refresh. It may be that branches within a cached loop lead to pipeline stalls and a cycle where the 6502 does not access memory. This could be used for refresh. For this the refresh counter would be allowed to stay some ns behind schedule. Of course this means that there are is no cycle timed code. If one uses it for a woz-machine for example, the disk controller would have to generate the DRAM access.

If we could employ a large on-chip cache, bus width cost goes down (no more pins). Then use ARM. Apparently cardridges for video consoles could not keep up with the speed of CPUs and the 6502 in snes needed to be throttled down. They could have used an ARM with large on chip cache and try to eliminate some of their co-processors. It was 1991 after all. Amiga came out 1985.

The biggest problem with the SNES is that developers who were used to 68000 tried way too hard to force the 65816 to do 32-bit number crunching and long addressing.

[kakemoms]

C16with64K wrote:

And for RISC: I do not understand how you could read and write on the same bus in one cycle. We do not have enough die area for two busses. At most there could be two sets of registers each which their own bus. For example Akkumulator latches the output from ALU. Everything else is on bus. But then how could AX be used as source and target in every 8bit CPU? There need to be two and a bridge to toggle between them. Two busses do not seem that more complicated. This reduces code space.

I tried to make a small core with 6502-like instructions (Nano6502) that do all instructions in one cycle, except the first one.. I hope to extend it over time to be more 6502 or 65816-like, but it is prioritized on speed, so its a slow development.

Basically, I prefetch the data byte and have separate data and code space. Memory is also dual-port so it can be read and written to within the same cycle. The prefetch does happen a half cycle in advance, so its stricktly pipelining that, but its only visible on the first instruction after reset.

The nice thing about single cycle instructions is that zeropage becomes more like 256 registers...

Oh, and all data is fetched as 16 bits, so only two-byte instructions (at the moment). Hope to change that.

[Aaendi]

Would the index registers be 16-bit?

[kakemoms]

Aaendi wrote:

Would the index registers be 16-bit?

16-bit instructions, meaning 8-bits opcode + 8-bits data/address. But it can be whatever you need it to be, its fairly easy to build upon: viewtopic.php?f=10&t=4980