Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers

[bieling@terra.es (Jorge Chamorro Bieling)]

mdj <mdj.mdj@gmail.com> wrote:

> 
> Wouldn't a general purpose cache unit inside the CPU achieve the same
> affect? Yet be better since it would also accelerate other areas of
> memory? a Store instruction could write to the cache in the same cycle,
> in theory. Heck, you could go 'all out' and implement an indirect
> lookup 'cache' to accelerate the indirect operations a cycle or two.
> All possible, all rather tricky.

But I'd like to be able to know *exactly* how many cycles does a certain
piece of code take to execute. You never know for sure when it's being
cached. I would be better to count on fixed, known and fast memory
cycles, this is the true Apple II style... isn't it ?

Also, caching is ok when the main memory is much slower than the cache
memory. In this case it does not necessarily have to be so. 

I'll try to scan tonight the schematic of my design of the "given one
address / give me the four consecutive bytes" block. Keep in mind that
this is not the same thing as a 32 bit bus. We can then estimate circuit
delays and see if it does make any sense or not. Please forgive me if
it's too badly messed up.

> I agree that this approach would result in fairly impressive
> performance increases, but I worry about just how much code this will
> break.

How much code does it break ? 
As much as a ZipChip.

How to avoid breaking code that depends on timing ?
It's unavoidable...

...sound ...disk II ...paddles ...etc

This code will have to be patched, or ran at 1Mhz.