New improved intuition.library version from the Kickstart 3.1

[itix]

_DrawImage
move.l   d2,-(sp)
move.l   8(sp),d0
move.l   $C(sp),d1
move.l   $10(sp),d2
clr.l   -(sp)
clr.l   -(sp)
move.l   $1C(sp),-(sp)
move.l   d2,-(sp)
move.l   d1,-(sp)
move.l   d0,-(sp)
bsr.w   _DrawImageState
lea   $18(sp),sp
move.l   (sp)+,d2 ; make the wrong CCR for BenchTrash 1.73
rts

FYI if BenchTrash is assuming CCR is set (unless explicitly documented in autodocs) then it is fault in BenchTrash. (Edit: when reading thread back to beginning it looks like this call was missing return code completely? Or?)

And another note. Now when you have optimized away function setup you still have problem with slow gfx output. What you have achieved is CopyMemQuick() optimization of intuition...

[itix]

And another note. Now when you have optimized away function setup you still have problem with slow gfx output. What you have achieved is CopyMemQuick() optimization of intuition...

I don't quite understand what you want to say here...

CopyMemQuick() is perfect example of redundant micro optimization. Assuming that routines are done right, CopyMemQuick() is never faster than CopyMem(). Saving six asm instructions on each CopyMemQuick() call is not worth it.

[itix]

You're assuming that CopyMemQuick() was always supposed to leverage an unrolled movem.l loop.

No, I am assuming CopyMem() is highly optimized just like CopyMemQuick(). If CopyMemQuick() is using better memory copy routine than its CopyMem() counterpart then there is something seriously wrong.

There are notes in the old autodocs which hint that somebody was dreaming about having hardware-accelerated data copying operations available at some point. I take it that this type of hardware actually did exist for 68k Sun workstations, so this wasn't completely unrealistic.

Given how cheap Commodore was, the ambition never resulted in such hardware showing up, though.

I'm speculating: had this hardware existed for the Amiga, it would have hooked into CopyMemQuick().

I always assumed they meant blitter. DMAing between chip and fast ram could have been nice.

[itix]

Why would you assume that? CopyMemQuick() is obviously supposed to be more optimised, because it has the word "Quick" in it.

Why not optimize CopyMem() ?

Look at this readme and check benchmarks. Using so called "optimized" CopyMemQuick() only pays off when you are copying small buffers (16 bytes or less) but then if you want really good performance for such small copies it is better inline it.

[itix]

It can never be as optimised because CopyMemQuick() only works on long word aligned data, while CopyMem() has to work on arbitrarily aligned data.

Only function prologue and epilogue are different. In CopyMem() they are longer, prologue because it must check long word alignment and epilogue because it must check if there are remaining bytes to copy.

 I looked what NewCMQ060 patch does and in CopyMem() patch the prologue is only 6 asm instructions longer than in CopyMemQuick() patch. This is reason why small copies (4-16 bytes) take longer in CopyMem() because it has to execute more instructions before memory copy is started.

But it does not matter because neither CopyMemQuick() is optimal for small copies. It is better than CopyMem() but not the best. It never can be the best.

In fact in general computing it could be better if CopyMem() shared its memcopy routine with CopyMemQuick() to have better chance for L1 instruction cache hit.

[itix]

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.

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?

[itix]

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

Why ask user? Is user expected to know difference of memory types? If I am streaming MP3 from the disk should I ask user what memory type is optimal for disk access and what memory type is optimal for ahi.device for audio output? And also ask what memory type is preferred for mega.library that could use some sort of hardware decoding?

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.

It is the best way. It is better than guru meditation or ask user for memory config. This is not MS-DOS.

[itix]

>

>The reality even today is that it is 100% possible (and not even hard) to setup a useable Amiga without ever touching ClassAct/ReAction. Try the same without useing MUI (yes even on OS4)...

I don't use any MUI programs, I keep it installed just for trying out new programs but have never found a MUI-based one worth keeping...I can't see how you could possibly have a usable Amiga without ReAction, considering that important OS components require it. At least for OS3.5/3.9.

OS 3.1 users don't have any OS components using ClassAct/Reaction and I don't know any 3rd party software requiring Reaction. AWeb works with ClassAct, so does DirAction and few other I have tried.

OS 3.5/3.9 had almost no improvements (scsi.device with large hd support was only major improvement there) but just 3rd party software you can download from Aminet for free.

[itix]

Hey, no fair, that hurts

I'm one of the crazy people who worked their asses off for those "almost no improvements" in OS 3.5.

I know...

You casually dismiss the whole effort of rebuilding and fixing most of the disk-based operating system components, including the datatypes, the printing subsystem, preferences, Workbench and its icon system. We even managed to put in bug fixes for ROM-based components. OS 3.5 brought API changes, code cleanup and the original plan was to build upon that in future development work. We even managed to beta test the whole product.

Unfortunately it is not so useful to end users. Being paid update users dont have much interest on API changes or code cleanup or components he can download from Aminet for free. OS 3.5 introduced GlowIcons (which I already had in NewIcons format) and WB improvements. Latter made me quite curious about to get update but in the end I never could justify price. OS 3.1 with all patches and that stuff was just too good.

But that is just me. Real problem in bigger picture obviously was lack of users.

In retrospect, the OS 3.5 update was too little too late, but it certainly was no frivolous attempt at selling basically nothing to the gullible.

It was developed in difficult situation, no doubt.

[itix]

I'm wondering: if we exclude the fact that it's opened (that's already huge, yes), can be fixed and improved by anyone, and is portable, what are the benefits of running AROS instead of original AOS on 68k hardware? It seems most AROS developers don't seem to be that interested in seeing it run correctly (ie: at least on par with original AOS on 68k hardware) but why would they? What's the motivation? What would it bring?

for amiga userrs aros brings additional functionalities, like built in usb stack, network stack, rtg support, gallium/mesa, css capable browser, ability to move windows off screen, a number of contributions, apps and games, capable of running on 68k.

I think AROS on Amiga HW is having sort of same problem than OS 3.5/3.9 had. If you had USB/network/gfx board or other expansion HW you already had required drivers and programs installed. Probably bunch of WB enhancers too which allow most of those candy features and given that Amiga hardware is quite limited it is difficult to build new enhancements.

If there was new/old 68k hardware supported only by AROS 68k then it could be different game. I guess it is too late to support old 68k Macs now ;-)

[itix]

Or maybe if AROS brought something really new and better (memory protection? etc...) ?

If you break binary compatibility why bother with 68k?

[itix]

>OS 3.5 introduced GlowIcons (which I already had in NewIcons format)

NewIcons is just an unofficial "hack and patch" based on tooltypes, whereas GlowIcons is a proper upgrade to the icon system, the two are not at all equivalent.

Not really hack and patch. NewIcons just replaces original icon image with image encoded in tooltypes. It is slower but works and is quite clean. Glowicons append IFF ICON chunk to end of icon file. Users dont really care how icon data is stored.

>The more recent releases have no big API updates anyway

Yes they do, obviously you haven't read the autodocs.

I did. New calls in Exec are not important. Improved printer.device is useful only to few application developers who want to support printing and it is probably enough if you support Turboprint. Icon.library changes -- not very useful to average developers. Me being MUI developer I dont have to deal with icon.library except when using GetDiskObject() to get proper app icon and icon.library new API was probably meant to support future 3rd party WB enhancers (?). Workbench.library changes are nice, OpenWorkbenchObject() is one of few new API calls I have ever used.

ClassAct is avaibale from Aminet and had they chosen to use MUI instead it would have not made any difference.

[itix]

> 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.

Memory is cheap. I had 64MB on my A1200 and there was always more than needed. But having ROM is advantage because to replace ROM libraries you had to reboot. It is annoying because even with 3.1 booting was taking quite long.

If there was 3.5/3.9 ROM chip with BVision support in boot menu it could have been much much better... dont you hate it when it stops booting and you dont have TV near? Sometimes I was thinking my Amiga 1200 was better without those stupid complex expansions. Just vanilla Kickstart 3.1 and Miami + ethernet card, simple 68030 accelerator and small HD, Workbench on 640x256 screen.

[itix]

The BlizzardPPC had a feature that would constantly copy the current screen from chip ram to BVision ram. It would be enabled if something was displayed during the boot process and disabled as soon as the first non PAL:Hires screen was opened. Display wasn't all that fast, but fast enough for BVision setup, ESM, or booting without startup-sequence.

Oh, indeed... you are correct.

Unfortunate how much Amiga knowledge one can forget.