Re: Accelerator / VGA Graphics card

["Charlie" <charlied@NOSPAMbboard.com>]

"Sheldon Simms" <sheldonsimms@yahoo.com> wrote in message
pan.2003.10.24.00.40.02.728516@yahoo.com">news:pan.2003.10.24.00.40.02.728516@yahoo.com...
> On Thu, 23 Oct 2003 17:14:36 -0400, Charlie wrote:

> > I looked at their website and the Efficeon does seem to be a better choice
> > although they are vague about the actual power usage.  The most I could
find is
> > that it uses under 7 Watts.
>
> I couldn't even find that. Do you have a URL for that?

http://investor.transmeta.com/news/20031014-119979.cfm

Here is the relavent quote from that page:

" the Efficeon processor family will be competitive with, or outperform
competing microprocessors operating within critical thermal limits such as the
7W limit for typical fanless notebook designs "

> > Yes, I believe that writing the software is the first thing you should
> > do, assuming that some type of hardware is truly feasible.  I realize
> > that this is sort of a "chicken or egg" thing.
>
> It is somewhat. Ideally development work on both would proceed
> at the same time, but the software may well take longer than the
> hardware anyway, so it might be good to get started on that first.
>
> But before I do that, I'd like there to be at least one person
> provisionally committed to do some hardware work. Ideally that
> would be someone who already has access to board design software.

I can understand that.  It seems like quite a project.

> > Would the processor on the card be running in place of the 6502/65816
> > or would both be running?
>
> It would replace the 6502/65816.

OK.

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

> > 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 (if that's even possible).

Charlie