[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers
mdj wrote:
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.
This is the correct approach--much simpler verification than all
the special casing that arises with "register memory".
I agree that this approach would result in fairly impressive
performance increases, but I worry about just how much code this will
break.
Exactly. What is the objective?
<snip>
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.
And look at all the great software that runs on those platforms... ;-(
Again--objective?
I believe that USB is more a software problem than a hardware problem.
The same goes for ethernet.
Right.
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.
In fact, if you drop in a RISC core, you could implement the entire
Apple II as a straightforward emulation on it, at very high speed.
Put another way, if you're emulating all the peripherals, why not
just emulate the system itself? Exactly what "authenticity" of
implementation or experience is being preserved?
With a little specialization of the RISC core, you could go at
*ludicrous* speed. ;-)
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.
300K is plenty of room and then some.
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...
Right! It's important to me to have my 2000-line assemblies done
before I can get my finger off the RETURN key... ;-)
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.
Now, playing with emulating an Apple II to learn FPGA's and digital
design is a *great* motivation.
But what are you guys doing with your Apple II's that causes you to
get bored waiting for it to finish, anyway?
-michael
Music synthesis for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."