Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9386

Re: A FAT32 bus mouse

Show all headers | View raw

Rod Pemberton" wrote:
> "Benjamin David Lunt" wrote:

>> Anyway, I think I know why Mike has created the Virtual
>> FAT32 concept and I may go investigate it a bit more.
>> He is just like me, and probably the rest of us, messed
>> up beyond words, but enjoy the hobbies we have. :-)
>
> My guess is that it pairs with his SudoBIOS extender

My proof-of-concept BootStrap32 boot loader (which of
course uses SudoBIOS) follows the AOD Virtual Partition
Specification and Protocol.

Like other boot loaders BootStrap32 uses "BIOS extension"
to load the executable file. This, however is where the
similarity ends.

Unlike the other loaders, the loaded file also has full
access to the PM32 SudoBIOS (which itself is written in C
and uses a low level "C" interface to access the RM16
native motherboard BIOS), a well as full access to same
low level access that SudoBIOS uses and requires no asm
(inline or otherwise) to do so. SudoBIOS is a high level
subset of the BIOS. There are also two similar high/low
level interfaces for asm. It might seem a bit funny that
the low level asm interface which provides full access the
RM16 native motherboard BIOS does not use the "int"
instruction but rather stack based parameter passing even
though it is written in asm and not C. Asm code uses the
"int" to access SudoBIOS. Asm code can also use the
SudoBIOS "C" stack based parameter passing interface.

The other difference is that Bootstrap32 does only two
things. In addition to loading the file it updates the BIOS
Parameter Block - Drive ID field with the actual BIOS
return "DL" value. Everything else, such as a memory map or
a video mode change etc. can easily be obtained (with the
use of SudoBIOS) by the loaded file itself.

> and goes with the 16-bit IO.SYS or other device driver
> code from MS-DOS v7.10 (Windows 98/SE) that he is using.

That was just a silly idea that I have long since
abandoned.

> Good guess? ...  E.g., perhaps he is shoving the 32-bit
> layer back one more level.

Close.
Currently I have no plans to rewrite the BIOS (or for that
matter hardware drivers) in PM32 - extending the RM16 BIOS
even with it shortcomings (actual or perceived) works
perfectly fine for me. I also have no plans to "extend"
anything other than the RM16 BIOS.

> Mike can be rather terse at times.  So, it's not always
> obvious to me what he is getting at.  Sorry Mike.  I'd
> rather have a description of where I could or why I
> should use his stuff than all the technical details up
> front, but we still need that stuff after the fact.

That's a very good suggestion, especially with all the
confusion surrounding the Virtual Partition. A much better
"presentation" will be forthcoming soon in the promised
AOD Virtual Partition Specification and Protocol.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta 

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A FAT32 bus mouse "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-04-01 11:57 -0700
  Re: A FAT32 bus mouse "wolfgang kern" <nowhere@never.at> - 2016-04-01 21:41 +0200
  Re: A FAT32 bus mouse Bernhard Schornak <schornak@web.de> - 2016-04-01 23:15 +0200
  Re: A FAT32 bus mouse Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-01 21:23 -0400
    Re: A FAT32 bus mouse "Mike Gonta" <mikegonta@gmail.com> - 2016-04-03 08:50 -0400
      Re: A FAT32 bus mouse James Harris <james.harris.1@gmail.com> - 2016-04-04 14:19 +0100

csiph-web