Re: Accelerator / VGA Graphics card

[Sheldon Simms <sheldonsimms@yahoo.com>]

On Fri, 24 Oct 2003 14:59:39 -0400, Charlie wrote:

> "Sheldon Simms" <sheldonsimms@yahoo.com> wrote in message
> pan.2003.10.24.13.26.01.77231@yahoo.com">news:pan.2003.10.24.13.26.01.77231@yahoo.com...
>> On Fri, 24 Oct 2003 00:06:54 -0400, Charlie wrote:
> 
>> >> > Would all Apple II memory be maintained on both the card and the
>> >> > Apple?
>> >>
>> >> The memory on the card would be the "real" memory. The main reason for
>> >> that is speed. There's no point in crippling the card's CPU by
>> >> requiring it to spend 90% of it's time waiting for the "old" Apple II
>> >> memory.
>> >
>> > Makes sense, but wouldn't you still have to transfer the data from the
>> > card memory to the Apple memory and vice-versa.   Although, on second
>> > thought this would probably only have to be done during I/O.
>>
>> There's actually no need to use the "Apple" memory at all,
>> although DMA could be a problem there.
> 
> Yeah, the more I thought about it the less I could see a use for the
> Apple RAM. Then you brought up DMA, which I had completely forgotten
> about.  Could the card just "direct" the DMA to the RAM on the card by
> watching pin 22 (DMA) and having the emulator "spin its wheels" until
> the DMA is completed?

Not really, because there would be no direct connection between
the on-card RAM and the Apple II bus. The on-card RAM would be
64-bit wide DDR SDRAM. The only direct access to it would be
through the memory controller on the CPU/northbridge.

The idea of having the card watch the DMA line is good, and the
card could provide the data from it's own memory under control
of the emulation program. DMA writes wouldn't be a problem.
The DMA busmaster would put the data on the bus and the "old"
Apple II memory would store it. The accelerator card would just
listen in on the transaction and store the data too.

DMA reads would be problematic, because the contents of the "old"
Apple II memory would almost certainly be outdated. When a DMA-
capable device tries to do a DMA read, the Apple II memory would
try to give it the data. But that would be wrong, because the
real data is in the card's memory. So the card would have to
be able to prevent the "old" memory from responding so that it
could respond itself.

The INH* signal seems tailor-made for this but apparently it only
works for the first 64K on the IIgs. (IIGS TN#32). I don't have
a IIgs hardware ref at the moment so I don't know what other
possibilites there are. I can think of some really ugly
potential solutions, but I'd rather hear from someone with
more knowledge of this sort of thing (especially w.r.t. Apple II)
before I propose anything.

In any case, once the "old" memory is out of the way, DMA
reads can be handled by the card in the same way it does any
writes to the bus. (as below).
 
>> >> > How do you handle Apple software that relies on precise timing
>> >> > such as disk I/O?
>> >>
>> >> The same way that traditional Apple II accelerators do - by slowing
>> >> down for a while after accessing timing-sensitive devices. How this
>> >> slowing down would be accomplished is yet to be determined. It may
>> >> be possible to do it completely in software, or it may require some
>> >> hardware assistance.
>> >
>> > I'm thinking that doing it by just slowing down might be tricky.  A
>> > traditional Apple II accelerator doesn't have an emulator to deal
>> > with so slowing it down works, but an emulator would have to maintain
>> > the exact ratio of time needed per instruction as a real 65816.
>> > Otherwise you couldn't guarantee that a particular code loop would
>> > run at the correct speed when the processor was slowed down to 1MHz.
>>
>> It isn't required that the card's processor be slowed to 1Mhz. It would
>> just have to drive the Apple II's bus at the correct speed. It would
>> probably be necessary to emulate every cycle of the 65816 execution. In
>> other words, this "slowing down" might actually be nothing more than
>> the emulation code executing a 65816 instruction and then waiting
>> around for each tick of the 1Mhz clock and writing the appropriate bits
>> to the Apple II's bus. This could be done mostly in software, but it
>> might require the 1Mhz clock to trigger interrupts on the card.
> 
> That makes sense and I like the idea of the 1MHz clock generating an
> interrupt on the card.  Wouldn't this free up the emulator to do other
> things (graphics) in between interrupts?

Well yes, but it would probably do everything it needs to do and then
still be waiting around.

> And even if there was nothing to do, from the little I've read about
> the Efficeon chip it drastically reduces its power consumption when
> it idles.

So does the Pentium M. This sort of idling won't save too much power
though, because it wouldn't happen except when the card needed to
access the bus -- disk, DOC, flipping soft switches, etc. And
most programs spend only a small amount of time doing that stuff.

> Anyway, it seems like you've put a lot of thought into this project. 
> You are slowly making me believe that it is doable (although the cost
> still seems to be an unknown).

Ha Ha! All of my thinking has been on the fly. I haven't actually sat
down to think about this at all.

> Assuming that a working design is
> created, is it your intention to actually produce complete cards or just
> plans on how to do it?  Maybe, something in between?

The only reasonable thing to do would be make complete cards. The
card will be too complex for people (well, most people anyway) to
build at home. Assuming the developers work gratis, the only costs
are parts and manufacturing. If we could get enough committed buyers
then the money for that would be there. I don't know what "enough"
means right now, though. Obviously it depends on the price of the
card.

Maybe it would be possible to collect provisional commitments
like "I am willing to pay $X for this card", where X is dollar amount
chosen by the person making the commitment. There would be no
restrictions, but each person should say what they are *really*
willing to pay and not try to lowball. Then it would be possible
to plot a curve showing how many people were willing to buy the card
at what price, which would help drive design decisions. If the
provisional demand is enough to cover manufacturing costs, then
the provisional committers would have to put the money in escrow.
If the escrowed money suffices (i.e. - if people don't back out on
their provisional commitments) then the arrangements would be made
for manufacturing and the money released from escrow for the purpose
of paying the manufacturer and shipping the cards.

Obviously this would need to be a completely open and auditable
process so that everyone involved can be sure that no one is
skimming.

-Sheldon