Forked it
Guess I better go grab the plus from the loft now!
And make a new thread about it!!!
Forked it
Guess I better go grab the plus from the loft now!
You can also change the pinout of the Xilinx CPLD if you need. Just let me know what your final pinout is so I can make sure it'll fit in the CPLD with the pinout you're using.Forked it
Guess I better go grab the plus from the loft now!
@Zane Kaminski I agree JDW. As a fellow SpeedCard user I can't wait to see the 68000 come pretty close to SE/30 speeds, which was the Nirvana back in the day for the SE.Much better than the Levco SuperMac SpeedCard I am using right now, which has the sound problem and doesn't have a fix, and which has a more bothersome method to disable the accelerator.
Absolutely fantastic, Zane!
The really neat thing about the SpeedCard is the same for Zane's forthcoming accelerator — either can be disabled at cold boot, allowing you to use the SE with its stock 8MHz 68000 processor.@Zane Kaminski I agree JDW. As a fellow SpeedCard user I can't wait to see the 68000 come pretty close to SE/30 speeds, which was the Nirvana back in the day for the SE.
It’s probably possible that you could do a statistical analysis of the ROM to determine which percentage of instructions will touch RAM on the following access - loads, stores, operands in RAM (based on the addressing mode), etc. You could then tune a refresh strategy based on the likelihood of a ROM instruction causing a RAM access.So it would be better if we could come up with a condition that predicted with reasonable accuracy when, say, two back-to-back ROM accesses were going to occur.
The SWIM isn't a surprise - as internally the SWIM includes the new chip AND the old chip - there's just a crossbar switch to select the relevant one when needed. IWM exists inside the SWIM at all times.
SWIM Mode | Format | Blocks | Is TSS valid? | SD or DD? | Sides | Sectors | Tracks |
IWM | 400K GCR | 800 | Yes | SD | 1 | 10 | 80 |
IWM | 800K GCR | 1600 | Yes | SD | 2 | 10 | 80 |
ISM | 720K MFM | 1440 | Yes | SD | 2 | 9 | 80 |
ISM | 1440K MFM | 2880 | Yes | DD | 2 | 18 | 80 |
Thinking about this some more, you could also do dynamic adjustments to the refresh probability - every time you don’t opportunistically refresh but could have, you increase the refresh probability; every time you do opportunistically refresh and shouldn’t have, you decrease the probability. You could also move more aggressively in one direction than the other - for example, increase the probability by 1 if you could have refreshed but didn’t, decrease the probability by 2 if you do refresh and shouldn’t have.Or - you could cut out the analysis, implement a scheme where some percentage of ROM accesses cause an opportunistic RAM refresh, and then experimentally tune the percentage (for example, pick a denominator like 16 or 32, and then try different numerator values).
I'm afraid I am of no help here. I'm still not fully straight on the technical aspects of how vintage RAM refresh works. I only know the historical tidbits such as the SE being up to 15% faster than the older Mac Plus because the SE video circuits don't use as much processor time for RAM refresh. And on that note, the "Merlin and Mac" section of the following article about the Unitron512 is a rather interesting read...Any ideas? It can be dynamic to an extent, like the RAM controller could switch between two or three different refresh hiding strategies depending on whether the current one is working well.
Yes yes this is basically it. I guess this is called “global scoreboarding” in the context of CPU branch prediction. It almost works but it needs another idea before it’ll improve performance. The issue is that we need more than one speculative refresh strategy. Then we can choose which to apply based on success rate. Otherwise with just one strategy, if the RAM controller observes that speculative refresh isn’t working well, it’s just deferred until it becomes urgent and the performance impact is worse. So we need another strategy or two to switch to, and then we can track the success of each and switch dynamically.every time you don’t opportunistically refresh but could have, you increase the refresh probability; every time you do opportunistically refresh and shouldn’t have, you decrease the probability. You could also move more aggressively in one direction than the other - for example, increase the probability by 1 if you could have refreshed but didn’t, decrease the probability by 2 if you do refresh and shouldn’t have.