When was the last new programming language environment brought to the 
Apple II?

I have no idea - until now.  Today, VM02, the Java-ish VM for the Apple 
II arrives at Alpha.  Things are looking good and its time for others to 
start playing with it.  From the README:



README for VM02, the Apple II Java Virtual Machine
==================================================

Intro:
------
Having a Java VM running on a stock 64K Apple II is the eventual goal.
There are many technical difficulties in getting a complete JVM working,
so I have made some concessions to the platform.  Some limitation are:

  - no 64 bit data types
  - small evaluation stack (uses 6502 hardware stack)
  - max of 256 local variables per method
  - max string length of 255, 8 bit characters (no unicode strings)
  - small memory size - it is a 64K, 8 bit, 1 MHz computer after all
  - limited classes

However, in order to make this a useful environment there are many
supported features:

  - Java class file format
  - pre-emptive multi-threading (default to 4 threads max)
  - floating point (single precision only)
  - multi-dimensional arrays (up to 15 dimensions)
  - exceptions
  - dynamic memory for garbage collection/compaction
  - Apple II specific support (graphics, sound, game controllers)

The VM runs as a ProDOS SYSTEM program.  The file hierarchy puts all
the standard Java class file in the JAVA/ directory.  No .jar packages
are supported, so they are simply the class files placed in the
directory specified by the package name.  Note that many of the
standard Java classes are either missing entirely or missing some
methods.  This is due to the large amount of system classes and/or the
memory constraints to fully implementing them.

Apple and vm02 specific classes are in the APPLE2/ directory.

  TODO: Swappable memory is implemented through a handle based memory
manager.  When RAM runs out, memory block can be written to disk under
the SWAP/ directory.  This swap directory can and should be placed on
the highest performance ProDOS volume.  RAMdisks, harddisks, and CF
disks would be best.


Purpose:
--------
You may ask the question: Why Java for the Apple II?  Well, the idea is
not so much to port existing Java code to the Apple II, although small
programs should port easily, but to bring a modern software environment
to the Apple II.  In the early days of the Apple II, Bill Atkinson
brought the USCD Pascal system to the Apple II and supplemented it with
Apple II features.  Pascal was the educational language of choice and a
good match for the computers of the time.  It was a powerful
environment with editor, assemblers, compilers, and other tools for
software development.  Fast forward 30 years, and Java is the
mainstream educational language.  It is also heavily used in the IT
field.  Perhaps not the perfect match for the Apple II, as it has some
interesting features that make it a challenge to implement on older
hardware.  Java was designed using UCSD Pascal as a historical
foundation and building somewhat more modern paradigms into the
language and VM.  Object orientation, multi-threading, exceptions and
compactness are core to the Java environment.  Bringing these concepts
to the Apple II allows a newer generation of programmer, who is
comfortable with Java, access to our favorite computer.  Combining the
Apple II's simple-to-program hardware features and Java's rich software
environment in an easy and relatively high performance manner is the
fundamental goal of this project.


Java-ishness on the Apple II:
-----------------------------
I say that because vm02 is not a Java VM.  In order to fit in ~20K of
6502 machine code, many requirements of Java were left out.  All the
error checking and verification implemented by a Java VM have been
greatly simplified or left out entirely.  There are probably many
features of the Java language that I didn't implement quite the same
way as Sun's JVM.  Oddly enough, vm02 has about the same startup time
on a 1 MHz 8 bit computer as Sun's JVM on a 1 GHz PowerPC.  In
combination with ProDOS, vm02 on the Apple II provide for a very
compete OS.  The Apple II is a single tasking computer, but vm02
supports pre-emptive multi-threading without any additional hardware.
Time can either be estimated by vm02, or a hardware time base (such as
a mouse card) can provide a consistent real-time base.  ProDOS supports
many storage devices.  One of my favorites being the CFFA (Compact
Flash For Apple), which provides a great deal of high speed, low power
storage.  A perfect match for the Apple II.  The first release of vm02
will only use 64K; in the future, 128K Apple IIe's and IIc's will have
their additional memory used to allow larger programs and more data.  A
more sophisticated memory manager with support for swapping to disk
will also be implemented to allow for bigger programs than will fit in
physical memory.

To allow access to the great hardware features of the Apple II, a few
classes are provided that give Java programs direct control of the
hardware.  Java wasn't designed for such low-level hardware control,
but a few Apple II specific classes can supply game paddle input, hires
graphics, sound, and support any hardware installed in the system.
Memory management is handled by vm02, but in this case, a rogue program
can read and write to any memory it chooses.  No hardware or system
support exists for keeping a program safe from trashing memory with the
provided tools.  One of the benefits of running close to the iron.


Development Environment:
------------------------
There are no native Java compilers running on the Apple II (yet).  You
will need a computer capable of running a Java compiler and
transferring the class file binary to a ProDOS volume (emulated or
physical).  If you want to use the Apple specific classes, you will
need them in your build directory.  You can use the binaries used on
the Apple II but you will need to rename them - i.e. rename
APPLESTUFF.BIN to AppleStuff.class.

If you want to write classes with native methods you will need the
tools I provide to convert a class binary to an assembly source file.
First, build a stub class in Java with the fields and methods defined.
The methods can either be fully implemented if you want to mix and
match native methods, or empty if you will be writing them in 6502
assembly.  Compile the Java class to a binary class file.  Run the
class2asm tool to output an assembly listing of the class binary.  The
first parameter to class2asm defines the assembly format.  'p' creates
a ProDOS (Merlin) formatted output for import to an Apple II
environment to edit and assembly.  'c' outputs assembly for use by the
cc65 build suite, useful for cross-build environments.  Look to my
sample classes to see an example.  Once the assembly file is generated,
some initial editing is required to create some constants to define the
native methods.  First, add a '6502' string to the constant pool.
Easiest is to copy the 'Code' string and place it at the end of the
constant pool definition.  Add one to the constant pool count field.
For every native method, you will change the access flags to indicate
native.  OR a value of 0x0100 to the method access flag.  If the access
flag is originally 0x0009, then it would become 0x0109.  Next, change
the attribute name index to point to the '6502' string instead of the
'Code' string.  The is the attribute name the class loader looks for
when loading native methods.


Native Method Implementation:
-----------------------------
The above section describes how to write a native method.  The
environment the native methods run in is described here.  Due to the
dynamic memory of vm02, address location is never know, or even
consistent between method invocations.  Methods must be written using
position independence.  This means no absolute jumps internal to the
method.  Only relative branches.  There are 16 zero page locations
reserved for native method invocations, $A0-$AF.  The A and X registers
contain the location of the method in memory for this invocation.  One
can save these values in zero page and reference them to access data
stored in the method itself.  Data saved in the method is persistent.
Parameter data is passed on the 6502 HW stack.  As such, you must pop
off the return address, save it, then pop off the parameters.
Parameters take 4 bytes each.  Any return value must be pushed before
the return address is pushed.  RTS will return to the calling object.
Again, look to the AppleStuff.s file to see how much of this is
implemented.

Understand that native methods are meant to implement very small,
machine specific functions that are hard to do in Java bytecode.  They
are not meant for complicated methods.  If you find the method getting
too complicated, then re-factor the method using bytecode for the logic
and small native methods to do the dirty work.  Bytecode is quite fast
and compact.  It also gives the VM flexibility in unloading and
reloading the methods when memory gets sparse.

There is rarely a need to write native methods as most things can be
done within Java and using the vm02 class.  The vm02 class implements
low-level memory access and 6502 routine calls.  There is an interface
directly to the VM as well as ROM routines.


Alpha Release 1
------------------
This release implements the final Java language support features in the
VM.  Additional classes/methods will be added as they are written and
debugged through the final Beta.  The VM itself is only getting bug
fixes until release.  Additional functionality will come after the
final release, i.e. swappable memory, 128K support, and such.


Dave Schmenk...


Disk image:
http://schmenk.is-a-geek.com/tarfiles/vm02alpha1.dsk.zip

Source tree:
http://schmenk.is-a-geek.com/tarfiles/vm02.alpha1.src.zip
--- SBBSecho 2.12-Win32