RE: [colorforth] Assembler or machinecode. BIOS or direct

["howerd.oakford" <howerd.oakford@xxxxxxxxxxxx>]

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:albert@xxxxxxxxxxxxxxxxxx]
Sent: 14 April 2005 00:29
To: colorforth@xxxxxxxxxxxxxxxxxx
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
> <ray.stmarie@xxxxxxxxx> 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.
albert@xxxxxxxxxxxxxxxxxx http://home.hccnet.nl/a.w.m.van.der.horst

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com




---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com