Aladdin AGA - possible to run on ECS?

[roondar]

It would be interesting to see an ECS version of Aladdin and how it would look.

The AGA version runs in 64 colour mode and uses the Blitter to move the background layer (and uses the wider AGA sprites to boot) so it would likely have to be cut down graphically quite a bit for it to work.

[AmigaHope]

Originally Posted by roondar

It would be interesting to see an ECS version of Aladdin and how it would look.

The AGA version runs in 64 colour mode and uses the Blitter to move the background layer (and uses the wider AGA sprites to boot) so it would likely have to be cut down graphically quite a bit for it to work.

ECS (but *NOT* OCS) blitter should be compatible with AGA blitter, so that part should work.

64-colors obviously not possible -- you'd have to make it work in 32 colors (and probably halve every independent palette the game expects to be able to use). You could probably get away with some EHB trickery to make things look better but would still have to work with the halved palettes. Biggest obstacle would be the AGA sprites.

If there were bandwidth limitations from ECS chip mem it might require shifting some stuff to CPU and/or require fastmem to buy CPU extra time. At bare minimum should be possible to get it working on the A3000 since its CPU -> chipmem interface is as fast (or frequently faster) than the A1200's.

[roondar]

Originally Posted by AmigaHope

ECS (but *NOT* OCS) blitter should be compatible with AGA blitter, so that part should work. 64-colors obviously not possible -- you'd have to make it work in 32 colors (and probably halve every independent palette the game expects to be able to use). You could probably get away with some EHB trickery to make things look better but would still have to work with the halved palettes. Biggest obstacle would be the AGA sprites.

Apart from the size of blits allowed in one blit, the Blitter is unchanged from OCS to ECS to AGA.

However, AGA can use faster graphics fetches from memory (4x the speed of OCS). Aladdin uses this feature, which gives it much more DMA cycles to actually use the Blitter than an OCS/ECS game would have.

As such, even if you were to run the game in 32 colours mode, you'd simply not be able to match the frame rate. So it's not just the screen depth and wider sprites, but also the fact that under AGA the Blitter appears to be significantly faster*. And obviously, the CPU in the A1200 is also much faster than the one in the A500 so it needs far less time to run the game logic, which adds to the problems for an OCS/ECS version.

These things combined, I just can't see getting a similar result even if you were to run it in 32 colours. The sprites don't help matters, but they are far from the only problem. I've not done the full math, but a quick back-of-the-envelope guestimate tells me that a 32 colour screen mode on an A500 takes uses up roughly 38% of all DMA cycles available vs a 64 colour screen mode on the A1200 taking up about 11%**. That's a pretty big difference to overcome.

*) note here that the Blitter is not actually running faster under AGA, it just gets far more DMA slots to operate in and thus gets to do more stuff in a frame.

**) For transparency: DMA cycles available = 70512-2304 for refresh & audio = 68208. OCS 5 BPL screen @320x256=(320/16)*256*5=25600. AGA 6 BPL screen @320x256=((320/16)*256*6)/4=7680.

Edit: I saw you specified the expected target to be an A3000. That would indeed change things a bit, but remember that bitplanes under AGA leave far more chipmem bandwidth available than ECS does, so even if the CPU interface to chipmemory ran at a higher overall bandwidth, less of the total bandwidth would be available to do such transfers. I'm honestly still not convinced you'd get a result that wouldn't be a clear downgrade. Also, the A3000 chipmemory interface is only faster when reading. Best case write speed is identical to the base A1200.

IMHO a 16 bit chipmem machine will definitely not be able to cope - fast mem or not (except perhaps some ludicrous system like one with a very fast CPU - such as a 68040 or 68060 and a bunch of fast memory).

[Mrz]

Aladdin could run in the A500 depending the engine used
for ex Team 17' Superfrog/Assassin engine is very fast it could run in a plain A500 platform games in 32 colors at 50 fps

Aladdin AGA uses the same putty squad engine, runs in 64 colors but runs at 25fps , this engine is not very good because is not enough smooth

[roondar]

Originally Posted by Mrz

Aladdin could run in the A500 depending the engine used
for ex Team 17' Superfrog/Assassin engine is very fast it could run in a plain A500 platform games in 32 colors at 50 fps

Not without significant cutbacks.

Case in point, the Superfrog/Assassin engine only shows layer instead of two, loses you half the colours and has (compared to Aladdin) very little in the way of on screen animation or enemies and the enemies that are there tend to be much smaller. Don't get me wrong, I really like both Superfrog & Assassin, but they are a lot less 'busy' than Aladdin is.

And that doesn't get into the memory difference, which does play a significant part here as well as it's part of what allows Aladdin having all those bigger and much nicer animated enemies (this also goes for player and other graphics).

[AmigaHope]

Originally Posted by roondar

These things combined, I just can't see getting a similar result even if you were to run it in 32 colours. The sprites don't help matters, but they are far from the only problem. I've not done the full math, but a quick back-of-the-envelope guestimate tells me that a 32 colour screen mode on an A500 takes uses up roughly 38% of all DMA cycles available vs a 64 colour screen mode on the A1200 taking up about 11%**. That's a pretty big difference to overcome.

*) note here that the Blitter is not actually running faster under AGA, it just gets far more DMA slots to operate in and thus gets to do more stuff in a frame.

**) For transparency: DMA cycles available = 70512-2304 for refresh & audio = 68208. OCS 5 BPL screen @320x256=(320/16)*256*5=25600. AGA 6 BPL screen @320x256=((320/16)*256*6)/4=7680.

. Also, the A3000 chipmemory interface is only faster when reading. Best case write speed is identical to the base A1200.

I seem to recall chipmem writes being significantly faster as well on the A3000 vs the A1200 due to Budgie being overly simplified and slower, with the A3000 offering buffering on longword writes resulting in fewer waitstates. i.e chipmem is fastest on A3000, followed closely by A4000 (same bus architecture but higher latency RAM), then A1200 (Budgie being the bottleneck resulting in bad waitstates especially if the bus is run asynchronously) The onboard 68EC020 not being affected by this but still being slower due to its nature.

While it's true that there will be less DMA time for the (identical) blitter to work on ECS, it's not THAT bad, and you could move some of those blits to CPU, which would have tons of free time with the simple addition of fast memory (the A1200's CPU with no fast memory is incredibly constrained, CPU performance almost doubles from the simple addition of fast RAM). You could probably shift half of the blits over to the CPU with all the spare cycles you got even on the bottom-tier A3000 w/68030@16Mhz. The blits would be faster than even the AGA native blitter since you'd keep a copy of the tilemaps in fast memory and only do fast2chip vs. the blitter doing its slow native chip2chip. (The AGA blitter not being upgraded was a travesty).

Basically on any system with 32-bit fastmem the only reason ever to use the blitter is that it can do its stuff in parallel as long as you have spare reserved DMA cycles. By virtue of being on fast RAM on an ECS A3000, you effectively gain an extra blitter vs. a chipmem-only A1200. Again, the goal isn't whether you could get equivalent performance with equivalent gear A3000 vs A1200. The question is whether a stock or modestly-upgraded A3000 with fast ram has the oomph to compensate for the lack of AGA vs. a stock chip-only A1200, to run a 32-color Aladdin (or maybe even an EHB Aladdin!)

[roondar]

Before I continue with my reply, I do want to make sure something is understood - when I am stating that OCS/ECS machines can't do Aladdin 'as is' and need to do significant cut-downs, I am mostly referring to people claiming that the A500 would be able to do it just as well as the A1200. If you equip an A3000 with a fast enough processor (say a 68040 or 68060 - or even a fast enough 68030), you'll probably get close.

With that said, let's continue.

Originally Posted by AmigaHope

I seem to recall chipmem writes being significantly faster as well on the A3000 vs the A1200 due to Budgie being overly simplified and slower, with the A3000 offering buffering on longword writes resulting in fewer waitstates. i.e chipmem is fastest on A3000, followed closely by A4000 (same bus architecture but higher latency RAM), then A1200 (Budgie being the bottleneck resulting in bad waitstates especially if the bus is run asynchronously) The onboard 68EC020 not being affected by this but still being slower due to its nature.

When I say A1200 chip memory is as fast as A3000 chip memory I am talking about base machine vs base machine. Expansion cards do change things on the A1200, but even there the 'properly designed' ones more or less reach the same speeds as the built-in 68020 and those that don't tend to be so fast as to make the problem moot (i.e. running a 68060 makes most problems go away as the CPU is so fast all non-graphics tasks for a simple game like Aladdin are going to be done in no time flat).

As is, the bustest (http://aminet.net/package/util/moni/bustest) program running on the A1200 shows the 68020 reaching chip memory write speeds of roughly 6.9MB/sec, which is only .1MB/sec off the theoretical limit so it's hardly 'poor'. Read speeds reach up to 5.6MB/sec, which is a lot less nice - but still better than the claimed speeds for a Cyberstorm accelerated A3000 on the bustest Aminet page (which only reached 3.8MB/sec - though it's possible different configurations reach better results).

I've attached a screenshot of bustest running on my A1200 for reference.

While it's true that there will be less DMA time for the (identical) blitter to work on ECS, it's not THAT bad, and you could move some of those blits to CPU, which would have tons of free time with the simple addition of fast memory (the A1200's CPU with no fast memory is incredibly constrained, CPU performance almost doubles from the simple addition of fast RAM). You could probably shift half of the blits over to the CPU with all the spare cycles you got even on the bottom-tier A3000 w/68030@16Mhz. The blits would be faster than even the AGA native blitter since you'd keep a copy of the tilemaps in fast memory and only do fast2chip vs. the blitter doing its slow native chip2chip. (The AGA blitter not being upgraded was a travesty).

A 68030/16MHz is only really guaranteed to beat the Blitter for unshifted tilemap actions. Shifted partially overlapping/transparent tiles (i.e. such as the Aladdin background) are unlikely to benefit nearly as much (the Blitter doesn't need extra steps to do any shifting, but the 68030 would need at least a separate move & shift* - which does slow things down significantly even with the barrel shifter of the 68020+). Cookie-cut operations are still going to be faster using the Blitter, again due to the Blitter doing these multi-source + logic operations in once step whereas the 68030 would need multiple.

As for there only being a small amount of losses here, an OCS/ECS 5 bitplane screen will lose you somewhere around 2.6MB/sec of chipmemory bandwidth (out of the 7MB/sec available). A 6 bitplane EHB screen loses you even more: around 3MB/sec. Meanwhile, the AGA 6 bitplane screen will only lose you about 0.8MB/sec of chipmemory bandwidth. That is not a small difference to overcome and I remain unconvinced a 16MHz 68030 with fastmemory has the oomph to make up for that.

Basically on any system with 32-bit fastmem the only reason ever to use the blitter is that it can do its stuff in parallel as long as you have spare reserved DMA cycles. By virtue of being on fast RAM on an ECS A3000, you effectively gain an extra blitter vs. a chipmem-only A1200.

For some Blitter operations, yes. But a base A3000@16MHz is not going to beat the Blitter at all tasks (essentially, any task that involves multiple sources/logical operations is likely to still be notably faster using the Blitter). Nor can you simply do all stuff in parallel: every cycle used by the Blitter/bitplanes/etc is one the CPU can't use to access chipmemory, even if it has unlimited fastram bandwidth.

Likewise, I feel you're underestimating the A1200 here - the 68020 can be used in parallel with the Blitter fairly well (i.e. not it's not that much worse off than the 68030 would be in the A3000) due to the low amount of DMA contention AGA offers, plus the low number of DMA slots the 68020 actually gets to access (while still reaching 99% of maximum possible write speeds to chip memory). As such, for tilemap actions a bunch of AGA games already use it instead of the Blitter and it performs quite well for these actions.

Now I do agree that tilemap/copy actions will benefit even more if the source is in fastram (and if the CPU is fast enough, all other operations will benefit as well), but again, you have to overcome losing a pretty big chunk of bandwidth compared to AGA. And all this is without ever considering what you yourself agreed would be a problem: the sprites, without which you have to do even more work to display the rather big sprites used in the game (and it's expensive work - Sprites are more or less 'free', soft blitting definitely isn't).

I guess you could go full 'build a fastmem framebuffer and copy over' to try and compensate but I'm not really convinced that is going to work all that much better as this would (due to the slow copy speed and large areas of the screen that Aladdin actually updates) leave you with very little time to actually build the buffer you want to show. Especially considering the rather slow CPU in the base A3000 model.

Again, the goal isn't whether you could get equivalent performance with equivalent gear A3000 vs A1200. The question is whether a stock or modestly-upgraded A3000 with fast ram has the oomph to compensate for the lack of AGA vs. a stock chip-only A1200, to run a 32-color Aladdin (or maybe even an EHB Aladdin!)

No, the question was whether an A500 with 1/2 a MB of extra memory could do it. It very clearly can't.

You wanted to look at the A3000 instead. This is fine, but that is not what the comparison started out as at all. Nor do I feel it's a particularly relevant one as an A3000 was about 6 times the price of an A1200 ($3500 vs $600) and clearly not aimed at the same market. Needing $3500 of kit (plus some upgrades) to get close to what a $600 budget computer can do doesn't sound like a 'win' for the $3500 machine to me TBH. In fact, I'd go so far as to say that this discussion we're having here is pretty good evidence that the A1200+AGA is a much nicer upgrade over the A500 than some (most?) people here hold it to be.

All in all, I still firmly believe the answer is in all likelihood still 'no' for a base 16MHz A3000, unless you're willing to cut down more than just the number of bitplanes. It'll definitely get much closer than an A500, though.

*) this is not quite true - in reality the two layer screen used in Aladdin will require more than just one move + one additional shift operation per word/long to get to work.

[DamienD]

How has this turned into a technical / coding thread?

...it's about trying to locate an ECS version; if one indeed exists.

Back on topic please.

[roondar]

Originally Posted by DamienD

How has this turned into a technical / coding thread?

...it's about trying to locate an ECS version; if one indeed exists.

Back on topic please.

That may have been my fault for musing about the possibilities. Apologies for getting the thread so far off topic!

However, I do find the discussion of these technical merits fun/interesting so I wonder if you'd be willing to to move the off-topic posts into a separate thread?

[DamienD]

Posts moved from the request.Old Rare Games --> Aladdin ECS thread...

[roondar]

Thanks for moving the thread!

Now back to the (by now on topic ) discussion:

It occurs to me that there may be a way to get a better result than I've been guessing. If the 68030 we're talking about here is fast enough to do at least some of the blits in fast memory, there may be a way to make this work better.

I will add that this idea does probably result in a much more complicated program than Aladdin is now, but here goes:

1. Have a copy of the tilemaps & bob/sprite source data in fastmemory and reserve space to soft blit all bobs/sprites needed by the game
2. Have two buffers of the screen bitmap in chipmemory (optionally use three to get a pristine background to use as source for blits if bobs end up being done by the Blitter as well)
3. Blit the background layer using the blitter in chip memory (I'm still convinced this will be faster than using the 68030 and copying it over )
4. Soft blit all bobs + the shifted background behind them into fast memory. Note: only blit the absolute minimum area needed, so a non-overlapping 32x32 bob will never use more than 48x32 pixels* of space
5. Make sure that overlapping bobs either get drawn as overlapping in step four, or have an additional 'merge' step to create overlapping bobs
6. Copy over only the affected areas of the screen to chip memory (dirty rectangles achieved :P)
7. Optionally use ECS sprites & any remaining raster time (if any is left at this point) to blit extra bobs
8. Swap buffers as needed

Why so many buffers/steps?

Well, the idea is to prevent a full-screen copy and instead get a 'dirty rectangles' approach going as the 68030 performs much better during a straight copy than doing a shifted/masked blit. Note you'll still have to do all that shifting/masking for the bobs & sprites, but only in fast memory and you can this while the Blitter is doing it's background layer thing, so it'll hopefully be fast enough. Especially as you're not actually going to copy whole screens from fast to chip.

I'm still not 100% convinced this will be fast enough given that a 16MHz 68030 is not really that fast, but it does seem to me like a more realistic way of achieving the desired result than just copying over the entire buffer.

Though to be fair, I'm pretty certain that Aladdin as is could probably be improved on the A1200 as well (although admittedly you might be forced to pick between 50Hz updates with the missing 'line scrolling effects' from the MD and using 64 colours).

*) or 64x32 since long word accesses should be just as fast as word ones on a 68030.

[zero]

I'm surprised that Aladdin AGA used 64 colours. It seems like a kind of random amount, unrelated to DMA slot usage. Maybe they just set it at the point where the blitter couldn't keep up any more, i.e. 7 bitplanes was too much.

[roondar]

Personally I think it's more likely due to the game being a port from the Mega Drive, which supports 64 colours on screen (if you don't want to use tricks), keeping the number identical allows for 'identical' graphics without Copper trickery.

[ross]

Originally Posted by zero

I'm surprised that Aladdin AGA used 64 colours. It seems like a kind of random amount, unrelated to DMA slot usage. Maybe they just set it at the point where the blitter couldn't keep up any more, i.e. 7 bitplanes was too much.

Why DMA unrelated?
With fetchmode x4 the DMA slots are all 64bits wide back-to-back, so you saving 6 chip ram CPU/Blitter acces/line vs 128 colors.

[Galahad/FLT]

Aladdin was 64 colours because it was based on the Megadrive version which was...... 64 colours

[Shatterhand]

Speaking from ignorance here...

When using dual playfield on AGA machines, aren't you restrained to 16 colors on the backfield and 16 on the front field? (4 bitplanes each).

I know you can get more colors with sprites and all, but still....

[Galahad/FLT]

Originally Posted by Shatterhand

Speaking from ignorance here...

When using dual playfield on AGA machines, aren't you restrained to 16 colors on the backfield and 16 on the front field? (4 bitplanes each).

I know you can get more colors with sprites and all, but still....

Yes, but the Aladdin and Putty Squad don't use dual playfield, the background layer is AGA sprites with a copperlist gradient

[Chrille]

Originally Posted by Mrz

Aladdin could run in the A500 depending the engine used
for ex Team 17' Superfrog/Assassin engine is very fast it could run in a plain A500 platform games in 32 colors at 50 fps

Aladdin AGA uses the same putty squad engine, runs in 64 colors but runs at 25fps , this engine is not very good because is not enough smooth

Superfrogs scrolling and sprites run at 50 fps and the scrolling is very fast, but notice that Superfrogs enemies (BOBs) run only at 25 fps. This is similar to Zool, Zool II and many other games.

[sandruzzo]

maybe with a reduced screensize we could see it!