TOS after 32 years - what could be done better ?

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

Moderator: Petari

User avatar
exxos
Site Admin
Posts: 1634
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: TOS after 32 years - what could be done better ?

Post by exxos » Tue Jan 09, 2018 3:05 pm

This was best mod done for TOS104 ;) For sure makes things a lot better :D

1.jpg
1.jpg (22.26 KiB) Viewed 390 times
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

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

Re: TOS after 32 years - what could be done better ?

Post by Petari » Thu Jan 25, 2018 1:51 pm

It was already mentioned here that FAT16 with large logical sectors (for partitions larger than 32 MB) is not really good and efficient way. This is something what bothered me for long time. There is solution to work with usual FAT16 partitions (with normal sector sizes of 512 bytes) - BigDOS program. That program is well made, and was freeware. But it takes extra RAM, and is not compatible with some SW, especially not with games.
So, I went in probably craziest TOS patching - reworking TOS filesystem to be capable to work with usual FAT16 partitions over 32 MB.
As I disassembled TOS 1.04 long time ago, it was natural candidate. I seen already then that the problem is lack of 32-bit sector access in all it.
Sector number inside partition is 16-bit integer - and it makes limit of 32MB. And that's the reason why Atari introduced large logical sectors - then can access for instance 512 MB partitions - with logical sector size of 8KB (16 normal sectors). Bad thing in it is, that with it, minimal size accessible is 8KB too. So, system must load from disk always multiples of 8KB, even if less is requested. Another bad side is need for larger buffers in BCB - 4x8 KB=32 KB minimal in case of partitions larger than 256 MB (max is 512 MB with TOS 1.04-3.06) .
After some 10 days of examining, tracing, making plenty of changes it finally works. I realized that adding 2 bytes more (using long, 32-bit variable instead word, 16-bit variable is possible without changing RAM layout, variable locations. Thanx to not much economic RAM usage of TOS. For instance I got 2 extra bytes in BCB (buffer control blocks) by shrinking 2 16-bit variables to 2 8-bit ones . I did already plenty of tests, and it seems now very reliable. Of course, will need special hard disk driver - basically only some smaller modifications in my existing one will be enough.
Then can have extremely low RAM hungry hard disk driver - some 4KB of allocated space will be enough. But I will add options to create some extra buffers for faster work.
For now plan is only modded TOS 1.04 and combo of TOS 1.04 and 2.06, with this improvement. Probably will look to mod TOS 1.62 - what is very similar to 1.04.
And something very interesting, what I found while examined available, very limited TOS sources:
Quotes from FS.H - likely from year 1987 :

" ** 04 Nov 85 KTB M01.01.03: new types: RECNO, CLNO. these
** are unsigned ints to be used for sector numbers
** (or sector counts) and cluster numbers (any
** value in the fat) respectively
**
** 15 Nov 85 KTB M01.01.04: new type: FH (file handle). To be
** added in declarations as they are modified.
**
** 25 Feb 86 KTB M01.01.05: modified BCB definition.
**
** 21 Mar 86 KTB M01.01.06: new access method
** 27 May 86 KTB M01.01.0527.03: removed decl of xcmps since it
** is only used in one module.
** 29 May 86 KTB M01.01.0529.01: removed O_COMPLETE flag in DND
**
** 08 Jul 86 KTB M01.01a.0708.02: moved def of dirscan() to
** fsdir.c
**
** 19 Sep 86 SCC M01.01.0919.01: changed definitions of 'time' and
** 'date' to 'unsigned int'.
**
** 31 Oct 86 scc M01.01.1031.01: Removed extern definition of ValidDrv()
**
** NAMES
**
** JSL Jason S. Loveman
** SCC Steve C. Cavender
** EWF Eric W. Fleischman
** KTB Karl T. Braun (kral)
"
Most interesting part:

"
** Type declarations
*/

#define BCB struct _bcb
#define FTAB struct _ftab
#define PD struct _pd
#define OFD struct _ofd
#define FCB struct _fcb
#define DND struct _dnd
#define DMD struct _dmd
#define CLNO int /* cluster number M01.01.03 */
#define RECNO int /* record number M01.01.03 */
/*** this should be changed to a long!! ***/
#define FH unsigned int /* file handle M01.01.04 */ "

RECNO is what I needed to change to long. And they in Atari knew it already in year 1986 ! Why it remained 16-bit over many years, actually, it seems that Atari self never changed it to long - that would be good question.
To add, that with good and complete source for TOS 1.04 (with all variables etc.) this would be much easier. I needed to patch machine code generated by some old, not much efficient C compiler. But in everything bad there is something good - so there was lot of places where could save some bytes. Updated code is shorter some 500 bytes than original, despite added some things :D
I will post updated TOS 1.04 ROM image in TOS mods. thread after some more testings ... Will give it # 1.05 most likely ...

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

Re: TOS after 32 years - what could be done better ?

Post by troed » Thu Jan 25, 2018 2:00 pm

Awesome achievement - congratulations!

User avatar
exxos
Site Admin
Posts: 1634
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: TOS after 32 years - what could be done better ?

Post by exxos » Thu Jan 25, 2018 3:00 pm

That is seriously cool! :dualthumbup:
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Gunstick
Posts: 23
Joined: Tue Aug 22, 2017 12:42 pm

Re: TOS after 32 years - what could be done better ?

Post by Gunstick » Wed Jan 31, 2018 5:22 pm

why did they have to go with that 8+3 filename format.
It's fine to be DOS compatible, but there was such a nice filesystem in the unix world.
This filename restriction bothered me the most during the time I used the ST.
The Amiga guys knew that and made the filenames anything you like. But screwed up on directory read speeds.

I could have imagined an NAMES.INF file in each directory, which would keep long filenames. Supported transparently by the OS.
So you could keep the underlying DOS/FAT format. Only headache would be to chose a 8+3 real filename when you save your "ParallaxScrollerV32.src".
If that would have been in the OS from the start, all software would have supported this without problems.

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

Re: TOS after 32 years - what could be done better ?

Post by Petari » Wed Jan 31, 2018 6:05 pm

Long filenames need more space, more computing power. I think that it was too early for it in 1985.
No need for some NAMES.INF file - I mean, that may be one solution for LFN, but it is solved without that in Win95, and that way is supported already by Mint - with special attribute combination as flag. I'm not fan of long filenames. It is not bad to have informative name, but some people really tries to put there too much info.

Funny thing is that early TOS versions (before 2.06) were made with many very 'economic' solutions - so there is only 8 cypher space provided for file size in Desktop, when displaying drive content in Text view mode. If file is longer than 99.999.999 bytes TOS will crash .

User avatar
arf
Posts: 41
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Wed Jan 31, 2018 11:23 pm

Gunstick wrote:
Wed Jan 31, 2018 5:22 pm
why did they have to go with that 8+3 filename format.
It's fine to be DOS compatible, but there was such a nice filesystem in the unix world.
They had no time completion TOS anyway. Putting something on top of the feature wish list was out of reach.
Gunstick wrote:
Wed Jan 31, 2018 5:22 pm
I could have imagined an NAMES.INF file in each directory, which would keep long filenames. Supported transparently by the OS.
So you could keep the underlying DOS/FAT format. Only headache would be to chose a 8+3 real filename when you save your "ParallaxScrollerV32.src".
If that would have been in the OS from the start, all software would have supported this without problems.
Sounds like Rockridge, which works similar to your suggestion.
--
Against signature spam!

User avatar
exxos
Site Admin
Posts: 1634
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: TOS after 32 years - what could be done better ?

Post by exxos » Mon Feb 05, 2018 10:10 pm

A small thought... 020 CPU support in TOS104. As most know, forced to move to TOS206 to use the 020 CPU.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

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

Re: TOS after 32 years - what could be done better ?

Post by Petari » Tue Feb 06, 2018 7:45 am

exxos wrote:
Mon Feb 05, 2018 10:10 pm
A small thought... 020 CPU support in TOS104. As most know, forced to move to TOS206 to use the 020 CPU.
That will not work because of used Line-F emulator in Desktop. What would be another flaw of TOS - it was used to make all it fit in 192KB ROM space - Line-F emulation is basically subrutine call, but only with 2 byte long command, instead 4 or 6 byte long one. With it they saved some 3-4 KB space at price of little speed loss. On 68020-30 there are opcodes starting with F, so Line-F emulation is not possible.
What is possible is to use AES and Desktop from TOS 1.62 . Of course, then it will need more than 192KB space (256KB) and start address at $E00000. What should be no problem, I'm sure, since accelerators already have sockets for extra ROMs .
I will put together it today . For now only for 68020/30 CPU, but it is possible to make smart one, what will detect CPU and can work on 68000 and 68020/30 - for case that there is switch for 68000 mode on accelerator.
I guess that intention here is better compatibility with old SW - what will be better than with 2.06, but CPU change self is not compatible with plenty of games, so don't expect miracles. There may be added support in HAGA f0r accelerated STs ....

Here is special TOS for STs with 68020/30 accelerators - patched TOS 1.04 GEMDOS part + TOS 1.62 AES, Desktop :
T146_1.ZIP
(106.9 KiB) Downloaded 12 times

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

Re: TOS after 32 years - what could be done better ?

Post by Petari » Thu Feb 08, 2018 11:03 am

I made better TOS 1.04 mod for 68020/30 + TOS 1.62 mod for STE machines with CPU upgrade. In both cases it works with 68000 CPUs and those with large stackframe - so 68010/20/30 . TOS 1.04 mod uses AES and Desktop from 1.62 - because that's the only way - and of course start address is not $FC0000 but $E00000.
There is no any specific initialization for 68020/30 CPUs . If that is needed, it can be added - three is plenty of space for ... Just need accurate info about it.
For ST -
T146LS3.ZIP
(106.42 KiB) Downloaded 7 times
For STE -
T162LS2.ZIP
(106.83 KiB) Downloaded 8 times

Post Reply