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

["mdj" <mdj.mdj@gmail.com>]

Jorge Chamorro Bieling wrote:

> It could be that only the first, "main" zero page was inside the
> processor, and the (seldom used ?) remaining zero pages (those in
> extended memory cards) mapped to regular ram, and these would take an
> additional memory cycle ?

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.

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

> Conceptually, I believe it is better to think of two separate blocks:
>
> -a "processor"
> -a "memory management unit"
>
> The processor has a custom bus design, not necessarily close nor similar
> to the 6502 bus. The bus needs to have whatever signals are required to
> co-laborate efficiently with the MMU.
>
> The MMU is the block that manages to interface properly and in sync with
> the (fast) RAM, the (Apple II) ROM, the (Apple II) I/O space, the slow
> (Apple II) RAM writes, etc:
>
> -Given a RAM read request, fetch 4 consecutive bytes from memory in a
> single cycle and present them to the processor bus.
> -Given a $C000..$cfff read/write request, sinchronyze to the Apple II
> bus.
> -Given a RAM write request, determine whether it has to write trhough to
> Apple II onboard ram.
> -Etc.
>
> The MMU design may probe to be nearly as complicated as the processor.
>
> In the end, I think, the memory address bus can be thought of as 16 bits
> wide plus some more address bits that reflect the settings of the
> extended/language memory bank softswitches.
>
> >
> > > 2.- The same goes for the stack. Can it be a set of 256 registers ?
> > > PHA would take 1 cycle instead of 2.
> >
> > Ditto the stack...
>
> Could the stack be made 16bits deep? I've been thinking about it lately,
> and I'm not sure. The question is that *maybe* the S register could be
> seen as 8 bits (the lsb 8 bits of a 16bit S register) by the 6502 code
> (so as to remain compatible with existing code), but be in fact a 16bit
> register, so that when you PHA beyond the 256th byte, even though the S
> register "rolls", in fact you'll get back the correct data when you PLA
> back. The problem here arises when the stack is manipulated "by hand",
> not by PHA/PLA. Well, this is something to think about. If such a thing
> can be done, it should.

I think for the most part, it would work, but be of limited utility as
you break compatibility with other 6502 systems. It'd be better to
implement the 65802 or 65816 in that case and use it's superior stack
handling abilities.

> I believe that USB is more a software problem than a hardware problem.
> The same goes for ethernet.

Once you've got a 300k gate on your hands, things change. Sure,
software is an issue, but there are better options with that many gates
lying around. For example, you can drop a simple RISC core in the FPGA
and drop things like TCP/IP and USB HCI stacks from open source
projects straight in, then all you have to worry about is presenting an
Apple II 'interface' to the thing. Implementing support for USB memory
sticks, mice, and even keyboards wouldn't be that hard.

I'd like to take the idea to extend that the RISC core can become a
'monitor' for the Apple II, allowing switching of IO slots, even funky
things like virtualisation of 5.25" disk drives, etc. Kind of an Apple
IIgs Control Panel on Steroids.

There might not be enough room on the Spartan 300K FPGA for all this
functionality, but if you were going to the trouble of producing a
board, you'd pick the biggest FPGA that was economically feasible just
in case.

> But remember. This is year 2006. 30 years later. Only 16MHz ? Come on !
> ZIPCHIPS ran at 8Mhz 20 years ago !. We should do it better...

There would be a pretty massive performance gap between an 8Mhz Zip
Chipped Apple II and a clone running 'natively' at 16Mhz, but yes, I
agree that far faster is possible, I'm just pointing out that achieving
16Mhz would make me happy enough to invest in such a thing.

I've been meaning to get my hands on a dev kit for a while and have a
play with some of the ideas I've had. Perhaps once winter hits and I
feel like spending more time indoors.

Matt