OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: kerravon on March 14, 2024, 03:46:07 pm

Title: new gcc toolchain
Post by: kerravon on March 14, 2024, 03:46:07 pm
I spent a lot of effort making the GCC 3.2.3 source code
C90-compliant instead of being riddled with POSIX stuff,
in order to allow the compiler to be hosted on the IBM mainframe.

I have now created a makefile for OS/2 that uses itself
to build itself. But it's quite simple to modify if you want
to use some other compiler in order to bootstrap from
source. I created such a makefile for Watcom and
Microsoft C for Windows, but don't have anything for
OS/2 currently (but you can bootstrap on Windows
from source if you want, and then use that to continue
over to OS/2).

Also in the chain are two assemblers (pdas and as86).
Note that as86 is a subset of Microsoft MASM unlike
most other assemblers available (including pdas) that
require some other syntax.

So with standard C90 and standard MASM you can
build everything required. The object code produced
is coff, but the pdld linker will take coff input and
produce an LX binary.

If you are interested, get pdoso.zip from http://pdos.org
and because I don't know how to make parted (see
\devel\parted on the disk) produce a VHD that can be
mounted in Virtualbox for use by OS/2 (I use 128
sector as the starting sector (for 4k alignment), but I
tried changing it to 504 (for both 63 sector multiple and
4k alignment), but that wasn't accepted either. But I
just realized now that maybe it needs me to specify 0C
instead of 0B:

< parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0b,504,956416 ..\pdos.vhd
---
> parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0b,128,956416 ..\pdos.vhd

given that it is FAT32.

So on Windows or Linux you need to mount a VHD that
is acceptable to OS/2 and then copy the contents of
pdoso.vhd across.

After that, let's say the new disk is the P drive, you can do:

path %path%;p:\dos
cd \devel\pdos\pdpclib
pdmake -f makefile.sos
(run pdptest abc def if you want)

cd \devel
unzip \misc\custom gcc-stage*
unzip gcc-stage*
del gcc-stage*

cd gcc\gcc
copy config\i386\genfiles (don't forget this step)
pdmake -f os2.mak

I see that "fc" is missing, but no problem, you can:

cd \devel\pdos\pdpclib
ren pdptest.c pdptest.bak
copy ..\util\fc.c pdptest.c
pdmake -f makefile.sos
copy pdptest.exe \dos\fc.exe

cd \devel\gcc\gcc
fc /b \dos\gccwin.exe gcc-new.exe

and have a byte-identical copy of the compiler.

Note that gccwin.exe is a historical name
(EDIT: for this OS/2 LX executable).
I'm planning
on renaming it to gcc386.exe in the future.

Note that I have only compiled the essential binaries
needed to be able to compile anything else you may need.
ie the other stuff in \dos are Windows executables mostly,
so "need" to be replaced, eventually.

I am hoping to replace gccwin.exe with SubC anyway.

Is anyone interested in compilers such that they would
like to assist with this?

A build error (will be fixed next drop) is preventing this
from working:

[P:\devel\pdos\world]pdmake -f worldos2.mak
pdcc -E -D__SUBC__ -U__WIN32__ -D__OS2__ -D__32BIT__ -Dunsigned= -Dlong=int -Dsh
ort=int -Dconst= -Ddouble=int -I ../pdpclib -o world.i world.c
sccwin -S world.i
rm -f world.i
pdas -o world.obj --oformat coff world.s
rm -f world.s
pdld -s --no-insert-timestamp -nostdlib --oformat lx  --stub ../pdpclib/needpdos
.exe -o world.exe ../pdpclib/os2strt.obj world.obj ../pdpclib/pdpos2.lib ../pdpc
lib/os2.lib

[P:\devel\pdos\world]world
hello, world

[P:\devel\pdos\world]


Hopefully by then I have a mountable disk too.

Note that I cherish old targets including i370 unlike
others who like to obsolete old targets. YMMV. So
yeah, I have been patiently plugging away at GCC 3.2.3
(including this latest change), for 20 years, instead of
"keeping up with the Joneses". And all source code is
in C90, not Turtle Graphics or whatever "modern" GCC
is written in these days. Except for the minimal
assembler required in the C library.

All clean 32-bit code too (not a single bit of 16-bit in any
executable on the disk except for the MBR, boot sector and
IO.SYS which aren't used if you are running under OS/2),
and all memory allocated with OBJ_ANY.

BFN. Paul.


P.S. gccwin also rebuilds itself on PDOS/386 - which is
what that pdoso.vhd is. PDOS/386 is a sufficient OS/2
mini-clone for that task.

P.P.S. Let me know if you don't know how to mount a
VHD on either Windows or Linux.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 01:37:52 am
If you are interested, get pdoso.zip from http://pdos.org
and because I don't know how to make parted (see
\devel\parted on the disk) produce a VHD that can be
mounted in Virtualbox for use by OS/2 (I use 128
sector as the starting sector (for 4k alignment), but I
tried changing it to 504 (for both 63 sector multiple and
4k alignment), but that wasn't accepted either. But I
just realized now that maybe it needs me to specify 0C
instead of 0B:

parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0c,504,956416 ..\pdos.vhd

Still not accepted by LVMGUI. It says it is free space, but
also can't create a partition in that free space.

Code: [Select]
C:\vbox>hexdump pdoso.vhd 0 512
000000  FA33C08E D88EC0B8 50008ED0 BC0077FB  .3......P.....w.
000010  BE007CBF 0006B900 01F3A5B8 500050B8  ..|.........P.P.
000020  240150CB 0E1F8816 B502BEBE 02B90400  $.P.............
000030  F6048075 0A83C610 E2F6BDBD 01EB6F80  ...u..........o.
000040  7C0400BD D8017466 26C706FE 7D0000B8  |.....tf&...}...
000050  00008EC0 B408BF00 00CD1372 1F80E13F  ...........r...?
000060  B500890E B1028AD6 B60083C2 018916B3  ................
000070  028B4408 8B540AE8 B600EB09 8A74018A  ..D..T.......t..
000080  4C028A6C 03B80000 8EC0BB00 7CE8D300  L..l........|...
000090  26813EFE 7D55AABD 14027512 8A16B502  &.>.}U....u.....
0000A0  8BEEB800 0050B800 7C50CBCD 1045B40E  .....P..|P...E..
0000B0  8A46003C 0075F487 DBFBF4EB FA4E6F20  .F.<.u.......No
0000C0  61637469 76652070 61727469 74696F6E  active partition
0000D0  20666F75 6E642100 41637469 76652070   found!.Active p
0000E0  61727420 68617320 696E7661 6C696420  art has invalid
0000F0  70617274 6974696F 6E207479 70652100  partition type!.
000100  4661696C 65642074 6F207265 61642056  Failed to read V
000110  42522100 56425220 6D697373 696E6720  BR!.VBR missing
000120  61613535 20736967 6E617475 72652100  aa55 signature!.
000130  F736B102 B5008ACA FEC133D2 F736B302  .6........3..6..
000140  8AF2528A F0B00051 B102D3E8 598AE65A  ..R....Q....Y..Z
000150  0BC8C350 528A16B5 02B80000 CD1372F5  ...PR.........r.
000160  5A58C350 53515206 8A16B502 B80102CD  ZX.PSQR.........
000170  137305E8 DDFFEBF0 075A595B 58C35053  .s.......ZY[X.PS
000180  8AC5E80D 008AC1E8 0800B020 E818005B  ........... ...[
000190  58C38AD8 51B104D2 E859E802 008AC324  X...Q....Y.....$
0001A0  0F049027 14402753 BB0000B4 0ECD105B  ...'.@'S.......[
0001B0  C3000000 00000000 5F20DD21 00008008  ........_ .!....
0001C0  01000C0D 0EB4F801 00000098 0E000000  ................
0001D0  00000000 00000000 00000000 00000000  ................
0001E0  00000000 00000000 00000000 00000000  ................
0001F0  00000000 00000000 00000000 000055AA  ..............U.

C:\vbox>

Any ideas? Again - I want to use this (public domain) parted via an automated procedure, not use LVM to create the partition. I'm happy to use LVM after the fact though (it would just be documented what you need to do).

Thanks. Paul.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 02:07:31 am
Note that I actually use two commands:

parted --boot devel\pdos\src\mbr.com mkpart 0x80,0x0c,504,956416 ..\pdos.vhd

mkdosfs --boot devel\pdos\src\fat32.com --blocks 478208 --offset 504 -F 32 -n "PDOS" ..\pdos.vhd


The second command is also on the same disk:

D:\devel\dosfstools>grep -i mkdosfs Makefile.pdw
makefile.pdw: all: clean mkdosfs.exe mcopy.exe mmd.exe mls.exe
makefile.pdw: mkdosfs.exe: lib.o mkfs.o $(COBJ)
makefile.pdw:   $(LD) -s -o mkdosfs.exe ../pdos/pdpclib/w32start.o lib.o mkfs.o $(COBJ) ../pdos/pdpclib/msvcrt.a
makefile.pdw:   rm -f *.o mkdosfs.exe

D:\devel\dosfstools>


Like parted:

D:\devel\parted>dir parted.c
 Volume in drive D is PDOS
 Volume Serial Number is 2218-141F

 Directory of D:\devel\parted

2024-03-14  01:58 AM            13,130 parted.c


The executables are win32:

D:\DOS>dir parted* mkdosfs*
 Volume in drive D is PDOS
 Volume Serial Number is 2218-141F

 Directory of D:\DOS

2024-03-14  02:02 AM            10,752 parted.exe

 Directory of D:\DOS

2024-03-14  02:02 AM            17,408 mkdosfs.exe


but I can create makefiles for OS/2 LX if that's an issue.

The author of both utilities (Robert Pengelly) is available to make any modifications if there is something specific that is being done incorrectly (or at least, unsuitable for OS/2).
Title: Re: new gcc toolchain
Post by: Dave Yeo on March 15, 2024, 02:20:56 am
Can you zip or 7z pdos.vhd and post it here? Seems an empty vhd should compress very well.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 03:01:11 am
Can you zip or 7z pdos.vhd and post it here? Seems an empty vhd should compress very well.
Sure. Here it is, empty. I confirmed that lvmgui won't let me create a partition with the free space (not that I want a new partition anyway), and also confirmed that Windows is fine with it.
Title: Re: new gcc toolchain
Post by: Andy Willis on March 15, 2024, 03:24:57 am
It likely is the partition alignment, or maybe less likely the drive geometry:
https://www.arcanoae.com/faqwd/how-can-i-tell-if-my-current-disk-drive-is-compatible-with-arcaos/
Title: Re: new gcc toolchain
Post by: Dave Yeo on March 15, 2024, 03:43:15 am
DFSee has this warning,
Code: [Select]
│Warning: The GEO Head/Sectors fields 16/63 in the bootsector         
│         do NOT match the current disk geometry values 14/63!       
│This may prevent using the partition from some operating systems like
│OS/2, eCS or windows that check this for consistency. The most likely
│cause for this is MOVING or CLONING the partition between different 
│primary locations, or between a primary and logical location. Use the
│FIXPBR command or 'Fix HiddenSectors/Geo value' menu to correct this.

I ran "Fix HiddenSectors/Geo value" on the vhd and attaching it.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 04:41:50 am
The GEO Head/Sectors fields 16/63 in the bootsector         
do NOT match the current disk geometry values 14/63!
Thanks for that - I'll pass it on to Robert. I tried zapping those values to be correct, but it still didn't change anything.

Quote
I ran "Fix HiddenSectors/Geo value" on the vhd and attaching it.
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 04:56:40 am
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Still no change - but although I zapped the geometry, I didn't change the hidden sectors, so let me first get Robert to decide what he would like to do to resolve the known inconsistency. Will hopefully have an answer overnight. Thanks for all the help.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 10:55:21 pm
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Still no change - but although I zapped the geometry, I didn't change the hidden sectors, so let me first get Robert to decide what he would like to do to resolve the known inconsistency. Will hopefully have an answer overnight. Thanks for all the help.

Robert looked at the VHD that was created by parted and said that the boot sector and VHD were consistent - 16 (x'10') as the number of heads, not 14. So I don't know why dfsee is saying 14 (I'm not saying dfsee is wrong - I just don't know where it is getting that from, as there is no x'0E' anywhere - and no x'0D' either in case it is 0-based counting).

He bought ArcaOS so that he could test it for himself, but after a lot of effort couldn't figure out what was happening, and he is at a loss of what to do without documentation. Is there any documentation for LVM?

Although he doesn't strictly need LVM - he only needs to get as far as the partition being accepted by ArcaOS so that LVM info can be added.
Title: Re: new gcc toolchain
Post by: Dave Yeo on March 15, 2024, 11:25:00 pm
Not much. Help lvm for the command line parameters, addendum.inf (toolkit) has the ioctl programming.
DFsee is available at https://dfsee.com (https://dfsee.com), Jan the author, is pretty knowledgeable, I believe there is a mailing list.
Title: Re: new gcc toolchain
Post by: kerravon on March 15, 2024, 11:29:15 pm
Not much. Help lvm for the command line parameters, addendum.inf (toolkit) has the ioctl programming.
DFsee is available at https://dfsee.com (https://dfsee.com), Jan the author, is pretty knowledgeable, I believe there is a mailing list.
Ok, thanks. But good news - I was looking in the VBR for an issue, as that is what "boot sector" means to me. I have found an issue with the MBR (high 2 bits of cylinder number not being stored in sector number). I'll report back later.
Title: Re: new gcc toolchain
Post by: Tom on March 15, 2024, 11:48:40 pm
He bought ArcaOS so that he could test it for himself, but after a lot of effort couldn't figure out what was happening, and he is at a loss of what to do without documentation. Is there any documentation for LVM?

Although he doesn't strictly need LVM - he only needs to get as far as the partition being accepted by ArcaOS so that LVM info can be added.

LVM documentation can be found at Alex Taylor's website: https://altsan.org/os2/toolkits/lvm/index.html
Title: Re: new gcc toolchain
Post by: kerravon on March 16, 2024, 11:23:07 am
DFSee has this warning,
Warning: The GEO Head/Sectors fields 16/63 in the bootsector         
do NOT match the current disk geometry values 14/63!

Ok, it's been a hell of a ride, with multiple bugs involved.

Let's go through them.

First, (I believe) that DFSee warning is incorrect. They are right about the bootsector values, but wrong about the geometry having 14 heads. It is correctly set to 16 heads.

Running this batch file on Windows:

C:\vbox\final>type doit.bat
del temp.vhd
del temp*.dat
del pdos.vhd
parted mkpart 0x80,0x0c,63,956416 temp.vhd
zcalc 948*63*16+15*63+1
zfill temp1.dat 489717760
xychop temp.vhd temp2.dat 489717760 489718271
copy /b temp1.dat+temp2.dat pdos.vhd
fc /b temp.vhd pdos.vhd

C:\vbox\final>

produces a VHD footer of:

C:\vbox\final>hexdump temp2.dat
000000  636F6E65 63746978 00000002 00010000  conectix........
000010  FFFFFFFF FFFFFFFF 2D8825AC 77696E20  ........-.%.win
000020  00060001 5769326B 00000000 1D308000  ....Wi2k.....0..
000030  00000000 1D308000 03B4103F 00000002  .....0.....?....
000040  FFFFEA8E 73730D77 04246D1E 46011211  ....ss.w.$m.F...
000050  27221837 00000000 00000000 00000000  '".7............

with offset 3A clearly set to x'10', ie number of heads 16.

You can see the number of cylinders (x'3B4' = 948) and the number of sectors after that (x'3F' = 63).


What the message is probably referring to is one of these fields in the partition entry of the MBR:

0001C0  01010C0D 0EB4

The x'0d' is the end of partition head number, ie head number 13, ie the last cylinder has 14 heads being used (0 to 13), with the last head only partially containing data.

That partial data is the x'0e' - 14 - the 14th sector (1 to 14), out of the 63 available sectors.

That (unfortunate) end CHS is due to the parameters given to parted - I haven't given it enough space to complete that last cylinder. So one bug (sort of a bug) is in my batch file - I need to either increase or decrease the space to get an exact cylinder boundary.

There is another bug (already committed - but the bug fix had another bug - and that has been corrected but not committed yet) - the cylinder number is B4. It should actually be 3B4 and the x'3' needs to be put into the top 2 bits of the sector number that is currently x'0E'.

Anyway, DFSee could be incorrectly reporting either of those values that are "14" as "geometry". It's not. It's either number of heads that have full or partial data in the last cylinder of the partition, or it is the number of sectors in the last track/head of the last cylinder of the partition - either thing requires a DFSee bug fix (unless I've misdiagnosed).

Next bug in next message.
Title: Re: new gcc toolchain
Post by: aziz on March 16, 2024, 11:48:25 am
Before I am looking deeper into it, I have a question:

How does this toolchain handle debugsymbols?

If I was to compile something with gcc -g ... do the debugsymbols end up in the exe file? If so, then what type of debugsymbols and is there a debugger on OS/2 that is compatible with those?
Title: Re: new gcc toolchain
Post by: kerravon on March 16, 2024, 12:10:39 pm
Next bug in next message.
As promised, here it is.

Using that previous batch file, which creates a blank disk with 16 heads per cylinder and 63 sectors per track, I hop into lvmgui and it is happy to create a partition. I choose to do "start of free space" and "primary partition". That creates final1.vhd in the attached. Later on I create a non-bootable compatible volume (final2.vhd) and later on I format it as FAT32 (final3.vhd).

The only change in the MBR between final1 and final3 is the partition type is changed from 06 (FAT16) to 0C (FAT32 using - ironically - LBA). The start/end partition values remain unchanged.

So here is final3.vhd:

C:\vbox>hexdump final3.vhd 0x1b0 80
0001B0  00000000 00000000 00000000 33CC8001  ............3...
0001C0  01000C0F FFB23F00 00009190 0E000000  ......?.........
0001D0  00000000 00000000 00000000 00000000  ................
0001E0  00000000 00000000 00000000 00000000  ................
0001F0  00000000 00000000 00000000 000055AA  ..............U.

Now we can see the x'0c' (FAT32) at 0x1C2 followed by the partition end head number (15 - ie maximum), the FF is sector 63 (x'3f') plus the 2 high bits set for the cylinder number (so B2 becomes 3B2).

So that means that cylinder 3B2 is completely maxed out - as is reasonable - giving cylinder alignment (although note that the starting LBA (after the x'b2') is 3F, so zero based means 40 sectors, ie it starts on head/track 1, sector 1. ie ArcaOS only needs track alignment, not cylinder alignment.

But regardless, the end of the partition is cylinder-aligned, meaning counting from the beginning of the disk (cylinder 0) to the end of the full cylinder 3B2 (946), we have a total of 947 cylinders with various stuff on it (starting with the MBR) or at least, assigned. 947 * 16 * 63 = 954576 sectors "in use". LBA is 0-based counting, so that means 0 to 954575 is "in use". With LBA 954575 being the end sector (inclusive).

That is hex e90cf

But ArcaOS has put an end LBA of e9091

That means if another system tries to use this disk to create the next partition, and uses LBA, as is normal, it will start at x'e9092', potentially trashing data in the first partition.

What is it out by?

cf-91 = decimal 62

So there's the ArcaOS bug - unless I have misdiagnosed.

And that's all the bugs I know of at the moment.
Title: Re: new gcc toolchain
Post by: kerravon on March 16, 2024, 12:14:07 pm
Before I am looking deeper into it, I have a question:

How does this toolchain handle debugsymbols?

If I was to compile something with gcc -g ... do the debugsymbols end up in the exe file? If so, then what type of debugsymbols and is there a debugger on OS/2 that is compatible with those?

Sorry - this is just meant to be a starter system.

I don't think there is any debugging capability. I always use printfs to debug. Except when there is a crash and I get the EIP and match it to the link map and assembler listings, and I read the assembler code and match it to the C code.

And I'm always doing optimized compiles where debugging isn't available anyway as far as I know.
Title: Re: new gcc toolchain
Post by: kerravon on March 16, 2024, 05:34:53 pm

So there's the ArcaOS bug - unless I have misdiagnosed.


I think I have misdiagnosed and it is parted that is wrong.

That's supposed to be number of sectors, not end LBA.

Will get back when confirmed.
Title: Re: new gcc toolchain
Post by: kerravon on March 16, 2024, 06:18:15 pm
Unrelated to the previous message, I have (hopefully temporarily) given up 4k alignment to produce a pdoso.zip that is acceptable to ArcaOS. Available at pdos.org

And independent of that, there is now ELF support under PDOS/386 via makefile.lnp (pdos.zip not pdoso.zip) which will hopefully evolve to be the same as pdoso.zip for OS/2.

Title: Re: new gcc toolchain
Post by: kerravon on March 17, 2024, 02:10:25 am

I think I have misdiagnosed and it is parted that is wrong.

That's supposed to be number of sectors, not end LBA.

Will get back when confirmed.

A hell of a ride.

Both Robert and I had confusion/misunderstandings about different things and that caused numerous emails back and forth, each insisting the numbers proved something the other wouldn't accept.

So when I saw in Wikipedia that the last value was meant to be a count, not the end LBA address - and having previously calculated that the end CHS matched the end LBA which made me think parted was correct - I was confident that the sector count was wrong, and the end CHS was likely correct.

Turns out that it was a correct count all along, and that the end CHS had similarly been implemented as an "offset" rather than an absolute value, and Robert believed that was exactly what it was meant to be, and insisted the values all matched. And furthermore, Windows and Linux didn't have a problem either. But they don't use those CHS values, so that's not a fair test. And furthermore, Windows doesn't seem to bother setting them to reasonable values, relying on the fact that they are supposed to be ignored in type x'0c'.

We had to go right back to MSDOS to confirm the behavior as "definitive", and then Robert made the required code change.

This was combined with inconsistent behavior from ArcaOS. It seems that the start CHS can be arbitrary, but the end CHS should be maxed out in the last cylinder. But ArcaOS doesn't strictly enforce that. So when I was making adjustments, and it worked, I would form a conclusion, but then have that conclusion invalidated by another test.

However, I eventually got it to work, and now there is a pdoso.zip that starts on sector 504, so I'm only wasting 230k or 200k depending on how you count (63 vs 128) in order to get both track alignment and 4k alignment.

In addition to that, pdoso.zip was updated with a new pdld so that ArcaOS can build ELF executables if that is useful for some reason. It won't run them though. You have to run them on PDOS/386 (either pdos.zip or pdoso.zip) or real Linux.

I'm expecting to now switch to replicating for Linux what I have just done for OS/2.
Title: Re: new gcc toolchain
Post by: kerravon on March 17, 2024, 08:14:49 am
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.
Title: Re: new gcc toolchain
Post by: Dave Yeo on March 17, 2024, 08:47:25 am
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

Did you change the partition type?
Edit: seems it is 06, so yes.
DFsee sees has this,
Code: [Select]
DFS partition  Id : 21  disk nr : 17  = FixedDisk Diskgeo = CHS:    957  16  63
 System Indicator : 0x06       = FAT16         UNIX devicename: /dev/Ida1     
 FileSyst. format : FAT16                     Windows BOOT.INI: Partition(1)   
 Partition   type : Primary    Visible        Bootrec-OEM-name: MSWIN4.1       
 Partition   size : 0x000E9091 =   466.1 MiB  =    946.938 cylinders           
FAT entry size of : 16  Bits   (FAT16   ) will be forced.                     
Size of FAT entry : 16  Bits    FAT label in Root : PDOS                       
FAT DIRTY status  : 0x00 = CLEAN                                               
FAT1 CRC-32 value : 0x861c6346  FAT2 CRC-32 value : 0x861c6346 = OK           
The FAT entry size seems weird.
Title: Re: new gcc toolchain
Post by: kerravon on March 17, 2024, 08:58:47 am
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

Did you change the partition type?

Yes, 06 for FAT16.

Created like this:

D:\scratch\xxx>type doit.bat
del pdos.vhd
parted mkpart 0x80,0x06,63,954513 pdos.vhd
mkdosfs --blocks 477256 --offset 63 -F 16 -n "PDOS" pdos.vhd
mcopy -i pdos.vhd --offset 63 hi.txt ::

D:\scratch\xxx>


Bug report:

https://mantis.arcanoae.com/view.php?id=3616
Title: Re: new gcc toolchain
Post by: kerravon on March 17, 2024, 09:03:54 am

parted mkpart 0x80,0x06,63,954513 pdos.vhd
mkdosfs --blocks 477256 --offset 63 -F 16 -n "PDOS" pdos.vhd
mcopy -i pdos.vhd --offset 63 hi.txt ::


BTW, all the above tools, and almost all the source code on the PDOS/386 disks - is C90 compliant and thus should compile on basically any C compiler, including the gcc 3.2.3 that I ship as LX executables.

I simply haven't constructed a makefile and executed the makefile to build them.

That is basically an exercise for the reader.

I have stopped at the point where all the essential tools to do a C90 compile have been built.

So using nothing more than either base OS/2 plus the tools on the PDOS/386 disk - or just PDOS/386 itself - you should be able to reconstruct the world armed with a C90 compiler and a masm-subset assembler.