[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

mdj wrote:

Michael J. Mahon wrote:



I agree, and also doubt the real-world benefits of speeding them up
beyond, say, 20MHz.



Same. I also believe that every reasonable technique in terms of speed
up has already been done. The only reasonable thing we can do to better
that these days is build accelerators with bigger caches, or faster
clocks. Essentially reinventing already proven designs (be it Transwarp
style or Zipchip style). Any other tweak that has been mentioned very
likely breaks something else in the process, or stands very little
chance of producing a perceptible improvement when running real world
code.



It would be crazy to throw out the baby with the bathwater, just to
get the possibility of a 200MHz processor that no one could tell was
running that fast when actually using the system.



Again agree. But my motives aren't 200Mhz Apple II speed. For me the
Apple II is my playground, and I really like to make that playground
more fun, more replaceable. I'd like the cards I own that won't work
while my accelerator is installed to work. I'd like to be able to add
tomorrows clever and as yet unimagined add-on without adding yet
another FPGA on a card. And I'm tired of seeing good ideas go
unimplemented because the effort and cost involved is too high.

>
>

You can't speed up the Apple bus without obsoleting almost every
card ever made for it.  That is a non-starter.



I think, well hope, at this point that we've established that the Apple
II expansion bus is to be preserved in it's current state.


Great!  Sorry I misunderstood your objectives.  There was other
discussion in this thread that seemed willing, even eager, to discard
the Apple bus as "part of the problem".


You could, in principle, add a second, faster peripheral bus for future
expansion, but that would be expressing what I fear is an unreasonable
hope.



If an FPGA exists on the motherboard, the only 'expansion bus' that's
necessary is access to the left-over I/O pins of the FPGA - an easily
acheivable goal.


Exactly--I like it.


Flexibility for flexibility's sake is a fool's errand.  The Apple II
is already a marvelously flexible design.



I take objection to this remark. Flexibility for flexibilities sake,
when it comes at no additional cost, and very little extra effort is
well worth exploring. The Apple II is the exemplification of this; had
Woz not designed in more flexibility than anyone could have dreamed of
exploiting at the time, it would not be the enigma it continues to be
today.


I agree with you, and apologize for shooting from the hip without
even checking the color of your uniform.  ;-)

I have, unfortunately, seen too many cases where "flexibility" was
used to justify sloppy or incomplete design.  After our conversations
here, I certainly am not worried about that in the context of your
efforts.


For example, consider an Appleworks 3 user with a 500KB database or
spreadsheet.  Consider a die-hard developer assembling a large program
or compiling a big Pascal program.  Consider a game player trying to
get to level 9 of something.



Coming as someone who's compiled a big Pascal program or two, I'm
recalling now that the Pascal compiler used to print a dot to the
screen for each Pascal source line (or outputted p-code word, I don't
remember which). This more than anything probably contributes to the
slowness of the compiler in terms of how effective accelerators are,
combined with the amount of I/O that goes on, although ramdisks help
this a *lot*.


I hope the console I/O routines are not so bad that printing dots
every thousand or so machine instruction is a noticeable drag, but
I get your point.  An accelerator would just slow down for one bus
cycle to store the data to the video memory, so 1 microsecond times
the number of dots shouldn't be a big issue.

In my experience, a fast hard disk interface is about as fast
as a RAM disk--when running an 8MHz Zip Chip.  It's been quite
a while since I did any quantitative tests against, say, a CFFA.


Just illustrating a real-world use case for a faster machine, that
presents a pretty big challenge to an accelerator. Probably get more
speedup by hacking the compiler to shut it's mouth ;-)


Actually, a p-system compiler is the perfect vehicle for profiling
and inlining of critical sections...  Digitek used this technique
to produce the world's smallest *and* fastest compilers in the
1960's, then "became" MicroFocus, IIRC.  ;-)


In an unaccelerated Apple II, it's full potential is not achieved at
all. It's the 6502's fault. The faster CPU controlled (not DMA)
throughput is 1/(LDA+STA cycles) MegaBytes per second.
This figure is a pitiful (1/8)MBps, or 125 KiloBytes per second..


Yep, Zip Chips help!  Of course, that bus is running flat out while
achieving 125KB/sec, fetching instructions--which is why caching is
such a help.



In an accelerated Apple II, either the STA or the LDA come/go to fast
ram, and the other will require a single slow Apple II cycle, so it's
throughput skyrockets to 1MegaBytes per second.. !


Actually, only the loads go to fast RAM, the stores usually go to both
fast RAM and to the bus--you never know who's listening.  ;-)



Does not sound good enough ?


Sounds just fine to me!

Only hardware debuggers (like the ProDev DDT) eavesdrop on processor
reads on the bus, so they don't work in a cached design, but that's
a small price to pay for significant acceleration.


I think a 20-25MHz "Zip Chip" would be a wonderful thing.  DMA
compatibility is of marginal value with fast programmed I/O.



At the least, it restores compatibility with the devices that zip chips
and other accelerators break.


True, and that would be a good thing.


Reimplementing the Zip Chip in FPGA form would be a great idea. May as
well clock the thing as hard and as fast as the FPGA allows. May as
well put in as much caching as the FPGA allows. I'm convinced though,
that the glass ceiling will be hit miles before the theoretical speed
limit, and will very possibly be hit before the 20-25 Mhz mark.

>

That is of course in terms of software that exists NOW, which as far as
I'm concerned is all that matters. I can think countless things I could
write that would exploit a faster 6502, but not many (if any) that I
could be bothered writing. Can't think of anything that exists now
that'd be improved by any impressively percievable amount.


We are in complete agreement.  (Which is why I'm not interested in
new, wider implementations of the 65x02 architecture.)


But then, if you want to do it, just to hit the glass ceiling, perhaps
that in itself is a worthy goal.


Sure--everyone can have a go.  ;-)


However. Throw in the other requirement everyone seems to want: modern
display compatibility. Consider how the only existing card that does
this works, then consider the miserable failure it is. Can a design be
constructed that alleviates the Second Sights limitations? Perhaps.
It'll be hard going though, assuming a design goal is "don't break
anything". The Second Sight itself didn't achieve this goal by a long
shot in my book.


Exactly.  Creating a perfect emulation of an NTSC-scan RGB display (or
a similar emulation of a composite display) on a VGA monitor is a very
worthwhile objective, and should be quite achievable.

New graphics modes are of much less interest to me, but maybe someone
will write enough software that they become interesting...?


Getting something operational can happen relatively quickly, and adding
mind boggling performance enhancements down the track is relatively
easy. Nobody's end goals are compromised, and virtually no extension
that any of us can dream up is made difficult/impossible. It's a
win-win


Except that this approach throws out the many hundreds of existing
Apple II peripherals--bad trade.



No. I'm not proposing to make a faster physical bus. The design does
allow, for instance, the possibility of a CFFA style 'card' plugged
into the virtual bus, and operating at high speed. The physical bus
must preserve compatibility. period. A virtual bus on the other hand.

It's a flexible enough design that we can have our cake and eat it too.


Excellent!


So much for the "joy of the hunt"...  ;-)



I'm happy to kiss it goodbye, and besides if such a device deflates the
current market value of the rarer peripherals, so much the better as
far as I'm concerned. The might then end up back in the hands of Apple
II enthusiasts and not in the hands of collectors.


Yes, I was just joking (like "making lemonade out of lemons").  ;-)


Sounds like it.  And how is this different from a good emulator running
on a modern system?  It seems to have all the same limitations in terms
of driving Apple peripherals and cards.  And it is hard and not done,
while emulators and modern platforms are easy and done!


I see that I mistakenly attributed some of the thoughts of others in
this thread to you.  We are in agreement!


Not at all. Think of it as a 'fusion' between an Apple II motherboard
and a FPGA development kit. I really think that such a fusion is a
natural one, if we consider how approachable the Apple II is to the
home experimenter. Bringing the two together benefits the Apple II, and
*potentially* creates some interest in FPGA development.

Yes yes, it probably won't happen, but so what? It's a 'design' that
meets all the proposed goals, is relatively straightforward to
implement, at least compared to building an accelerator+VGA adapter on
a card, and opens up possibilities of creativity in a way that I feel
is a very natural blend of Apple II ethos and 2006 technology.


As noted in another response to you in this thread, I'm very much
in support of your goals as I now understand them.

This has been a very enjoyable exchange!

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