[movitz-devel] First-cut floppy driver

Nyef nyef at softhome.net
Sun Jan 18 22:13:00 UTC 2004


On Sun, Jan 18, 2004 at 10:25:49PM +0100, Frode Vatvedt Fjeld wrote:
> Nyef <nyef at softhome.net> 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




More information about the movitz-devel mailing list