Arcade / Console --> Amiga conversion discussions

[idrougge]

Originally Posted by Miggy4eva

EDIT - OK, now I see online some details. STE had simm slots on the motherboard for 30 pin simms. So what? My point is still that STE with fully populated RAM slots is modified. It is considered modified, therefore you must allow Amiga modified with RAM board, or the tracer cut on the motherboard to allow 2MB of chipram to be allowed. Most Amiga ram board required very little soldering anyway, and then once board was installed you could use SIMM's to change memory as much as you want with zero effort.

The cost of a RAM board for the Amiga must be added to the cost of memory itself, which is why there are so few fast RAM expansions for the A500 around. The STE doesn't have that problem since as soon as SIMMs come down in price, they can be installed using nothing more than a screwdriver.

You can't just cut traces and get 2 MB of chip RAM. Only a minority of Amigas have the required 8375 Agnus.

And if inserting SIMMs into the motherboard is modified, then so is a trapdoor expansion for 1 MB of RAM. So the Amiga should enter the competition with 512 kB of chip RAM.

4MB STE isn't a "stock" STE, so to have equal, fair chance in a retro style battle of ports then A500 must be allowed to compete with RAM upgrade also. That is my point.

Originally Posted by Miggy4eva

ST users were budget people and not much of them could afford 4MB in the 80's anyway. Yes, early 90's when the 30 pin simms started to get cheap maybe every die-hard STE owner who hadn't upgraded to Amiga or PC by then might have 4MB but it's not common configuration in "golden era" so you can't compare 4MB STE to 1MB A500 in these battles. Should be 4MB STE vs 4MB A500 with 2MB Chipram motherboard mod to be equal, oranges vs oranges comparison. And in that situation the Amiga will defeat the ST yet again.

If you're doing that kind of upgrading, just do the full Monty and install a Vampire.

[idrougge]

Originally Posted by AnimaInCorpore

I think this is a very good point. FastRAM seems the way to go. What are the options here for the Amiga 500 (except for turbo cards)?

Most hard drives had fast RAM.

[idrougge]

Originally Posted by zero

I remember reading the startup-sequence rant of Final Fight that the coder claimed to be doing flipping in real-time. I always wondered about that... Maybe he meant just vertical flipping which is easy and cheap, because I can't really see any good way to do horizontal flipping while blitting without it being really slow.

Vertical flipping in a side-scrolling beat'em up seems quite pointless.

However, it is acceptable if a beat'em up character takes more than one vbl to turn around, so you could say that it is real-time.

[chb]

Originally Posted by zero

I remember reading the startup-sequence rant of Final Fight that the coder claimed to be doing flipping in real-time. I always wondered about that... Maybe he meant just vertical flipping which is easy and cheap, because I can't really see any good way to do horizontal flipping while blitting without it being really slow.

No idea how Final Fight does it, but the usual method would be using the cpu and a flip table.. either byte-based (256 bytes) or word-based (64kb). Some also stored the lower half of the bob flipped, so that for every direction half of the bob has to be flipped, to ensure constant runtime.


So first flip using the cpu, then blit+cookie-cut with the blitter. It's not exactly fast, but much more efficient than using the blitter alone, especially if you can afford the 64k for a word table.

[frank_b]

Originally Posted by chb

No idea how Final Fight does it, but the usual method would be using the cpu and a flip table.. either byte-based (256 bytes) or word-based (64kb). Some also stored the lower half of the bob flipped, so that for every direction half of the bob has to be flipped, to ensure constant runtime.


So first flip using the cpu, then blit+cookie-cut with the blitter. It's not exactly fast, but much more efficient than using the blitter alone, especially if you can afford the 64k for a word table.

It would have been useful to have a smudge mode equivalent indirect addressing mode on the amiga blitter. The st one can do horizontal bitmap hflippibg in four passes. It has 32 bytes of lookup table built in. You just need to combine it with the masks.

[frank_b]

Only the 500 plus and the 600 can have two meg chip memory with ecs.
It requires an upgrade board in the trapdoor slot. Well the 3k does but it's not 500 class

[dlfrsilver]

Originally Posted by zero

I remember reading the startup-sequence rant of Final Fight that the coder claimed to be doing flipping in real-time. I always wondered about that... Maybe he meant just vertical flipping which is easy and cheap, because I can't really see any good way to do horizontal flipping while blitting without it being really slow.

Basically, the sprite list also include the flipped sprites frames.

so the 561 bytes i talked about, contains the left and right side, depending on the animation of the skeleton that has to take place.

[chb]

Originally Posted by frank_b

It would have been useful to have a smudge mode equivalent indirect addressing mode on the amiga blitter. The st one can do horizontal bitmap hflippibg in four passes. It has 32 bites of lookup table built in. You just need to combine it with the masks.

If I'm not mistaken, the Amiga blitter should be able to do a hflip also in 4 passes - you'd using two source with different shift settings (one left-shift*, one right-shift) and a static mask in source C. Then first flip the bits pairwise (shift +/-1, mask 010101..), then in pairs of 2 bits (+/-2, mask 00110011..), 4 bits, finally 8 bits. I do not know if it was used, and I've never implemented it myself.

Smudge mode seems to be cool, though.

*by changing the start adress by one word + right-shift

EDIT: And you'd need to change the word order at one of the passes, but that should be free - just use a negative destination modulo (-2) which will give a hflip + vflip (reverse complete word order for the bob), and correct the vflip by using a negative modulo when you blit to the bitmap. Oh, and for bobs that blitting to the screen with for cookie-cutting and shifting would be the fith step, but I guess that's not included in your calculation for the STe, too?

[frank_b]

Originally Posted by chb

If I'm not mistaken, the Amiga blitter should be able to do a hflip also in 4 passes - you'd using two source with different shift settings (one left-shift*, one right-shift) and a static mask in source C. Then first flip the bits pairwise (shift +/-1, mask 010101..), then in pairs of 2 bits (+/-2, mask 00110011..), 4 bits, finally 8 bits. I do not know if it was used, and I've never implemented it myself.

Smudge mode seems to be cool, though.

*by changing the start adress by one word + right-shift

EDIT: And you'd need to change the word order at one of the passes, but that should be free - just use a negative destination modulo (-2) which will give a hflip + vflip (reverse complete word order for the bob), and correct the vflip by using a negative modulo when you blit to the bitmap. Oh, and for bobs that blitting to the screen with for cookie-cutting and shifting would be the fith step, but I guess that's not included in your calculation for the STe, too?

Neat.
The advantage of the look up table is that you're not limited to one transformation. You can hflip and scale by 2x, 4x, 8x, 16x at the same time too

Masking would indeed be a separate step. You need to use the shift to select which 4 bits of the source to look up and swap.
The masks control which bits on the destination are mutable. You can use the smudge mode all sorts of cool ways. It can be used for colour expansion of a mono bitmap to a high colour screen for example. Useful for text blitting on palette less screens.

[chb]

Originally Posted by frank_b

Neat.
The advantage of the look up table is that you're not limited to one transformation. You can hflip and scale by 2x, 4x, 8x, 16x at the same time too

Seems interesting! But how do you handle the different source- and destination sizes? Do you need additional passes or do your passes get bigger in size (e.g. 2x,4x...)? Horizontal flip + 2x scaling on the Amiga would be 8 passes, but everyone of them with the size of the original data. So no penalty for doing a hflip when scaling 2x (at least that's what I came up with, but it's literally back-of-the-envelope )

Originally Posted by frank_b

Masking would indeed be a separate step. You need to use the shift to select which 4 bits of the source to look up and swap.
The masks control which bits on the destination are mutable. You can use the smudge mode all sorts of cool ways. It can be used for colour expansion of a mono bitmap to a high colour screen for example. Useful for text blitting on palette less screens.

Nice stuff!

[zero]

I guess he was probably talking about vertical only flipping (some of the characters spin round and Haggar's piledriver move turns them upside down). Sometimes there are copies of the same character facing both ways on screen, so unless he flips as he blits them onto the screen there wouldn't be much to gain...

[frank_b]

Originally Posted by zero

I guess he was probably talking about vertical only flipping (some of the characters spin round and Haggar's piledriver move turns them upside down). Sometimes there are copies of the same character facing both ways on screen, so unless he flips as he blits them onto the screen there wouldn't be much to gain...

I was talking about hflipping a raster with the blitter, I uploaded an implementation I wrote in c via the atari blitter from about 2007 or so. The thread can be found on atari-forum.com if you're interested

When scaling the dest is going to be larger than the source.
Here's the implementation and compiled atari binary. https://www.dropbox.com/s/gpdc18dm0v...CALER.zip?dl=0

The CPU routine was used initially to test the lookups and algorithm. It's interesting to compare the speed between the two.
Hardware wins It's an elegant little chip. It's more useful in an art package than a game. Brush flipping and magnification is the main use case.

[zero]

I did a few experiments today, admittedly on my A4000/060, but it certainly seems like even a very small amount of fast RAM would really provide a massive boost for an unexpanded Amiga. With caches off the difference between running code from chip RAM and fast RAM is dramatic, especially when you have lots of DMA enabled.

My little test code could easily plot 2x as many dots to screen with code in fast RAM, without any optimization.

[kovacm]

offtopic: I can not remember exactly but Amiga with e.g. 030 CPU for some reason can not use CPU cache? or I am completely wrong??

[idrougge]

The CPU cache is used by default.

[frank_b]

Originally Posted by idrougge

The CPU cache is used by default.

Chip memory isn't cached with the datacache. The instruction cache works from chip though.

[kovacm]

Originally Posted by frank_b

Chip memory isn't cached with the datacache. The instruction cache works from chip though.

I see. Amiga design prevent use of data cache with chip ram.

[frank_b]

Originally Posted by kovacm

I see. Amiga design prevent use of data cache with chip ram.

User space programs can grab the blitter and use it directly. There's no single interface to it which can flush the cache. Safer to inhibit it. The individual computers accelerators allow you to switch it on though via a tuning parameter.

[kovacm]

Data in CPU data-cache and actual data in chip-memory could be different since Amiga custom chips can modify chip ram data without CPU.
This is the reason why it is safe (or needed) to disable CPU data cache on Amiga? And there is no way for chip ram to tell CPU to flush data cache? Did I understand correctly?

[frank_b]

Originally Posted by kovacm

Data in CPU data-cache and actual data in chip-memory could be different since Amiga custom chips can modify chip ram data without CPU.
This is the reason why it is safe (or needed) to disable CPU data cache on Amiga? And there is no way for chip ram to tell CPU to flush data cache? Did I understand correctly?

You can easily flush the caches via a supervisor mode instruction. There's no single interface to the blitter though. Where do you flush the data cache if every app can just grab the blitter and use it?