New improved intuition.library version from the Kickstart 3.1

[psxphill]

But we're talking about AmigaOs, and as I already said: At *some* point, the copy has to be made. At file system level, or at device level. The question is just *where*. And the answer is quite obvious: Whoever created the mess must clean up.

Your solution is not obvious if you want the best speed. Forcing everything in the system to take copies is the worst solution for performance and for the sanity of the device developers.

A good solution would allow you to stream data from a file on a hard disk into memory on a sound card without any cpu copying involved ever with the hard disk device and the sound card device negotiating how to do it through an exec api. If copying was required then it would be exec that would do it.

Then again, where do you suppose to make the cut? At File system level? At user program level? If you make it at file system level, there is no freaking difference. Wether the FFS copies the data, or the device copies the data makes no difference.

Why do you need to copy the data? If you're streaming data then buffering it is pointless. If you've told the file system to buffer your file then it makes sense for the file system to take copies, but that should be optional.
 

Unfortunately, that is not true in this generality. For example, there is a batch of A4000 where CBM in their wisdom installed the wrong bus drivers for motherboard RAM (inverting instead of non-inverting). For the CPU, it doesn't make a difference since the data is read and written just "upside down". For DMA, it means that you get all your data inverted from the disk into the RAM. Thus, the only safe destination is really RAM on the card.

I've not heard about this. Any zorro transfer into motherboard ram (chip and fast) is broken? That definitely would require the type of system I'm proposing as it's the motherboard that is broken and making every device avoid dma'ing into motherboard ram is a horrible idea.

[psxphill]

I'm not forcing to make copies. I'm requiring that devices provide the data where the user requested them.

And the user cannot allocate memory in the most optimal way, so you are forcing devices to make copies.
 
 If the user allocates memory then for performance you need to make it the applications responsibility to allocate the correct memory, which is what we have now.
 
 Saying it's broken because it doesn't work like Windows is a rather odd stance.

[psxphill]

I mean working on x86 first, then eventually trying to port that back to 68k. That's just insane from simplicity, testing and performance standpoints.

I don't think they planned to port it back, or they would have done 68k first.
 
 From what I can tell it's mostly the graphics HID that is the problem, as well as sub optimal compilers.

[psxphill]

Please tell me how to do it. Lets say, I want to create generic trackdisk based copier that copies data from drive A to drive B. Source drive could use trackdisk.device and destination drive could use usbtrackdisk.device.

What is the most optimal buffer type application should use? And how to find it out? Ask user for correct memory type?

If you're asking the user for the usbtrackdisk.device name and unit then why not ask them for the type of ram?

Asking both devices is the only way to get the most optimal solution. By telling exec what things need to be able to access the ram then you can implement memory protection at the same time.

Or you could just copy the data using memcpy and pretend it's the best way.

[psxphill]

>Actually 3.1 was released by Village Tronic, not Commodore.
 
 It was distributed by Village Tronic. The content came from commodore.
 
 > Not that there is anything sacred about Commodore.
 
 In terms of Provenance there is.
 
 If I converted the Ship of Theseus to fibre glass then would it be the same ship? http://en.wikipedia.org/wiki/Ship_of_Theseus
 
 Some people want to maintain classic cars in their original form, others want to strip them down and rebuild them with different engine, suspension and lower the roof etc. The later only appeals to a minority, like OS3.5/3.9/4.x
 
 It's a shame that AROS hasn't been more focused on 68k in the past, I think that had the most potential for bridging the gap between old and new hardware.
 
 > I don't see the relevance of whether the ROM upgrade is performed in
 > firmware or software.

 If it's not in ROM then it's taking up RAM.

[psxphill]

I suggest to stick with 1.2 then. Everything else was not delivered with the original Amiga.

None of my original Amigas were ever delivered with 1.2

Oh, com'on! How many MBs does the average Amiga has today?

I have no idea & it's not relevant to my argument. It's relevant to your argument, so why don't you know?

Do you think a couple of KBs do actually matter?

The difference between software running or not could be 1 byte, but where are you getting "a couple of KBs" from. That was neither in the original statement or my reply.

[psxphill]

Did your Amgias come with 3.1 equipped?

I bought original Amigas with 1.3 (A500), 3.0 (A1200) and 3.1 (A1200).

Mine did not. Mine came with 1.2, so who's lying?

You didn't say your Amiga, you said "the original Amiga". So I'd say it was you who is lying by trying to twist facts to justify your argument.

[psxphill]

>>In terms of Provenance there is.

>I suppose you think that an Amiga Technologies (Escom) A1200 is not a >real Amiga then?

Why would you suppose that? Once you have reverted the floppy disk motherboard hack then it's mostly equivalent to a commodore A1200.

The AmigaOne isn't an Amiga though.

>I should point out that OS3.1 and even earlier versions used SetPatch to patch the ROM.

SetPatch goes back a very long way, but they were generally very small patches. OS3.5/3.9 replaced some libraries in ROM with disk based versions. Ideally you'd have the latest scsi.device in ROM.

[psxphill]

Well, if you revert enough of OS3.5/3.9 you can turn it back to OS3.1.

"enough" is subjective. I consider the Amiga Technologies badge and the floppy hack on the A1200 to be trivial to revert, while I don't consider having to install a CD drive to be trivial.

I don't have a problem with icon or datatype changes, even a standard tcpip stack is a good idea. Some of the bundled software wasn't the best examples out there though, but it tried to gain traction by virtue of it being distributed on the official media.

It's a bit like saying that a PPC Mac or Intel Mac isn't actually a Mac, only a 68K Mac is a real Mac. I suspect that if anyone went to a Mac forum and claimed such a thing there would be howls of derision.

Apple didn't go bankrupt with a seven year gap between new products. Also Apple certainly had opposition amongst it's user base when it switched to PPC and to Intel, it was just so long ago now and they've been so successful that people have moved on. Which makes the two situations quite different.