aiiadict@gmail.com wrote:
On Jan 1, 8:17 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
aiiad...@gmail.com wrote:
On Dec 30 2007, 9:39 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
When I'm using my AppleCrate, I find that I frequently look at the
network activity light and the individual 'Crate machine "send"
lights.
The patterns are sometimes quite useful for debugging, as is plugging
a video monitor into various 'Crate machines to see what they're
doing.
these I/O indicators could be added to the internet interface in the
future.
An interesting problem in itself...
An uninteresting problem isn't something I want to find the answer
to..
Right. This one, if pursued directly, would lead to a 8-32 bit parallel
input for a Mac or PC, which then used the binary value received to
modify the "control panel" page presented to a user.
They are especially useful for observing that a setup is working as
intended. ;-)
Hopefully the network I set up here will be working properly!
It's not hard to get the physical setup working, but when a
parallel program is run, there are lots of "logical" problems
that can occur--in fact, that's when you learn the most. ;-)
For sure! I'm very interested in parallel programming,
I very frequently keep a monitor plugged into 'Crate machine #2--the
Message Server--since it displays a dynamic histogram of the lengths
of each of the queues it is handling. This would not be easily
"exported" to a remote user.
40-column text screen. A message server needs all the space
it can muster. ;-)
ok, so the ammount of data isn't the problem...
No, the problem is that the Message Server displays this screen by
modifying its video memory, and, aside from the monitor, this data
is not exported.
It is possible to read the message queue data from another machine,
using &PEEK to the Message Server, but that would add considerably
to network load if read dozens of times per second.
The monitor in this case provides a kind of "out-of-band" signalling
of Message Server status.
Another approach would be to have a machine run a "Message Server
queue shadow", which would listen promiscuously for traffic between
the Message Server and its users, and keep a "shadow" copy of queue
status. This machine could then communicate the status to a web-
connected machine over a serial link (which would have to not interfere
with the timing and constant surveillance of NadaNet (a bit tricky,
in itself).
(The reason for the need for *constant* polling of NadaNet is that,
unlike the *intended* recipient of messages, an eavsdropping machine
cannot ignore or NAK a packet, since the intended recipient may respond
instantly.)
Typically, it's being updated 20-50 times per second, so when
I said "dynamic" I wasn't kidding. ;-)
But the speed of transmitting and displaying the data is..
Actually, web updates faster than a few per second seem
problematic to me...
While it would probably be OK to see the message queues sampled
a few times per second, reasonable sample rates would obscure the
rapid patterns revealed by the send LEDs. In fact, a random sample
is quite likely to reveal *no* machine sending at that instant.
The "pulse stretcher" (PDL 3) lengthens a "send" pulse to about
3 milliseconds, but more would require external hardware (and
slower sampling would still remove the patterns).
I'll get it to work and if nothing else, it'll be a fun project
getting it to interface with the internet.
I agree--I'd like to see a real Apple II be "usable" over the net!
And, of course, I'd love to see it hooked up to an AppleCrate! ;-)
-michael
NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."