VM02 SourceForge project
David Schmenk
access, send me an email with your sourceforge account name. I have the
same username at sourceforge.net. I'll be migrating the code over in
the next few days,
Dave...
Bill Garber
"David Schmenk" <dsch...@YUCH.gmail.com> wrote in
message news:XoAzk.438$Ws1...@nlpi064.nbdc.sbc.com...
Regular abusers, I mean users, can download the files
without a special access card though, right? ;-)
I mean, I am in no way shape or form ready to help
with the developement, yet.
Bill Garber from GS-Electronics
http://www.garberstreet.com
"If you wish to forget anything on the spot,
make a note that this thing is to be remembered."
(Edgar Allen Poe)
David Schmenk
Exactly. Anonymous CVS access is available. I'm sure there will be
releases including DSK images, SHK images, and source tarballs. Some of
the best way to help with development is to just try it out and report
back how things work (good and bad). If you haven't used SourceForge
before, it's a very nice web based interface to ongoing projects. There
are many aspects of helping out, including documentation, web page
development, etc.
Dave...
BLuRry
Wow. Very impressive stuff. A couple of questions:
1) Is it possible to move some of the VM or class files into aux
memory to free up both graphics pages?
2) So you had problems with flow control too? I also had the same
issue with my USB dongle, but also suspected it might have been a
pinout problem with my custom cable, this especially being the case
with the //c cable as there were only 5 pins to work with.
3) Do abstracts and interfaces work? What about class casting? (I
know that the java compiler converts a lot of this for you, but felt
it was worth asking)
3) Are there any java.* classes, or is this binary support for raw
stuff only? I can imagine java isn't the same without java.util.* or
java.io.*
4) Any introspection or dynamic binary class loading support? A wacky
idea that comes to mind is sending a compiled class over the wire
(binary class file) and dynamically loading that class for testing.
So, you could for example have a pre-defined interface available on
the apple, compile something that conforms to that interface, and send
that implementation over.
4) Any limit on the number of imports, or otherwise?
5) Any garbage collection?
Thanks for such a wonderful project -- with serial support it makes it
so trivial to build out much more exciting things.
David Schmenk
> **wipes drool off face**
>
> Wow. Very impressive stuff. A couple of questions:
>
> 1) Is it possible to move some of the VM or class files into aux
> memory to free up both graphics pages?
>
That will be post v1.0. For 128K machines, I will place bytecode in AUX
memory. However, the basic VM is just too big to free up both pages of
hires graphics and still have a sane memory map.
> 2) So you had problems with flow control too? I also had the same
> issue with my USB dongle, but also suspected it might have been a
> pinout problem with my custom cable, this especially being the case
> with the //c cable as there were only 5 pins to work with.
>
When I tried a regular PC serial port, it worked great. Darn USB dongles.
> 3) Do abstracts and interfaces work? What about class casting? (I
> know that the java compiler converts a lot of this for you, but felt
> it was worth asking)
>
Abstracts aren't supported (just a little too much to check for in the
class loader). I just use a dummy (empty) method and let the compiler
do the abstract checking. Interfaces work, but they are not robust.
The runtime simply looks for the interface method dynamically and throws
an exception if not found. Interface fields are not supported. As for
class casting, I'm not sure. You may have to try it.
> 3) Are there any java.* classes, or is this binary support for raw
> stuff only? I can imagine java isn't the same without java.util.* or
> java.io.*
>
Yep. But there are a lot of them, and I can only type so fast :-) I've
implemented some very basic classes. I make a tradeoff between size and
importance when I add a class, so not all the standard classes and their
methods exist. Just look in the JAVA directory (or the source tree).
> 4) Any introspection or dynamic binary class loading support? A wacky
> idea that comes to mind is sending a compiled class over the wire
> (binary class file) and dynamically loading that class for testing.
> So, you could for example have a pre-defined interface available on
> the apple, compile something that conforms to that interface, and send
> that implementation over.
>
Not such a wacky idea. It isn't very hard to add introspection or
dynamic binary class loading. Everything exists in the VM, I just
haven't exposed it through class Class or ClassLoader. I would love to
be able to develop in Eclipse and have it serve the class files to the
Apple over serial or ethernet.
> 4) Any limit on the number of imports, or otherwise?
>
You have less than 32K to work with. Fill 'er up!
> 5) Any garbage collection?
>
Yes, the memory manager is handle based and reference counted. When it
is unable to allocate another block, it runs through a two stage
process. First, it combines all adjacent free space, then it tries
shuffling the free blocks to low memory - repeating this process over
and over until it can either satisfy the alloc request or errors out
with memory full. I have a build option to incrementally run GC during
the idle loop, but it causes the keyboard response to be a little
sluggish until complete.
> Thanks for such a wonderful project -- with serial support it makes it
> so trivial to build out much more exciting things.
My thoughts too. The Apple II has so much to offer hardware-wise. I'm
closely watching Dave Schmidt's uthernet support. I think I'll pick his
brain for TCP/IP support post v1.0.
This also brings up the question of which serial port class to
implement. I've seen two classes, the SerialPort class in the javax
package and the RXTX package. Which one is preferred?
Dave...
schmidtd
> BLuRry wrote:
> > Thanks for such a wonderful project -- with serial support it makes it
> > so trivial to build out much more exciting things.
>
> My thoughts too. The Apple II has so much to offer hardware-wise. I'm
> closely watching Dave Schmidt's uthernet support. I think I'll pick his
> brain for TCP/IP support post v1.0.
bugs through a lot of heavy use over a long period of time; I think I
finally found the "last" one a week ago. (Ooops, I just jinxed it)
> This also brings up the question of which serial port class to
> implement. I've seen two classes, the SerialPort class in the javax
> package and the RXTX package. Which one is preferred?
In the real world, javax serial isn't well supported, platform-wise.
RXTX is compatible with the interface and has better platform
support. And so... I guess the answer is the same. I don't remember
needing anything beyond platform support in RXTX over Sun's
implementation.
BLuRry
> > implement. I've seen two classes, the SerialPort class in the javax
> > package and the RXTX package. Which one is preferred?
>
> In the real world, javax serial isn't well supported, platform-wise.
> RXTX is compatible with the interface and has better platform
> support. And so... I guess the answer is the same. I don't remember
> needing anything beyond platform support in RXTX over Sun's
> implementation.
Agreed. javax.serial was half-baked at best. RXTX filled the void.
But, as RXTX took a platform-agnostic approach and uses native
libraries (dll on windows, .so on *nix) to perform the operations, it
might be best to have something RXTX-looking without all the
abstraction. I can't imagine why the abstraction layer of RXTX would
be beneficial and would just consume extra memory.
One possible hack is to implement a rudimentary factory class that has
basic serial configuration options and takes an input stream for
sending and provides an output stream for receiving. Skip all the
abstraction and go straight to the metal.
Which reminds me of an unrelated question I forgot to ask: Is it
possible to inline or call external assembler routines?
-B
David Schmenk
> On Sep 18, 12:26 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> BLuRry wrote:
>>> Thanks for such a wonderful project -- with serial support it makes it
>>> so trivial to build out much more exciting things.
>> My thoughts too. The Apple II has so much to offer hardware-wise. I'm
>> closely watching Dave Schmidt's uthernet support. I think I'll pick his
>> brain for TCP/IP support post v1.0.
> MagerValp's ip65 stack is clean and tight. I've found a couple of
> bugs through a lot of heavy use over a long period of time; I think I
> finally found the "last" one a week ago. (Ooops, I just jinxed it)
>
Great! That will save lots of work.
>> This also brings up the question of which serial port class to
>> implement. I've seen two classes, the SerialPort class in the javax
>> package and the RXTX package. Which one is preferred?
>
> In the real world, javax serial isn't well supported, platform-wise.
> RXTX is compatible with the interface and has better platform
> support. And so... I guess the answer is the same. I don't remember
> needing anything beyond platform support in RXTX over Sun's
> implementation.
Thanks, I couldn't find much info one way or the other. It doesn't
appear that serial port control from Java is a very active topic.
David Schmenk
>>> This also brings up the question of which serial port class to
>>> implement. I've seen two classes, the SerialPort class in the javax
>>> package and the RXTX package. Which one is preferred?
>> In the real world, javax serial isn't well supported, platform-wise.
>> RXTX is compatible with the interface and has better platform
>> support. And so... I guess the answer is the same. I don't remember
>> needing anything beyond platform support in RXTX over Sun's
>> implementation.
>
> Agreed. javax.serial was half-baked at best. RXTX filled the void.
> But, as RXTX took a platform-agnostic approach and uses native
> libraries (dll on windows, .so on *nix) to perform the operations, it
> might be best to have something RXTX-looking without all the
> abstraction. I can't imagine why the abstraction layer of RXTX would
> be beneficial and would just consume extra memory.
>
> One possible hack is to implement a rudimentary factory class that has
> basic serial configuration options and takes an input stream for
> sending and provides an output stream for receiving. Skip all the
> abstraction and go straight to the metal.
Thats what I've been doing with the other classes too. I just want to
present a good face to ease porting without delving into the labyrinths
of Java class hierarchy (anarchy).
>
> Which reminds me of an unrelated question I forgot to ask: Is it
> possible to inline or call external assembler routines?
>
> -B
There are a few ways to do this. If you are calling ROM code, you can
do that directly through the low-level vm02 class (and peek/poke
memory). If you want to load a library and call it, you will have to do
some work - it should be relocatable. I plan on adding something like
this for the TCP/IP stack, but doesn't exist currently. The last way is
to write a native method. There are a few limitations and drawbacks
using this approach. First, you need to write the class in java, using
dummy methods for the ones you want to implement in assembly. Then, you
run the class file through an assemblerizer that spits out an assembly
language file representing the class file. Rewrite the methods you want
in 6502 code and massage the code attribute to get it to load.
Unfortunately, the code has to be position independent. Not a problem
for small, limited functionality routines, but very hard for extensive
routines. However, with clever usage of bytecode and native helper
functions, there isn't much you can't do. Calling native functions from
bytecode is quite fast. Implementing just what you have to natively,
and the logic in Java, makes for a pretty good solution. I have a few
examples to start from.
I have a good idea for a hi-res character generator type class for use
in an Ultima style game. The assembly will be short and sweet but
should be able to animate a large section of the screen. It really
makes you think about what you want in assembly and what you want in Java.
Dave...
Michael J. Mahon
> BLuRry wrote:
>> 2) So you had problems with flow control too? I also had the same
>> issue with my USB dongle, but also suspected it might have been a
>> pinout problem with my custom cable, this especially being the case
>> with the //c cable as there were only 5 pins to work with.
>>
>
> When I tried a regular PC serial port, it worked great. Darn USB dongles.
There is a tendency to expect that one can adapt anything to USB.
Flow control is a real-time activity, and USB is pretty poor at
any real-time interaction--too much protocol and attendant buffering.
-michael
AppleCrate II: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
mdj
> David Schmenk wrote:
> > BLuRry wrote:
> >> 2) So you had problems with flow control too? I also had the same
> >> issue with my USB dongle, but also suspected it might have been a
> >> pinout problem with my custom cable, this especially being the case
> >> with the //c cable as there were only 5 pins to work with.
>
> > When I tried a regular PC serial port, it worked great. Darn USB dongles.
>
> There is a tendency to expect that one can adapt anything to USB.
>
> Flow control is a real-time activity, and USB is pretty poor at
> any real-time interaction--too much protocol and attendant buffering.
That's true, but at least 'in theory' (with the necessary caveats
applied) there should be a sufficient enough bandwidth difference
between the the two protocols that it isn't an issue. Beware of cheap
implementations ;-)
Matt
Michael J. Mahon
It would be interesting to see comparisons of the latency measured
by, say, looping the handshake lines back, and measuring on the
PC/Mac side. E.g.: raise line, wait for loopback to rise, log
time delay, report mean and variance.
This information could be very helpful in selecting USB-to-serial
or USB-to-parallel adapters, and would clarify what can and cannot
be done with them.
David Schmenk
To be fair, my USB dongle implements hardware handshaking just fine. It
was the XON/XOFF protocol that fell apart. I only have a 256 character
buffer on the Apple II side, so any round trip to the PC's serial port
driver would have to be able be hold off the buffering inside the USB
dongle. I would assume the USB dongle accepts a small buffer of
characters at a time to keep from reducing the entire USB bus to 9600
characters/second. No doubt this small buffer overloaded my receive
buffer before any XOFF could be processed by the PC. One could imagine
implementing XON/XOFF inside the USB dongle, though.
Dave...
P.S. a little Googling brought this up:
mdj
> mdj wrote:
> > On Sep 24, 4:06 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> >> David Schmenk wrote:
> >>> BLuRry wrote:
> >>>> 2) So you had problems with flow control too? I also had the same
> >>>> issue with my USB dongle, but also suspected it might have been a
> >>>> pinout problem with my custom cable, this especially being the case
> >>>> with the //c cable as there were only 5 pins to work with.
> >>> When I tried a regular PC serial port, it worked great. Darn USB dongles.
> >> There is a tendency to expect that one can adapt anything to USB.
>
> >> Flow control is a real-time activity, and USB is pretty poor at
> >> any real-time interaction--too much protocol and attendant buffering.
>
> > That's true, but at least 'in theory' (with the necessary caveats
> > applied) there should be a sufficient enough bandwidth difference
> > between the the two protocols that it isn't an issue. Beware of cheap
> > implementations ;-)
>
> It would be interesting to see comparisons of the latency measured
> by, say, looping the handshake lines back, and measuring on the
> PC/Mac side. E.g.: raise line, wait for loopback to rise, log
> time delay, report mean and variance.
>
> This information could be very helpful in selecting USB-to-serial
> or USB-to-parallel adapters, and would clarify what can and cannot
> be done with them.
That would be handy. Unfortunately these devices seem only to have
been tested with common usage scenarios, which seems to be limited to
testing printers and modems.
USB-to-parallel adapters are probably the worst in this regard. I gave
up in the end and found a decent USB->JTAG adapter, and threw out the
last parallel printer I had.
Do I miss being able to do synchronous bit-banging on modern machines?
Nope :-) Now I *have* to use an Apple II
Matt