Amiga questions you've always been too embarrassed to ask

[Toni Wilen]

Originally Posted by Marle

I have a question, AGA sprites.

I understand OCS/ECS sprites well enough but not very clear on some of the AGA stuff.

So I know you can have 16x16, 32x32 and 64x64 sprites with AGA, but does that mean all 8 of them have to be the same size, can you mix and match, or is it two sizes on screen at a time e.g. like the SNES which can have 16x16 and 32x32 on screen, but not 16x16, 32x32 and 8x8?

Do the larger sprites occupy 1 or more sprite channels?

Colour wise, do they work like OCS/ECS sprites, 4 colours by default, 16 if attached? Or can they have more colours? I am aware you can shift the colour register offset where sprites take their colours away from col reg 16.

Sprites (all chipsets) don't have any height limits, they can be from 1 pixel to as tall as screen.

All sprites use same size (global size select bits in FMODE) horizontally. Nothing prevents you to change size with the copper but you won't gain anything useful because sprite width does not affect DMA usage.

16 pixel wide = uses normal 16-bit DMA cycles (1x bandwidth). 32 pixel = AGA-only 32-bit wide bus cycles (2x bandwidth). 64 pixel = double 32-bit bus cycles (4x bandwidth). (Annoyingly only bitplanes and sprites support 2x/4x bandwidth)

Attachment works identically. Odd and even sprites have separate color "bank" selection (0=colors 0 to 15, 1 = colors 16 to 31, 2 = colors 32 to 47 and so on.. OCS/ECS is hardwired to "bank" 1)

AGA sprites also have global resolution setting, independent of bitplane resolution.

[NorthWay]

Originally Posted by Marle

I have a question, AGA sprites.

They are exactly like OCS sprites apart from being 16, 32 or 64 pixels wide. The setting is for _all_ the sprites at the same time.

What changed with AGA was that you could select fetch mode to be 16 or 32 bits wide, and do one or two back-to-back fetches in the old 280ns timeslot that OCS dictates.

This reflects itself in sprites being 16, 32 or 64 pixels wide. You attach them like with OCS, and they have exactly as many colours as with OCS. Just wider.
There is an oddity in that the control words will now also have to be the same size, so you need to pad out with zeros - I don't know if anyone has checked to see if the pad data has any effect.

What is not so nice is that the display fetch hw was not made as flexible with AGA so if you are sideways scrolling it can eat 4(?) of your hw sprites when using the new fetchmodes for the display itself.
There are also no new SPRxDAT registers so you can only manually display them as the old 16 pixels wide.

[Marle]

Thanks Guys this is super helpful or rather really interesting. Yes sorry forgot Amiga sprites can be any height, had my NES/SNES head on.

It does seem AGA in terms of sprites was really quite hamstrung but sadly I always felt the Amiga's sprite capability was a weak point. Especially once the PC Engine (ok that's borderline once you reuse sprites on the Amiga), Mega Drive and heaven forbid the X68000 and NeoGeo rocked up.

[mcgeezer]

Originally Posted by Marle

Thanks Guys this is super helpful or rather really interesting. Yes sorry forgot Amiga sprites can be any height, had my NES/SNES head on.

It does seem AGA in terms of sprites was really quite hamstrung but sadly I always felt the Amiga's sprite capability was a weak point. Especially once the PC Engine (ok that's borderline once you reuse sprites on the Amiga), Mega Drive and heaven forbid the X68000 and NeoGeo rocked up.

Believe me, they're a pain in the arse!

[Leffmann]

Originally Posted by NorthWay

What is not so nice is that the display fetch hw was not made as flexible with AGA so if you are sideways scrolling it can eat 4(?) of your hw sprites when using the new fetchmodes for the display itself.

I wish! If you use 64-bit bitplane fetch and want HW scrolling for a standard 320 pixel wide screen then you lose all but sprite 0.

AGA was rushed, and a missed opportunity.

[Daedalus]

Originally Posted by NorthWay

They are exactly like OCS sprites apart from being 16, 32 or 64 pixels wide. The setting is for _all_ the sprites at the same time.

There are a couple of other changes too, as Toni pointed out. The palettes can be altered to point at different banks of 16 colours for odd and even channels, meaning that all 8 sprites can use different colours if you wanted, instead of all being stuck using pens 17-31. There's also subpixel positioning to go with the subpixel scrolling of the display.

As for setting different widths, there's no need as pointed out. You can simply use 16 pixel wide data in a 32- or 64-pixel-wide sprite channel with no performance penalty, leaving the rest of the sprite blank (colour 0). Once the handle is set appropriately, it will behave no differently from an ECS sprite.

[idrougge]

Originally Posted by Leffmann

I wish! If you use 64-bit bitplane fetch and want HW scrolling for a standard 320 pixel wide screen then you lose all but sprite 0.

Both horizontal and vertical scrolling?

[turrican3]

Originally Posted by Daedalus

Yeah, if you're using a CD32 emulator, CDDA should just work provided the standard CD32 access methods are followed. Streaming CDDA from hard drive is doable, but it would surprise you to know just how much of the computer's time that takes up on, say, a standard A1200. One minute of music takes around 10MB, so preloading will be tricky too unless you've a lot of RAM, and transferring that much data could take 10 seconds every minute. So it's not really an option except on much more powerful machines.

Yes it can't be done on a vanilla amiga 1200 but perhaps with a 030/50 mhz, what i mean : it's even if the 1st step isn't perfect it could lead to a better solution if coders see people using it and enjoy it. But the best way is surely to use whdload with interrupts to lauch a cdda between each stages.It could be set by a list in the drawer and perhaps with all indications needed to know the exact audio device to use and if not present , don't do anything.Making interupts to launch a cdda command shouldn't be so long and don't foget it will happen more of the time during stages switch a little interrrupt during this time is not so disturbing, you won't be in the middle of the satge. I know they are working on it and surely in the most clean way possible but it's too bad that they didn't discuss about there progress about it. But i can understand why they don't speak about it... some times peoples posts can be imprevisible and discouraging, i really hope they will succeed, i can just cross my fingers.
ps whdload team if you need help to test cdda functions, ask me if i can help... It will be a pleasure.

[Vot]

Originally Posted by turrican3

Yes it can't be done on a vanilla amiga 1200 but perhaps with a 030/50 mhz, what i mean : it's even if the 1st step isn't perfect it could lead to a better solution if coders see people using it and enjoy it. But the best way is surely to use whdload with interrupts to lauch a cdda between each stages.It could be set by a list in the drawer and perhaps with all indications needed to know the exact audio device to use and if not present , don't do anything.Making interupts to launch a cdda command shouldn't be so long and don't foget it will happen more of the time during stages switch a little interrrupt during this time is not so disturbing, you won't be in the middle of the satge. I know they are working on it and surely in the most clean way possible but it's too bad that they didn't discuss about there progress about it. But i can understand why they don't speak about it... some times peoples posts can be imprevisible and discouraging, i really hope they will succeed, i can just cross my fingers.
ps whdload team if you need help to test cdda functions, ask me if i can help... It will be a pleasure.

Oh lord you again with the same question. Playing cd and game sound On a 1200 isn’t trivial.

Cd32 games send commands to AIKIKO to play the cd audio.
The cd player plays it and mixes it via analog after paula for the final audio output.

There is no easy way to intercept these commands because every game doesn’t necessarily use the proper cd.device (which is where you could easily intercept the calls if they all used the system device) some bang akiko directly. You would need to modify, patch each cd32 whdload game.


Just say you were able to intercept the calls.. the next problem is you need enough dma,cpu time etc to read the data from the hdd for the cd audio... just say that is even possible (which for a number of games it may not be) then how do you play it..

The games expect to use all the audio channels. The only way to mix the audio would be to rewrite the hardware audio routines to a software mixer that then played it via paula or ahi. Do you understand that requires a lot of cpu time and completely rewriting the audio engine of each individual game?

In short its just not feasible...




Sent from my iPad using Tapatalk

[jotd]

what is doable (with some work!) is to add CD music on games with music OR sfx on a real CD32. On standard amiga, no way.

You cannot compare Amiga to a modern PC which is a CPU beast. Try to run Pacman on MAME on a 68060 you'll see how it crawls. On a PC it takes a few % CPU, it takes a few CPU to mix a lot of channels & resample them too. Not the same approach.

BTW it's AKIKO not AIKIKO

[Vot]

Originally Posted by jotd

BTW it's AKIKO not AIKIKO

Ah #$&% thats what i get for writing replies at 5am..


Sent from my iPad using Tapatalk

[roondar]

Originally Posted by idrougge

Both horizontal and vertical scrolling?

If you don't use horizontal scrolling, a 320x<any> screen should support all sprite channels on AGA, just like on OCS.

[seko]

Hi

i tested virtual sprite structure. coded ansi c language. i use vbcc for compiler.Result was trouble. i change arrow colors. Other spriters sometimes changed color.Maybe could code more optimise .Or i can use assembly language.




This video


[ Show youtube player ]

[idrougge]

Originally Posted by roondar

If you don't use horizontal scrolling, a 320x<any> screen should support all sprite channels on AGA, just like on OCS.

I was wondering re: Banshee.

[turrican3]

Originally Posted by jotd

what is doable (with some work!) is to add CD music on games with music OR sfx on a real CD32. On standard amiga, no way.

You cannot compare Amiga to a modern PC which is a CPU beast. Try to run Pacman on MAME on a 68060 you'll see how it crawls. On a PC it takes a few % CPU, it takes a few CPU to mix a lot of channels & resample them too. Not the same approach.

BTW it's AKIKO not AIKIKO

This what i thought about about add cdda to games for making cd32 enhanced versions. "vot" , thank you for the answer, didn't know that they used akiko for cd player too, i thought it was just used for C2P. A 1200 patch would be cpu hungry for sure. Thanks a lot for your answers.

[drHirudo]

How does Oxyron Patcher managed to get faster speeds on 68040/68060 Amigas, than the official AmigaOS 68040.library?

If Oxyron Patcher is rewritten with today's assemblers and the better knowledge of 68040/68060 undocumented features/instructions, will it make the old machines perform faster?

Can I lend some bitcoin miner's rack to search for the best optimised 68K code for Oxyron Patcher or 68040.library, so we get the best case scenario for the slow patched instructions or even patch all the previous Amiga 68K software code to perform faster?

[zipper]

I think MMULib system + MuRedox by Thor is the best patcher. http://aminet.net/util/libs/MMULib.lha http://aminet.net/util/boot/MuRedox.lha .

[AMIGASYSTEM]

Originally Posted by zipper

I think MMULib system + MuRedox by Thor is the best patcher. http://aminet.net/util/libs/MMULib.lha http://aminet.net/util/boot/MuRedox.lha .

This is more advanced v46.4 (same library)

http://aminet.net/package/util/libs/MMULib

[StingRay]

How does Oxyron Patcher managed to get faster speeds on 68040/68060 Amigas, than the official AmigaOS 68040.library?

Because it uses optimised code for each unsupported instruction that needs to be emulated instead of the "lazy" approach 68040 library uses.

If Oxyron Patcher is rewritten with today's assemblers and the better knowledge of 68040/68060 undocumented features/instructions, will it make the old machines perform faster?

Not really, the code is pretty optmised already.

[van_dammesque]

Originally Posted by drHirudo

How does Oxyron Patcher managed to get faster speeds on 68040/68060 Amigas, than the official AmigaOS 68040.library?

If Oxyron Patcher is rewritten with today's assemblers and the better knowledge of 68040/68060 undocumented features/instructions, will it make the old machines perform faster?

Can I lend some bitcoin miner's rack to search for the best optimised 68K code for Oxyron Patcher or 68040.library, so we get the best case scenario for the slow patched instructions or even patch all the previous Amiga 68K software code to perform faster?

OK my first question in this thread! I bought this for £6ish? With my Apollo 040 25Mhz in my A1200, my question is what programs/tests showed the patcher working? I ran with and without but didn't notice ANY difference (including running Doom etc...)!