Dear 6502 core writers .

Say, you can do 32-bit wide memory accesses. Why not exploit this in the core ? Gets rid of all those pesky byte-wide instruction fetches. Instant speedup. E.g. simply replace every opcode fetch with a 32-bit memory read. Combine result with leftover bytes from any previous read (shift register ? swap between two 32-bit registers and multiplex ?). Voila, opcode fetches have become instruction fetches. Argument bytes instantly available. E.g. LDA abs reduces from 'opcode fetch, low byte fetch, high byte fetch, access' to 'instruction fetch, access'.

Who's first ?

Do it! And then prove it in a real world system. Make your own board,etc. We all welcome this. See if it is so easy as you think...

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Well, one of my own designs uses MichaelM's 65C02 core. I could probably adapt it. But I'd rather the author did it. It's only common sense.

The implementation of the idea is actually quite 'orthogonal' to most core designs I've seen, and relatively simple, compared to what else goes on in there. Maybe if you'd think about it a little first, you'd realize that.

Wow. It must be Grumpy Gus day.

Please do not inject emotion into this area... We all desire knowledge and look down on emotional BS

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

OK, windfall's idea is to use 32-bit memory. Fetch 32 bits into a 4-byte buffer, then use it as a cache. However, the problems I see are
- Why are you using 32-bit memory with an 8 or 16-bit processor anyway?
- First read will cost a cycle (with SRAM), unless a bypass of some kind is implemented.
- Subsequent reads will not be aligned, requiring a delay to read more if instruction does not fit.
- The complexity of this prefetch circuit greatly overshadows any benefit. It is likely to slow down the fetching, not accelerate it.

What exactly are you trying to gain here? For classic 6502 emulation, cycle accuracy is needed, obviating any need for this kind of buffering. For fast 6502 cores - well, are there any cores that run faster than byte SRAM? 100MHz is pretty much the limit with homemade FPGA cores, 10ns SRAM is plentiful.

Edit: if you are unlucky enough to use a devboard with 32-bit drams, throw it away and get one with SRAM. A DRAM controller is a horrible thing, often as big as a 6502 core itself. DRAM refresh will often delay reads by tens of cycles. Fetching 32 bits is the least of your problems.

So without being grumpy - bad idea (for 6502-related cores anyway) as it fails to solve a problem that does not exist in the first place.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

It would be very challenging to rewrite the classic 6502 core so it would use less cycles for the same instructions. That much effort would be better spent on a 16 or 32 bit processor to start with. Take the (ind), Y modes for instance. After fetching the opcode+operand you still need to fetch 2 zero page bytes, and the actual data.

Another option, which would be easier to implement, is to use a cache inside the FPGA. This cache could have an 8 bit interface to the 6502 core, but a 16 or 32 bit interface to external memory, reducing the amount of memory cycles it would take to read/write a cache line. This would work nicely in combination with SDRAM, and video access. It would increase memory bandwidth, but without complicating the 6502 core itself.

Thanks to Windfall anyway, I for one like the speculation threads that pop up now and then, even when an idea may be impractical - there's always some interesting discussions around as to why, and other ideas are spawned. And as I was reading this thread I got some ideas for my own emulators, not directly related, but when something wakes the mind up it starts churning. Ideas generate other ideas, even distant ones.

-Tor

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

So don't start it, by responding with 'do it yourself' instead of getting into the technical discussion.

That's nonsense.

The idea is about exploiting wider memories on a standard 6502, not extending the 6502 internals to 32 bit.