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

[albert@xxxxxxxxxxxxxxxxxx (Albert van der Horst)]

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