Re: Accelerator / VGA Graphics card

[mjmahon@aol.com (Michael J. Mahon)]

Sheldon Simms replied:

>On Fri, 24 Oct 2003 21:56:34 +0000, Michael J. Mahon wrote:
>
>> Sheldon Simms wrote:
>> 
>>>On Fri, 24 Oct 2003 14:59:39 -0400, Charlie wrote:
>> 
>> <snip>
>> 
>>>> 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.
>> 
>> Have you checked out how long the Pentium M requires to take an
>> interrupt and restore state and return?  I'll bet that caches are much
>> less helpful for this than you imagine, and _lots_ of cycles are needed.
>
>After reading this I poked around a bit in Intel documentation but
>they are not very forthcoming. However, considering the front side
>bus frequency of 400Mhz, and the fact that all code on the Pentium M
>would be running in supervisor mode (i.e. - no need to change protection
>level), I have a hard time believing that it couldn't handle a 1Mhz
>interrupt source. But perhaps I'm wrong. In that case other measures
>would be required.

Note that FSB speed only applies to burst transfers from RAM to and
from cache, and does not include the startup latency, which is probably
50-60ns.

I'm not saying that the processor can't handle interrupts at a 1MHz
rate, but I am saying that it may use a lot bigger fraction of the
processor's time than a first reading of the specs might suggest.

Today's high speed processors do their best work on the straightaway
and slow down mightily in the "curves".

>>>> 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.
>> 
>> And if you speed the processor execution up by a factor of, say,
>> 25x, then the time spent doing these low-speed things does not
>> accelerate, and the fraction of time doing low-speed things rises
>> proportionately.
>> 
>> For example, if a real Apple II running program X takes 10% of its
>> time doing things like disk I/O, then even if the processor is
>> accelerated infinitely, the program runs only 10x faster, since
>> all of its time is now spent on disk I/O.
>
>Of course, but few real Apple II running programs spend 10% of their
>time doing disk I/O. In fact, most Apple II programs amenable to
>acceleration don't do disk I/O at all except at occasional well-
>defined times (such as when the user saves a document).

But acceleration is almost irrelevant when using a keyboard-limited
program.  The only time that acceleration is really useful is when
you press Enter and a long compilation or other computation is
invoked--then acceleration really makes a difference in human
"wait time".  And it is not at all unusual for such long computations
to involve disk I/O--in fact, it's quite common, since 64KB/128KB
doesn't hold that much data to munch on.  ;-)  (Of course, if you
put all the data into Aux RAM or RAM disk, then that doesn't apply.)

>I don't deny that "slowing down" to do I/O puts a brake on the
>accelerator, but it does that for acclerators like the Zip GS or
>Transwarp GS as well. I expect the performance of this proposed card
>would greatly exceed the performance of previous accelerators
>regardless.

True.  Any emulation that supports access to real devices must
run at the real devices' speed.  I was just making the point that
the human "wait time" reduction for any accelerator is limited
by the use of real peripherals, so that the marginal value of 
increasing acceleration speed becomes less and less, beyond
some threshold.

I point this out only because some people seem to think
that it would be great to have a 50x-100x Apple II, when it
would be about as exciting as having a 64MB Apple compared
to a 16MB Apple.  These extreme extensions don't really allow
much more to be done than could be done at more modest speeds
and memory capacities, just because of the design point of most
Apple II software.

If you're into computing for speed, Apple II's are a terribly
inefficient way to get there.  ;-)

And if you're into computing for fun, Apple II's will get you
there at a very enjoyable speed.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/