Arcade / Console --> Amiga conversion discussions

[zero]

Originally Posted by dlfrsilver

I remember that Richard Aplin explained on an old topic on EAB that Strider could have been arcade perfect on A500 with 8mb of ram, the whole lot with the triple playfield. With lots of memory, you can do a lot of things.

That's pretty far fetched. For a start, the arcade system has more colours than OCS can display.

The unreleased PC Engine port is an interesting example. 2MB RAM and a more powerful tile/sprite engine than the Amiga. The CPU is 8 bit, but most of the instructions are one or two cycles and it runs at around 7MHz IIRC so for that kind of game it's probably faster than a similar speed 68000.

The 68000 is really a workstation CPU. It's powerful and good for running C code, but because every instruction takes multiple clock cycles and the max clock speed isn't that high, for games a CPU that has a much higher IPC (instructions per clock) is better.

For comparison, at 8MHz a 68000 is about 1.4 MIPS, while a 65C02 is about 3.44 MIPS. Plus the 65C02 instruction words are shorter so less memory bandwidth is needed just for instruction fetching. 68k instructions can do more, but for games that's not necessarily that useful.

[Miggy4eva]

Originally Posted by frank_b

I think the STe wins here if the sprite data is massive. An ST or STe can use all of the 24 bit range for its blitter. Add a monster card and you can have 12 meg of sprite data if you want. It isn't doing two pass masking either. It's a line by line fringed copy due to the intelligent end masks. Ie worst case 12 cpu cycles per word with a best case of 8 excluding overhead. It is really fast at blitting with this technique.

It would be good to see an a500 version though

Umm, what about Amiga fastram easily added on the side expansion slot? And also hardware sprites can move some of those far better than the ST can. Not bashing ST just talking about arcade conversion to Amiga, and how the Amiga has far superior hardware and can beat the ST easily.

Originally Posted by dlfrsilver

as roondar explained, the sidecar expansion port is the port on the left of the A500. It supports up to 8mb of ram (fast type).

I remember that Richard Aplin explained on an old topic on EAB that Strider could have been arcade perfect on A500 with 8mb of ram, the whole lot with the triple playfield. With lots of memory, you can do a lot of things.

But anyway, the problem remains the same : lower the RAM specs and only loads the required sprites and tiles in memory.

No comment, just wanted to say great post.
I would have loved to have seen arcade perfect Strider conversion with full 50fps parallex scrolling and sprites.
I don't see what is so bad about making games for OCS/ECS to take advantage of extra fastRAM? The Atari guys are doing it with 4MB RAM board after all. It's not stock. And 12MB... for that money you could afford an A1200 back in 1992, so there's no point using 12MB UNLESS Amiga ports can also use 8MB fastram.

[idrougge]

Originally Posted by Miggy4eva

The Atari guys are doing it with 4MB RAM board after all. It's not stock.

No RAM board. You seem very knowledgeable about the Atari, so surely you know what an STe looks like internally?

[robinsonb5]

Originally Posted by Miggy4eva

Umm, what about Amiga fastram easily added on the side expansion slot?

The custom chips can't access it - the point you seem to be missing is that the STe's blitter *can* access the expanded RAM.

Not bashing ST just talking about arcade conversion to Amiga, and how the Amiga has far superior hardware and can beat the ST easily.

You've just been given one scenario where it doesn't.

I don't see what is so bad about making games for OCS/ECS to take advantage of extra fastRAM?

There's nothing bad about it - it's just that almost no-one ever did because the vast majority of A500 owners had either an extra 512k of slow RAM or a Gary-hacked 1.5meg expansion - still slow RAM - rather than true Fast RAM.

There are exceptions, though - Zeewolf 2, for example, is much improved on a machine with true Fast RAM.

[Miggy4eva]

Originally Posted by robinsonb5

There's nothing bad about it - it's just that almost no-one ever did because the vast majority of A500 owners had either an extra 512k of slow RAM or a Gary-hacked 1.5meg expansion - still slow RAM - rather than true Fast RAM.

There are exceptions, though - Zeewolf 2, for example, is much improved on a machine with true Fast RAM.

And then the same rule applies to Atari people. Nobody had 12MB back then, and 4MB boards were expensive, different third party supplies have different hacks to make it work. Just a mess. Games were not written back then for 2MB or 4MB or 12MB on Atari for a reason. So if the suddenly do it today why not the same for Amiga? It's not "cheating", add crazy mods to your ST to give 4 - 12MB of RAM and we can do the same on Amiga

EDIT and about Amiga chips not accessing all of RAM, as has been discussed previously in the thread there are solutions to that, copying data between chipram and fast ram, keeping the executable outside of chipram, only holding data in chipram that the chipset needs to work on. You have 2MB to play with, it's plenty.

[robinsonb5]

Originally Posted by Miggy4eva

And then the same rule applies to Atari people. Nobody had 12MB back then, and 4MB boards were expensive, different third party supplies have different hacks to make it work. Just a mess. Games were not written back then for 2MB or 4MB or 12MB on Atari for a reason.

Agreed - indeed, most didn't even use the Blitter, since relying on it would have restricted the market for the game.

So if the suddenly do it today why not the same for Amiga? It's not "cheating", add crazy mods to your ST to give 4 - 12MB of RAM and we can do the same on Amiga

I'm not sure just filling the SIMM sockets counts as "crazy mods" - but again, agreed. Personally I'd like to see just what an A500 with true Fast RAM can achieve (and I have a couple of projects in mind myself that I'd try if my time wasn't already completely committed for the foreseeable future). But even now they're not that common - the closest thing I have is a variety of Minimig ports. (Plus an A500+ with Vampire, but that's a *totally* different beast.)

[Miggy4eva]

Originally Posted by robinsonb5

I'm not sure just filling the SIMM sockets counts as "crazy mods" - but again, agreed. Personally I'd like to see just what an A500 with true Fast RAM can achieve (and I have a couple of projects in mind myself that I'd try if my time wasn't already completely committed for the foreseeable future). But even now they're not that common - the closest thing I have is a variety of Minimig ports. (Plus an A500+ with Vampire, but that's a *totally* different beast.)

Yes, just stick to 2MB accessed by chipset and I'd love to see A500 can do. I'm sure it would surprise many.
Also, some Amiga ram board accepted SIMM's also

[frank_b]

Originally Posted by Miggy4eva

Yes, just stick to 2MB accessed by chipset and I'd love to see A500 can do. I'm sure it would surprise many.
Also, some Amiga ram board accepted SIMM's also

It would certainly surprise me. That particular game uses 14 meg of memory. Most of it is for sprites. They can be used at any time.
There's some debate whether it can be split level by level down to 4 meg of RAM.

It might require buffering as I mentioned in my post.
Your possible choices are

a) caching to chip + frequent loading screens whilst data is buffered from fast
b) drawing all masked graphics with the CPU
c) Buffering data dynamically between fast and chip

a might not be feasible depending on how the assets are used.
b is going to be hideously slow versus using a blitter (8x slower than the STe?)
c is going to be 2.5 to 3x slower clock for clock than the ST version

I'll be explicit here. Fast RAM *cannot* be accessed via the custom chips on the Amiga. The blitter can't access it. The only chip in the Amiga capable of accessing the full addressing range is the 68k. A 68000 can't draw sprites efficiently. It requires preshifting. Preshifting requires an extra column for each sprite and 16 copies of the sprite/mask data.

On the ST both the blitter and the CPU can access everything in the 24 bit range. Ie all 16 meg of it including RAM, ROM, Alt ram above 4 meg and memory mapped IO address space.

[sandruzzo]

Since Amiga have blitter is better to use it for drawing bob, and left cpu doing cpu staff. I remember when I add A590 to my Amiga, the whole seems to run 2x faster!

[frank_b]

Originally Posted by sandruzzo

Since Amiga have blitter is better to use it for drawing bob, and left cpu doing cpu staff. I remember when I add A590 to my Amiga, the whole seems to run 2x faster!

Crazy idea alert! Why not see if it's possible to fit the ST one on a CPU card?
It was retrofitted to original ST machines.

It's supposed to act like a 68000 on the bus. A combined fast RAM blitter card would be cool. Crazy but cool The other option is someone clones the Amiga one and makes it a proper bus master. Make it available with a fast RAM card. That would open up the 500 to all the games possible with this technology. Would be great for Workbench too. Fonts and background patterns could be stored in fast RAM.

The Amiga port of EmuTOS could use either one for the VDI interface. I'd pay money for either option!

[sandruzzo]

In my opinio OCS chip set was an unfinished project.

[robinsonb5]

Originally Posted by sandruzzo

In my opinio OCS chip set was an unfinished project.

I'd have to disagree there - given the limitations of technology, memory speed and cost at the time, and compared with everything else of the same era, the OCS chipset is remarkable. It should certainly have been developed further, but it was largely a victim of its own success - the whole system was designed and integrated very tightly, so making incremental improvements is very difficult.

I do seem to remember reading somewhere that the chipset was originally intended to have a YUV mode, though - and that's what HAM mode was originally intended for. YUV was scrapped but HAM remained. I can't find any reference to this now, though - was I imagining it?

[Miggy4eva]

Originally Posted by frank_b

a might not be feasible depending on how the assets are used.
b is going to be hideously slow versus using a blitter (8x slower than the STe?)
c is going to be 2.5 to 3x slower clock for clock than the ST version

Are you really sure that's true?? It really seems amazing to me if it's true..... and doesn't explain why Amiga games are so much better than ST

Originally Posted by frank_b

I'll be explicit here. Fast RAM *cannot* be accessed via the custom chips on the Amiga. The blitter can't access it. The only chip in the Amiga capable of accessing the full addressing range is the 68k.

I know that, that's why I say make the game in just 2MB of chipram

Originally Posted by frank_b

Crazy idea alert! Why not see if it's possible to fit the ST one on a CPU card?
It was retrofitted to original ST machines.

It's supposed to act like a 68000 on the bus. A combined fast RAM blitter card would be cool. Crazy but cool The other option is someone clones the Amiga one and makes it a proper bus master. Make it available with a fast RAM card. That would open up the 500 to all the games possible with this technology. Would be great for Workbench too. Fonts and background patterns could be stored in fast RAM.

The Amiga port of EmuTOS could use either one for the VDI interface. I'd pay money for either option!

Ahahaha, that would be amazing. To just run these ST ports of Ghouls n Ghosts on an Amiga LOL

[sandruzzo]

Originally Posted by robinsonb5

I'd have to disagree there - given the limitations of technology, memory speed and cost at the time, and compared with everything else of the same era, the OCS chipset is remarkable. It should certainly have been developed further, but it was largely a victim of its own success - the whole system was designed and integrated very tightly, so making incremental improvements is very difficult.

I do seem to remember reading somewhere that the chipset was originally intended to have a YUV mode, though - and that's what HAM mode was originally intended for. YUV was scrapped but HAM remained. I can't find any reference to this now, though - was I imagining it?

Think about it: 32kb of fast ram would be not so expensive, so to have fast chip mem taht would allow to have ham6 in hires..Amiga was an home computer not only game console

[robinsonb5]

Originally Posted by sandruzzo

Think about it: 32kb of fast ram would be not so expensive, so to have fast chip mem taht would allow to have ham6 in hires..Amiga was an home computer not only game console

32K of fast RAM would have been great - or even better, making the trapdoor slot into real fast RAM - but I don't think even that would have opened up enough DMA slots to do hires HAM6.

[roondar]

Originally Posted by frank_b

It would certainly surprise me. That particular game uses 14 meg of memory. Most of it is for sprites. They can be used at any time.
There's some debate whether it can be split level by level down to 4 meg of RAM.

While I'm sure it's possible that all tile & sprite data can be accessed at any time, this doesn't actually seem to happen in the game itself - certainly not in the space of say a couple of hundred frames.

It might require buffering as I mentioned in my post.
Your possible choices are

a) caching to chip + frequent loading screens whilst data is buffered from fast
b) drawing all masked graphics with the CPU
c) Buffering data dynamically between fast and chip

a might not be feasible depending on how the assets are used.
b is going to be hideously slow versus using a blitter (8x slower than the STe?)
c is going to be 2.5 to 3x slower clock for clock than the ST version

I'd say option b) is not acceptable and option a) sounds like a non-optimal approach. However, I personally feel your take on option c) is rather negative. While it is true that transfering data from fast to chip is not going to be very fast, I am also pretty certain you don't actually need to transfer all that much per frame.

And after transfer, you'd obviously not use the CPU for drawing.

It would be relatively easy to transfer from fast to chip at a much slower rate than the peak, just enough to satisfy what is needed in the for the current frame and the near future. The total memory requirement would not change, obviously, but you don't have to transfer all data across all the time.

As a quick back-of-the-envelope kind of thing:

The maximum number of tiles you'd need to transfer the definition of at any time would be roughly 30 (assuming 8x8 tiles). At 16 colours, that is all of 960 bytes and that is assuming there are no tiles at all available in chipmemory at the time that can satisfy the new tiles that need to be drawn (which is exceedingly unlikely).

The maximum number of sprite frames is harder to estimate, but a single sprite frame (assuming 32x32 and 16 colours) is roughly 512 bytes. Assuming 8 new sprite frames are needed every frame (which I again, find exceedingly unlikely), you are looking at transfering 4096 bytes of data.

So in a scenario that most likely will never actually happen, you still only need roughly 5K of bandwidth.

Transfering that would cost (effectively) 1.280 CPU cycles / 640 DMA cycles. That is, it would take more from the CPU's point of view, but only 1.280 CPU cycles actually touch chipmemory, the rest is all in fastmemory - meaning that running such a transfer can largely be done while other DMA is running in chipmemory.

And again, that does make assumptions that may not be true. In reality, if tiles are 8 pixels in size, you basically have multiple frames to transfer them. For sprites, you only need to transfer what is needed newly - and that's not going to be hundreds of frames of data. Most of the animations don't seem to actually show a new image every frame, lowering the required bandwidth further.

Now, I'll admit that there may be rough patches in which much more must suddenly be done in a frame and that implementation of this is awfully Amiga specific and not as easy as writing about it is, but the overall picture doesn't feel like it's impossibly hard to satisfy.

Hard to implement, probably. But surely not impossible.

I'll be explicit here. Fast RAM *cannot* be accessed via the custom chips on the Amiga. The blitter can't access it. The only chip in the Amiga capable of accessing the full addressing range is the 68k. A 68000 can't draw sprites efficiently. It requires preshifting. Preshifting requires an extra column for each sprite and 16 copies of the sprite/mask data.

On the ST both the blitter and the CPU can access everything in the 24 bit range. Ie all 16 meg of it including RAM, ROM, Alt ram above 4 meg and memory mapped IO address space.

Of course, this is all true - but does miss pointing out the advantages of having fastram. Unlike the base ST/STe, an Amiga with fastram can run the Blitter and CPU at full speed concurrently, one in chipram the other in fast. This effectively means that Blitter throughput is increased 'for free'.

The amount by which it is increased is open to debate, but I'd guess a low-end game engine might use 10% of the available raster time, while a more high-end one could clock in at somewhere near say 25-30%. That is a pretty big chunk of CPU time you're getting back for Blitter use - or for other purposes, such as transfering memory from fastram to chipram, without impacting apparent Blitter speed compared to a normal non-fastram Amiga.

Especially when you consider that the impact on chipram bandwidth is limited to only those memory accesses that do the final write, during the rest of the time other DMA can keep going at full speed.

However, to be clear: this kind of full CPU/Blitter concurrency would only work if you can fit enough data in fastram and actually have fastram available. Plus, it would need to be coded specifically for the Amiga.

[frank_b]

Originally Posted by Miggy4eva

Are you really sure that's true?? It really seems amazing to me if it's true..... and doesn't explain why Amiga games are so much better than ST



I know that, that's why I say make the game in just 2MB of chipram


Ahahaha, that would be amazing. To just run these ST ports of Ghouls n Ghosts on an Amiga LOL

In the case where you need to buffer due to only having 1/2, 1 or 2 meg of memory, yes I'm sure it's true. How are you going to fit 4-10 meg of sprite data in 2 meg of memory or less?

I gave you the cycle and DMA tick counts for buffering in my post. I'm very familiar with the ST and Amiga hardware. I'm not 100% sure if you grasp the difference between chip and fast RAM. It might be an idea for you to read the Amiga HRM. It's fairly accessible.

If you need more than that amount of memory the STe likely wins. Anima's technique for avoid masking is more or less as fast as the Amiga 3 source $CA method. Introducing fast to chip RAM buffering to the mix and the results will be .... slowwwwww

[idrougge]

Originally Posted by Miggy4eva

Also, some Amiga ram board accepted SIMM's also

The difference being that the STE didn't use a RAM board at all.

[frank_b]

Originally Posted by robinsonb5

32K of fast RAM would have been great - or even better, making the trapdoor slot into real fast RAM - but I don't think even that would have opened up enough DMA slots to do hires HAM6.

Bogo ram was an a500 invention The 1k uses real fast. I have 8 meg in mine

[dlfrsilver]

Originally Posted by frank_b

It would certainly surprise me. That particular game uses 14 meg of memory. Most of it is for sprites. They can be used at any time.

I don't agree here. I have pin pointed the whole list of sprites per levels, and no most sprites are levels specific. Only 2 or 3 can appear in more than one levels.

the 14 mb of ram is due to the way the program is organized.

There's some debate whether it can be split level by level down to 4 meg of RAM.

Level per level ? it should even go even lower than 4mb.

It might require buffering as I mentioned in my post.
Your possible choices are

a) caching to chip + frequent loading screens whilst data is buffered from fast
b) drawing all masked graphics with the CPU
c) Buffering data dynamically between fast and chip

a might not be feasible depending on how the assets are used.

Solution A is the most clever to me. This because the chip ram space is use as a memory space to blit the sprites and tiles. 2mb of chip would be great to use.

a GNG sprite (not the bosses!) is mostly 80kb in size (facing left and right). if you have 4 or 5 different on screen, count 800kb of sprites in ram. And then you have the tilemap of the level. let's say 300-400kb, that's around 1,2mb of assets to blit. the main code is around 350kb (wet finger), and with the AI splitted for each sprite and for each level, in fast ram, It's ok

But all this is speculation until the whole code can be splitted in parts.

b is going to be hideously slow versus using a blitter (8x slower than the STe?)

It's hideously slow if the CPU is also doing other chores than taking of the sprites/tiles.

c is going to be 2.5 to 3x slower clock for clock than the ST version

The CPU speed clock is mostly is a "myth" (remember what Mcoder said on Atari Forum, that it was totally irrelevant).

Basically, the Amiga strength relies in the fact that when the CPU loads/send the assets to the chipset, it has more power under the foot to process other things.

The STe blitter is less faster than the Amiga one.

I'll be explicit here. Fast RAM *cannot* be accessed via the custom chips on the Amiga. The blitter can't access it.

Of course. But as explained, the best method is to have the program part relocated in fast ram for full speed, and copying every needed asset inside the chip ram fully free, so that the whole chipset can do his wonder.

with this way, the CPU and blitter can work in parallel without blocking each other.

The only chip in the Amiga capable of accessing the full addressing range is the 68k. A 68000 can't draw sprites efficiently. It requires preshifting. Preshifting requires an extra column for each sprite and 16 copies of the sprite/mask data.

This is the ST method, and this is not the method to use on the Amiga. Never ever

On the ST both the blitter and the CPU can access everything in the 24 bit range. Ie all 16 meg of it including RAM, ROM, Alt ram above 4 meg and memory mapped IO address space.

The Amiga solution is the program in fast ram or even the whole program is a board was built to have 8 mb of fast, and 2mb of chip, as chipset buffer for blitting, Copper, sprites, sound whatever you want.