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

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

Jorge Chamorro Bieling wrote:

> Well, this preserves the whole thing, because when you remove the card,
> what remains is an entire fully functional Apple II.
>
> Then you can take the card with you and plug it into another Apple II.
>
> Also, a card is much easier to plug/remove than a zipchip.

you're right, it works very well as a concept. I maintain though, that
the implementation complexity of an accelerator+vga in this form factor
is both unnecessarily complex and actually much slower, compared to
just replacing the board.

Removing the existing board doesn't destroy it in any way, it'll still
work just fine. For me it's preferrable, as I can wack the replacement
board in another Apple IIe chassis, and my already expanded to the hilt
with original components IIe can stay exactly as it is now.


> > The Apple II is very much a 'concept', which expands far beyond just
> > the original motherboards made by Apple, into the expansion hardware
> > made by Apple and others, and into the software. To me, the Apple II is
> > not it's motherboard.
>
> 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*

> 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.
>
> We're are talking about running
> SEVERAL TENS OF TIMES FASTER THAN AN 8MHZ ZIPCHIP.

Yes, but if you plug into the Apple II bus, and remain compatible with
the majority of perphierals out there, how fast do you think you'll
get? Not fast in theoretical terms, fast in real world terms. Most of
your speedup relies on not having to write to the Apple II bus very
much. If you do that, you'll get a massive increase, that's for sure.
The onboard video won't work anymore, though (an unreasonable tradeoff
as far as I'm concerned). I remain unconvinced that it'll make any
appreciable difference, without writing new software to exploit it.

Look, I'm not saying it's an unworthy project, I'm quite convinced it
will work, and quite convinced you can appreciably outdo a zipchip. I
just feel that the implementation complexity is actually very high. It
would certainly give me 2 things I want; a replacement accelerator and
VGA video. If someone builds it and it works, heck, I'll buy one :-)
It's better than what I've got now.

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.

> > but I think it's a bit of a waste of what an FPGA can do.
>
> We may use a cheaper FPGA and save $ ...

Check out the prices of the FPGA's. Now look at the cost of having a
circuit board built. This for me is the biggest issue. Cost difference
between a FPGA based motherboard replacement and FPGA based card? Not a
lot.

> > > Redesigning the slot interface because it's slow, in favor of a faster
> > > one, is not an upgrade, is an, I don't know,
> > > maybe an evolution: "Apple II EVO 4".
> >
> > Not redesign, reimplement. The problem with using a slot to accelerate the
> > machine is that in doing so you break compatibility with a lot of
> > devices.
>
> If you're thinking of DMA devices, not necesarily.
> The slot connector in this card could cope with DMA.
> Only the other 6 slots on the MLB could not.
> But do you think DMA is a feature that many cards use ?
>
> The other thing that *may* not work is the video overlay card, unless
> the writes to video memory were writethrough.

Writes to video memory encompass $400-$7FF, $2000-$5FFF in both memory
banks. That's 36k of memory you can't accelerate writes to. Very
valuable real estate too, as these areas have nice bank switching
properties, so code tends to cluster around there.

> This could easily be a setup preference if the card booted to a small
> "BIOS" (for example by making it look like a disk II card, and plugging
> it to the right of the first disk II card).
>
> Anyway, it could boot into a "control panel" where you setup these
> things according to your needs, run diagnostics, cache peripheral ROMs,
> cache ROM space ROMs, configure, in short, how much "optimization" do
> you want, etc.
>
> > You could avoid much of this by using a slot, and the original processor
> > socket as well, like IIgs accelerators do. But as amazing a feat of
> > engineering these devices are, that only applies to 1980's engineering
> > possibilities. They carry with them a number of issues - break
> > compatibility, impose power issues upon the bus, have a aesthetically ugly
> > and unreliable 'umbilical cord' back into the motherboard.
>
> Discarded.
> Too difficult to setup.
> Plug in the card in a standard slot and go is much better, isn't it ?

It's conceptually good, but practically difficult, IMHO

> Here, when you say "existing hardware", you mean Apple II existing
> hardware, or USB, Ethernet, I2C ... ?

I mean real Apple II hardware, that works with the Apple II bus, plus
anything you care to dream up with the left over space on the FPGA

> I think that to make a Disk II run, the timing has to be correct, but
> also the events in the adress/data bus while executing an instruction
> have to happen exactly in the same order as a 6502 would do them.
>
> This may mean a lot of additional (design) work.

> > > Even though I agree, it may not be a good idea to try to design a new
> > > platform. There's a thin line that has to be drawn somewhere.
> >
> > Not a new platform, a modern recreation of an existing platform. I
> > agree there's a line that must be drawn, but in my mind, that line is
> > between what's feasible and what's not.
>
> But feasible is almost whatever.
> The point is how much to depart from what an Apple II really is.
> I'd like to make it only faster, but not different.
> Very different is a new platform.
> A small difference may be justified, but the less the better.

A worthy goal, to be sure, but one that will make not much difference
to real world application performance, assuming you maintain at least
current levels of compatibility in accelerator design.

> The bottlenecks is what we need to find and circumvent.

Indeed!

> The keyboard is one of the worse, but no too difficult to solve.
> The disk II can not be thought off as a bottleneck, because there's no
> way to read/write to a disk any faster.
> What remains ?
> The paddles, they can not be read any faster.
> As for the rest, they are not hit very often...
> Things like an IDE interface card, will surely benefit of accelerated
> speed without suffering timing issues.
> Remember, the limit is now close to 1MB/s, instead of the old 0.125
> MB/s..
>
> This deserves more study, though.

Yes. We need though, to study the tradeoff in terms of implementation
complexity versus net gain.

> Touché. The options are
>
> 1.- Embed the video generator in the card, or
> 2.- Write through to MLB video RAM addresses, or
> 3.- Both, make 2 a setup option.
>
> > You still need to write through the screen holes in the text
> > page.
>
> Are you sure ? Why ?

It's a potential use case, where an application sets up information for
an I/O card to consume. I can't think of an example at the moment.
Pretty much every peripheral card would require that these sections be
either readthrough or that the accelerator discard any cache lines from
this region after an I/O access. More study would be required to
determine the exact impact.

> > If this were software, I'd call this approach to the solution
> > intractable; the complexity is just too high.
>
> Maybe.
> 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.

Matt