TOS 2.06 improving - task for good C coder

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

Petari
Posts: 357
Joined: Tue Nov 28, 2017 1:32 pm

TOS 2.06 improving - task for good C coder

Post by Petari » Tue Jun 26, 2018 6:51 pm

I got some e-mails recently with questions, suggestions about doing same improvements as what I did in TOS 1.04/1.62 - improved FAT16 in first place. What now, with max 30 partitions possible, and 1 GB max partition sizes allows usage of even 32 GB cards, fully utilized ( they are never full 32 GB, despite Simbo will say different :D ) - and all accessible directly.
I will not for sure doing same what did with 1.04 and 1.62 - full disassembly and harder part of modding that S source. What would be easier if it was done with same compiler as mentioned 2 (from 1989), but it is not same, and machine code is pretty much different.
And no need for it, there is much easier way, because sources in C (with little ASM in) are available for 2.06 (and 3.06 too). It is for German TOS 2.06, but that's not problem at all. GEMDOS part of German and UK, US, etc. is practically 100% same . Difference is mostly in RSC structures at the end of AES/Desktop section, where practically all txt is . Need to deal only with GEMDOS part, what is shorter than AES/Desktop part. About 100 KB .
I'm not good with C, I don't like it, I don't have time for it. What I can do is to give all help for this, indeed useful improvement. And with C sources, it will be at least 10x easier than what I performed in disassembled S 'source' - what is not real source of course, just bunch of ASM lines and addresses.
Main task is to change recno variable from 16-bit to 32-bit, to change signed cluster # variable to unsigned. Then few changes in code responsible for max supported partition count. I did already hard work of tracing down what to change.
It is possible then to compile it with original Alcyon compiler, or with some new, what will produce shorter and little faster code.
Any volunteers ? Don't expect big salary, but fame is guaranteed :D
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

troed
Posts: 223
Joined: Mon Aug 21, 2017 10:27 pm

Re: TOS 2.06 improving - task for good C coder

Post by troed » Tue Jun 26, 2018 7:08 pm

Petari wrote:
Tue Jun 26, 2018 6:51 pm
It is for German TOS 2.06
Hmm no it's for all languages, so, even easier.

http://www.atari-forum.com/viewtopic.ph ... 43#p312633

(I've compiled binary exact Swedish TOS 2.06 using it, on target HW, for example)

Petari
Posts: 357
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Tue Jun 26, 2018 7:13 pm

Sorry for my misinformation ... believe me, it was written somewhere, not my idea.
It is rather that it was originally only German, but in meantime they added other languages - people dealing with it - Thorsten Otto in first part, I guess.
Yeah, that about compiling on exact HW will help the case ....
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

troed
Posts: 223
Joined: Mon Aug 21, 2017 10:27 pm

Re: TOS 2.06 improving - task for good C coder

Post by troed » Tue Jun 26, 2018 10:06 pm

Petari wrote:
Tue Jun 26, 2018 6:51 pm
Main task is to change recno variable from 16-bit to 32-bit, to change signed cluster # variable to unsigned. Then few changes in code responsible for max supported partition count. I did already hard work of tracing down what to change.
bpb.h:

Code: Select all

BPB /* bios parameter block */
{
	/*  0 */ int16_t recsiz; 	/* sector size in bytes */
	/*  2 */ int16_t clsiz;		/* cluster size in sectors */
	/*  4 */ int16_t clsizb; 	/* cluster size in bytes */
	/*  6 */ int16_t rdlen;		/* root directory length in records */
	/*  8 */ int16_t fsiz;		/* fat size in records */
	/* 10 */ int16_t fatrec; 	/* first fat record (of last fat) */
	/* 12 */ int16_t datrec; 	/* first data record */
	/* 14 */ int16_t numcl;		/* number of data clusters available */
	/* 16 */ int16_t b_flags;
	/* 18 */ 
};
numcl?

bios.h:

Code: Select all

typedef int16_t RECNO;             /* record number  */ /* BUG: should be unsigned */
typedef int32_t LRECNO;            /* record number  */ /* BUG: should be unsigned, but Alcyon does not support unsigned long */
Didn't look for partition count.

Petari
Posts: 357
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Tue Jun 26, 2018 10:56 pm

There is better C source, where is clearly said that it should be 32-bit:
viewtopic.php?f=39&t=430&start=30
Then talk about that Alcyon compiler can not deal with unsigned ...

Considering max partition count - that part is messy. at least in 1.04/1.62 , Most likely, nothing relevant changed in 2.06 .
Drvbits var. is 32-bit, but there is some other variable involved, holding what partitions are opened, and that's only 16-bit. That needs to change to 32-bit, and of course, must use other address, to not break layout. Possible without big problem. Then there are some counters up to 16 instead 32. Array of 64 bytes (16x4) needs to expand to 128 bytes (32x4) . How hard is to find it in C sources of 2.06, I have no clue, There are couple other things, what surely look different in C src. than in ASM, but and.l $FFFFFFF0 ... should be visible - change to $FFFFFFE0 ....
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

troed
Posts: 223
Joined: Mon Aug 21, 2017 10:27 pm

Re: TOS 2.06 improving - task for good C coder

Post by troed » Tue Jun 26, 2018 11:32 pm

Petari wrote:
Tue Jun 26, 2018 10:56 pm
There is better C source, where is clearly said that it should be 32-bit:
viewtopic.php?f=39&t=430&start=30
Then talk about that Alcyon compiler can not deal with unsigned ...

Considering max partition count - that part is messy. at least in 1.04/1.62 , Most likely, nothing relevant changed in 2.06 .
Drvbits var. is 32-bit, but there is some other variable involved, holding what partitions are opened, and that's only 16-bit. That needs to change to 32-bit, and of course, must use other address, to not break layout. Possible without big problem. Then there are some counters up to 16 instead 32. Array of 64 bytes (16x4) needs to expand to 128 bytes (32x4) . How hard is to find it in C sources of 2.06, I have no clue, There are couple other things, what surely look different in C src. than in ASM, but and.l $FFFFFFF0 ... should be visible - change to $FFFFFFE0 ....
Right, I quoted from the C source which Thorsten has provided so we know it compiles :) That fs.h does not contain those defines what I can see (but I only looked quickly for the right definitions). I mainly wanted your input on whether numcl in the BPB was the "cluster #" you meant.

I think the partition stuff is all over the place. Not as clear cut. At least if I understand the 16 to 32 bit drvmap idea.

GEM fileselector (gemfslib.c):

Code: Select all

#define DEVICES	16						/* sixteen devices  */
fsmain.c

Code: Select all

/******************************************************************************
 *
 * Chk_Drv - Check drive number
 *
 *	Utility routine used by F_IOCtl
 *
 ******************************************************************************
 */

int Chk_Drv(P(int16_t *) d)
PP(int16_t *d;)
{
	int map;

	*d = *d ? *d - 1 : run->p_curdrv;	/* Resolve drive number     */
	map = Drvmap();

	return map & (1 << *d);			/* Check for existence      */
}

/*
 *  xsetdrv - set default drive
 *	( 0 = A, etc )
 *	Function 0x0E	Dsetdrv
 */

/* 306de: 00e17234 */
/* 306us: 00e171da */
ERROR xsetdrv(P(int16_t) drv)
PP(int16_t drv;)
{
	run->p_curdrv = drv;
	return Drvmap();
}
(not meant as an exhaustive check - those were just examples of where I see 16 bits being used for drive. Doesn't seem to be 16 bit in the map though, only as an index for the drive. Still haven't found that open partition map)

Petari
Posts: 357
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Thu Jun 28, 2018 6:40 am

OK. I think that this way will not work, not until someone takes care and plenty of time to correct C sources, so they will be possible to compile with some modern compiler. Why ? Because you can not get good code, what will handle unsigned variables with Alcyon compiler (is it possible that they did not update it until year 1991 ?) . And then nothing from 1GB partition access.
I mailed Thorsten Otto yesterday, and he gave me links for fresh updates:
http://www.tho-otto.de/download/tos306de.tar.bz2
http://www.tho-otto.de/download/alcyon.tar.bz2
Now you can compile Alcyon for your host system - like Linux or Win, and compile with it TOS 2-3.xx in second. I tried with mingw64 - and what a shock, it worked not - some minor diff in library, it seems. Will try later in Linux.
However, the problem here is that we don't want to make reconstruction of original code, but improving it. And that seems impossible with old compiler (base). Quote from README: "Note that, despite all the fixes, no changes were made (especially to the compiler) that would lead to different code generation."

I can be wrong. Then someone please explain what and how to do. Main thing is possibility to use unsigned variables, 16 and 32-bit ones, so updated FAT16 work properly . To add, that I solved it in ASM mostly by changing branch commands like from bge to bcs, sometimes adding some value for comparison .

P.S. is it possible that some limitations are just because they used not much good C compiler ?
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
Smonson
Posts: 95
Joined: Sat Oct 28, 2017 10:21 am

Re: TOS 2.06 improving - task for good C coder

Post by Smonson » Thu Jun 28, 2018 9:10 am

If you're going to update the TOS code to make it compatible with modern C compilers, I would like to suggest that you break with the tradition of using the obsolete assembler syntax that necessitates the use of gcc-68k-atari-mint. Standard gcc syntax is way more portable.

If you have to build a customised non-vanilla cross-compiler to build the ROMs, it's almost as bad a situation as what we have now with Alcyon C. Plain GCC all the way!

I think my view is the minority one in this area but I just thought I'd put it out there.

troed
Posts: 223
Joined: Mon Aug 21, 2017 10:27 pm

Re: TOS 2.06 improving - task for good C coder

Post by troed » Thu Jun 28, 2018 9:34 am

Petari wrote:
Thu Jun 28, 2018 6:40 am

I can be wrong. Then someone please explain what and how to do. Main thing is possibility to use unsigned variables, 16 and 32-bit ones, so updated FAT16 work properly
I agree that if we're breaking binary compatibility (not so important for TOS 2.06 I think) it would be nice to have an updated toolchain. However, signed 32 bit variables should be enough to get full FAT16 support.

(I don't know when I will have time to actually make the modifications. The C code is fully understandable though so the task of making the actual edits should be quite simple as long as all the correct points to change can be found)

Petari
Posts: 357
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Thu Jun 28, 2018 10:54 am

Smonson wrote:
Thu Jun 28, 2018 9:10 am
If you're going to update the TOS code to make it compatible with modern C compilers, I would like to suggest that you break with the tradition of using the obsolete assembler syntax that necessitates the use of gcc-68k-atari-mint. Standard gcc syntax is way more portable.
If you have to build a customised non-vanilla cross-compiler to build the ROMs, it's almost as bad a situation as what we have now with Alcyon C. Plain GCC all the way!
I think my view is the minority one in this area but I just thought I'd put it out there.
As said, I'm not good with C. So, you mean that should change something at ASM parts syntax ? Or you mean that not use 68000 ASM at all ?
I don't think that it can be done without serious speed problems and lot of time. Early stage - HW init, test, BIOS is done in ASM. Then interrupt handlers, because they are time critical. If it is just to change sysntax of included ASM code, should be not that hard.
Other way, what I think is more realistic is to use some established C compiler for Atari. That will not produce so efficient code as some modern, but it will work after not too much corrections, I guess.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply