Arlet, looking at my notes I see that I was using the 'self-refresh' mode, which consumed a ridiculous amount of cycles. It would've made more sense to do a regular refresh during vertical blank, losing a few cycles here and there.

Thanks for the core! I wish I had it back then. The XESS vhdl core was a pain.

You have more patience here then I... I don't think this guy gets it (or wants to understand) about registers eating cycles and critical path delays slowing down the clock. Or using memory output without registers. Or instruction decoding, for that matter.

I've implemented a similar system to decode 6-bit instructions from 18-bit words years ago. Like I said before, if you happen to be using wider memory and have no choice, you have to do something like this. Knowing what I know today, if I had a meg of 32-bit ram, I'd sooner use the low 8 bits then mess around with this foolishness.

Thanks again.

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

Well, you do register it. Just in processed form. Which requires faster memory. But I suppose there are always tradeoffs to consider.

I already said they were registers. And they're loaded at the same time as IR (their values are not needed until the next instruction), so there's no penalty.

I explained all that before. Data could go via 'NOT request_instruction' and could arrive at the core as anything it chooses to be. Including directly.

Please do me and others the courtesy of reading what has been said and letting it sink in for a while before you react. I have to repeat myself endlessly, and I'm sure I'm not the only one annoyed by it.

I give up. Go ahead and show the code when you've implemented it.

_________________
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 a good point, Garth. But, honestly, for this thread I kind of dread the idea of any more explaining! I've gotten a little bit burned out. Maybe that's partly due to reliance on English, which isn't especially well suited to the topic. Short of actual HDL, what's the alternative? If there's to be any further explanation, maybe it'd be worth considering a graphical presentation of the pipeline -- something in the form of the (nonsense) diagram below

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Again. I won't do that until some core author, who actually gets it (and clearly my expectations were too high here), is cooperating. Since this 8-to-32-bit trick, if it works properly, benefits the 'community' (for lack of a better word) a.k.a. all existing cores, I refuse to do all the work.

How about this. The registers are : PWA, PW, IR. Rest self explanatory. 'Whatever' is whatever Arlet decodes and stores based on the opcode.

Oh, and PW and PWA are sometimes not updated, depending on what part of the 64 incoming bits is copied to IR. I.e. that is not shown here.

As a neutral observer: The issue is that you are the one who came up with an idea for improving things, thus if others don't see it that way it's you who will have to prove that it is so.
This is the standard approach for all kinds of science and research.

-Tor

I don't have to do anything, Tor. Let's start with that. I think this is an exciting idea, because it could speed up 6502 cores considerably, without much cost. But this is just hobby to me, so I could take or leave 'proving' it.

I didn't know we did science and research here. But, continuing with that rather lofty viewpoint, it is also standard approach to obtain cooperation from those more knowledgeable about some parts of the problem. The core needs to be changed. Since I'm not the one who knows it in detail, the author is, I am not the one to do core changes.

The burden of proof is always on the one who came up with the new idea. Particularly when others took a look at the idea and said it won't work. This is standard practice in every area of life.

-Tor

There's no need to repeat your viewpoint. I've read it. And you have my response.

HA! I can't believe the hubris. Let me paraphrase:

"Here is my great idea. I am smart. You are all too stupid to understand it. If one of you jerks agrees that they will use it sight unseen, 'all or nothing', I may actually create a demonstration. But don't get me wrong, I don't have to do anything here."

Amazingly, this genius has insulted everyone here, even those trying to defend him.

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

Proposal to end this thread.

Friends, this thread has become more then unproductive. Let's take the high road. It is obvious that even asking for clarification will evoke a string of insults; any criticism will be met with outright abuse; and anything short of bowing to the greatness of this idea and the genius of the creator, will not suffice.

Should we, the 'community', ever be in a situation requiring 8-bit fetches from 32-bit memory, I think it's pretty clear that a muxing approach, with registers for the remaining bytes, is simply the only way to do this. And if someone decides to build a prefetch circuit to accelerate a 6502 core, they will make one. We will come up with something that works without this kind of discourse. Arguing over a non-problem with a 'solution' described in terminology no one can possibly understand is just a waste of time.

32 bit is still 32 bit, 8 bit is 8 bit, and 32 is hardly the new 8.

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

Enso: better to leave a thread alone if you don't like it. Just stop responding and disable notifications.

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