Filesystem creation

Filesystem creation

[lnordstrom]

Hello.

As being new to this list, first a short introduction:
Living 15 km outside the nearest town with my woman and four
cats. Working as a lathe-turner in town.
I have been interested in and tinkered with computers since the
late seventies, more actively since late eighties.
Could afford to buy my first DOS-box (second hand XT) -89. Since
then the zoo has grown a bit. Installed Linux for the first time
somewhere late -98. Got LRP running on an old crappy 386 to
network my modem a year later. Fiddel with muLinux now and then.
Never done any serious programming of any sort, just small bits
and pieces in Basic, Pascal, assembler, DOS batch, shellscript.
Enough of this.

I was glad when I found out about ELKS a while ago (2-3 yrs) and
even gladder to see that there now are ready-to-go floppy
images.

I'm trying to run the image "comb" on an IBM PS/2-30. It boots
OK and runs as I expect. But when I try to make a file system on
the harddisk and mount it, I bump into something.

fdisk reports 773 cyl, 2 heads, 27 sec.

/dev/bda1  *  0 1   6   1 27 385   1  20520
/dev/bda2  *  0 1 386   1 27 695  80  16740
/dev/bda3  *  0 1 696   1 27 772  80   4158

mkfs /dev/bda2 5859 finishes OK, but a following fsck /dev/bda2
produces an error message, fsck: bad magic number in super-block.

If I reduce the number of blocks by one, to 5858, fsck finishes
without error message.

Mounting the new fs under /mnt goes OK, but ls /mnt gives error
messages.

/mnt:
Bad inode number on dev 0302: 3677 is out of range
Bad inode number on dev 0302: 11330 is out of range
(some garbage on this line)

Trying to repair the fs with fsck -a desn't seem to do any good.

If I reduce the number of blocks further, down to 5666, I get no
error messages anywhere. Mounting, unmounting, making
directories, copying files seems to work OK.

Did I bump into anything but my own ignorance?

I realize I know too little about the minix fs. Google produces
a lot of links but the first few pages contained no link to a
spec. Anybody got a good URL to a little detail on minix fs?


Regards,
Lars

Does steel wool come from metal sheep?

Net-Tamer V 1.10.1  - Registered

Re: Filesystem creation

[Riley Williams]

Hi Lars.

> As being new to this list, first a short introduction: Living 15 km
> outside the nearest town with my woman and four cats. Working as a
> lathe-turner in town. I have been interested in and tinkered with
> computers since the late seventies, more actively since late
> eighties. Could afford to buy my first DOS-box (second hand XT)
> 1989. Since then the zoo has grown a bit. Installed Linux for the
> first time somewhere late 1998.

Similar to my own experience in many ways, although the years vary
slightly.

> Got LRP running on an old crappy 386 to network my modem a year
> later. Fiddle with muLinux now and then. Never done any serious
> programming of any sort, just small bits and pieces in Basic,
> Pascal, assembler, DOS batch, shellscript. Enough of this.

I've done a lot more programming though...

> I was glad when I found out about ELKS a while ago (2-3 yrs) and
> even gladder to see that there now are ready-to-go floppy images.
> I'm trying to run the image "comb" on an IBM PS/2-30.

I don't know that particular model, but have a PS/2-70 here and that has
an ESDI hard drive.

> It boots OK and runs as I expect. But when I try to make a file
> system on the harddisk and mount it, I bump into something.
>
> fdisk reports 773 cyl, 2 heads, 27 sec.
>
> /dev/bda1  *  0 1   6   1 27 385   1  20520
> /dev/bda2  *  0 1 386   1 27 695  80  16740
> /dev/bda3  *  0 1 696   1 27 772  80   4158
>
> mkfs /dev/bda2 5859 finishes OK, but a following fsck /dev/bda2
> produces an error message, fsck: bad magic number in super-block.
>
> If I reduce the number of blocks by one, to 5858, fsck finishes
> without error message.
>
> Mounting the new fs under /mnt goes OK, but ls /mnt gives error
> messages.
>
> /mnt:
> Bad inode number on dev 0302: 3677 is out of range
> Bad inode number on dev 0302: 11330 is out of range
> (some garbage on this line)
>
> Trying to repair the fs with fsck -a desn't seem to do any good.
>
> If I reduce the number of blocks further, down to 5666, I get no
> error messages anywhere. Mounting, unmounting, making directories,
> copying files seems to work OK.
>
> Did I bump into anything but my own ignorance?

Probably only the same problem I'm having - I don't have the foggiest
how to calculate the figure to use on the mkfs line. The figures
produced and used by the various tools appear to bear no resemblance
to each other in any shape or form.

Perhaps somebody with a bit more knowledge can arrange for the ELKS mkfs
tool to auto-calculate the correct figure given the partition to use?
Probably hoping too much, but...

> I realize I know too little about the minix fs. Google produces a
> lot of links but the first few pages contained no link to a spec.
> Anybody got a good URL to a little detail on minix fs?

I tried asking Copernic for "Minix File System specification" and only
came up with a spec for the umsdos file system, not what you're after,
so can't help...

> Does steel wool come from metal sheep?

Probably...

Best wishes from Riley.

Re: Filesystem creation

[Javier Sedano]

lnordstrom@home.se wrote:
> 
> I realize I know too little about the minix fs. Google produces
> a lot of links but the first few pages contained no link to a
> spec. Anybody got a good URL to a little detail on minix fs?
> 

	Try the Tanenbaum's "Operating System. Design and implementation" book.
It is the book where minix was explained and designed, so it the best
place to look for minixfs information..

-- 
Mamaaaa, ¿donde has dejado el manual de la vela?
--------
Javier Sedano Jarillo      http://www.it.uc3m.es/~jsedano
 jsedano@dit.upm.es (*)
 jsedano@ieee.org
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Filesystem creation

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]


The mkfs utility needs the size to be specified because block devices in
ELKS do not update the blk_sizes array. (Remember the swap discussion).

Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: Filesystem creation

[Riley Williams]

Hi Harry.

> The mkfs utility needs the size to be specified because block
> devices in ELKS do not update the blk_sizes array. (Remember the
> swap discussion).

I don't remember the discussion you refer to, so presume it wasn't
on this list but on some other list. However, there's a few obvious
questions that your comment poses, so can I ask them?

 1. How come the figure that mkfs needs is so different from
    the figure displayed by fdisk? I've yet to work out what
    the correlation between the two is, as they appear to
    bear no relation to each other.

 2. How hard would it be to make mkfs take as its size parameter
    the number reported by fdisk and calculate the size it needs
    from that rather than expect the user to do the calculation
    instead?

 3. How hard would it be to fix ELKS so the size doesn't need to
    be specified, either by getting the block devices to update
    the blk_sizes array or by whatever other means are required?
    This way, the whole problem just vanishes.

Best wishes from Riley.

Re: Filesystem creation

[Alan Cox]

>  2. How hard would it be to make mkfs take as its size parameter
>     the number reported by fdisk and calculate the size it needs
>     from that rather than expect the user to do the calculation
>     instead?

That would break the expected but daft old Unix API

>  3. How hard would it be to fix ELKS so the size doesn't need to
>     be specified, either by getting the block devices to update
>     the blk_sizes array or by whatever other means are required?
>     This way, the whole problem just vanishes.

You can fill in the block sizes for each partition by reading the
partition table. In the ELKS case I'd argue that mkfs ought to figure
out the primary device, and do the partition table read itself simply
because kernel space is precious and only mkfoo need to know

Re: Filesystem creation

[Riley Williams]

Hi Alan.

>>  2. How hard would it be to make mkfs take as its size parameter
>>     the number reported by fdisk and calculate the size it needs
>>     from that rather than expect the user to do the calculation
>>     instead?

> That would break the expected but daft old Unix API

The other option would be to give fdisk an option to do the calculation
and display the numbers that mkfs needs...

>>  3. How hard would it be to fix ELKS so the size doesn't need to
>>     be specified, either by getting the block devices to update
>>     the blk_sizes array or by whatever other means are required?
>>     This way, the whole problem just vanishes.

> You can fill in the block sizes for each partition by reading the
> partition table. In the ELKS case I'd argue that mkfs ought to
> figure out the primary device, and do the partition table read
> itself simply because kernel space is precious and only mkfoo need
> to know

I'm in full agreement with that.

Best wishes from Riley.

Re: Filesystem creation

[Riley Williams]

Hi Alan.

>> 2. How hard would it be to make mkfs take as its size parameter
>>    the number reported by fdisk and calculate the size it needs
>>    from that rather than expect the user to do the calculation
>>    instead?

> That would break the expected but daft old Unix API

I have to admit that I didn't even know there was a Unix API to break,
and from a personal viewpoint I'd be a lot more interested in building
compatibility to the current Linux system on the assumption that if the
API is important in the Unix world as a whole, then Linux will already
follow it, and if Linux doesn't, then the API can't be that important.

>> 3. How hard would it be to fix ELKS so the size doesn't need to
>>    be specified, either by getting the block devices to update
>>    the blk_sizes array or by whatever other means are required?
>>    This way, the whole problem just vanishes.

> You can fill in the block sizes for each partition by reading the
> partition table.

Alternatively, and according to Blaz, it's only the RamDrive driver that
fails to provide this information already, so if we correct that bug
(which I'm looking into now), then mkfs can already get all it needs
from the current drivers and the problem just evaporates.

> In the ELKS case I'd argue that mkfs ought to figure out the primary
> device, and do the partition table read itself simply because kernel
> space is precious and only mkfoo need to know

I could certainly agree with that argument if there was lots to insert
in the ELKS kernel code to support it, but such is claimed not to be the
case. I'll let you know what I find out anyway.

Best wishes from Riley.

Re: Filesystem creation

[Alan Cox]

> > That would break the expected but daft old Unix API
> 
> I have to admit that I didn't even know there was a Unix API to break
> and from a personal viewpoint I'd be a lot more interested in building
> compatibility to the current Linux system on the assumption that if the
> API is important in the Unix world as a whole, then Linux will already
> follow it, and if Linux doesn't, then the API can't be that important.

Linux fdisk/mkfs also behave the same wacky way

Alan

Re: Filesystem creation

[Riley Williams]

Hi Alan.

>>> That would break the expected but daft old Unix API

>> I have to admit that I didn't even know there was a Unix API to
>> break and from a personal viewpoint I'd be a lot more interested in
>> building compatibility to the current Linux system on the assumption
>> that if the API is important in the Unix world as a whole, then
>> Linux will already follow it, and if Linux doesn't, then the API
>> can't be that important.

> Linux fdisk/mkfs also behave the same wacky way

Now you have me puzzled - I don't remember ever having to specify the
partition size when running any of the Linux mkfs commands. Perhaps you
could remind me what I'm missing please?

	mke2fs /dev/hda3

	mkdosfs /dev/hdb2

For some reason, both of those commands worked fine earlier today...

Best wishes from Riley.

Re: Filesystem creation

[Alan Cox]

> Now you have me puzzled - I don't remember ever having to specify the
> partition size when running any of the Linux mkfs commands. Perhaps you
> could remind me what I'm missing please?
> 
> 	mke2fs /dev/hda3
> 
> 	mkdosfs /dev/hdb2
> 
> For some reason, both of those commands worked fine earlier today...

It computes it, if you need to specify it then its in K and the fdisk
data is in sectors.

Re: Filesystem creation

[Riley Williams]

Hi Alan.

>> Now you have me puzzled - I don't remember ever having to specify
>> the partition size when running any of the Linux mkfs commands.
>> Perhaps you could remind me what I'm missing please?
>> 
>> 	mke2fs /dev/hda3
>> 
>> 	mkdosfs /dev/hdb2
>> 
>> For some reason, both of those commands worked fine earlier today...

> It computes it.

That's the API that I'm aware of, and what I'd prefer to see in ELKS.

> If you need to specify it then its in K and the fdisk data is in
> sectors.

To quote from Lars' email of a few days ago...

 Q> I'm trying to run the image "comb" on an IBM PS/2-30. It boots
 Q> OK and runs as I expect. But when I try to make a file system on
 Q> the harddisk and mount it, I bump into something.
 Q> 
 Q> fdisk reports 773 cyl, 2 heads, 27 sec.
 Q> 
 Q> /dev/bda1  *  0 1   6   1 27 385   1  20520
 Q> /dev/bda2  *  0 1 386   1 27 695  80  16740
 Q> /dev/bda3  *  0 1 696   1 27 772  80   4158

I've just fed the above parameters into Linux's fdisk and I get the
following display:

    Disk /dev/hda: 2 heads, 27 sectors, 773 cylinders
    Units = cylinders of 54 * 512 bytes

       Device Boot    Start       End    Blocks   Id  System
    /dev/hda1  *          1       385     10381+   1  FAT12
    /dev/hda2  *        386       695      8370   80  Old Minix
    /dev/hda3  *        696       772      2106   80  Old Minix

By your argument, the "Blocks" column should be displaying the same
numbers in both tables, but the ELKS version displays what looks like
precicely double the number the Linux version reports, at least for
partitions 2 and 3, and it appears to set totally different parameters
altogether for partition 1.

Simple arithmetic shows that the Linux fdisk is displaying actual track
capacities in Kilobytes in the Blocks column in each case, which is
contrary to the API you refer to above.

Alan: Can you explain this please?

Lars continues:

 Q> mkfs /dev/bda2 5859 finishes OK, but a following fsck /dev/bda2
 Q> produces an error message, fsck: bad magic number in super-block.
 Q> 
 Q> If I reduce the number of blocks by one, to 5858, fsck finishes
 Q> without error message.
 Q> 
 Q> Mounting the new fs under /mnt goes OK, but ls /mnt gives error
 Q> messages.
 Q> 
 Q> /mnt:
 Q> Bad inode number on dev 0302: 3677 is out of range
 Q> Bad inode number on dev 0302: 11330 is out of range
 Q> (some garbage on this line)
 Q> 
 Q> Trying to repair the fs with fsck -a desn't seem to do any good.
 Q> 
 Q> If I reduce the number of blocks further, down to 5666, I get no
 Q> error messages anywhere. Mounting, unmounting, making
 Q> directories, copying files seems to work OK.

According to the details provided by the ELKS fdisk, /dev/bda2 has
16,740 sectors, so 8,370 Kilobytes. However, the numbers he's supplying
to mkfs are (a) 5,859, (b) 5,858 and (c) 5,666, all of which are
considerably smaller than 8,370.

According to the details provided by the Linux fdisk analysis of his
settings, /dev/bda2 has 8,370 sectors, so 4,185 Kilobytes. In this case,
the numbers he's supplying are LARGER than this.

According to your comments above, the "expected API" is that the
parameter to mkfs is exactly half the number reported by fdisk.
If so, then ELKS mkfs is NOT following that API at this time.

Alan: Please explain the error in this reasoning, as I can't find it.

Best wishes from Riley.

Re: Filesystem creation

[Harry Kalogirou]

Την Δευ, 13-05-2002 στις 23:55, ο/η Blaz Antonic έγραψε: 
> > The mkfs utility needs the size to be specified because block devices in
> > ELKS do not update the blk_sizes array. (Remember the swap discussion).
> 
> Weren't you the one who posted the update to correct that ? It is really
> simple error and should be fixed immediately (i can't think of any
> reason for _not_ fixing it).
> 
> Blaz Antonic
> 

No I just spoted it, didn't fix it! The only problem that I can see is
that the blk_sizes is an array with the one dimention being the major
and the other the minor device number. This is probably a waist of data
segment in the case of ELKS. That is the only reason I can see, that
made the developers comment out the source the blk_sizes references. 

Harry

-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Filesystem creation

[Alan Cox]

> and the other the minor device number. This is probably a waist of data
> segment in the case of ELKS. That is the only reason I can see, that
> made the developers comment out the source the blk_sizes references.=20

Thats why I thought it would be a much better thing to leave in user
space. 256 long words is expensive

Re: Filesystem creation

[Riley Williams]

Hi Harry.

>>> The mkfs utility needs the size to be specified because block
>>> devices in ELKS do not update the blk_sizes array. (Remember
>>> the swap discussion).

>> Weren't you the one who posted the update to correct that ? It is
>> really simple error and should be fixed immediately (i can't think
>> of any reason for _not_ fixing it).

> No I just spoted it, didn't fix it! The only problem that I can see
> is that the blk_sizes is an array with the one dimension being the
> major and the other the minor device number. This is probably a
> waste of data segment in the case of ELKS. That is the only reason I
> can see, that made the developers comment out the source the
> blk_sizes references.

I've now had a look at both the doshd.c and rd.c source files, and the
ONLY references I can find resembling what you're discussing are to the
blksize_size array. This is only a one dimensional array indexed by
MAJOR_NR, and appears to contain the size of the block rather than the
number of blocks as per this discussion. In both doshd.c and rd.c it's
set to 1024 in the initialisation routine (or at least, it would be if
the relevent lines weren't #if 0'd out altogether) and is then never
used at all therein.

Does anybody have any documentation on the expected API for new block
devices? If not, I'll try to write one based on the kernel source, then
I might just have an idea what is going on here. I certainly don't at
the moment.

Best wishes from Riley.

Re: Filesystem creation

[lnordstrom]

  

Hello Riley.

On 2002-05-12 rhw@infradead.org said:

 rh>> I'm trying to run the image "comb" on an IBM PS/2-30.
 rh>I don't know that particular model, but have a PS/2-70 here and
 rh>that has an ESDI hard drive.

 AFAIK, it's an updated XT. The difference is much interface
 electronics integrated on the motherboard. Video (MCGA), parport,
 serport, mouse, floppy (720k) and harddisk (20M). Takes PS/2 keyboard
 and mouse. Three 8 bit ISA slots.

 It's even got ROM Basic. Found out when I messed with fdisk and
 forgot to put a floppy in the drive.

 No ESDI hard drive, no MCA slots, just a plain XT.

 rh>Probably only the same problem I'm having - I don't have the
 rh>foggiest how to calculate the figure to use on the mkfs line.

 I guessed a block to be 1024 bytes, 2 sectors. The figures I
 got doesn't divide evenly with figures from fdisk. :-(

 A look in the source /include/linuxmt/fs.h leads me to believe
 that the blocks are 1024 bytes long. But I'm not fluent in C so
 I can't be certain.

 I'll just have to wait until it's fixed. 5.5MB is plenty to
 play with for the time being. :-)



Regards,
Lars

FIRST rule of intelligent tinkering: save all the parts!

Net-Tamer V 1.10.1  - Registered

Re: Filesystem creation

[Riley Williams]

Hi Lars.

>>> I'm trying to run the image "comb" on an IBM PS/2-30.

>> I don't know that particular model, but have a PS/2-70 here and
>> that has an ESDI hard drive.

> AFAIK, it's an updated XT. The difference is much interface
> electronics integrated on the motherboard. Video (MCGA), parport,
> serport, mouse, floppy (720k) and harddisk (20M). Takes PS/2
> keyboard and mouse. Three 8 bit ISA slots.

Ah - the 70 is basically an updated AT-286 but with the MCA bus rather
than the ISA bus.

> It's even got ROM Basic. Found out when I messed with fdisk and
> forgot to put a floppy in the drive.

It's an IBM product, so that's to be expected.

> No ESDI hard drive, no MCA slots, just a plain XT.

When it comes to hard drives, there's no such thing as a "plain
XT". From experience, I've seen XT's with MFM, RLL, ESDI, (E)IDE and
SCSI hard drives, and as the original XT didn't even have a hard drive
interface, it's anybody's guess which is fitted.

I've just had a look on IBM's website, and the Model 30 reference
diskette is for a 286 based system. I know that some of the PS/2 range
were available with different processor options, and it's more than
possible that the Model 30 is one such, but there's precious little
about that machine on their website, so that didn't help.

>> Probably only the same problem I'm having - I don't have the
>> foggiest how to calculate the figure to use on the mkfs line.

> I guessed a block to be 1024 bytes, 2 sectors. The figures I
> got doesn't divide evenly with figures from fdisk. :-(

> A look in the source /include/linuxmt/fs.h leads me to believe
> that the blocks are 1024 bytes long. But I'm not fluent in C so
> I can't be certain.

The term "block" is misleading in this sense as it's used in two totally
different ways in ELKS, so let me clarify:

 1. To the low level media drivers, a block is a physical sector, and
    in ELKS, that's always 512 bytes.

 2. To the high level FS subsystem, a block is the fundamental unit
    for organising data on permanent storage, and is almost always
    2 sectors (1,024 bytes) although it can be more.

The problem I have is that the blocks specified by fdisk are 512 byte
sectors, at least in theory, but this figure bears no resemblance to the
figure one has to specify to the mkfs command.

What I'd love to see is the ELKS mkfs command work the same way as the
Linux one, where one just specifies the partition and it works out the
size for itself. In reality, there's no reason that I can think of why
it should need the size specifying, other than that the programmer was
either a tad idle or a tad careless.

> I'll just have to wait until it's fixed. 5.5MB is plenty to
> play with for the time being. :-)

True.

Best wishes from Riley.

Re: Filesystem creation

[Dan Olson]

> When it comes to hard drives, there's no such thing as a "plain
> XT". From experience, I've seen XT's with MFM, RLL, ESDI, (E)IDE and
> SCSI hard drives, and as the original XT didn't even have a hard drive
> interface, it's anybody's guess which is fitted.

Actually I think they came standard with a 10 meg full height MFM drive.
The origional PC didn't come with a hard drive, and some without floppies.

	Dan


> I've just had a look on IBM's website, and the Model 30 reference
> diskette is for a 286 based system. I know that some of the PS/2 range
> were available with different processor options, and it's more than
> possible that the Model 30 is one such, but there's precious little
> about that machine on their website, so that didn't help.

I've got an 8086 based PS/2, a 25 I believe.  It was a while ago, but I
had trouble with ELKS when I last tried it on that machines, the keyboard
wouldn't work.

	Dan

Re: Filesystem creation

[Riley Williams]

Hi Dan.

>> When it comes to hard drives, there's no such thing as a "plain XT".
>> From experience, I've seen XT's with MFM, RLL, ESDI, (E)IDE and SCSI
>> hard drives, and as the original XT didn't even have a hard drive
>> interface, it's anybody's guess which is fitted.

> Actually I think they came standard with a 10 meg full height MFM
> drive. The origional PC didn't come with a hard drive, and some
> without floppies.

To be accurate...

 1. The original IBM PC was supplied with a CASSETTE drive as
    standard. 160k floppies were a very expensive optional extra
    as you had to buy not only the drive, but also an interface
    card and an operating system to boot from them, all sold as
    separate items. Hard drives were NOT supported, and it was
    not possible to add support for them as the BIOS didn't have
    the ability to hook extensions in.

 2. The original IBM PC/XT was supplied with a "new upgraded" 180k
    floppy drive as standard, and as an option, these could be
    replaced with a 360k drive for an extra £275. I remember paying
    the extra when this wmachine was top of the range.

 3. The "Revised" IBM PC/XT was supplied with dual 360k floppies
    as standard, and one of them could be replaced with an MFM
    hard drive - originally 5M in capacity, but those were replaced
    with 10M ones within a month, and the MFM interface was replaced
    with an RLL one about a month later to increase the capacity.

 4. The IBM PC/AT was supplied with a 20M hard drive as standard,
    as well as the 286 processor and various other "standard extras"
    as IBM referred to them.

>> I've just had a look on IBM's website, and the Model 30 reference
>> diskette is for a 286 based system. I know that some of the PS/2
>> range were available with different processor options, and it's more
>> than possible that the Model 30 is one such, but there's precious
>> little about that machine on their website, so that didn't help.

> I've got an 8086 based PS/2, a 25 I believe.

That agrees with IBM's website.

> It was a while ago, but I had trouble with ELKS when I last tried it
> on that machines, the keyboard wouldn't work.

If you still have it handy, could you try the latest images out and see
whether it works now. If not, would you be willing to help explore why
it doesn't work so we can fix the problem?

Best wishes from Riley.

-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Filesystem creation

[Alan Cox]

>  1. The original IBM PC was supplied with a CASSETTE drive as
>     standard. 160k floppies were a very expensive optional extra
>     as you had to buy not only the drive, but also an interface
>     card and an operating system to boot from them, all sold as
>     separate items. Hard drives were NOT supported, and it was
>     not possible to add support for them as the BIOS didn't have
>     the ability to hook extensions in.

It would be nice to find someone with an XT with 512-640K of RAM and
the casette drive, if only for an excuse to add /dev/tape 8)

>     replaced with a 360k drive for an extra =A3275. I remember paying
>     the extra when this wmachine was top of the range.

Youch. I'd forgotton how big those prices were at the time

Re: Filesystem creation

[Dan Olson]

> It would be nice to find someone with an XT with 512-640K of RAM and
> the casette drive, if only for an excuse to add /dev/tape 8)

I've got both, but IBM did away with the cassette interface when they
introduced the XT, so you won't find such a thing.  I was only offered on
the PC (5150, I believe).  Of course you could always find a PC with a
memory board that's got 640K of RAM.  How you'd load ELKS from cassette to
memory using ROM BASIC is beyond me though :)

> Youch. I'd forgotton how big those prices were at the time

Yea, no kidding, think what those 10 meg hard drives cost!

	Dan

Re: Filesystem creation

[Riley Williams]

Hi Dan.

>> It would be nice to find someone with an XT with 512-640K of RAM and
>> the casette drive, if only for an excuse to add /dev/tape 8)

> I've got both, but IBM did away with the cassette interface when
> they introduced the XT, so you won't find such a thing. I was only
> offered on the PC (5150, I believe). Of course you could always find
> a PC with a memory board that's got 640K of RAM. How you'd load ELKS
> from cassette to memory using ROM BASIC is beyond me though :)

Not quite true - IBM made the cassette interface an "optional extra" on
an expansion card for the original IBM PC/XT (with up to 256k of RAM on
the motherboard) but had discontinud it by the time the revised model
(with up to 640k of RAM on the motherboard) hit the shelves.

My understanding is that the BIOS support didn't vanish until the XT-286
and as such, if you can find one of those interface cards, you can quite
probably still get a 640k XT with a cassette interface.

Best wishes from Riley.

Re: Filesystem creation

[Dan Olson]

> Not quite true - IBM made the cassette interface an "optional extra" on
> an expansion card for the original IBM PC/XT (with up to 256k of RAM on
> the motherboard) but had discontinud it by the time the revised model
> (with up to 640k of RAM on the motherboard) hit the shelves.

Huh, I didn't know that, and I don't expect to see such a thing either :)
>
> My understanding is that the BIOS support didn't vanish until the XT-286
> and as such, if you can find one of those interface cards, you can quite
> probably still get a 640k XT with a cassette interface.

You know, now that you mention it, my AT has ROM BASIC, I wonder if it was
in there to support that card.  I don't know what else you'd do with it,
if you didn't have a bootable hard drive and didn't choose to boot from
floppy.  Did the disk-based basic talk to the BIOS, or to the hardware
itself?

	Dan

Re: Filesystem creation

[Riley Williams]

Hi Alan.

>>  1. The original IBM PC was supplied with a CASSETTE drive as
>>     standard. 160k floppies were a very expensive optional extra
>>     as you had to buy not only the drive, but also an interface
>>     card and an operating system to boot from them, all sold as
>>     separate items. Hard drives were NOT supported, and it was
>>     not possible to add support for them as the BIOS didn't have
>>     the ability to hook extensions in.

> It would be nice to find someone with an XT with 512-640K of RAM and
> the casette drive, if only for an excuse to add /dev/tape 8)

We could easily add that anyway, and label it as EXPERIMENTAL until
somebody with such a machine turns up to test it. After all, the BIOS
routines for that are fairly well documented.

>>     replaced with a 360k drive for an extra GBP 275. I remember paying
>>     the extra when this wmachine was top of the range.

> Youch. I'd forgotton how big those prices were at the time

My first hard drive (a 20M one) cost me nearly GBR 850 at the time, and
the 60G one I recently bought cost me GBP 95 by comparison.

Best wishes from Riley.

Re: Filesystem creation

[Dan Olson]

> We could easily add that anyway, and label it as EXPERIMENTAL until
> somebody with such a machine turns up to test it. After all, the BIOS
> routines for that are fairly well documented.

Sure, but with the cost of floppies and even RAM and flash drives, there'd
be little point.  Cassettes were really for those that couldn't afford any
other form of storage, and are really a poor way to store data, despite
being kinda neat in their own strange way.  Besides, it may takes hours to
load :)

> My first hard drive (a 20M one) cost me nearly GBR 850 at the time, and
> the 60G one I recently bought cost me GBP 95 by comparison.

Doesn't it make you sick to see how quickly that stuff looses it's value?
I've started getting hardware used or at least "trailing edge" just to
avoid pumping a lot of money into something that will soon be
worthless...and because I don't really need that much to do what I'm
doing.

	Dan

Re: Filesystem creation

[Dan Olson]

> To be accurate...
>
>  1. The original IBM PC was supplied with a CASSETTE drive as
>     standard. 160k floppies were a very expensive optional extra
>     as you had to buy not only the drive, but also an interface
>     card and an operating system to boot from them, all sold as
>     separate items. Hard drives were NOT supported, and it was
>     not possible to add support for them as the BIOS didn't have
>     the ability to hook extensions in.

Sure it is, what are you talking about?  It wasn't until the AT was
introduced that hard drives were BIOS supported.  Before that, the
controller card had it's own BIOS on it, and the system BIOS just scanned
for adaptor BIOSes before trying to boot.  I've used both MFM and SCSI in
origional PCs.

>  2. The original IBM PC/XT was supplied with a "new upgraded" 180k
>     floppy drive as standard, and as an option, these could be
>     replaced with a 360k drive for an extra £275. I remember paying
>     the extra when this wmachine was top of the range.

I thought single sided drives were only offered in the origional PC....the
real old ones that only had 16-64K of RAM optional.  Don't know for sure
on that one though I guess.

>  3. The "Revised" IBM PC/XT was supplied with dual 360k floppies
>     as standard, and one of them could be replaced with an MFM
>     hard drive - originally 5M in capacity, but those were replaced
>     with 10M ones within a month, and the MFM interface was replaced
>     with an RLL one about a month later to increase the capacity.

Yup, the "eXtended Technology" :)

>  4. The IBM PC/AT was supplied with a 20M hard drive as standard,
>     as well as the 286 processor and various other "standard extras"
>     as IBM referred to them.

And it ran at a whopping 6MHz too :)

> > I've got an 8086 based PS/2, a 25 I believe.
>
> That agrees with IBM's website.

Good, then I'm actually remembering something right today!

> If you still have it handy, could you try the latest images out and see
> whether it works now. If not, would you be willing to help explore why
> it doesn't work so we can fix the problem?

Well, it's not handy, but I still have it.  If I stumble across it I'll
grab it and see if it works or not.  I'm having a hard enough time just
getting a boot disk made and installed in my IBM XT (eXtended Technology
:).  You know, it's a little off the subject, but what would really be
handy is a little C compiler that ran under ELKS.  It wouldn't need to be
able to compile the OS, just something we could use to write little
programs.  Just a thought, it would give me a little motivation to use the
OS anyway :)

	Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Filesystem creation

[Riley Williams]

Hi Dan.

On checking, I see that mislabelled them slightly, so here's the
corrected version...

>> To be accurate...
>>
>>  1. The original IBM PC was supplied with a CASSETTE drive as
>>     standard. 160k floppies were a very expensive optional extra
>>     as you had to buy not only the drive, but also an interface
>>     card and an operating system to boot from them, all sold as
>>     separate items. Hard drives were NOT supported, and it was
>>     not possible to add support for them as the BIOS didn't have
>>     the ability to hook extensions in.

> Sure it is, what are you talking about? It wasn't until the AT was
> introduced that hard drives were BIOS supported. Before that, the
> controller card had it's own BIOS on it, and the system BIOS just
> scanned for adaptor BIOSes before trying to boot. I've used both MFM
> and SCSI in origional PCs.

The problem with your quote above is quite a simple one - the original
IBM PC didn't scan for adapter BIOSes, so was VERY limited in what
expansion one could add to it. That was an oversight by IBM's engineers
as they provided the slots for plugging in expansion cards, but forgot
to allow for BIOS support for those expansions. The BIOS included the
ability to boot from floppies as standard, but that was about all.

This was the original version of the original IBM PC, with a fixed 16k
of RAM that couldn't be expanded on the motherboard.

>>  2. The original IBM PC/XT was supplied with a "new upgraded" 180k
>>     floppy drive as standard, and as an option, these could be
>>     replaced with a 360k drive for an extra £275. I remember paying
>>     the extra when this wmachine was top of the range.

> I thought single sided drives were only offered in the origional PC
> - the real old ones that only had 16-64K of RAM optional. Don't know
> for sure on that one though I guess.

This is the one I mis-labelled - this is the revised original PC, where
the RAM could be expanded from the supplied 16k up to 64k, and NOT the
PC/XT as I originally labelled it. Yes, I had one, and I paid the extra
for the floppy drive.

This is where Bill Gates made his famous "Nobody will want more than
64k" comment - see below for his later comment.

>>  3. The "Revised" IBM PC/XT was supplied with dual 360k floppies
>>     as standard, and one of them could be replaced with an MFM
>>     hard drive - originally 5M in capacity, but those were replaced
>>     with 10M ones within a month, and the MFM interface was replaced
>>     with an RLL one about a month later to increase the capacity.

> Yup, the "eXtended Technology" :)

As stated, this was the original IBM PC/XT - I stand corrected. This
also allowed for up to 256k of RAM to be fitted to the motherboard, and
was where the clones started to appear. Unlike IBM's offering, the
clones offered 512k of RAM on the motherboard as standard.

I also omitted a couple here, so here we go...

   3a. The "revised IBM PC/XT" was the original IBM PC/XT with the
       onboard RAM capacity upgraded to 640k when the clones were all
       offering 512k on the motherboard. The clones promptly followed
       and allowed 640k as well.

       It was at this point that Bill Gates made his famous "640k will
       be enough for anybody" comment

   3b. The IBM PC/XT-286 was supplied with a 286 processor running at
       6 MHz (compared to the original 4.77 MHz) and was available in
       two versions, one with dual 1200k floppy drives, the other with
       a 360k floppy drive and a 15M hard drive.

>>  4. The IBM PC/AT was supplied with a 20M hard drive as standard,
>>     as well as the 286 processor and various other "standard extras"
>>     as IBM referred to them.

> And it ran at a whopping 6MHz too :)

Exactly the same as the PC/XT-286 that preceded it. I liked the "standard
extras" phraseology myself...

>>> I've got an 8086 based PS/2, a 25 I believe.

>> That agrees with IBM's website.

> Good, then I'm actually remembering something right today!

You do indeed. IBM's website labels the Model 25 as being 8086 based,
and the Model 30 as being 80286 based. My Model 70 is listed as being
available in either 286 or 386 based versions, and I have the 286
version here.

>> If you still have it handy, could you try the latest images out and see
>> whether it works now. If not, would you be willing to help explore why
>> it doesn't work so we can fix the problem?

> Well, it's not handy, but I still have it. If I stumble across it I'll
> grab it and see if it works or not. I'm having a hard enough time just
> getting a boot disk made and installed in my IBM XT (eXtended Technology :).

Could you advise what the problem is with doing that? The various Linux
distributions all supply rawrite.exe which can write the image out to
floppy under MS-DOS so the procedure isn't hard.

> You know, it's a little off the subject, but what would really be
> handy is a little C compiler that ran under ELKS. It wouldn't need
> to be able to compile the OS, just something we could use to write
> little programs. Just a thought, it would give me a little
> motivation to use the OS anyway :)

We would all love that. However, according to Alan Cox, BCC is slightly
too large and as a result won't compile itself, although the assembler
and linker both compile fine to run under ELKS.

There's one or two tweaks I would like to see done to BCC anyway, so I
may soon be looking into this and seeing if I can get bcc to compile
itself. No promises though...

Best wishes from Riley.

-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Filesystem creation

[Dan Olson]

> The problem with your quote above is quite a simple one - the original
> IBM PC didn't scan for adapter BIOSes, so was VERY limited in what
> expansion one could add to it. That was an oversight by IBM's engineers
> as they provided the slots for plugging in expansion cards, but forgot
> to allow for BIOS support for those expansions. The BIOS included the
> ability to boot from floppies as standard, but that was about all.
>
> This was the original version of the original IBM PC, with a fixed 16k
> of RAM that couldn't be expanded on the motherboard.

Ah! Okay, I've never seen such a machine, they were very short-lived.
Maybe someday I'll find one.

> This is the one I mis-labelled - this is the revised original PC, where
> the RAM could be expanded from the supplied 16k up to 64k, and NOT the
> PC/XT as I originally labelled it. Yes, I had one, and I paid the extra
> for the floppy drive.

Okay, that makes sence now, the floppy was definetly an option in those
machines.

> This is where Bill Gates made his famous "Nobody will want more than
> 64k" comment - see below for his later comment.

I forget the exact story, but I think he's the one who pushed IBM into
making the PC a 64-256k machine, as the original 16k was too limiting.  Of
course sticking adaptor ROMs at the 640k-1M range was done because 640K
was way more memory than anybody could use! :)

>    3a. The "revised IBM PC/XT" was the original IBM PC/XT with the
>        onboard RAM capacity upgraded to 640k when the clones were all
>        offering 512k on the motherboard. The clones promptly followed
>        and allowed 640k as well.

Okay, that's what my board is, I was wondering if it was a true IBM
offering as all the documentation I have mentions the board having a
smaller capacity.  Turns out there's a jumper on the board that selects
which type of system you have...ie it determines the amount of memory the
DIP switch settings give you.

> > And it ran at a whopping 6MHz too :)
>
> Exactly the same as the PC/XT-286 that preceded it. I liked the "standard
> extras" phraseology myself...

That's great...then again, they were probably impressive compaired to some
of the other clones of the day, with the 16 bit ISA bus and all.

> > Well, it's not handy, but I still have it. If I stumble across it I'll
> > grab it and see if it works or not. I'm having a hard enough time just
> > getting a boot disk made and installed in my IBM XT (eXtended Technology :).
>
> Could you advise what the problem is with doing that? The various Linux
> distributions all supply rawrite.exe which can write the image out to
> floppy under MS-DOS so the procedure isn't hard.

I guess that wasn't too clear, it hard simply because I'm always doing
something else, it would be much easier if I took an hour and sat down in
front of the computer and made the disk, then gave it a try.  It's also
hard because I'm sharing one desk/monitor between three PCs :)

> We would all love that. However, according to Alan Cox, BCC is slightly
> too large and as a result won't compile itself, although the assembler
> and linker both compile fine to run under ELKS.
>
> There's one or two tweaks I would like to see done to BCC anyway, so I
> may soon be looking into this and seeing if I can get bcc to compile
> itself. No promises though...

Well, compiling itself is definetly a good thing, but even if we could
compile a binary on a different machine, then stick it on an ELKS disk
image or something, that'd be all I'd want.  I'm just interested in
writing a couple short programs on the ELKS machine, then compiling them
locally.  Is that a difficult task?  I have no idea what it'd take to get
a compiler running under ELKS.

	Dan

Re: Filesystem creation

[Alan Cox]

> image or something, that'd be all I'd want.  I'm just interested in
> writing a couple short programs on the ELKS machine, then compiling them
> locally.  Is that a difficult task?  I have no idea what it'd take to get
> a compiler running under ELKS.

bcc can compile itself (or it could). However it creates a version of itself
a little too big to use. Bcc cross built by a dos compiler is small enough
so its demonstrably a matter of improving bcc's space optimisation until it
generates code good enough to fit itself into 64K