Re: Apple II virtual enhanced

[Michael J. Mahon <mjmahon@aol.com>]

Riccardo <rigreco.grc@gmail.com> wrote:
> HI,
> 
> "Encode and decode data on the //c side", i think is not necessary if the
> data are handle in the same format of Apple II OS, for this reason i
> think that in the server side could be use an emulator program of Apple
> II OS for processing data. Emulator program that work at frequency of
> PC/Microcontoller system server.  
> 
> Thanks.

The problem isn't the speed of the attached PC, it's the pitifully low
bandwidth of the serial connection. 

Consider using the PC as an arithmetic coprocessor, with one 40-bit FP
number passed to the PC and one 40-bit result returned. 

Even if no "opcode" is passed, that's 80 bits transferred. If we assume the
maximum serial speed of 115kbits/sec, there will be ten bit times per 8
bits, for a total of 100 bit times. The time to communicate is almost 1
millisecond, rendering the time for the PC to compute the result almost
irrelevant. 

If you consider a "chunkier" operation, like running some code for an
emulated processor, the input argument is most of the 64KB address space,
and the result is similarly most of the address space.

Almost certainly, you would want to compress the address space transfers by
sending only the differences from the previous state--hence "encoding and
decoding" which must be performed on both ends of the communication. 

As the amount of computation on the PC increases--say, by computing until
I/O is needed--the configuration degenerates to an emulation running on the
PC using the Apple II as a terminal. 

The bandwidth of the serial port maxes out at 115,000 bits/second, while
the bandwidth (for processing) of the Apple peripheral bus is 8,000,000
bits/second--almost two orders of magnitude faster. 

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon