Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135180 times)

Description:

0 Members and 3 Guests are viewing this topic.

Offline kolla

Re: Os 3.2 development preview
« Reply #344 from previous page: December 03, 2019, 08:36:44 PM »
Can you say something about ASL and requesters? Will they too follow the same layout limitations and settings as the prefs programs? Will there at last be a RequestString coming with the OS that is system conform, ASL based and not requiring (ancient) reqtools.library?
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 CBH

Re: Os 3.2 development preview
« Reply #345 on: December 04, 2019, 12:15:45 AM »
I am not aware of several different protocols - could you elaborate?
Several variants exist how such adapters identify themselves as being present.

Someone is going to have to do something eventually. IDE splitters being incompatible with the OS drive handling improvements means that the people most interested in those improvements can't use them.

Even something basic for the scsi.device to say "hey is there any more IDE ports down there?" so that something third party can yell back "over here, here's how you talk to them" -hopefully without needing a reboot.

Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #346 on: December 04, 2019, 04:47:21 AM »
Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.

Why don't you talk to Elbox then? It's their product, and it's their duty to keep it updated. Is there any reason why the work of third party developers has to be offloaded to the core development team? We cannot even maintain their product - there is no specification I have, there is no hardware to test with we have, we cannot give any guarantee that such a code would be correct.

So, frankly, how could this possibly work? A hardware developer not taking his products and clients serious, but we should help out to fill the gap?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #347 on: December 04, 2019, 05:06:08 AM »
Next component: The FastFileSystem.

There is not really much to say as we haven't found any bugs. There are two slight improvements:

First, the FFS stores now all the bitmap blocks contiguous instead of interleaved with the bitmap list blocks. This has the (potential) advantage that a future FFS implementation may read them in one single go. We currently read them one by another. That's ok, but not quite as fast as we could. Still, it's faster than the previous version of the FFS as the code no longer allocates the memory for each block individually, reads it, and then releases it again, so AllocMem() and FreeMem() were stressed quite a lot. Instead, the FFS makes one allocation, and then keeps it.

Second, the FFS supports now ACTION_DIE, a new dos packet, that indicates to the file system that it should shut down if possible, releasing all its resources. It remains mounted, but with no handler task attached. This is one of the core ingredients to the new "Mounter" tool which mounts partitions from the RDB, and - as part of its job - also unmounts previous file systems on the same physical layer. With ACTION_DIE, it can release many more resources and does not have to keep copies of the file system lie around in memory, doing nothing.

Actually, ACTION_DIE was already integrated into CrossDos and the CDFS in 3.1.4, so we just completed a job that was started long before. It was a bit more tricky for the FFS because the FFS is heavily multi-threaded, and its code flow is not exactly easy to follow.

To trigger an ACTION_DIE manually, the "mount" command received a new option: "SHUTDOWN". Thus, "mount df0: SHUTDOWN" un-mounts df0: All provided, of course, that there are no locks open on DF0:, no files are open, and the FFS is idle as you would otherwise "pull the rug under its feet".

"Assign Dismount DF0:" is quite different. All it does is that it makes the mounted file system invisible to the dos.library and hence to programs that want to open files on it, but it keeps running in the background, potentially modifying the disk, and potentially (still) reacting on programs that talk to it. Thus, if a program still accesses the disk, "Assign Dismount" will not stop such programs, but the program will continue to operate. If you mounted a different disk layout on the same drive, this will cause quite some desaster.....

So the old rule still applies: RDB is not for removable media. Mount them with "SuperFloppy = 1", and no RDB on them, and the FFS will take care about the disk geometry itself and will size itself accordingly.

Thus, a safer way to un-mount a partition is first to attempt a "mount shutdown", and if that worked, kick the mount out of the system with "Assign dismount". Unfortunately, the latter is still not quite clean as it cannot reclaim the memory for the actual DosNode (i.e. the information on the disk in the dos.library) as there are multiple ways how it could have been allocated, but at least the major part of the memory and resouces is then cleanly released.
 
The following users thanked this post: Tygre

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #348 on: December 04, 2019, 06:45:02 AM »
Thanks for all the interesting things coming up for 3.2 -- taking me awhile to catch up :)

*) The con window is now opened in "new style" colors. While it makes typically no difference, it implies that the "Ed" window is now black on white, not yellow on black.

Does this mean that that these escape codes for changing foreground and background color would work with Ed with the correct colors?   

Code: [Select]
echo "*e[>1m*e[32;41m*e[0;0H*e[J"
prompt "*n*e[>1m*e[33;41m*e[1m%N.%R.*e[30;41m%S>*e[0m*e[32;41m "
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #349 on: December 04, 2019, 06:49:51 AM »
Does this mean that that these escape codes for changing foreground and background color would work with Ed with the correct colors?   
Err, what? No, this has nothing to do with with font rendering in the console. It is just how the menu is rendered. In 3.1 and before, the menu Ed attached to the window was "old style" "yellow on black". With 3.2, the menu will be "black on white", same as all other menus.
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #350 on: December 04, 2019, 07:01:28 AM »
Thanks for clarifying.

Does this mean that that these escape codes for changing foreground and background color would work with Ed with the correct colors?   
Err, what? No, this has nothing to do with with font rendering in the console. It is just how the menu is rendered. In 3.1 and before, the menu Ed attached to the window was "old style" "yellow on black". With 3.2, the menu will be "black on white", same as all other menus.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #351 on: December 04, 2019, 07:07:27 AM »
Elbox, IComp, AmigaKit and everyone else, they all do the “IDE splitting” the same way. Apparently there was one vendor (“VOL”?) that did it differently, but everyone else do it the same “EB Standard” (“ElBox”?) way, as far as I know. I am sure Jens could answer on this one, and perhaps even provide hardware.
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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #352 on: December 04, 2019, 07:10:17 AM »
Elbox, IComp, AmigaKit and everyone else, they all do the “IDE splitting” the same way.
Nope.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #353 on: December 04, 2019, 11:52:38 AM »
Elbox, IComp, AmigaKit and everyone else, they all do the “IDE splitting” the same way.
Nope.
Really - well, leave it to NetBSD and Linux to support Amiga hardware...
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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #354 on: December 04, 2019, 12:01:28 PM »
Really - well, leave it to NetBSD and Linux to support Amiga hardware...
If you want to use Linux and NetBSD on the Amiga, then go for it, works for me.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #355 on: December 04, 2019, 12:18:35 PM »
Really - well, leave it to NetBSD and Linux to support Amiga hardware...
If you want to use Linux and NetBSD on the Amiga, then go for it, works for me.
And AROS, apparently.
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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #356 on: December 04, 2019, 12:23:31 PM »
And AROS, apparently.
Also works for me. And, your point is?
 

Offline kolla

Re: Os 3.2 development preview
« Reply #357 on: December 04, 2019, 12:59:25 PM »
And AROS, apparently.
Also works for me. And, your point is?

My point is that it would be better to support the hands down most common variant of this hack (as implemented on UAE, as implemented in Minimig, as well as "real" Amiga), than to not support _any_ of them. Like Linux does, like NetBSD does, like AROS does.

I understand that you specifically do not *wish* to have this implemented. Your argument is "Several variants exist how such adapters identify themselves as being present", but as far as I have read, these devices do not at all identify themselves (and how would a cable with a couple diods identifiy itself?)  It is fine that you don't want to do it, but it appears that you specifically will not allow anyone else to look into it as well.

Maybe one of those things that will have to change with Cloanto as owner.
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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #358 on: December 04, 2019, 01:05:10 PM »
I understand that you specifically do not *wish* to have this implemented.
No, completely wrong. My point is that if I support a component, I better have the specs available, and I better have the hardware available for testing. None of the two is given. Thus, you can do the following:

a) ask Elbox to update their software
b) ask Elbox to send me their specs and their hardware to get it supported,
c) organize hardware and specifications, and send them

There *is* no component going into the kickstart, especially into a component we cannot update by software, that is untested by any means. I don't want to end with the situation that we have some half-working component without at least having the chance to get it tested, and having verified that it does what it is supposed to do.


 

Offline kolla

Re: Os 3.2 development preview
« Reply #359 on: December 04, 2019, 01:33:25 PM »
I understand that you specifically do not *wish* to have this implemented.
No, completely wrong. My point is that if I support a component, I better have the specs available, and I better have the hardware available for testing. None of the two is given.

What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?

Again . Jens Schönfeld is very likely able to provide you all the spec information needed, and there is source code available from all the mentioned projects about how this is implemented.

Quote
Thus, you can do the following:

a) ask Elbox to update their software.
b) ask Elbox to send me their specs and their hardware to get it supported,
c) organize hardware and specifications, and send them

I don't get exactly why this focus on ElBox? This was never their invention, they are just one of many implementers, among them, also Jens Schönfeldt - http://wiki.icomp.de/wiki/IDE-fix (and now I understand that EB is "Elaborate Bytes") 

Quote
There *is* no component going into the kickstart, especially into a component we cannot update by software, that is untested by any means. I don't want to end with the situation that we have some half-working component without at least having the chance to get it tested, and having verified that it does what it is supposed to do.

One could argue that the current scsi.device is "half working" as one could really support exactly twice as many devices on the bus :)

There is no need to put it in kickstart - it would be easy to allow the (drumroll) __*** U S E R ***___ to explicitly load a dedicated variant of scsi.device with such support that officially is considered "an experiemental hack".
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