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

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

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.

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

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

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

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 ;-)

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

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.

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

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.

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

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

> 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!

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.

Matt