RE: Assembler or machinecode. BIOS or direct

Hi Chris,

The proof of the pudding....
I hope it is as easy as you say,

Regards

Howerd

-----Original Message-----
From: Chris Walton [mailto:[email protected]]
Sent: 16 April 2005 20:53
To: [email protected]
Subject: Re: [colorforth] Assembler or machinecode. BIOS or direct


Soemthing that is not necessarily fast, but feasible in such a simple
environment such as colorforth is to simply leave protected mode, do
the BIOS action, then reenter protected mode.

On 4/16/05, howerd.oakford <[email protected]> wrote:
> Hi Albert,
>
> There was a thread in clf ( I think ) about making 16 bit BIOS calls from
a
> 32 bit protected mode program.
> I was rather put off the idea : it seems that you have to create a cosy 16
> bit environment for the BIOS program to live in. This includes any
interrupt
> routines that it may decide to use. In particular, the floppy disk BIOS
> calls probably require the system timer tick interrupt, and who knows what
> else. This would probably be an order of magnitude more complex than the
> system we are trying to boot...
>
> Your mission ( should you choose to accept it ) is to make BIOS calls from
> 32 bit protected mode, and to return unharmed.
> If you fail we shall, of course, disclaim all knowledge....
>
> But if you succeed, we may have a universal colorForth! And booting from
USB
> should be a doddle!!
>
> Good luck. This message will self destruct in 5 seconds, but archived
copies
> will be available for all eternity ;)
>
> Howerd  8^)
>
>
> -----Original Message-----
> From: Albert van der Horst [mailto:[email protected]]
> Sent: 14 April 2005 00:29
> To: [email protected]
> Subject: Re: [colorforth] Assembler or machinecode. BIOS or direct
>
> On Wed, Apr 13, 2005 at 08:51:47AM -0400, Dr Nick Maroudas wrote:
> > >On Apr 10, 2005 8:01 PM, Ray St. Marie
> > <[email protected]> wrote:
> <SNIP>
> > and Chris Walton wrote:
> >
> > > (snip)
> > >
> > >You know, I've written a lot of bootsectors and I'd be
> > willing to
> > >write one thats a bit less selective about the
> > hardware, and is a
> > >drop-in replacement for the colorforth one.  (snip)
> > > Regards, Chris
> >
> > Nick here:
> >
> > Chris, your unfussy bootsector might answer those pleas
> > for help that pop up regularly in the CF list.    As I
> > understand it, Chuck's boot.asm has no BIOS calls.
> > Surely the BIOS exists for the very good reason that
> > each manufacturer of a specific, quirky piece of
> > hardware (the "BrandX" PC) is obliged to provide a
> > reliable interface for software in general?   Terry
> > increased the number of successful boots by adding one
> > little trick from a BIOS onto Chuck's code. So why not
> > try a modular boot segment that calls more of the PC's
> > own BIOS?  Wouldn't this increase success with different
> > "BrandX" PCs?
>
> May I second this?
>
> It makes perfect sense for Chuck Moore to jump directly into
> protected mode and access the floppy, because he needs to
> access the floppy in protected mode anyway.
>
> For us that want to make colorforth available to as large a number of
> people available the situation is totally different.
> For us it is better to use guaranteed and portable methods to at least
> boot colorforth.
> Once colorforth runs, a number of tests can be done to
> figure out the floppy access. We have then colorforth available
> to sort things out. A more or less sophisticated process can be
> used that would be totally unfeasible during booting.
>
> > One could also add a short overall explanation of what
> > the CF core needs for a boot.  Tim has already added
> > some helpful comments to his two nasm versions of
> > Chuck's masm listing (colorN.asm & cmcolor.lst).
> > Terry's 4Word "colorless colorforth" also contains
> > helpful documentation.  But there is no overall
> > explanation of what the boot needs to set up in terms of
> > CF's architecture; certainly not the way that people
> > used to write whole books explaining FIG & F83.
>
> I have been busy with the boot image.
> The first sector contains boot code and a global descriptor
> table.
> The booting proceeds like this (this code all sits in the first
> sector):
> - It first copies itself to address 0. (From address 0xC700).
> - Jumps down to proceed executing code from the copy
> - It installs the global descriptor table
> - It switches to protected mode
> - It reads the remainder of the sectors to address 0x200
>  and beyond, directly.
>
> This is all straightforward, but the direct reading of sectors
> in protected mode may fail depending on the hardware.
>
> If the image is to be read using the BIOS this has to be changed to
> - Read the remainder of the image (to address 0xC700 + 0x200)
> - Copy the whole image to address 0
> - Jumps down to proceed executing code from the copy
> - Install the global descriptor table
> - Switch to protected mode
>
> The image may contain screens of code to find out how the floppy
> (or other device) is to be accessed.
>
> >
> > Regards,
> >
> > Nick
> >
>
> Groetjes Albert
>
> --
> Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
> Economic growth -- like all pyramid schemes -- ultimately falters.
> [email protected] http://home.hccnet.nl/a.w.m.van.der.horst
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> Main web page - http://www.colorforth.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> Main web page - http://www.colorforth.com
>
>


--
Chris Walton
arke on irc.freenode.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Main web page - http://www.colorforth.com