Welcome, Guest. Please login or register.

Author Topic: Cloanto's Kickstart ROM 3.X and SFS  (Read 4083 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline kolla

Re: Cloanto's Kickstart ROM 3.X and SFS
« Reply #14 from previous page: February 14, 2018, 01:32:05 PM »
Quote from: psxphill;836128
If what you're saying is true, then the person who wrote that structure was not very good at their job.

Quick and dirty, no thought of supporting other filesystems than those shipping with it.
« Last Edit: February 14, 2018, 01:35:26 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Cloanto's Kickstart ROM 3.X and SFS
« Reply #15 on: February 14, 2018, 01:36:32 PM »
Silly question - why does this bug manifest itself only in exec v45 and up?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline psxphill

Re: Cloanto's Kickstart ROM 3.X and SFS
« Reply #16 on: February 14, 2018, 04:36:53 PM »
Quote from: kolla;836129
Quick and dirty, no thought of supporting other filesystems than those shipping with it.


Well we know it was quick and dirty, for example the trackdisk.device used software decoding to find the sync mark until something like 2.0 even though all amigas could do it in hardware. I assume they wrote the code before the hardware was working and then never went back to fixing it.

Using the same identifier for the file system was a particularly poor choice and naming the variable so that the obvious interpretation was that it's a file system sealed the deal.

It reminds me of:

enum Bool
{
    True,
    False,
    FileNotFound
};

Trying to decode what the "correct" usage is therefore becomes a painful exercise. Especially when even official software supposedly went with the wrong interpretation.
 

guest11527

  • Guest
Re: Cloanto's Kickstart ROM 3.X and SFS
« Reply #17 on: February 14, 2018, 07:28:41 PM »
Quote from: kolla;836130
Silly question - why does this bug manifest itself only in exec v45 and up?
It does not. SFS has a version check in it, that is why. Exec is completely unrelated.
 

guest11527

  • Guest
Re: Cloanto's Kickstart ROM 3.X and SFS
« Reply #18 on: February 14, 2018, 07:43:19 PM »
Quote from: psxphill;836135
Well we know it was quick and dirty, for example the trackdisk.device used software decoding to find the sync mark until something like 2.0 even though all amigas could do it in hardware.
As far as the trackdisk.device is concerned: At the time trackdisk was written, PAULA was not yet completely engineered. In fact, it was called PORTIA back then, and PORTIA did not have automatic synchronization to a sync word. This was added "last minute". You find this in the ancient trackdisk sources. There was apparently no time to "clean up" trackdisk, and since it worked, nobody cared - there was more important stuff to do.

As far as Info() is concerned: Tripos was an academic exercise, and many details where engineered in an "ad hoc" way, without giving too much thought on the details and the implications. Look for example at ACTON_EXNEXT. This packet is almost impossible to implement correctly, and the way how OFS handled it, was outright naive and could have only worked in non-multitasking environemtns.

Quote from: psxphill;836135
Trying to decode what the "correct" usage is therefore becomes a painful exercise. Especially when even official software supposedly went with the wrong interpretation.
That was not the only mistake that was introduced with FFS: OFS has a pretty useful interpretation of the read/write open mode that locked the file from other processes similar to ACTION_FINDOUTPUT, but unlike the latter, did not overwrite it. This was messed up by FFS which only requests a read-lock on READWRITE, and thus allows two tasks modifying the same file at the same time. Unfortunately, this bug was then back-ported to the Ram-Handler as well. Oh well...

You find such hisitorical errors all over the place. This is just one of them.

In case you care: You find the partition type in the mount list aka the Environment-Vector.