>>>>>>>>>>>>>>>>>>> part of news posting by Roderik 2001090?

In the meantime I'll jot down some first information (containing big holes)
from the top of my head...


For starters,
- MAP.COM was written by Gert de Boom
- the Novaxis SCSI BIOS was written by Jurgen Kramer - you've got the info
from that one on ftp.funet.fi already, apparently.
- NFDISK was written by me, using windowing routines from Jeffrey Timmer and
in v1.2 some code from a friend from a friend in Tilburg, whose name I
forgot...

As far as I can make out, it's the info on the partition types you're
looking for.

Manuel wrote:
> Partitiontype : MAK 3.0
> Partitiontype : Extended
> Partitiontype : BERT/HPN
> Partitiontype : Old PC
> Partitiontype : Old MSX

*churn churn*
*braindamage*
...oh no, this is not going to work...
I think I wrote some documentation on it. I hope so, since I'm not planning
to delve into assembly code in order to get that info. (Although it would be
nice to see how unstructured I programmed back then :-)

What I still remember is that the partition table (on sector 0 of the
harddisk, before any partitions) contains sets of 32 bytes of info for each
partition. There should be documents available _somewhere_ which detail
this, since it's used on every PC...

The 'old PC' format is exactly the same as PC's without extended partitions.
There can be 4 partitions maximum, i.e. 4 times 32 bytes.

The 'old MSX' format was exacly the same format but used up to 8 partitions.
(It just placed the same 4*32 bytes of information behind (or before?) the
4*32 bytes for the PC partitions because there is room for that. I have no
idea why all PCs did not just do it like this.) It must have been used in
some older interfaces (MAK? others? which ones were there? I don't
remember.)

The 'MAK 3.0' format also has room for 8 partitions, but did something
different, so it's not compatible with the other format. (Maybe the offset
of the area of 8*32 bytes is different from PCs, maybe the order of the data
inside the 32 bytes is different from PCs; I don't know...)

The 'Extended' format uses sectors elsewhere on the disk, as does the
BERT/HPN format.
The fourth entry in the 'normal pc' partition table in this case does not
contain data about a partition, but points to another sector somewhere on
the harddisk which holds data on more partitions (i.e. more sets of these 32
bytes, at the same position as sector 0). That's the main idea.
On normal PC's, this is only done once, i.e. you have maximum 2 sectors with
partition data - one with info about 3 partitions + a pointer to the second
sector, and one with 4 partitions. So you can have max. 7 partitions on a
PC.

Note that this format is NOT supported by NFDISK (or any other MSX program I
know). Back then I did not know anything about how the PC does extended
partitions, so I just created some partitions with a BERT interface, saw how
they did it, copied that, and assumed that that was how the PC did it too.
What they do is: in sector 0 of the harddisk there are 2 * 32 bytes of info;
the first holding data about partition 1, the second being a pointer to
another sector. In this sector there are 2 * 32 bytes of info; the first
holding data about partition 2, the second being a pointer to another
sector. In this sector there are 2 * 32 ...(reiterate until you get to
partition 32. If I remember correctly that 32 partitions was the maximum -
anyway, it's an arbitrary limit.)
(I thought that this format was PC compatible. I now don't really think it
is, because the PC only does a pointer to another sector once. It may be
compatible depending on how the particular PC's BIOS is implemented,
perhaps, maybe, kind of, idunno...)

So what's the difference between 'Extended' and 'BERT/HPN'? Well, I wanted
the Novaxis 'Extended' format to be compatible with the Bert, but I screwed
up somewhere in NFDISK 1.0 (and those routines also got into the Novaxis
interface) because I did the pointers to other sectors as absolute sector
numbers, while the BERT had it as a relative offset from the current sector.
So in NFDISK 1.1/2 I added the 'BERT/HPN' format. (There must be a very
small utility around -on some Quasar disk anyway- that converts Extended
to/from BERT format. If someone knows this by any chance, please tell me -
because there may be documentation included that proves whether I'm talking
nonsense here or not.)

I don't know if I have all details right. I may have mixed up something in
Extended vs. BERT and in old MSX / MAK 3.0... But this is about it, kind of.



>>>>>>>>>>>>>>>>>>>>>> Parts of answer from Adriano 20010904

> > What I still remember is that the partition table (on sector 0 of the
> > harddisk, before any partitions) contains sets of 32 bytes of info for
> > each
> > partition. There should be documents available _somewhere_ which detail
> > this, since it's used on every PC...

That's right. The standard partition info for each partition on a
harddisk has 32 bytes, at physical sector 0.

> > The 'old MSX' format was exacly the same format but used up to 8
> > partitions.
> > (It just placed the same 4*32 bytes of information behind (or before?) the
> > 4*32 bytes for the PC partitions because there is room for that.

Behind. Sunrise ATA-IDE uses the same scheme, but up to 31
partitions, since there is room for that in sector 0.

> > I have no
> > idea why all PCs did not just do it like this.)

Because the top of sector 0 contains the MBR (Master Boot Record)
program. It selects the bootable partition and run the bootsector on it.
OS loaders, like LILO, overwrite this piece of code with their code, so
they can select the boot partition.

> > The 'Extended' format uses sectors elsewhere on the disk, as does the
> > BERT/HPN format.
> > What they do is: in sector 0 of the harddisk there are 2 * 32 bytes of
> info;

Do you remember if the partition info has the correct partition
type byte (extended partition has type 5, indicating that this entry
points
to another partition info sector, with data about the other partitions
on
disk)?

> > the first holding data about partition 1, the second being a pointer to
> > another sector. In this sector there are 2 * 32 bytes of info; the first
> > holding data about partition 2, the second being a pointer to another
> > sector. In this sector there are 2 * 32 ...(reiterate until you get to
> > partition 32. If I remember correctly that 32 partitions was the maximum -
> > anyway, it's an arbitrary limit.)
> > (I thought that this format was PC compatible.

No, it's not. But it's compatible with MegaSCSI format (assuming
that the partition type byte is set accordingly).

> > So what's the difference between 'Extended' and 'BERT/HPN'? Well, I wanted
> > the Novaxis 'Extended' format to be compatible with the Bert, but I
> screwed
> > up somewhere in NFDISK 1.0 (and those routines also got into the Novaxis
> > interface) because I did the pointers to other sectors as absolute sector
> > numbers, while the BERT had it as a relative offset from the current
> sector.

Yes! That's it! Now I really understand what NOVAXTAB.BAS does! :)

> > - what more do you need to know?

Do you remember how can I check the partition table type (MAK 3.0,
BERT, Extended, Old PC, Old MSX, etc)? Checking the number of entries in
the
partition table?


Regards,


Adriano Camargo Rodrigues da Cunha          (adrcunha@yahoo.com.br)
http://www.adrpage.cjb.net                  MSX: more fun per less MHz



>>>>>>>>>>>> Parts of answer from Roderik 20010907:

> Do you remember if the partition info has the correct partition
> type byte (extended partition has type 5, indicating that this entry
> points
> to another partition info sector, with data about the other partitions
> on
> disk)?

Yes.
(You can also see the first (or first two, or so) extended partitions on a
PC - because it has the right value.)

> > > - what more do you need to know?
>
> Do you remember how can I check the partition table type (MAK 3.0,
> BERT, Extended, Old PC, Old MSX, etc)? Checking the number of entries in
> the
> partition table?

That I can probably find out from the NFDISK sources. (If you don't mind
translating back from assembler to human logic, I might leave that
translation up to you - and you'll have the asm routine... There should be a
single piece of code in there which reads partition data from any of those
formats into an x*y memory area... It has been incorporated from there into
the Novaxis ROM too, so...)



>>>>>>>>>>>> Parts of another answer to an answer, by Roderik 20010907:

> > > Do you remember if the partition info has the correct partition
> > > type byte (extended partition has type 5, indicating that this entry
> > > points
> > > to another partition info sector, with data about the other partitions
> > > on
> > > disk)?
> > Yes.
> > (You can also see the first (or first two, or so) extended partitions on
a
> > PC - because it has the right value.)
>
> That's very good. So, only 'old MSX' and 'MAK 3.0' formats are
> problematic. Other interfaces can access only the last 4 partitions...

Well, yes... And I introduced another problem. Our 'Novaxis Extended' format
may cause problems because it looks like the BERT/HPN (which is the same as
MegaSCSI, I assume) in everything, but has invalid 'pointers' to extended
partition tables. So you need to be careful.
(If I'm right. See my asm routine.)

> > There should be a
> > single piece of code in there which reads partition data from any of
those
> > formats into an x*y memory area... It has been incorporated from there
into
> > the Novaxis ROM too, so...)
>
> Nice! It will be very useful.
> BTW, If I put my hands on on your code, do you give me your permission
> to use parts of it on UZIX? Of course your copyrights will be respected

You have my permission to do anything you want with the code. I didn't think
of explicitly saying that in the last message...
(It's not all mine - but if people complain, just blame me.)



>>>>>>>>>>>>>>>> Last answer by Roderik 20010913:

These are sources for version 1.0. I'm not sure what happened between v1.0 and v1.2 
(for which I don't have the sources anymore), but I think it was:
- some fix in calculation routines. (That calculated the optimal number of sectors/cluster, 
  or something.)
- ....?
Unlike what I said earlier, I think that NFDISK never properly supported the 'BERT/HPN' format. 
Unlike MAP 3.0 (that Manuel searched through), when I look through NFDISK.BIN 1.2 for strings 
I only see 'Extended/MAK 3.0/(old) PC/(old) MSX', no mention of 'BERT/HPN' partition type.

Adriano: this means that you need to adjust the ASM routine if you want to be able to read 
BERT(=MegaSCSI?) as well as the 'buggy extended' format that NFDISK 1.0 uses. 
But you probably had to adjust it anyway...

The comments were in Dutch, but I just translated all comments at data fields & the routine 
reading the partition table & boot & directory sectors into English. The code you need is at 
ReadPData and further. (And the code in the middle, which reads boot & directory sectors, 
you can probably scrap because you don't need it.) The code which checks for different partition 
types is easy enough to isolate...