Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline kolla

Re: Os 3.2 development preview
« Reply #359 from previous page: 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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #360 on: December 04, 2019, 01:44:46 PM »
What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?
Once again: I DON'T KNOW AND I DON'T CARE. This is not Linux, NetBSD, AROS Miniming or UAE.

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 his this is implemented.

That still doesn't allow me to test anything. Once again: Specs *AND* hardware.

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") 

It does not matter. Replace by "generic vendor". Once again, in case you still don't get it: WE ARE NOT THE SUPPORT FOR /generic vendor/. IF /generic vendor/ WANTS US TO SUPPORT HIS HARDWARE, WE NEED THE SPECS AND THE HARDWARE, OR /generic vendor/ HAS TO DO THE SUPPORT ITSELF.

Got it? This is how commercial products work. You wouldn't also request your landlord to support your washing mashine just because it's sitting in your appartment.

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

It is fully working to what it was supposed to be working with. Namely, the naked IDE/SCSI interface available in the hardware that it was developed for.

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".
WE DO NOT DEVELOP EXPERIMENTAL SOFTWARE. This is not an open source project where you can get away with "oh well, we didn't care so much". Either the thing is tested and working, or it is not tested. And software that is not tested is not working.

Yes, we do make bugs, as everybody else. But at least, I will not blindly type down something, "oh well, this is good enough, let's just sell it". Not without having a piece of hardware, and without having someone evaluated it and having tested it positively.

Despite, I still don't get why you expect us to take down the trash of some third party vendor that abandoned its products. That's bad enough, but why do you expect to us to put this support on our shoulders. If the support for /generic vendor/ does not work, ditch the product. After all, you seem to believe that I'm responsible for every product that could potentially be installed in the Amiga.

THAT IS NOT THE CASE. Get over it. IT IS /generic vendor/ WHO IS RESPONSIBLE FOR ITS PRODUCTS.
 

Offline CBH

Re: Os 3.2 development preview
« Reply #361 on: December 04, 2019, 01:51:57 PM »
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?

The answer you seek is in the post you replied to

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.

Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.
 

Offline CBH

Re: Os 3.2 development preview
« Reply #362 on: December 04, 2019, 01:55:36 PM »
What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?
Once again: I DON'T KNOW AND I DON'T CARE. This is not Linux, NetBSD, AROS Miniming or UAE.

THOR: there's no solution to this problem. It's totally impossible, insurmountable problem
kolla: what about this well proven solution?
THOR: I DON'T KNOW OR CARE ABOUT SOLUTIONS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #363 on: December 04, 2019, 02:00:49 PM »
Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.
But that is exactly the problem: There is no API at the scsi.device level to get that supported. Hence, I do not know how their products work. They probably replace the entire code of the scsi.device and patch its BeginIO() vector over. We can make up an API for that, but it wouldn't help as the vendors have deprecated their products anyhow.

Thus, if you want to use their hardware, continue to use them. There is no intention to break any existing hardware. If the software that is required to get their hardware working doesn't work to your liking, and is not up to date because it doesn't support large drives, or your drive, then I don't quite see why that is a problem I need to solve.

I *could* solve that problem if someone sends me the specs AND the hardware, and asks politely. I.e. exactly unlike Kolla.

Just to clear that up, once again: NOTHING BREAKS IDEFIX or the Elbox software at that point. The limitations such software has with large drives is not up to the updated scsi.device. It is due to the limitations in the product sold by such parties itself.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #364 on: December 04, 2019, 02:14:06 PM »
I just tested on FS-UAE with the IDEFix (and *just* the IDEFix binary - no devs:atapi.device or anything) dowloaded from IComp, and with FS-UAE configured with two first drives as native gayle ide0 and two next as ide1 it works just as on real hardware, as well as MiSTer.

So this can be tested also without having tons of hardware available.
(and who knows - perhaps the largest mass of buyers are user of emulators and FPGA systems anyhow)

http://kolla.no/fs-uae-gayle2x.png
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 #365 on: December 04, 2019, 02:18:10 PM »
I just tested on FS-UAE with the IDEFix (and *just* the IDEFix binary - no devs:atapi.device or anything) dowloaded from IComp, and with FS-UAE configured with two first drives as native gayle ide0 and two next as ide1 it works just as on real hardware, as well as MiSTer.
And how do you know that? IOWs, instead of depending on hardware, you now depend on the correctness of the emulation. Sorry, but this is not a product for emulation, and you know that. It is a product for real hardware.
 

Offline CBH

Re: Os 3.2 development preview
« Reply #366 on: December 04, 2019, 02:20:12 PM »
Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.
But that is exactly the problem: There is no API at the scsi.device level to get that supported.

That is exactly the point, numbnuts. There is no API for scsi.device right now.

However: YOU ARE A DEVELOPER. YOU COULD MAKE ONE.

That's all you would have to do. You don't have to include OS support for IDE splitters or buffers, you just need to provide an API for third parties to develop this support themselves.

99% of the functionality the third party hardware/software provides is now in your updated AmigaOS. All we want is a safe way to enable the last 1% ourselves. Otherwise we have to throw away your 99% and your endeavour was pointless.

As it is this is my compromise argument, where you don't have to support any hardware you already don't, just provide a new (and rather small) API. But as kolla points out your arguments against actually supporting such thirdparty HW is bad - you say there's no specs and it can't be tested properly, but it's all documented and implemented by everyone else 100%, so it's obviously not that hard. "I don't care" is not an adult response to being proved wrong.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #367 on: December 04, 2019, 02:22:04 PM »
And how do you know that? IOWs, instead of depending on hardware, you now depend on the correctness of the emulation. Sorry, but this is not a product for emulation, and you know that. It is a product for real hardware.
Good effin greef - allright then, give me your address and I will send you an adapter!
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 #368 on: December 04, 2019, 02:26:48 PM »
Good effin greef - allright then, give me your address and I will send you an adapter!
Thanks. You have it. It's actually in any software guide I wrote.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #369 on: December 04, 2019, 02:30:01 PM »
However: YOU ARE A DEVELOPER. YOU COULD MAKE ONE.
Great. And then how do we get /generic vendor/ to support it?

Just to remind you: The problem is with the existing hardware that has been abandoned by its vendors. So how likely is it that this strategy will help users?

 

Offline kolla

Re: Os 3.2 development preview
« Reply #370 on: December 04, 2019, 02:30:47 PM »

you just need to provide an API for third parties to develop this support themselves.
That API is already there, but most, if not all, third parties have vanished.

It is clear that Thomas will not do it, so if this is important enough for the some of us, it is really a matter of finding someone who is willing and able to disassemble and patch the official scsi.device as it evolves. Legally this should be all fine, as it falls under "interoperability".
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: Os 3.2 development preview
« Reply #371 on: December 04, 2019, 02:33:27 PM »
Thanks. You have it. It's actually in any software guide I wrote.

I had the impression that you recently moved.
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 #372 on: December 04, 2019, 02:37:22 PM »
I had the impression that you recently moved.

Believe me. It will reach me if you send it to Berlin. I'll be there over Christmas. A 2nd drive (or something else) to connect it to would also be helpful, otherwise it's just a adapter without additional functionality. Please also note the type of adapter you have, and which of the identification protocols it speaks. I have about four of them.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #373 on: December 04, 2019, 02:43:00 PM »
That API is already there, but most, if not all, third parties have vanished.
There is no API, really. It would need a hook for identifying the device, and another one to modify the drive selection phase. scsi does not have external interfaces beyond the exec device interface.

It is clear that Thomas will not do it, so if this is important enough for the some of us, it is really a matter of finding someone who is willing and able to disassemble and patch the official scsi.device as it evolves. Legally this should be all fine, as it falls under "interoperability".
That's legally not fine anymore, but ask your lawer of least distrust. You are creating a derived product. It was ok a while ago if you had disassembled a binary to find out how to speak to a particular software, without using any of the software in the implementation of your interface. But that's not what you are intending. You intend to redistribute the binary. That was, even back then, not legit.

To make this more precise: If scsi.device had a hidden undocumented interface, you had been allowed a while back then to find out how this interface works, then program against that interface. This is as far as it went. Problem is: There is no hidden undocumented interface. There is just BeginIO().

You can implement your own scsi.device, from scratch. In fact, I wouldn't argue against that at all.

 

Offline kolla

Re: Os 3.2 development preview
« Reply #374 on: December 04, 2019, 02:43:15 PM »
Please also note the type of adapter you have, and which of the identification protocols it speaks. I have about four of them.

I still don't grasp this "identification protocol" you keep mentioning - how does a cable and two diods "identify" itself?
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