[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:



Absolutely. But we don't want them to trash the a2 MLBs...
This way they need to have an Apple II to get the most out of this.



You do with my approach too. I only plan to implement IIe or II+
compatible keyboards. Of course the design may be extended to allow USB
keyboards, etc. and that's fine. I personally don't need them, but
someone might think it's cool.

There's not much point using one of these things without an Apple II
chassis. It'd be designed to run from the same power supply and bolt
down using the same mount points. Sure it'd work outside of it's
intended environment, but so do Apple II motherboards. One crazy nutter
once took eight of them, and assembled them together in a wooden cube
:-) Sacrilege!

*mdj ducks, swivels and runs for the hills, laughing, but wearing a
shirt with the words 'my tongue was in my cheek' emblazened across the
back*


LOL!  ;-)

(Crazy nutter, eyes wide and glistening, prowls about the countryside,
searching for innocent Apples to dismember and put in the rack... ;-)


I don't think that a zipchip@8Mhz is "close enough".
Here we are talking about 10..30 MIPS.
Keep in mind that a ZipChip slows down to 1MHz for every write, and
every time there's a cache miss. If you could avoid that happening, and
you can't because it's design, the best it could do *would be* between
1..4 MIPS. In fact it's much less than that, though.



You mention a few tricks you'd like to implement to keep speed up, for
instance bypassing the speed drop for keyboard polling. How, other than
implementing a keyboard decoder in the FPGA, and plugging the keyboard
into the card instead of the mainboard do you think this can be done ?
Then even if you do that, you've got increased complexity again since
PB0 and PB1 are the apple keys, and exist in three physical locations
in an Apple IIe.


Frankly, I can't think of a single case where keyboard polling
is done so frequently *during a computation* that taking a
microsecond to accomplish it would make much difference in speed.

If a keyboard poll takes 1 microsecond, and the fast processor
can do 100 cycles worth of work in that time, then even if the
processing loop only contains 100 cycles worth of work, the
processor is still 50% efficient in computing.

Does anyone know any real cases of applications that poll the
keyboard while doing useful work that is *not* animating a
display, making a sound, or just waiting for a keypress (all
of which require standard speed).



Anyway, if complexity translates just into more lines of hardware
description code, then this does not look like a big problem, isn't it ?



Actually, it does. complexity is complexity be it hardware or software.


Absolutely, and it is the ultimate limiter of what can be achieved.

-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."