Future source-code patches for TOS 2.06/3.06

[Arne]

Thanks to Thorsten Otto we are able to compile TOS 2.06, 2.08 and 3.06 from its sources.
IMHO that may lead to new problems:
new patches will surface (which is good) but they probably will break compatibility with the TOSPatch package (by Markus Heiden).
Spoken technically: insert one "nop" and the address of all other code following that "nop" will be increased and therefore not be compatible
with the absolute addresses in the TOSPatch package.

For example: I have patched 3.06's TT-RAM test so it will correctly show sizes beyond 99999KB and not some garbled string.
My patch is smaller than Atari's original so I have filled in the void with nops. But not every patch works this way.
Holger Zimmermann had to put his IDE patch at the end of the TOS space.

So how to handle this compatibility issue?
Where to collect all the patches, language options... and maintain there compatibility to each other?

[ThorstenOtto]

My patch is smaller than Atari's original so I have filled in the void with nops. But not every patch works this way.

If you were able to replace it in the binary, then it should also be possible to include the asm source compiling to the same sequence. And of course you only need to care about this when applying only some patch as asm, and later other ones with TOSPatch.

[joska]

Do you even need the binary patches when you can patch the sources directly?

[Arne]

My patch is smaller than Atari's original so I have filled in the void with nops. But not every patch works this way.

If you were able to replace it in the binary, then it should also be possible to include the asm source compiling to the same sequence.

True.

And of course you only need to care about this when applying only some patch as asm, and later other ones with TOSPatch.

If the asm-patch is smaller than the code it replaces, then there is no concern.
What if the asm-patch is bigger? This will break compatibility with TOSPatch.
And changes of the C-code will break it for sure IMHO.

Do you even need the binary patches when you can patch the sources directly?

Are all (needed) patches available as source? Or do TOSPatch BIN files need to be re-assembled?

[AtariZoll]

Do you even need the binary patches when you can patch the sources directly?

Of course that may want/need it in some cases. I think that for smaller patches, corrections is better to not recompile whole thing. Even if new code is longer, you can put it in unused space at end. The benefit is better compatibility - you don't change positions of code, data.

But let everyone decide what and how want to patch. I don't think that now we will suddenly see plenty of TOS patches, fixes, improvements.
There are some things what would be nice to see - my favorite is DOS type FAT16 filesystem instead AHDI with large logical sectors - that would make hard disk work more efficient, possible larger partitions . But that's pretty big task.

[joska]

There are some things what would be nice to see - my favorite is DOS type FAT16 filesystem instead AHDI with large logical sectors - that would make hard disk work more efficient, possible larger partitions . But that's pretty big task.

That has already been done in EmuTOS. EmuTOS's weak spot is the AES and desktop I think. A combination of EmuTOS DOS and TOS AES would be nice.

[troed]

Do you even need the binary patches when you can patch the sources directly?

Exactly. We just need a common repository.

/Troed

[1st1]

A combination of EmuTOS DOS and TOS AES would be nice.

Yes, but then TOS 4.x (Falcon) please, with all hacks that WinX provides.

[ThorstenOtto]

What if the asm-patch is bigger? This will break compatibility with TOSPatch.
And changes of the C-code will break it for sure IMHO.

That is only of concern if you want the patch the newly generated image further by TOSPatch. IMHO mixing both does not make much sense.

Are all (needed) patches available as source? Or do TOSPatch BIN files need to be re-assembled?

AFAIK TOSPatch uses some propiertary format to describe the patches, you will have to figure out what is actually patched. One of the reasons why i left in the original addresses in the source code as comments (at least for the german & us versions; other will have a constant offset applied most of the time).

[ThorstenOtto]

EmuTOS's weak spot is the AES and desktop I think

The AES of EmuTOS is functionally almost identical to the AES 3.20 found in x.06 version. A small difference is that x.06 provides wind_set WF_COLOR/WF_DCOLOR. But it's only half-hearted: it was never documented that it is available, wind_get() with that options is not supported, and there is no appl_getinfo() that could announce that its avilability, so there is probably no program that uses it on those TOS versions.

The desktop is a bit behind, but some of the missing features are being worked upon.

[AtariZoll]

There are some things what would be nice to see - my favorite is DOS type FAT16 filesystem instead AHDI with large logical sectors - that would make hard disk work more efficient, possible larger partitions . But that's pretty big task.

That has already been done in EmuTOS. EmuTOS's weak spot is the AES and desktop I think. A combination of EmuTOS DOS and TOS AES would be nice.

I just tried it with simple case: image with 2 short DOS FAT16 (under 32MB) partitions, and one BigDOS of 61MB, and EmuTOS 0.9.6 supplied with Hatari 2.0.0 mounts only first 2 non-BigDOS partitions (what can TOS too), 61 MB part. not.
So, what EmuTOS version can do it, any special requirements ?

[ThorstenOtto]

So, what EmuTOS version can do it, any special requirements ?

[/quote]

If in doubt, you might try this snapshot version:

https://sourceforge.net/projects/emutos ... /20170304/

[joska]

So, what EmuTOS version can do it, any special requirements ?

I would expect EmuTOS to handle this. Maybe you need a more recent version, 0.9.6 is rather old now. See Thorsten's link.

[AtariZoll]

So, what EmuTOS version can do it, any special requirements ?

If in doubt, you might try this snapshot version:

https://sourceforge.net/projects/emutos ... /20170304/[/quote]

Thanx - it mounted that partition too. However, seems as still not complete. Info for that partition just works not in Desktop. Btw. I complained earlier on slow disk info, and it is still that. TOS is much faster in that.

[czietz]

I just tried it with simple case: image with 2 short DOS FAT16 (under 32MB) partitions, and one BigDOS of 61MB, and EmuTOS 0.9.6 supplied with Hatari 2.0.0 mounts only first 2 non-BigDOS partitions (what can TOS too), 61 MB part. not.
So, what EmuTOS version can do it, any special requirements ?

If you provide the harddisk image, we can have a look. Note that support for MS-DOS-style extended partitions was added to EmuTOS only recently, so an old version like 0.9.6 won't support these -- regardless of the file system or partition type, though.

Info for that partition just works not in Desktop.

I can also have a look at that if I get the HD image.

[troed]

We got sidetracked. I still believe we need a common repository to work on these sources. I would also propose keeping the 2.06/3.06 version numbers and adding a minor number (word, I guess, we might make maaaany edits ) someplace else. Too many programs, I believe, will crap out on seeing 2.09 etc.

As to where that repository is hosted, well, maybe not too high profile - but still accessible. Any suggestions?

[BlankVector]

(sorry to be out of topic)

I just tried it with simple case: image with 2 short DOS FAT16 (under 32MB) partitions, and one BigDOS of 61MB, and EmuTOS 0.9.6 supplied with Hatari 2.0.0 mounts only first 2 non-BigDOS partitions (what can TOS too), 61 MB part. not.

I'm not sure if Big-DOS partitions are supported by EmuTOS yet. I have just asked on the EmuTOS Mailing List, where it is the right place.

Note that support for MS-DOS-style extended partitions was added to EmuTOS only recently,

MS-DOS MBR partition table has been supported for ages in EmuTOS. However, support for extended MS-DOS partitions (in opposition to primary) has only been added in EmuTOS 0.9.7. I'm really not sure this is related to AtariZoll's problem. It depends on how the drive has been formatted, partition table format, special settings, etc.

[AtariZoll]

I don't think that talking about EmuTOS features is off topic here - at least not if we want to use some parts of it.
And yes, that 3rd partition is extended.
DOS MBR partition table format is well known, standard, so that should not be issue. Same stays for FAT16 partitions used in DOS.
I made lot of tests in past with diverse medias, what partitioned with some Windows tools, like Partition Magic and Easeus partitioner.
Here is image: http://atari.8bitchip.info/TranscWithBigD.zip
It is one of those, what I used for Drive Imager developing.
But it is really easy to create something like, especially today with Flash cards. I'm sure that possible in Linux too, and there must be some GUI SW too.

[czietz]

I don't think that talking about EmuTOS features is off topic here - at least not if we want to use some parts of it.

I don't want to be spoilsport here, but I want to remind you of the licensing terms. If you use parts of EmuTOS, you create a derivative work. The GPL then requires you to license the whole work under said license. However, you cannot place Atari TOS sources -- the legality of which as far as I know remains questionable, anyway -- under the GPL.

Here is image: http://atari.8bitchip.info/TranscWithBigD.zip

I'll have a look at the issue with the "drive info" you mentioned before.

EDIT: There's something broken with the third (extended) partition in the image that you provided. That's why EmuTOS refuses to show you the drive information. I'll send you a PM since this doesn't belong in this thread anymore.

[AtariZoll]

What here goes is mostly hobby activity. Nobody will make money with some TOS patching. Count of interested people is low.
Really don't think that some legal issues should be problem.

[1st1]

To be precise, under which licence is the original ATARI TOS. What I know:

a) TOS consisists of different layers, BIOS, XBIOS, GEMDOS, VDI, AES, Desktop, many of them have been developped together with or by Digital Research
b) original GEM (on MS DOS PC) was by Digital Research and was put on GPL open source status later by last commercial owner (Caldera?)
c) EMUTOS (Atari & Co) and Free-GEM (PC) are based on b) and they are open source (GPL), the whole MiNT package as well also new OS layers like fvdi and naes.
d) TOS is based on b) but after initial versions ATARI did not continued partnership with DRI and advanced "their" GEM by themselves. TOS 2.0x, 3.0x and 4.0x (and 4.92) have much more comfortable desktop as DRI's original, so there is a lot of property of ATARI in these. TOS was never released as Open Source, maybe the intellectual property was sold to HTC, Hasbro, Infograms, new ATARI, where it is now?
e) APPLE in the mid 1980's filed DRI for GEM design and forced them to limit functionality (desktop icons, window arrangement, max two desktop windows as otherwise it's look&feel was too close to Finder. ATARI GEM mostly was not impacted by APPLE, probably except for limit to maximum 4 desktop windows (see KAOS TOS which is based on 1.04 or simple TOS patches which can do a lot more even on 512 kB machine).
f) Medusa has the licence on TOS 4.0x to use and modify it for it's clones, I think Firebee is using it (FireTOS).
g) also R.Czuba/Willy seems to have the possibility to use TOS 4.04 modification for CT6x.

The question is, as ATARI separated TOS early after bringing ST to market from DRI, what's it's licence status, specially as DRI's GEM has been put to GPL later? Maybe the question also must be, was Caldera right to put DRI GEM under GPL as ATARI GEM is not? The other conflict I see was already done by ATARI when they merged MiNT (which always was open source) with their proper Newdesk to create MuliTOS.

Can you clarify this, do I have some wrong thoughts, or is everything Ok now?

[1st1]

Really don't think that some legal issues should be problem.

This can not be an explanation.

[BlankVector]

Here is image:

Thanks to czietz for looking at that.

What here goes is mostly hobby activity.

Of course you are free to do what you want for yourself with GPL software (i.e. playing with EmuTOS sources or binaries). Limitations will only occur if you want to redistribute your work. Rules are simple: if you merge GPL sources to your project, and distribute it in binary form, then you must also license your project with GPL (otherwise it would violate copyright of The EmuTOS development team, Digital Research, Lineo, etc.). And you can only redistribute software under GPL (or any other license) if all copyright owners allowed to do that.

Nobody will make money with some TOS patching.

There is no question of money in GPL. It is about Freedom.

Count of interested people is low.

I would not say that.

[Nimrod]

Hmmm... is this a case of better to ask for forgiveness than permission?
Asking Atari(?) to GPL sources might result in a negative answer.

Still thinking of sending Atari an email at least to ask for clarification if they still retain the original sources and IP.
If they do, and the code is the jumbled mess as it appears to be, would they not potentially benefit from an open source cleanup and audit of the code?

[Cyprian]

ATARI GEM mostly was not impacted by APPLE, probably except for limit to maximum 4 desktop windows (see KAOS TOS which is based on 1.04 or simple TOS patches which can do a lot more even on 512 kB machine).

7 not 4