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



mdj <mdj.mdj@xxxxxxxxx> wrote:

Jorge Chamorro Bieling wrote:

How much an Apple II would it be if there was no real Apple II at all ?
The Apple II as a concept ?

In essence, yes, although the same holds true of the accelerator card
concept. The Apple II aint much more than a 6502, expansion plane and a
video generator at the end of the day, and what you're proposing only
preserves the 'original' expansion plane :-)

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.

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.

Don't you think you should "forgive" all the poor old Apple IIs in the
world their slowness, and do the the best that you can to circumvent it,
instead of trashing their MLBs in the first place ?

I believe there's still plenty of room to speed them up a lot.

I think the already available accelerators get pretty close to 'close
enough' in terms of speeding up the Apple II. If all you achieve is
replacing these with a more accessible part, that's a worthy goal,

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.

but I think it's a bit of a waste of what an FPGA can do.

We may use a cheaper FPGA and save $ ...

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.

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 ?

The umbilical approach was the most effective solution back then, but
don't you think, had it been more economically feasibel for AE or Zip
Technologies to replace the entire board, avoid all the compatibility
issues and produce a far superior product for less money, then that's
exactly what they would've done?

I have no desire to make a 'better' Apple II compatible bus, with the
exception of making it more compatible with existing hardware than can
be achieved by retaining the existing physical implementation.

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

Isn't it better to speed it up as much as possible, but trash as little
as possible in the process ?

Yes!

The disk II interface looks to me like the most important thing that
should not be trashed in the process.
It's at the same time the hardest problem.

It's the most difficult thing to virtualise, that's for sure. In terms
of not trashing it, all you need is a compatible slot for a disk II
controller, which I intend to keep.

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.

The slot interface is not too bad, not very limiting.
I would not like to trash it.
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..

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

Does not sound good enough ?

In practice (remember, there are already accelerators out there) this
doesn't happen. There is simply too much interaction with the original
I/O subsystems to get anywhere near this speed.

The bottlenecks is what we need to find and circumvent.

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.

In practice, you have to write back to the bus a lot more data than you
think. You can't, for instance, not write back data changes to
$2000-$3FFF because graphics mode is disabled. You can't tell in
advance that the application wasn't pre-rendering. Ok, so you're
replacing the video output controller as well, that solves that
problem.

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 works, but any device that 'sniffs' information about the
video buffer off the bus is now rendered inoperable.

The video overlay card...
And someones's VGA *project*...

Once you've shifted enough of the Apple II's functionality onto your
card to achieve your performance goals, you're left with the mainboard
being nothing more than 6 expansion connectors and a keyboard decoder.
Talk about a butcher job ;-)

Yes. You're right.
But when you remove the card,
what remains is a fully operative Apple II.

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 ?

Yes, in a sense, we are all wasting our time.

Mais non! We're stimulating our sense of creativity within a field
we're all obviously passionate about, and posing ourselves interesting
and intricate intellectual challenges. The only was this exercise could
be improved is to convert our internet connected PC's to pedal power
;-)

And thinking is free :-)
--
Jorge Chamorro Bieling
.



Relevant Pages

  • Re: A 21st Century Apple II?
    ... If the Second Sight card is any indication, ... to plug them into a real Apple II. ... For some people an emulator is fine. ... reason that similar changes could not be made with an FPGA version. ...
    (comp.sys.apple2)
  • Re: An FPGA card for Apple: ideas
    ... 1)have video IN/OUT connectors on the card. ... between displaying Apple II NTSC or NBIIAII specific video (so a NES ...
    (comp.sys.apple2)
  • Re: RFC : SOME IDEAS FOR THE APPLE II FPGAers
    ... Then you can take the card with you and plug it into another Apple II. ... just feel that the implementation complexity is actually very high. ... current levels of compatibility in accelerator design. ...
    (comp.sys.apple2)
  • More Network from Heck rambles
    ... Well it had been a while since I had tinkered with an Apple II. ... Uthernet card that was being discussed. ... downloaded the goodies to a Macbook pro which has no floppy drive. ... Would one of you guys PLEASE invent a USB port for the Apple II? ...
    (comp.sys.apple2)
  • Re: Another idea for outputting to VGA/DVI/HDMI
    ... best would be a second-sight style card using more modern components. ... all Apple II graphics modes. ... as it works by simply pulling bytes out of video ... available on the board to interface with the Apple bus to do the job. ...
    (comp.sys.apple2)