From mbealby at gmail.com  Tue Jan  2 22:30:24 2007
From: mbealby at gmail.com (M Bealby)
Date: Tue, 02 Jan 2007 22:30:24 +0000 (GMT)
Subject: [movitz-devel] Writing directly to memory
Message-ID: <20070102.223024.92582943.mbealby@gmail.com>

Hey all,

I am attempting to utilise movitz to learn about low level programming and
hopefully contribute a few drivers.  One of the things that I am trying to do
is play around with some VGA programming, mainly because graphics programming
gives instant satisfaction.

I have successfully changed video mode to 640x480x16bpp by manipulation of the
vga register sets, and movitz continues to run (i.e. doesn't crash), as I can
switch back. :)

However, I am now stuck when it comes to writing directly to memory.  I want to
write to the vga memory area (as reported by vga-memory-map) but I couldn't
work out how to do it.  I attempted using the form (setf (io-port #xa000
:unsigned-byte16) #x0000), but this failed to write to memory (as reported by a
subsequent io-port read call)

Anyone able to give me any hints?

Martin


From pjb at informatimago.com  Wed Jan  3 00:20:44 2007
From: pjb at informatimago.com (Pascal Bourguignon)
Date: Wed, 3 Jan 2007 01:20:44 +0100
Subject: [movitz-devel] Writing directly to memory
In-Reply-To: <20070102.223024.92582943.mbealby@gmail.com>
References: <20070102.223024.92582943.mbealby@gmail.com>
Message-ID: <17818.63196.607029.559554@thalassa.informatimago.com>

M Bealby writes:
> Hey all,
> 
> I am attempting to utilise movitz to learn about low level programming and
> hopefully contribute a few drivers.  One of the things that I am trying to do
> is play around with some VGA programming, mainly because graphics programming
> gives instant satisfaction.
> 
> I have successfully changed video mode to 640x480x16bpp by manipulation of the
> vga register sets, and movitz continues to run (i.e. doesn't crash), as I can
> switch back. :)
> 
> However, I am now stuck when it comes to writing directly to memory.  I want to
> write to the vga memory area (as reported by vga-memory-map) but I couldn't
> work out how to do it.  I attempted using the form (setf (io-port #xa000
> :unsigned-byte16) #x0000), but this failed to write to memory (as reported by a
> subsequent io-port read call)
> 
> Anyone able to give me any hints?

If you want to write to the memory, you don't want to write to an io-port!
Use normal memory accesses.
For example, using (setf muerte::memrange)

Also, it imay be possible to map an array to a given memory address,
so you can access these bytes directly with svref or aref.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"Logiciels libres : nourris au code source sans farine animale."


From ffjeld at common-lisp.net  Wed Jan  3 10:14:19 2007
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: 03 Jan 2007 11:14:19 +0100
Subject: [movitz-devel] Re: Writing directly to memory
References: <20070102.223024.92582943.mbealby@gmail.com>
	<17818.63196.607029.559554@thalassa.informatimago.com>
Message-ID: <2hr6uc76ys.fsf@vserver.cs.uit.no>

M Bealby writes:

>> [..] Anyone able to give me any hints?

Pascal Bourguignon <pjb at informatimago.com> writes:

> If you want to write to the memory, you don't want to write to an
> io-port!  Use normal memory accesses.  For example, using (setf
> muerte::memrange)

Right, the I/O and memory address spaces are accessed differently.
The canonical operator for accessing memory (as such) is memref (which
memrange currently boils down to, if you look at its source).

  defun memref (object offset
                &key (index 0) (type :lisp) localp (endian :host))


The object is any lisp-value whose 32-bit-pattern is taken as the base
address, to which the integer offset is added. Finally, the integer
index is multiplied with the byte-size of the type, and added to get
the final address.

For example, the lisp value 100 (a positive fixnum) is represented by
the bit-pattern #x00000400, which means that e.g.

  (memref 100 6 :index 1 :type :unsigned-byte16)

is compiled into something like this pseudo-assembly:

  movw (#x408) <destination>


A variant of memref is memref-int, which computes the address a bit
differently:

  defun memref-int (address
                    &key (offset 0) (index 0) (type :unsigned-byte32)
                         (physicalp t))

Here, the address is provided explicitly as an integer, to which the
integer offset and the index multiplied by the type's size is
added. memref-int tends to be more appropriate for accessing hardware
devices, while memref is more of a primitive for the lisp system as
such.


I'll describe the remaining arguments which are (more or less) common
to the two operators. The type argument determines how the memory is
read and interpreted. To read a value of type :lisp, you have to know
very well what you are doing, because otherwise you can easily end up
with an illegal lisp value. For hardware programming, you typically
want :unsigned-byte32, 16, or 8. Some other types supported but less
useful are :character (which is 8-bit and rather ill-specified in
terms of character-sets, which is true of Movitz in general), and
:location which takes a 32-bit value and strips the lower two bits,
leaving a fixnum lisp-value.

The localp argument is to do with some GC-related protocols that are
not really finalized. Just leave it at its default is safe.

The endian argument determines the endianess of unsigned-byteXX bytes.

The physicalp argument, finally, is important. Set this to true if the
address is to be interpreted as a physical address, as seen on the
memory bus and by hardware peripheral devices. Movitz currently sets
up the CPU such that the default memory space is shifted one MB or so
from the physical address space (using segmentation). This leaves most
of the "interesting" hardware memory space unavailable, unless you
have :physicalp t (which is the default for memref-int).

Anyways, the following should be approximately what the OP wants:

  (memref-int #xa0000 :index foo :type :unsigned-byte16)


Hm.. I suppose a wiki would be nice for information such as this.


> Also, it imay be possible to map an array to a given memory address,
> so you can access these bytes directly with svref or aref.

This is unfortunately not currently possible. Christophe Rhodes' work
on extensible sequences might be worth looking at in this context,
however.


-- 
Frode Vatvedt Fjeld



From ffjeld at common-lisp.net  Wed Jan  3 10:50:54 2007
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: 03 Jan 2007 11:50:54 +0100
Subject: [movitz-devel] Re: Writing directly to memory
References: <20070102.223024.92582943.mbealby@gmail.com>
	<17818.63196.607029.559554@thalassa.informatimago.com>
	<2hr6uc76ys.fsf@vserver.cs.uit.no>
Message-ID: <2hmz50759t.fsf@vserver.cs.uit.no>

Frode Vatvedt Fjeld <ffjeld at common-lisp.net> writes:

> Hm.. I suppose a wiki would be nice for information such as this.

I'd forgotten there is a wiki integrated with Trac. Have a look at
this:

  http://trac.common-lisp.net/movitz

-- 
Frode Vatvedt Fjeld



From pparkkin at cc.jyu.fi  Thu Jan 11 10:45:42 2007
From: pparkkin at cc.jyu.fi (Paavo Parkkinen)
Date: Thu, 11 Jan 2007 12:45:42 +0200
Subject: [movitz-devel] sbcl: heap exhausted
Message-ID: <b9edbea70701110245ufd5246fn709a95d87e5d059e@mail.gmail.com>

I was trying to compile the los0 image on my own computer this morning
and after taking a while, and printing a bunch of messages, "(load
"load.lisp")" came up with a "Heap exhausted, game over." -message.

I have 512M memory (~500M swap); is that not enough, or did I do
something wrong?


p


ps. I'm attaching the last few lines of output from sbcl.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gameover.txt
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20070111/968c7da4/attachment.txt>

From ffjeld at common-lisp.net  Thu Jan 11 15:37:08 2007
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: 11 Jan 2007 16:37:08 +0100
Subject: [movitz-devel] Re: sbcl: heap exhausted
References: <b9edbea70701110245ufd5246fn709a95d87e5d059e@mail.gmail.com>
Message-ID: <2hmz4p60d7.fsf@vserver.cs.uit.no>

"Paavo Parkkinen" <pparkkin at cc.jyu.fi> writes:

> I was trying to compile the los0 image on my own computer this morning
> and after taking a while, and printing a bunch of messages, "(load
> "load.lisp")" came up with a "Heap exhausted, game over." -message.
> 
> I have 512M memory (~500M swap); is that not enough, or did I do
> something wrong?

Did it work before? Movitz is rather memory hungry.. and I do seem to
remember I used to prefer CMUCL over SBCL at one time because CMUCL
seemed to provide more and more stable memory handling. You can try to
limit the features you bring into the image (by removing require
statements at the top of los0.img).

Wheter 1 GB in absolute terms is enough, I am not sure.. it does seem
a bit scarce.

-- 
Frode Vatvedt Fjeld



From pparkkin at cc.jyu.fi  Fri Jan 12 06:31:26 2007
From: pparkkin at cc.jyu.fi (Paavo Parkkinen)
Date: Fri, 12 Jan 2007 08:31:26 +0200
Subject: [movitz-devel] Re: sbcl: heap exhausted
In-Reply-To: <2hmz4p60d7.fsf@vserver.cs.uit.no>
References: <b9edbea70701110245ufd5246fn709a95d87e5d059e@mail.gmail.com>
	<2hmz4p60d7.fsf@vserver.cs.uit.no>
Message-ID: <b9edbea70701112231l13061e70re80d91b6c9f6a37f@mail.gmail.com>

This was my first time compiling los0. I tried CMUCL and it worked
just fine, and didn't even take very long.

Thank you!

p


On 11 Jan 2007 16:37:08 +0100, Frode Vatvedt Fjeld
<ffjeld at common-lisp.net> wrote:
> "Paavo Parkkinen" <pparkkin at cc.jyu.fi> writes:
>
> > I was trying to compile the los0 image on my own computer this morning
> > and after taking a while, and printing a bunch of messages, "(load
> > "load.lisp")" came up with a "Heap exhausted, game over." -message.
> >
> > I have 512M memory (~500M swap); is that not enough, or did I do
> > something wrong?
>
> Did it work before? Movitz is rather memory hungry.. and I do seem to
> remember I used to prefer CMUCL over SBCL at one time because CMUCL
> seemed to provide more and more stable memory handling. You can try to
> limit the features you bring into the image (by removing require
> statements at the top of los0.img).
>
> Wheter 1 GB in absolute terms is enough, I am not sure.. it does seem
> a bit scarce.
>
> --
> Frode Vatvedt Fjeld
>
> _______________________________________________
> movitz-devel site list
> movitz-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel
>


From mbealby at gmail.com  Fri Jan 19 12:51:43 2007
From: mbealby at gmail.com (M Bealby)
Date: Fri, 19 Jan 2007 12:51:43 +0000 (GMT)
Subject: [movitz-devel] Drivers, standards and design
Message-ID: <20070119.125143.63129846.mbealby@gmail.com>

Hey all,

Between attempting to code device drivers for movitz I have been thinking about
how the drivers currently work.  Currently, the drivers are completely separate
from one another.  However, I was wondering if anyone had thought about
providing some higher level hardware information to any running applications.

By this I mean that during startup, movitz would probe for any hardware it
understands and create information lists for each device.  I envision a list to
be constructed of an identifier to explain what the device type is, followed by
the parameters of that device.  One example (for a serial port) would be:

([serial-port-key] [uart-address] [baud-rate])

Then, following this probe procedure, creating a list called something like
hardware-info, which contains all of the lists for discovered hardware.

The advantage of this approach is for hot-swappable hardware, such as usb
devices, device-lists can be simply removed or appended to the hardware-info
list.

I feel that this would be useful as any movitz applications can then access
this hardware-info list to find options available to users on there hardware.

This would only require minor modifications to the current drivers (the add and
remove hardware functions) while providing a framework to which new drivers
could be built upon.

Any thoughts?

Martin


From ffjeld at common-lisp.net  Wed Jan 24 22:51:40 2007
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: 24 Jan 2007 23:51:40 +0100
Subject: [movitz-devel] Re: Drivers, standards and design
References: <20070119.125143.63129846.mbealby@gmail.com>
Message-ID: <2hk5zc3uo3.fsf@vserver.cs.uit.no>

M Bealby <mbealby at gmail.com> writes:

> Between attempting to code device drivers for movitz I have been
> thinking about how the drivers currently work.  Currently, the drivers
> are completely separate from one another.  However, I was wondering if
> anyone had thought about providing some higher level hardware
> information to any running applications.
> 
> By this I mean that during startup, movitz would probe for any
> hardware it understands and create information lists for each
> device.  I envision a list to be constructed of an identifier to
> explain what the device type is, followed by the parameters of that
> device.  One example (for a serial port) would be:
> 
> ([serial-port-key] [uart-address] [baud-rate])
> 
> Then, following this probe procedure, creating a list called
> something like hardware-info, which contains all of the lists for
> discovered hardware.

This is good and well, but I'd like to add one perspective to this
picture: Think of the list of device (-driver) descriptors as a
program, the probe procedure as an evaluator of that language, and the
list of detected hardware as the output of the program's
evaluation. Now, I suggest that plain Lisp (possibly augmentet by some
appropriate macros) would work very well in the role of this language
and evaluator. Or in other words, I suspect that the probing and
book-keeping of devices is one of the things that will turn out to be
entirely trivial in Movitz, even if it tends to be complicated in unix
and the like. At least so long as everything lives inside a single
address space and objects (i.e. driver instances) can be easily passed
around by reference. 

What I percieve to be more of a challenge, is shared resource
management in various forms. For example, how to express "call this
function in 10 milliseconds" (i.e. sharing the timer), etc.

> This would only require minor modifications to the current drivers
> (the add and remove hardware functions) while providing a framework
> to which new drivers could be built upon.

I'd like to note that the current "drivers" are mostly more or less
sketches, providing some bare essentials but usually nothing in the
way of resource management or anything else that requires some
overarching structure. Improvements and suggestions are welcome, of
course.

-- 
Frode Vatvedt Fjeld



From happyarch at gmail.com  Mon Jan 29 02:37:53 2007
From: happyarch at gmail.com (l l)
Date: Mon, 29 Jan 2007 11:37:53 +0900
Subject: [movitz-devel] movitz on plan9?
Message-ID: <768a59a70701281837i867f55fu481f60cf0a0a52c0@mail.gmail.com>

Hi,

I am new to movitz community.
Is it possible porting movitz to plan9 using alisp?

TIA

http://plan9.bell-labs.com/plan9/
http://www.cliki.net/LISP%20in%20PLAN%209
http://www.t3x.org/alisp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20070129/0c4e9b69/attachment.html>

From ffjeld at common-lisp.net  Mon Jan 29 08:04:35 2007
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: 29 Jan 2007 09:04:35 +0100
Subject: [movitz-devel] Re: movitz on plan9?
References: <768a59a70701281837i867f55fu481f60cf0a0a52c0@mail.gmail.com>
Message-ID: <2hfy9u45t8.fsf@vserver.cs.uit.no>

"l l" <happyarch at gmail.com> writes:

> I am new to movitz community.

Hi, and welcome to the community, such as it is.

> Is it possible porting movitz to plan9 using alisp?

If "alisp" is an ANSI-compliant Common Lisp that runs on plan9, this
should be no (big) problem.

-- 
Frode Vatvedt Fjeld