From mmhansen at gmail.com  Sat Oct  8 01:55:34 2005
From: mmhansen at gmail.com (Michael Hansen)
Date: Fri, 7 Oct 2005 18:55:34 -0700
Subject: [movitz-devel] off-topic: Poking the parallel port
Message-ID: <a8907c780510071855q7eced47fv7549a070ff571cf2@mail.gmail.com>

Sorry for the off-topic post, but there appears to be no list for user
discussion yet...

Mr. Fjeld's presentation slides from June of last year indicate that "Poking
the parallel
port should be easy!" Would anyone be willing to share some code which
illustrates
a trivial case? I haven't used anything which is less abstract than Scheme
since the
early 1990's and I know little about the entrails of x86 hardware. I am
growing
comfortable with the differences between Scheme and Lisp, but I don't even
know
where to start on this problem.

Specifically, I want to be able to toggle and latch the state of four
outputs on an x86
parallel port under Movitz. I have been told it is going to be more
complicated than
just fiddling with the memory map as might be done with BASIC on a DOS box,
since
Movitz (Muerte?) runs in protected-mode.


Why? What am I doing?

I'm taking an old PC motherboard, 64 MB RAM, a floppy drive, a convoluted
mess of
DC-DC converters, a big 12V battery, a pair of DC gear-head motors, a pair
of H-bridge
motor controllers, a homebrew parallel port break-out box with buffers and
optocouplers,
attaching it all to some pieces of sheet metal, and trying to teach myself
something
about mobile robot navigation.

I would eventually like to learn about peeking at some parallel port inputs
so I can add
motor-shaft encoders and collision sensors. It would also be nice to point
the REPL
at a serial port so I can interact with the machine using an RF modem or a
dragged cable,
but for now, I would be very grateful to simply know how I can control the
motors.

Thanks,
-Mike Hansen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20051007/31778400/attachment.html>

From frodef at cs.uit.no  Sat Oct  8 22:31:31 2005
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: 09 Oct 2005 00:31:31 +0200
Subject: [movitz-devel] Re: off-topic: Poking the parallel port
References: <a8907c780510071855q7eced47fv7549a070ff571cf2@mail.gmail.com>
Message-ID: <2hoe5z3akc.fsf@vserver.cs.uit.no>

Michael Hansen <mmhansen at gmail.com> writes:

> Specifically, I want to be able to toggle and latch the state of
> four outputs on an x86 parallel port under Movitz. I have been told
> it is going to be more complicated than just fiddling with the
> memory map as might be done with BASIC on a DOS box, since Movitz
> (Muerte?) runs in protected-mode.

I don't think anything is complicated by Movitz running in protected
mode. (Perhaps whomever you talked to were thinking about the
kernel/user-space protection in typical kernels?) You can easily
fiddle with the parallell port under Movitz by saying things like

  (setf (io-port <io-base> :unsigned-byte8) <bits>)

interactively or in a compiled function or whatnot. I don't remember
off-hand the exact details of how one interfaces the PC parallell
port, but I seem to remember that there are about eight pins that can
be controlled in the obvious way by writing to a certain (byte)
I/O-port. The exact details should be easily available on the web or
from one of the books on PC hardware programming.

Don't hesitate to ask more specific questions here if you run into
problems.

-- 
Frode Vatvedt Fjeld



From sabetts at vcn.bc.ca  Mon Oct 24 06:27:37 2005
From: sabetts at vcn.bc.ca (Shawn Betts)
Date: Mon, 24 Oct 2005 02:27:37 -0400
Subject: [movitz-devel] yield stuff in threads.lisp
Message-ID: <86fyqr2zvq.fsf@shitbender.gagrod>

Hi Frode,

could you give an explanation of the yield stuff in the threads.lisp
file? Is that what needs to be called to "stop" a thread?

-Shawn


From frodef at cs.uit.no  Mon Oct 24 19:43:51 2005
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: 24 Oct 2005 21:43:51 +0200
Subject: [movitz-devel] Re: yield stuff in threads.lisp
References: <86fyqr2zvq.fsf@shitbender.gagrod>
Message-ID: <2hzmoyzonc.fsf@vserver.cs.uit.no>

Shawn Betts <sabetts at vcn.bc.ca> writes:

> could you give an explanation of the yield stuff in the threads.lisp
> file? Is that what needs to be called to "stop" a thread?

I suppose it's described more accurately as "starting" another
thread. I.e. the thread that calls yield is suspended, and the thread
that is passed as argument to yield is resumed.

You can even do this interactively, i.e. someting like

  (setf *t1*) (current-run-time-context))
  (setf *t2* (make-instance 'threading:thread))
  (threading:yield *t2*)

    [now you're in t2.. try e.g a backtrace]

  (threading:yield *t1*)

    [now you're back to the context of the first yield.. i.e. it'll be
     just as if the first call to yield just returned.]


Execpt, of course, right now there are some lingering bugs that
prevents this from working. I'll try to have it fixed this evening.

-- 
Frode Vatvedt Fjeld



From frodef at cs.uit.no  Mon Oct 31 10:01:12 2005
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: 31 Oct 2005 11:01:12 +0100
Subject: [movitz-devel] Re: yield stuff in threads.lisp
References: <86fyqr2zvq.fsf@shitbender.gagrod>
	<2hzmoyzonc.fsf@vserver.cs.uit.no>
Message-ID: <2hfyqiyphz.fsf@vserver.cs.uit.no>

So, the SO is visiting the dentist, the little brat has been sleeping
for an hour or two, and I've allowed myself half a day off from
working on the new house, and jupiter and mars are properly aligned
with the moon, etc..  so I've been able to work an hour or so on
movitz' threading:

It turned out the problem wasn't really related to the threads as
such, rather it was the REPL and readling code that didn't respond so
well to the default environment that a fresh thread gets set up
with. Now I've debugged and robustified this code somewhat, and this
should make testing threading:yield etc. work ok.

Here's an illustrative screenshot from a bochs session, with
line-numbers added for references below:

                           
 1  INIT> :pa threading
 2  THREADING> (+ 35 7)
 3  #x2a
 4  THREADING> (yield (make-instance 'thread))
 5  [0d] INIT> *
 6  NIL
 7  [0d] INIT> :bt
 8   <1 (THREADING::STACK-BOOTSTRAPPER ...)
 9  [0d] INIT> (/ 17 2)
10  #x11/2
11  [0d] INIT> (setf *t2* (current-run-time-context))
12  #<THREAD  @ #xf0176>
13  [0d] INIT> (setf *t1* (%lispval-object 6))
14  #<RUN-TIME-CONTEXT :INIT @ #x6>
15  [0d] INIT> (yield *t1*)
16  NIL
17  THREADING> *
18  NIL
19  THREADING> ***
20  #x2a
21  THREADING> (yield init::*t2*)
22  NIL
23  [0d] INIT> ***
24  #x11/2
25  [0d] INIT>


Line 4 is the most interesting one: It first makes a new thread, and
immediately switches control to it. Line 5 is from inside this new
thread, and you can see e.g. that it's getting a default *package*
bound to the INIT package. In line 7 a (short) stack backtrace is
printed for the new thread.  In line 11 the variable *t2* is set to
the new thread object (i.e. the object returned by make-instance in
line 4), which is available through the current-run-time-context
operator which returns the run-time-context that is currently
active. Note that a the threading:thread class is a specialization of
the muerte:run-time-context class. In line 13 the variable *t1* is set
to the initial boot-up "thread", which is not a threading:thread but
just a mere muerte:run-time-context instance. This object is always at
located at the very start of the address-space under the current
image-dumping scheme for LOS0. (6 is the low-tag for such objects.)

In line 15 control is switched back to the original "thread". Line 16
is actually the print-out of the return-value of the functon-call in
line 4. (Note that the yield at line 15 would accept an optional
second argument that would be this return-value.) Line 19 shows that
the *** variable of the initial thread is bound to the value from line
3, and that none of the goings-on in the other thread (lines 5-15)
affected such local bindings. In line 21 control is once more switch
back to the new thread, and we see that there are indeed two separate
environments.

Beware that GC is unlikely to behave robustly in the presence of
multiple thread objects yet (I'm not really sure, but I can't remember
working much on it, so..)

-- 
Frode Vatvedt Fjeld