Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

[mpattonm]

Incredible!

[Frank B]

i think that on the amiga you could use maybe 32 colors instead of 16. Any other "magic effect" would raise the bar i think on the memory requirements.

it would be cool if anima could explain what he applied in order to make the STE display the tiles without any dedicated chipset

Erm you only have 512k of blittable memory on the 500 and 2 meg max on the 600 or 500+.
The STe can blit from anywhere (alt ram or normal ram). It has either 4 meg or 12 meg of memory where sprites can be stored.
You might be running out of RAM fast if it needs a 4 meg STe. Buffering sprites from fast RAM would cripple performance on the Amiga.

[Cyprian]

Erm you only have 512k of blittable memory on the 500 and 2 meg max on the 600 or 500+.

yep, it means that sprites located in the memory are outside blitter range will be managed the CPU - huge slowdown in case of amiga and 5 bitplane mode

[dlfrsilver]

you know like me that the STe is dealing with everything out of the hardware scrolling in software.

Mostly in Software = no problem with fast ram = full 68000 speed

Ah and of course, if A500, it will require a board with the amount of ram required.

[Cyprian]

a500 fast ram doesn't help: 1) CPU there still slower than in STfm 2) CPU software sprites need to be moved to slow ram blocked by blitter and 5 bitplanes

[EvilFranky]

you know like me that the STe is dealing with everything out of the hardware scrolling in software.

What do you mean?

[dlfrsilver]

The STe is actually dealing with the hardware scrolling, and as far as i know, the sprites game logic for the CPS-1 is fully software.

The only commands send by the 68000 to the chipset is the metadata for the sprites, palettes, and tiles for each 3 playfields.

The around 1mhz more the STe is nothing to kill a dead horse.

I'll let Anima talk about the amount a data needed and to be blitted in ghouls'n'ghosts.

Just to illustrate, the CPS1 program is splitted in 512kb + 512kb. First 512kb contains the full code + data and the second 512kb of program contains the tiles metadatas for the levels and sprites.

[dlfrsilver]

here is an example :

The skeleton tiles metadata starts in offset $7046C.

It has some bytes, followed by this :

sprite frame 01 :

0201,0202,
0210,0211,0212,
0220,0221,0222,

You can check this by pressing 'F4' in mame in order to access the tileviewer, get the 16x16 tiles, and you'll find the skeleton.

[Frank B]

here is an example :

The skeleton tiles metadata starts in offset $7046C.

It has some bytes, followed by this :

sprite frame 01 :

0201,0202,
0210,0211,0212,
0220,0221,0222,

You can check this by pressing 'F4' in mame in order to access the tileviewer, get the 16x16 tiles, and you'll find the skeleton.

I think you'll find the game is pretty blitter intensive. You'd have to either move from fast ram to chip then blit or try and fit the game into 512k of CHIP ram. The graphics would be bigger because of the extra bitplane. You don't even have enough fast ram to preshift your graphics. No intelligent end masking on your blitter either. That was due to come with the Hombre chipset. The ST blitter had it from day one.

[EvilFranky]

Yes but STe is also dealing with sprite display in hardware using the blitter.

That is the point Frank B was making, the Amiga could not hold all the available sprite data in RAM, in an area that the Amiga blitter can access.

It would need copied from fast -> chip before the blitter could do anything with it.

[Frank B]

Yes but STe is also dealing with sprite display in hardware using the blitter.

That is the point Frank B was making, the Amiga could not hold all the available sprite data in RAM, in an area that the Amiga blitter can access.

It would need copied from fast -> chip before the blitter could do anything with it.

Indeed. You could cache some of the graphics but you would still cripple performance the minute you need to buffer graphics.
The CPU wouldn't be fast enough to draw the sprites in a 68k Amiga. You'd have to preshift and there isn't enough fast ram for that!
Realistically you'd need to cache and buffer the rest from fastram to an intermediate chip ram buffer. Good luck with that if it needs 4 meg of RAM.
The tiles could be stored in fast ram and drawn with the CPU. You can forget about doing that with the sprite data. It would need buffered.

[EvilFranky]

Even the AGA machines have a 2MB limit for the blitter right? You'd probably be targeting 8bpp on those machines so the constraints may be even worse.

[Frank B]

Even the AGA machines have a 2MB limit for the blitter right? You'd probably be targeting 8bpp on those machines so the constraints may be even worse.

Better to do dual play field on that machine. If you have an accelerator you can store all graphics in fast RAM.
It might still not be possible without fast RAM. The ST blitter wins because of the 24 bit addressing range.

[CiH]

Can I add my jaw to the pile of those already dropped?

[dlfrsilver]

Well there is a possibility : using an extension board connected to the cartridge port. this one can address 8mb of ram directly connected to the 68000.

The maximum an A500 can deal with in memory is 2mb of chip, and 8mb of fast ram. that's more than enough to do the job.

[Cyprian]

The maximum an A500 can deal with in memory is 2mb of chip

to be precise, a500 has OCS chip therefore max. 512KB chip ram. only some a500, produced after 1990 has ECS and 2MB chip ram
A500: "Release date 1987 Discontinued 1991" and Wiki: "ECS was introduced in 1990 with the launch of the Amiga 3000."

[dlfrsilver]

The expansion port, left of the 68000 support 2,4,and 8 mb of ram anyway

[Frank B]

The expansion port, left of the 68000 support 2,4,and 8 mb of ram anyway

None of which is addressable by the blitter, copper or any other DMA channel.

[dlfrsilver]

The expansion port, left of the 68000 support 2,4,and 8 mb of ram anyway

None of which is addressable by the blitter, copper or any other DMA channel.

Yes, it's connected directly to the CPU.

But look, since we used computer, Daimakaimura should be broken per parts. This would reduce tremendously the ram needed.

[calimero]

you know like me that the STe is dealing with everything out of the hardware scrolling in software.

???
what about blitter in STe?

The expansion port, left of the 68000 support 2,4,and 8 mb of ram anyway

None of which is addressable by the blitter, copper or any other DMA channel.

Yes, it's connected directly to the CPU.

No, that memory is not addressable by the blitter, copper or any other DMA channel.

[AtariZoll]

Jesus ... and this thread too can not go without silly Amiga vs. STE discussion
Even worse is that some here don't care to write clearly.

Well there is a possibility : using an extension board connected to the cartridge port. this one can address 8mb of ram directly connected to the 68000.
The maximum an A500 can deal with in memory is 2mb of chip, and 8mb of fast ram. that's more than enough to do the job.

Cartridge port on which computer ? Atari or Amiga ? Is there at all cartridge port on Amiga ? If yes, why using it, when there is expansion port ?

[dlfrsilver]

Jesus ... and this thread too can not go without silly Amiga vs. STE discussion

Nope, we're just talking about the possibilities on the amiga. Nothing more.

Cartridge port on which computer ? Atari or Amiga ? Is there at all cartridge port on Amiga ? If yes, why using it, when there is expansion port ?

I'm talking about the Amiga (anima has a work in progress version running on STE). Yes there is a cartridge port on the Amiga. This one is directly connected to the CPU. It's also an expansion port, because you can connect on it a cart with 2,4, or 8 mb of RAM.

[AtariZoll]

Since Anima wisely stays out from discussions here - he has better things to do, I will write here some simple technical thoughts related with sprite and tile draw.
RAM speed in some ST(E) is 8 MB/sec - what means that you can read from or write to so much - in theory. Half of time is dedicated to video generation, so only 4 MB/sec is left for CPU, blitter, DMAs .
The simplest case is clearing of whole screen (or filling it with unique pattern) - then you just write some constant (usually 0) to screen buffer. Even with CPU can do it very fast, using movem . With blitter little faster. Very close to theoretical 4 MB/sec. It means that can clear 4000/32=125 times whole video buffer in 1 sec, or more useful info: it takes 40% of 1 frame time when it works at 50 Hz (PAL) . Basically, RAM speed is the real limit here.

Drawing background: it can be simple copy of somewhere stored bitmap, or more complex tile based draw. What is important here is that it needs 2 RAM accesses: first reading source, then writing to screen buffer. So, theoretical max speed is 2 MB/sec for copy. Ergo, in best case it will eat 80% of 1 frame time. But with tile draw it is more - when drawing full screen.
In reality, you don't draw tiles directly on screen in scrolling games - then some shifts are necessary. And that's when blitter can speed up it a lot.

Drawing sprites: it is basically 2 step process, actually may be 3 step if undrawing is necessary too. First need to /AND mask of sprite with background, and then to OR bitmap . Undraw is restoring of background. If it is all done in SW, fast solution may be pretty long code, but still will be far from what is possible with blitter. Theoretical max speed would be 2000/3=~666KB/sec, or about 250% of 1 frame time . Of course, we never have so much sprites that fill whole screen, but whole process is more complex, so achievable draw speed is much less. In simplest case maybe some 300-400KB/sec, but it depends a lot of sprite size, how it is presented in source RAM.

All in all, RAM speed is the key factor here. RAM size is relevant too - in more RAM can hold graphic data in such format what allows faster processing by screen draw. Shift operations are very slow with 68000 CPU, and that's where blitter gives nice speed gain. It does RAM operations simultaneously with shifts, logical operations between source and destination, + 2 dimension (X,Y) RAM address increments, With CPU it needs at least 4-5 instructions.
With larger sprites, scrolling of larger screen area 50 fps is simply not possible on 8 MHz STE.

Let's hope that this will be SW what will show true potential of an STE - well, latest demo did it already pretty well

[dlfrsilver]

Ghouls'n'Ghosts is maybe inauguring a new set of game ports. Because what Anima did with Ghouls'n'Ghosts can be basically replicated on all the other CPS1 game, since the arcade code follow more or less the same rules, and his made more or less in the same vein.

I got my hands in most CPS1 games, the main difficulty is that most metadata should be saved as external data files, but those are so numerous.....

Just to illustrate, the full disassembly of a game like Ghouls 'n' ghosts by hands represents 1 month of work by hand.

I think the most awesome thing would be to have the same kind of accurate port helped with the original arcade program with games like SF2 for example. This one should be also a great demonstration of what can be done by a talented coder on the STE.

The only thing is that SF2 would maybe require an extension board with 8 or 16mb of ram.

[Frank B]

I think the ST blitter acts like a 68000 on the bus. It has all the same pin outs. It might be possible to just fit it on a CPU breakout card on the Amiga. It was possible to retrofit to earliest ST models. That would give you full blitter access to fast ram for storing sprites. No idea if that would be feasible but it would be a really good hack!