From nyef at softhome.net Mon Jan 12 19:33:24 2004 From: nyef at softhome.net (Nyef) Date: Mon, 12 Jan 2004 14:33:24 -0500 Subject: [movitz-devel] Patch: Fix asdf builds of ia-x86 Message-ID: <20040112193324.GA18581@miyu.paradiesanalytics.com> Hello all. Attached is a patch to fix building using asdf, tested using cmucl 18e. Hope this helps. --Alastair Bridgewater -------------- next part -------------- Index: ia-x86.asd =================================================================== RCS file: /project/movitz/cvsroot/ia-x86/ia-x86.asd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ia-x86.asd --- ia-x86.asd 12 Jan 2004 15:23:55 -0000 1.1.1.1 +++ ia-x86.asd 12 Jan 2004 19:29:39 -0000 @@ -32,7 +32,8 @@ (:file "read") (:file "codec") (:file "proglist") - (:file "def-instr"))) + (:file "def-instr") + (:file "postload"))) (defmethod perform :after ((o load-op) (c (eql (find-system :ia-x86)))) (when (y-or-n-p "Initialize instruction tables? It may take a while, ~ From ffjeld at common-lisp.net Tue Jan 13 13:20:56 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 13 Jan 2004 14:20:56 +0100 Subject: [movitz-devel] Movitz initial source release Message-ID: <2hoet8kmrr.fsf@vserver.cs.uit.no> Well, this is a combined announcement of the initial release of the Movitz CVS repository and test of the mailing-lists. There are currently three modules in the repository: ia-x86 binary-types movitz The former two are required for building and using the latter. Also, both ia-x86 and binary-types have been somewhat tested for portability, whereas Movitz itself has only ever been used with Allegro CL. I'm hoping that someone with experience with other lisp implementations than Allegro can make movitz runnable under their system, and submit patches to that effect to movitz-devel at common-lisp.net. -- Frode Vatvedt Fjeld From seb-cl-mailist at matchix.com Tue Jan 13 15:25:45 2004 From: seb-cl-mailist at matchix.com (=?iso-8859-1?Q?S=E9bastien_Saint-Sevin?=) Date: Tue, 13 Jan 2004 16:25:45 +0100 Subject: [movitz-devel] html need to be fixed Message-ID: Hi Frode, In the html file located at http://www.common-lisp.net/project/movitz/, under the mailing lists section, the three mailing lists point to movitz-devel instead of their respective list. This causes me to register twice to devel... Hope this helps, Sebastien. From ffjeld at common-lisp.net Tue Jan 13 15:35:18 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 13 Jan 2004 16:35:18 +0100 Subject: [movitz-devel] html need to be fixed In-Reply-To: =?iso-8859-1?q?=28S=E9bastien?= Saint-Sevin's message of "Tue, 13 Jan 2004 16:25:45 +0100") References: Message-ID: <2hk73vkgjt.fsf@vserver.cs.uit.no> S?bastien Saint-Sevin writes: > In the html file located at > http://www.common-lisp.net/project/movitz/, under the mailing lists > section, the three mailing lists point to movitz-devel instead of > their respective list. Ok, fixed. That's what you get for cut'n'pasting'n'search'n'replacing the "sample project" html. Thanks for the info. [Did anyone else get my NNTP-posted messages via email? I didn't.] -- Frode Vatvedt Fjeld From james at unlambda.com Wed Jan 14 01:34:38 2004 From: james at unlambda.com (James A. Crippen) Date: Tue, 13 Jan 2004 16:34:38 -0900 Subject: [movitz-devel] html need to be fixed In-Reply-To: <2hk73vkgjt.fsf@vserver.cs.uit.no> (Frode Vatvedt Fjeld's message of "Tue, 13 Jan 2004 16:35:18 +0100") References: <2hk73vkgjt.fsf@vserver.cs.uit.no> Message-ID: Frode Vatvedt Fjeld writes: > [Did anyone else get my NNTP-posted messages via email? I didn't.] Nope. -- James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From nyef at softhome.net Thu Jan 15 12:56:04 2004 From: nyef at softhome.net (Nyef) Date: Thu, 15 Jan 2004 07:56:04 -0500 Subject: [movitz-devel] Binary-types not working on CMUCL Message-ID: <20040115125604.GA25763@miyu.paradiesanalytics.com> Hello all. I've been poking around at trying to get movitz to compile on CMUCL when I ran accross an incompatability with binary-types. What follows is a transcript of me triggering this incompatability: CMU Common Lisp CVS release-18e-branch + minimal debian patches, running on miyu.paradiesanalytics.com With core: /usr/lib/cmucl/lisp.core Dumped on: Tue, 2003-11-11 23:57:40-05:00 on miyu.paradiesanalytics.com For support see http://www.cons.org/cmucl/support.html Send bug reports to the Gentoo Bugzilla http://bugs.gentoo.org Type (help) for help, (quit) to exit, and (demo) to see the demos Loaded subsystems: Python 1.1, target Intel x86 CLOS 18e (based on PCL September 16 92 PCL (f)) * (load "binary-types.lisp") ; Loading #p"/home/nyef/src/lisp/movtiz-cvs/binary-types/binary-types.lisp". T * (in-package binary-types) # * (defclass movitz-heap-object () ()) # * (define-binary-class movitz-cons (movitz-heap-object) ((car :binary-type word :map-binary-write 'movitz-intern :map-binary-read-delayed 'movitz-word :initarg :car :accessor movitz-car) (cdr :binary-type word :map-binary-write 'movitz-intern :map-binary-read-delayed 'movitz-word :initarg :cdr :accessor movitz-cdr)) (:slot-align car -1)) Error in function PCL::SLOT-READER-SYMBOL: non-symbol and non-interned symbol slot name accessorsare not yet implemented Restarts: 0: [ABORT] Return to Top-Level. Debug (type H for help) (PCL::SLOT-READER-SYMBOL #:|hidden-slot-CDR|) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:pcl/defclass.lisp. 0] I figure that this is probably not what is supposed to happen. Anyway, that's my report for today. --Alastair Bridgewater From ffjeld at common-lisp.net Thu Jan 15 13:23:26 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Thu, 15 Jan 2004 14:23:26 +0100 Subject: [movitz-devel] Binary-types not working on CMUCL In-Reply-To: <20040115125604.GA25763@miyu.paradiesanalytics.com> (nyef@softhome.net's message of "Thu, 15 Jan 2004 07:56:04 -0500") References: <20040115125604.GA25763@miyu.paradiesanalytics.com> Message-ID: <2hwu7tgx8m.fsf@vserver.cs.uit.no> I added a hack to binary-types that hopefully allows cmucl to build Movitz regardless of this PCL misfeature, if you just set bt:*ignore-hidden-slots-for-pcl* to true. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Thu Jan 15 18:31:23 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Thu, 15 Jan 2004 19:31:23 +0100 Subject: [movitz-devel] Partial success with CMUCL Message-ID: <2hn08pgj2c.fsf@vserver.cs.uit.no> I have had partial success building Movitz with CMUCL 18e: * (load "load") ... ; lots of noise * (in-package movitz) => # * (setf *compiler-compile-macro-expanders* nil *compiler-compile-eval-whens* nil) ; don't trigger CMUCL bug => NIL * (create-image) ... ; much noise ; Compilation unit finished. ; 50 warnings => # ; Success! Now, (dump-image) should dump this structure onto a file, but this does not seem to work quite yet. However it should now be possible to develop (compile, disassemble etc.) Movitz-side code under CMUCL. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Fri Jan 16 18:29:05 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Fri, 16 Jan 2004 19:29:05 +0100 Subject: [movitz-devel] Host implementation status Message-ID: <2h7jzrhhn2.fsf@vserver.cs.uit.no> In addition to Allegro, it seems that SBCL is currently able to build working Movitz images. CMUCL is almost there, only the final dump-image process doesn't quite work yet. There appears to be a nasty bug in CLisp, which must be fixed in CLisp before it has any hope with the Movitz compiler. Any other implementations I haven't tried. -- Frode Vatvedt Fjeld From nyef at softhome.net Fri Jan 16 19:15:31 2004 From: nyef at softhome.net (Nyef) Date: Fri, 16 Jan 2004 14:15:31 -0500 Subject: [movitz-devel] SBCL build fixes Message-ID: <20040116191531.GA27941@miyu.paradiesanalytics.com> Hello all. Attached is a patch that prevents building on SBCL from erroring out with complaints about constants being redefined with uneql values. --Alastair Bridgewater -------------- next part -------------- Index: image.lisp =================================================================== RCS file: /project/movitz/cvsroot/movitz/image.lisp,v retrieving revision 1.2 diff -u -r1.2 image.lisp --- image.lisp 15 Jan 2004 17:36:19 -0000 1.2 +++ image.lisp 16 Jan 2004 19:09:08 -0000 @@ -686,7 +686,9 @@ (#+allegro excl:tenuring #-allegro progn (psetq *image* (let ((*image* (make-movitz-image start-address))) (when init-file - (movitz-compile-file init-file)) + #+sbcl(handler-bind ((sb-ext:defconstant-uneql #'continue)) + (movitz-compile-file init-file)) + #-sbcl(movitz-compile-file init-file)) *image*) *i* (when (boundp '*image*) *image*)) ;; #+acl (excl:gc) Index: load.lisp =================================================================== RCS file: /project/movitz/cvsroot/movitz/load.lisp,v retrieving revision 1.5 diff -u -r1.5 load.lisp --- load.lisp 16 Jan 2004 18:22:37 -0000 1.5 +++ load.lisp 16 Jan 2004 19:09:08 -0000 @@ -47,7 +47,10 @@ (do () (nil) (with-simple-restart (retry "Retry loading ~S" path) (return - (load (compile-file (make-pathname :name path :type "lisp") + #+sbcl (handler-bind ((sb-ext:defconstant-uneql #'continue)) + (load (compile-file (make-pathname :name path :type "lisp") + :print nil))) + #-sbcl(load (compile-file (make-pathname :name path :type "lisp") :print nil)))))) '("packages" "movitz" From nyef at softhome.net Sun Jan 18 15:08:04 2004 From: nyef at softhome.net (Nyef) Date: Sun, 18 Jan 2004 10:08:04 -0500 Subject: [movitz-devel] First-cut floppy driver Message-ID: <20040118150804.GA30396@miyu.paradiesanalytics.com> Hello all. Attached is a first cut for a floppy driver. It has been tested against real hardware, and is capable of spinning up the drive, seeking to various tracks on the disk, and spinning the drive down again. It is limited to using 1.44M 3.5" HD disks in the first disk drive. Anyway, here it is. It goes in movitz/losp/x86-pc/, and you may need to modify all.lisp in the same directory to load it. --Alastair Bridgewater -------------- next part -------------- ;;; ;;; floppy.lisp ;;; ;;; First-cut floppy driver ;;; (provide :x86-pc/floppy) (defpackage muerte.x86-pc.floppy (:use muerte.cl muerte muerte.lib muerte.x86-pc)) (in-package muerte.x86-pc.floppy) ;;; ;;; At this time, this driver is only capable of spinning up the drive motor ;;; and seeking to different tracks on a 1.44M 3.5" HD disk. ;;; ;;; In order to use the driver, do: ;;; ;;; (setf *package* (find-package "X86-PC.FLOPPY")) to switch to this package. ;;; ;;; (fd-start-disk) to initialize the controller and spin the drive up. ;;; ;;; (fd-seek 70) to seek to track 70. ;;; ;;; (setf (fd-motor) nil) to turn the drive and controller off. ;;; ;;; Variations on this theme include: seeking to different tracks. ;;; ;; I/O port locations (defconstant +fd-main-status-register+ #x3f4) (defconstant +fd-data-register+ #x3f5) (defconstant +fd-digital-output-register+ #x3f2) (defconstant +fd-that-other-register+ #x3f7) ;; Basic accessors (defun fd-status () (io-port +fd-main-status-register+ :unsigned-byte8)) (defun fd-data () (io-port +fd-data-register+ :unsigned-byte8)) (defun (setf fd-data) (value) (setf (io-port +fd-data-register+ :unsigned-byte8) value)) (defun (setf fd-dor) (value) (setf (io-port +fd-digital-output-register+ :unsigned-byte8) value)) ;; Fundamental operations (defun (setf fd-motor) (value) (if (null value) (setf (fd-dor) 0) (progn ;; FIXME: Should delay after this setf for motor to come up to speed. (setf (fd-dor) #x1c)))) (defun fd-wait-ready () "Returns #x40 if fdc is expecting a read next." (loop for status = (fd-status) when (not (zerop (logand #x80 status))) return (logand #x40 status))) (defun fd-write-data (value) (unless (zerop (fd-wait-ready)) (error "FDC expecting read when we want to write.")) (setf (fd-data) value)) (defun fd-read-data () (when (zerop (fd-wait-ready)) (error "FDC expecting write when we want to read.")) (fd-data)) ;; Basic commands (defun fd-cmd-specify (byte1 byte2) (fd-write-data #x03) (fd-write-data byte1) (fd-write-data byte2)) (defun fd-cmd-sense-interrupt-status () (let ((dsr0) (cylinder) (status)) (loop doing (fd-write-data 8) (setf dsr0 (fd-read-data)) (setf status (fd-wait-ready)) until (not (zerop status))) (setf cylinder (fd-read-data)) (values dsr0 cylinder))) (defun fd-cmd-recalibrate () (fd-write-data 7) (fd-write-data 0) (fd-cmd-sense-interrupt-status)) (defun fd-cmd-seek (cylinder) (fd-write-data #xf) (fd-write-data 0) (fd-write-data cylinder) (fd-cmd-sense-interrupt-status)) (defun fd-initialize-controller () (setf (fd-motor) nil) (setf (io-port +fd-that-other-register+ :unsigned-byte8) 0) (setf (fd-dor) #xc) (fd-cmd-specify #xdf #x02)) (defun fd-start-disk () (fd-initialize-controller) (dotimes (i 4) (fd-cmd-sense-interrupt-status)) (setf (fd-motor) t) (fd-cmd-recalibrate)) ;;; EOF From ffjeld at common-lisp.net Sun Jan 18 21:25:49 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Sun, 18 Jan 2004 22:25:49 +0100 Subject: [movitz-devel] First-cut floppy driver In-Reply-To: <20040118150804.GA30396@miyu.paradiesanalytics.com> (nyef@softhome.net's message of "Sun, 18 Jan 2004 10:08:04 -0500") References: <20040118150804.GA30396@miyu.paradiesanalytics.com> Message-ID: <2had4leyoy.fsf@vserver.cs.uit.no> Nyef writes: > Attached is a first cut for a floppy driver. [..] Thanks! I thought I'd just offer some comments about style etc. (Of course, I'd appreciate other's comments and views too.) > Anyway, here it is. It goes in movitz/losp/x86-pc/, and you may need > to modify all.lisp in the same directory to load it. The all.lisp was something I added so I could conveniently include everything in the los0 image, which has been functioning as a testing base. And, the whole require/provide design isn't very good. If anyone has ideas about for example some defsystem design, that'd be great. > ;;; (setf *package* (find-package "X86-PC.FLOPPY")) to switch to > ;;; this package. There's a toplevel-command :package that does this easier. E.g. INIT> :pa x86-pc.floppy X86-PC.FLOPPY> > ;; I/O port locations > > (defconstant +fd-main-status-register+ #x3f4) > (defconstant +fd-data-register+ #x3f5) > (defconstant +fd-digital-output-register+ #x3f2) > (defconstant +fd-that-other-register+ #x3f7) If there's any chance at all that a floppy controller can live at another I/O base address (?), relavtive addressing should be used. > (defun fd-status () > (io-port +fd-main-status-register+ :unsigned-byte8)) I think it's pointless to both have a separate package and prefix every symbol. Packages are name-spaces (not software modules), so I'm leaning towards for example that the floppy driver should live in the x86-pc package. BTW I plan on renaming muerte.x86-pc to just x86-pc. The muerte prefix is really a remnant from a previous scheme where every movitz package was required to have such a prefix. > (defun (setf fd-motor) (value) > (if (null value) > (setf (fd-dor) 0) > (progn > ;; FIXME: Should delay after this setf for motor to come up to speed. > (setf (fd-dor) #x1c)))) It's a very good idea I believe to ensure that every setf function returns the value argument. Sooner or later, someone will be very surprised when they discover that (setf (fd-motor) nil) returns #x0. Great work! Now who's volunteering for PCI, IDE, USB, SCSI, SVGA & friends? :-) -- Frode Vatvedt Fjeld From nyef at softhome.net Sun Jan 18 22:13:00 2004 From: nyef at softhome.net (Nyef) Date: Sun, 18 Jan 2004 17:13:00 -0500 Subject: [movitz-devel] First-cut floppy driver In-Reply-To: <2had4leyoy.fsf@vserver.cs.uit.no> References: <20040118150804.GA30396@miyu.paradiesanalytics.com> <2had4leyoy.fsf@vserver.cs.uit.no> Message-ID: <20040118221300.GA30825@miyu.paradiesanalytics.com> On Sun, Jan 18, 2004 at 10:25:49PM +0100, Frode Vatvedt Fjeld wrote: > Nyef writes: > > > Attached is a first cut for a floppy driver. [..] > > Thanks! No problem. > I thought I'd just offer some comments about style etc. (Of course, > I'd appreciate other's comments and views too.) > The all.lisp was something I added so I could conveniently include > everything in the los0 image, which has been functioning as a testing > base. So is this a file that should be added to, or not? > And, the whole require/provide design isn't very good. If anyone has > ideas about for example some defsystem design, that'd be great. Is there some way we could use ASDF? > > ;;; (setf *package* (find-package "X86-PC.FLOPPY")) to switch to > > ;;; this package. > > There's a toplevel-command :package that does this easier. E.g. Heh. I should have known I was missing a trick. > > ;; I/O port locations > > > > (defconstant +fd-main-status-register+ #x3f4) > > (defconstant +fd-data-register+ #x3f5) > > (defconstant +fd-digital-output-register+ #x3f2) > > (defconstant +fd-that-other-register+ #x3f7) > > If there's any chance at all that a floppy controller can live at > another I/O base address (?), relavtive addressing should be used. I am under the impression that such a hardware configuration is rather rare, at best. It is not something I am going to lose sleep over. Oh yeah, and I should find the correct name for +fd-that-other-register+. It's not listed in the source or documentation I was looking at recently. > > (defun fd-status () > > (io-port +fd-main-status-register+ :unsigned-byte8)) > > I think it's pointless to both have a separate package and prefix > every symbol. Packages are name-spaces (not software modules), so I'm > leaning towards for example that the floppy driver should live in the > x86-pc package. Okay, so I should leave the prefixes and assume that the package will be going away at some point? > > (defun (setf fd-motor) (value) > > (if (null value) > > (setf (fd-dor) 0) > > (progn > > ;; FIXME: Should delay after this setf for motor to come up to speed. > > (setf (fd-dor) #x1c)))) > > It's a very good idea I believe to ensure that every setf function > returns the value argument. Sooner or later, someone will be very > surprised when they discover that > > (setf (fd-motor) nil) > > returns #x0. So noted. I'll fix that. > Great work! Thank you. > Now who's volunteering for PCI, IDE, USB, SCSI, SVGA & friends? :-) Well, I've only ever done PCI through direct hardware access, not through the BIOS32 directory, the IDE driver I have for some reason locks up during relatively high-speed read/write combinations, I've only done a driver for the base VGA card (which, when last tested, breaks bochs), not for any SVGA devices, and I haven't messed with USB or SCSI before. That said, I was thinking about possibly transliterating the VGA mode switch code that I have. I'm just not sure what good it would do without a set of VGA textmode fonts and some sort of usable graphics model. --Alastair Bridgewater From joels at mobyfoo.org Mon Jan 19 16:45:14 2004 From: joels at mobyfoo.org (Joel Smith) Date: Mon, 19 Jan 2004 16:45:14 +0000 (GMT) Subject: [movitz-devel] Driver problems Message-ID: Hi everyone, I'm having some real problems writing a graphics driver for movitz. I need full 32bit data width for both reading and writing to the graphics ioports. Is there any sort of support for unboxed 32bit fixnums? My current kludge for this problem is to create a structure with two values to represent each half of the 32bits. This works nicely for writing to the ioports, but I can't figure out how to store the data read back from the ioports back into the structure's slots. How do you store data into a structure from within 'with-inline-assembly'? Well I think thats all my problems for now ;) I just wanted to say a big THANKS to Frode for working on movitz!!! This stuff is really cool. By the way, is anyone interested in using movitz to write a proper LispOS? Is movitz going to stay purely a dev platform or is it going to turn into a full LispOS project? Happy Hacking, Joel. From ffjeld at common-lisp.net Mon Jan 19 17:03:03 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Mon, 19 Jan 2004 18:03:03 +0100 Subject: [movitz-devel] Driver problems In-Reply-To: (Joel Smith's message of "Mon, 19 Jan 2004 16:45:14 +0000 (GMT)") References: Message-ID: <2had4jeurc.fsf@vserver.cs.uit.no> Joel Smith writes: > I'm having some real problems writing a graphics driver for > movitz. I need full 32bit data width for both reading and writing to > the graphics ioports. Is there any sort of support for unboxed 32bit > fixnums? No, this is still one of the rather rough edges of Movitz. It needs to be worked out sooner or later, but in the mean time, is it possible to use a simpler mode with 8 or 16-bit IO access for the driver? > My current kludge for this problem is to create a structure with two > values to represent each half of the 32bits. This works nicely for > writing to the ioports, but I can't figure out how to store the data > read back from the ioports back into the structure's slots. How do > you store data into a structure from within 'with-inline-assembly'? It shouldn't be so difficult if you know assembly and look at the definition of the movitz-struct class. But this kind of stuff is likely to change, so again I think it'd be wiser at this point of development to write at least one driver that is likely to work, before doing something more optimized. > By the way, is anyone interested in using movitz to write a proper > LispOS? Is movitz going to stay purely a dev platform or is it going > to turn into a full LispOS project? I'd certainly like to see a LispOS happen (or two..), but somewhat independently of Movitz itself, in a layered kind of way. Discussions about the design of such an OS is something I'd like to see here on the list. But I suppose Movitz needs to stabelize a bit before something substantial happens on the OS level. -- Frode Vatvedt Fjeld From weel at caltech.edu Tue Jan 20 06:49:41 2004 From: weel at caltech.edu (Jaap Weel) Date: Mon, 19 Jan 2004 22:49:41 -0800 Subject: [movitz-devel] Bochs trouble Message-ID: Hello to all! Let me start of by saying that I'm very impressed by Movitz. When I copy the image onto a 3.5" disk, go find a PC, and boot it, all is fine. When I try to run it on my little Macintosh under bochs, however, the (virtual) system reboots as soon as it's done loading. My bochsrc file looks like this: +--- romimage: file=$BXSHARE/BIOS-bochs-latest,address=0xf0000 megs: 2 vgaromimage: $BXSHARE/VGABIOS-elpin-2.40 floppya: 720k="los0.img", status=inserted boot: a log: bochsout.txt panic: action=ask error: action=report info: action=report debug: action=ignore ips: 3000000 mouse: enabled=0 +--- I have also tried allowing 64 rather than 2 MB of memory. The bochs screen does this: +--- VGA BIOS - Version 2.40 [...] Bochs BIOS [...] Booting from Floppy... Loading Movitz 1875.. ()()()()()()()()()()()()()() [...] Enter..Ok +--- at which point it restarts and happily does the same thing again. The log file looks like this: +--- 00000000000i[ ] Bochs x86 Emulator 2.1 00000000000i[ ] January 11, 2004 00000000000i[ ] System configuration 00000000000i[ ] processors: 1 00000000000i[ ] A20 line support: yes 00000000000i[ ] APIC support: no 00000000000i[ ] CPU configuration 00000000000i[ ] level: 5 00000000000i[ ] fpu support: yes 00000000000i[ ] paging support: yes, tlb enabled: yes 00000000000i[ ] mmx support: yes 00000000000i[ ] sse support: no 00000000000i[ ] v8086 mode support: yes 00000000000i[ ] 3dnow! support: no 00000000000i[ ] PAE support: no 00000000000i[ ] PGE support: no 00000000000i[ ] PSE support: no 00000000000i[ ] x86-64 support: no 00000000000i[ ] SEP support: no 00000000000i[ ] Optimization configuration 00000000000i[ ] Guest2HostTLB support: no 00000000000i[ ] RepeatSpeedups support: no 00000000000i[ ] Icache support: no 00000000000i[ ] Host Asm support: yes 00000000000i[MEM0 ] allocated memory at 0x505000. after alignment, vector=0x505000 00000000000i[MEM0 ] 2.00MB 00000000000i[MEM0 ] rom at 0xf0000/65536 ('./BIOS-bochs-latest') 00000000000i[MEM0 ] rom at 0xc0000/32769 ('./VGABIOS-elpin-2.40') 00000000000i[CMOS ] Using local time for initial clock 00000000000i[CMOS ] Setting initial clock to: Mon Jan 19 13:25:15 2004 (time0=1074547515) 00000000000i[DMA ] channel 4 used by cascade 00000000000i[DMA ] channel 2 used by Floppy Drive 00000000000i[FDD ] fd0: 'los0.img' ro=0, h=2,t=80,spt=9 00000000000i[XGUI ] test_alloc_colors: 16 colors available out of 16 colors tried 00000000000i[XGUI ] font 8 wide x 16 high, display depth = 24 00000000000i[VGA ] interval=30000 00000000000i[ ] init_mem of 'harddrv' plugin device by virtual method 00000000000i[ ] init_mem of 'keyboard' plugin device by virtual method 00000000000i[ ] init_mem of 'serial' plugin device by virtual method 00000000000i[ ] init_mem of 'parallel' plugin device by virtual method 00000000000i[ ] init_mem of 'extfpuirq' plugin device by virtual method 00000000000i[ ] init_dev of 'harddrv' plugin device by virtual method 00000000000i[HD ] Boot device will be 'a' 00000000000i[HD ] Floppy boot signature check is enabled 00000000000i[ ] init_dev of 'keyboard' plugin device by virtual method 00000000000i[KBD ] will paste characters every 1000 keyboard ticks 00000000000i[ ] init_dev of 'serial' plugin device by virtual method 00000000000i[SER ] com1 at 0x03f8 irq 4 00000000000i[ ] init_dev of 'parallel' plugin device by virtual method 00000000000i[PAR ] parallel port 1 at 0x378 irq 7 00000000000i[ ] init_dev of 'extfpuirq' plugin device by virtual method 00000000000i[ ] reset of 'harddrv' plugin device by virtual method 00000000000i[ ] reset of 'keyboard' plugin device by virtual method 00000000000i[ ] reset of 'serial' plugin device by virtual method 00000000000i[ ] reset of 'parallel' plugin device by virtual method 00000000000i[ ] reset of 'extfpuirq' plugin device by virtual method 00000000000i[XGUI ] [x] Mouse off 00000003980i[BIOS ] rombios.c,v 1.85 2002/12/13 16:26:17 cbothamy Exp $ 00000090000e[VGA ] character height = 1, skipping text update 00000180000e[VGA ] character height = 1, skipping text update 00000270000e[VGA ] character height = 1, skipping text update 00000360000e[VGA ] character height = 1, skipping text update 00000450000e[VGA ] character height = 1, skipping text update 00000540000e[VGA ] character height = 1, skipping text update 00000540051i[KBD ] reset-disable command received 00000630000e[VGA ] character height = 1, skipping text update 00000720000i[XGUI ] charmap update. Font Height is 16 00012351354e[HD ] device set to 0 which does not exist 00012351647e[HD ] device set to 1 which does not exist 00013907541i[CPU ] WBINVD: (ignoring) 00013907590e[CPU ] load_seg_reg: LDT invalid 00013907590e[CPU ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting 00013911570i[BIOS ] rombios.c,v 1.85 2002/12/13 16:26:17 cbothamy Exp $ 00014340071i[KBD ] reset-disable command received 00014490000i[XGUI ] charmap update. Font Height is 16 00026183802e[HD ] device set to 0 which does not exist 00026184095e[HD ] device set to 1 which does not exist 00027739971i[CPU ] WBINVD: (ignoring) 00027740020e[CPU ] load_seg_reg: LDT invalid [repeats itself many times from here onwards] +--- It boots up a FreeDOS floppy image just fine. Does anyone have an idea about what the problem might be? I gather it must probably be contained in "00013907541i[CPU ] WBINVD: (ignoring) 00013907590e[CPU ] load_seg_reg: LDT invalid 00013907590e[CPU ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting", but I don't really now what WBINVD and LDT mean. Also, when I get this running, I think I should post a sample bochsrc file to og along with the floppy image. As you see, they are short, but they can be quite tricky at times. I've previously spent many potentially productive hours getting some of the incantations right for more complicated virtual systems with hard drives, CDROMs and the like. /jaap ======================================================================== Jaap Weel Campus address: | dorm (626) 795-9748 Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A. www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033 E-mail: weel at caltech.edu Kelderstraat 2-4, 6171 GB Stein, Netherlands ======================================================================== From ffjeld at common-lisp.net Tue Jan 20 11:24:43 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 20 Jan 2004 12:24:43 +0100 Subject: [movitz-devel] Bochs trouble In-Reply-To: (Jaap Weel's message of "Mon, 19 Jan 2004 22:49:41 -0800") References: Message-ID: <2hzncidfr8.fsf@vserver.cs.uit.no> Hello, Jaap Weel writes: > [..] My bochsrc file looks like this: > > +--- > romimage: file=$BXSHARE/BIOS-bochs-latest,address=0xf0000 > megs: 2 The los0 image simply initializes the consing pointer to the 2 MB mark, so you want somewhat more than this configured. > floppya: 720k="los0.img", status=inserted This is the main culprit, most likely. Movitz' bootloader assumes the 1_44 floppy geometry. Probably this should be checked for somehow, not just ignoring the issue and ending up with loading random junk. Then again, the loader is confined to 512 bytes, so there's a limit to what it can do. Anyway, problems that are the related to loading tends to go away when using the grub loader. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Tue Jan 20 16:07:05 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 20 Jan 2004 17:07:05 +0100 Subject: [movitz-devel] Driver problems In-Reply-To: (Joel Smith's message of "Mon, 19 Jan 2004 16:45:14 +0000 (GMT)") References: Message-ID: <2hvfn6d2om.fsf@vserver.cs.uit.no> Joel Smith writes: > I'm having some real problems writing a graphics driver for > movitz. I need full 32bit data width for both reading and writing to > the graphics ioports. Is there any sort of support for unboxed 32bit > fixnums? I just checked in the beginnings of a new operator that might help you. It's muerte:%io-port-read-succession, and you should be able to use it like this: (%io-port-read-succession port object 2 0 1 :32-bit) ..to read a 32-bit port into the first slot in a struct. The 2 is the offset in bytes from the object's address, and 0 1 are start and end delimiters, considering the memory as an array of 32-bit words. However, this wouldn't be a good idea, because struct slots are lisp words. You'd better use for example a vector specialized to (unsigned-byte 8). The usage would be the same. Another example: (%io-port-read-succession #x100 (make-array 8 :element-type '(unsigned-byte 8)) 2 0 2 :32-bit) ..will read #x100 as a 32-bit io-port twice, and the value of the first is in positios 0-3 of the array, the second in 4-7. -- Frode Vatvedt Fjeld From joels at mobyfoo.org Tue Jan 20 17:40:27 2004 From: joels at mobyfoo.org (Joel Smith) Date: Tue, 20 Jan 2004 17:40:27 +0000 (GMT) Subject: [movitz-devel] Driver problems In-Reply-To: <2hvfn6d2om.fsf@vserver.cs.uit.no> References: <2hvfn6d2om.fsf@vserver.cs.uit.no> Message-ID: Hello, On Tue, 20 Jan 2004, Frode Vatvedt Fjeld wrote: > I just checked in the beginnings of a new operator that might help > you. It's muerte:%io-port-read-succession, and you should be able to > use it like this: > > (%io-port-read-succession port object 2 0 1 :32-bit) > That's great! I think it's just what I need. I assume you are going to add an operator for writing to ports as well? I am a little worried about the lack of a defined API for the device code. I worry that when people start writing drivers for Muerte then they will all start doing their own thing in terms of the API. I realize that you wish to have only a "very thin abstraction over the hardware" and not a proper driver, which I tend to agree with, but don't we still need some sort of low level API for the various classes of devices. If/when in the future someone comes to write proper drivers for a LispOS based on Movitz they are going to have a terrible time trying to support all the Muerte device code which shares no common interface. What do people think about this? Happy Hacking, Joel. From weel at caltech.edu Tue Jan 20 19:34:01 2004 From: weel at caltech.edu (Jaap Weel) Date: Tue, 20 Jan 2004 11:34:01 -0800 Subject: [movitz-devel] Bochs trouble In-Reply-To: <2hzncidfr8.fsf@vserver.cs.uit.no> References: <2hzncidfr8.fsf@vserver.cs.uit.no> Message-ID: <99B12ED2-4B7F-11D8-B1D6-000A959B403C@caltech.edu> I got it working now. But then, once I got it working, I removed some newlines from the bochsrc. And it stopped working. But then I got it working again. I quite clearly rememember that earlier, on 1_44 it didn't work at all, which is why I had switched it to 720k. Ah well, black magic, shall we say. Thanks a lot, Frode! Here's the bochsrc that has been shown to work: +-----------------bochsrc.txt------------- romimage: file="$BXSHARE/BIOS-bochs-latest", address=0xf0000 megs: 64 vgaromimage: $BXSHARE/VGABIOS-elpin-2.40 floppya: 1_44="los0.img", status=inserted boot: a log: bochsout.txt panic: action=ask error: action=report info: action=report debug: action=ignore ips: 5000000 mouse: enabled=0 +----------------------------------------- On 20 Jan 2004, at 03:24, Frode Vatvedt Fjeld wrote: > > The los0 image simply initializes the consing pointer to the 2 MB > mark, so you want somewhat more than this configured. > >> floppya: 720k="los0.img", status=inserted > > This is the main culprit, most likely. Movitz' bootloader assumes the > 1_44 floppy geometry. Probably this should be checked for somehow, not > just ignoring the issue and ending up with loading random junk. Then > again, the loader is confined to 512 bytes, so there's a limit to what > it can do. Anyway, problems that are the related to loading tends to > go away when using the grub loader. ======================================================================== Jaap Weel Campus address: | dorm (626) 795-9748 Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A. www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033 E-mail: weel at caltech.edu Kelderstraat 2-4, 6171 GB Stein, Netherlands ======================================================================== From ffjeld at common-lisp.net Tue Jan 20 20:09:57 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 20 Jan 2004 21:09:57 +0100 Subject: [movitz-devel] Driver problems In-Reply-To: (Joel Smith's message of "Tue, 20 Jan 2004 17:40:27 +0000 (GMT)") References: <2hvfn6d2om.fsf@vserver.cs.uit.no> Message-ID: <2hn08icrfu.fsf@vserver.cs.uit.no> Joel Smith writes: > That's great! I think it's just what I need. I assume you are going > to add an operator for writing to ports as well? Yes, that's the plan. > I am a little worried about the lack of a defined API for the device > code. I worry that when people start writing drivers for Muerte then > they will all start doing their own thing in terms of the API. I > realize that you wish to have only a "very thin abstraction over the > hardware" and not a proper driver, which I tend to agree with, but > don't we still need some sort of low level API for the various > classes of devices. If/when in the future someone comes to write > proper drivers for a LispOS based on Movitz they are going to have a > terrible time trying to support all the Muerte device code which > shares no common interface. What do people think about this? I think there's a slight chicken-and-egg problem here: It's hard to specify an API before we have experience with writing a few drivers. I think that the process will be like write a few drivers, tighten up the API and update existing code, and so there is a decent API for when/if the code-base grows. In my experience it's not so dificult to change existing code. So for example, I'm expecting to remove the io-read/write-sequence functions, which now seem to me quite ill-designed. -- Frode Vatvedt Fjeld From ffjeld at common-lisp.net Wed Jan 21 10:08:36 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Wed, 21 Jan 2004 11:08:36 +0100 Subject: [movitz-devel] Low-level things Message-ID: <2hr7xtbom3.fsf@vserver.cs.uit.no> I checked in the writer companion to %io-port-read-succession yesterday, %io-port-write-succession. These operators move untyped data (in units of 8, 16 or 32 bits) between memory and I/O ports. I've tried to introduce the % notation from the lisp-machines. It's my understanding that operator-names beginning with % signalled an unsafe operation, that if not used with care could damage the run-time invariants. The idea (on my part) is that such operators are the building blocks above which more useable operators are written, that take care of appropriate type-checking etc. before doing the dangerous operation. -- Frode Vatvedt Fjeld From james at unlambda.com Thu Jan 22 07:00:01 2004 From: james at unlambda.com (James A. Crippen) Date: Wed, 21 Jan 2004 22:00:01 -0900 Subject: [movitz-devel] Low-level things In-Reply-To: <2hr7xtbom3.fsf@vserver.cs.uit.no> (Frode Vatvedt Fjeld's message of "Wed, 21 Jan 2004 11:08:36 +0100") References: <2hr7xtbom3.fsf@vserver.cs.uit.no> Message-ID: Frode Vatvedt Fjeld writes: > I've tried to introduce the % notation from the lisp-machines. It's my > understanding that operator-names beginning with % signalled an unsafe > operation, that if not used with care could damage the run-time > invariants. Yes, the % operators are those which should be considered wizardly incantations not for use by mere mortals, but only by Masters Who Know What They Are Doing. % functions were assumed to not do any sort of safety checking on their arguments. Often a %FOO operation disregards type information, and may correspond to a single low-level machine instruction, like %LOGDPB or %CRASH. They might be used by people who wanted faster code in certain places, and who could guarantee safety by other means. There are also %% constants which contain assorted bits and bytes that are supposed to be unknown or invisible to anyone but implementors. Like %%Q-HIGH-HALF, %%PAGE-HASH-TABLE-AGE, or %%KBD-ALL-CONTROL-BITS. I don't think that %% were ever functions, only constants. They were definitely not for ordinary users. Also, the SI package was the container for a large amount of the system. It stood for SYSTEM-INTERNALS or something like that. It was where things inside the system that were meant for Mere Mortals to use were exported as external symbols. SBCL calls the same thing SB-SYS and SB-EXT, I think. 'james -- James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))