Re: Apple II virtual enhanced

[BLuRry <brendan.robert@gmail.com>]

On Wednesday, January 9, 2013 3:02:00 AM UTC-6, Riccardo wrote:
> Hi guy,
> 
> 
> 
> Follow me, i think a more simple way, this is a possible procedure:
> 
> 
> 
> 1) Clone Apple IIc program (or a part of it) to the PC server emulator
> 
> 2) Run program on Apple IIc, this simple write a file with the input data in the vdisk.
> 
> 3) Server emulator process file data and put a new file with result on vdisk.
> 
> 4) Apple IIc read on the vdisk a file with result of process and continued your business.
> 
> 
> 
> A graphic example (draw a circle):
> 
> 1) Client send a block of data (center and ray) in a file on vdisk
> 
> 2) Server emulator draw a circle and bsave a image of HGR memory on vdisk
> 
> 3) Client bload the image and put on screen.
> 
> 
> 
> Thanks to all

It's funny you mention this.  Have you been looking at how Apple Game Server works?  Here's the overall process:

1) The computers are turned on, AGS is started on the PC and the Apple is set to accept input from the serial (typically: in#2)

2) AGS bootstrap begins.  Depending on the options selected, a small 7-byte program might be transferred to kick the serial port to 115.2k before the main "driver" program is sent.  If debug is activated, this is not performed and the serial port remains at is original speed.

3) If the non-debug bootstrap method is employed, each character sent by the PC is sent back to the PC.  This is used to validate that data is going through.  Otherwise, for debug cases AGS will send data a little slower to ensure that nothing is truncated.

4) The driver program is executed and its main loop begins.

----

The main loop of the driver is rather simple.  It polls the serial port for an instruction.  All instructions come from the PC, and the apple is really a dumb terminal.  The most frequent command is to poll the keyboard and return any active keypress if any.  If there is no active keypress then the PC-side waits a little and then polls again.

When a key is received, the apple game server UI code responds to the keypress in what ever way is appropriate.  The user interface is re-drawn in an image buffer on the PC side.  Then the image buffer is compared to the previous buffer, collecting a list of differences.  A pack-bytes algorithm is used to compress the differences into a much smaller stream of data.  This is sent to the apple side, and is decompressed on the fly.  It can be decompressed on the fly because the apple game server code has timing pauses to wait for decompression -- so data isn't sent until the apple is ready.  When this is all said and done, the page is switched (yes, AGS uses page flipping!)

When a user finally selects a program or game, it is sent to the memory of the apple (using a CRC check to ensure it doesn't get corrupted) and then a JMP is issued to start the program.  Disk games are more complicated, the RWTS of DOS 3.3 is replaced with a small serial driver.

It is possible, in fact openly encouraged, to take the apple game server code and replace the Game Selector application with a totally different application.  It isn't really much different than writing a very small Java swing application.  There are primitives for drawing boxes, borders, text and graphics.  All graphics are scaled and dithered automatically for you so the user interface code is rather clean and uncomplicated.

For example, writing a simple text editor is rather trivial.  The game search widget already defines text entry boxes, so if you extend those to multiple rows, you have a text editor.  :-)

The best part is that the drawing portion is separate from the user interface and application side.  So the user can select a text-based experience if desired.  Features that don't translate (like drawing pictures) fail gracefully as needed (drawing an image on a text screen simply does nothing)

If you want to ensure that you get the best color accuracy, it is a good idea to use colors that are as close to the Apple hi-res palette as possible.

I have not implemented a DHGR version of the program, but I do have DHGR conversion routines defined as well -- so it probably wouldn't be too difficult to implement.

-B