[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