Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

Tried this game some minutes ago and it looks good. The playability is slow, here on all my four Amiga-500 machines. In the description here is written, when the Amiga has Fastmem, the gamespeed will be good. Which kind of memory is meant here exactly, because i have a A501 trapdoor memory-expansion in every of my four A500 machines, and back then in the 90's, we called this memory "Fastmem". Now it's called Slowmem und Fastmem is another type of memory. The A501 didn't help me, in the game here, when it comes to speed. Therefore i guess, that, when you wrote about "Fastmem" in the description, you not meant the memory of the A501 expansion, right?

I hope something can be done, that the game also runs in fullspeed on every normal 1MB equipped A500, because it would be sad, if you would need a AGA machine, to run it in fullspeed. By the way. Thanks for the good work, by porting all these classic Arcade games, that so many people love, to the Amiga now. Your "Galaxian 500", "Donkey Kong", "Bagit Man", "Moon Patrol" and so on, are all great ports. Good work, this is really cool!

thanks for the feedback. Yes, performance on A500 is disappointing. But I've updated the game, and maybe it will be better... Of course it flies with real fastmem, but I suppose you need a 68020 for that?

(4 edits)

Hy, thanks for answering. I tried the newer version, but sadly it runs in the same slowmotion like the older version, on all of my A500 machines. I hope, that there can be done something, to speed it up, because normally, a Amiga500 with 1MB memory should actually be able, to run such a game in full speed, if you look at games like for example "Uridium 2" in comparison, with the very huge spaceships there, that the playership flies over and everything still runs in full speed and without any stuttering on 1MB A500 machines, that are equipped with a A501 memory-expansion.

By the way, i noticed one thing more, in the newer version of Galaga500, when i copied the image to a real disk and tried it on my Amiga. The floppy-LED stays always on, even when the game is completely loaded and the diskdrive don't stop working. This is not in the older Galaga500 version, therefore i guess, that you maybe have forgotten, to reset the _MTR-Signal in the CIA, or something like that, in this newer version of the game? Could that be? This should be changed, because i think, it's not good for real floppys, when the motor didn't stop and runs all the time, while playing the game.

Regarding fast RAM, the A500 trapdoor memory expansion is **not** fast RAM, it's slow RAM. That is, RAM which is as slow as chip RAM: when the CPU wants to access it, it must wait for the chips to stop accessing chip RAM first (even though, that RAM cannot be accessed by the chips).

To get fast RAM on the A500, you need to use an expansion board which plugs on the left expansion port of the A500.
An Indivision ACA board would work.

Regarding performance, yes, the A500 can run a port of Galaga at full frame rate but you must take into account the conditions under which this port is done: this is not a rewrite but a transcode of the original Z80 assembly code so its performance will not be as good as a conversion "by hand" by a human coder. But that conversion will be however much faster and simpler: a few days compared to possibly months of by hand conversion.
Also, the rest of the arcade board also needs to be emulated/virtualized in some way since the transcoded Z80 code will still expect to bang the hardware of the arcade board so there is a necessary layer of conversion between the game code and the Amiga hardware, this also can eat significant performance.

Sure, a manual conversion of the whole thing would play at 60FPS hands down but it would take months of very painful work.

JOTD has to find a balance between the amount of time he can spend on those conversions and the end result.
If you can help him, you should!

(1 edit)

thanks for the explanation. Actually I challenge anyone to create a 50FPS Galaga exact clone on A500. There are 64 sprites to display, and the trajectory & frame computations are complex. Check other games of the category like Galag or Deluxe Galaga it doesn't move as many objects.

The explanation about the transcode is actually incorrect. The Z80 is converted with a tool, but manually reviewed and optimized, so you can consider that it is 68000 native code. The only issue is that even degrading to 25FPS, the game logic still has to run at 50FPS.


Maybe something could be done with hardware sprite multiplexing but it's pretty difficult to achieve technically. You'd have to compute the exact row where to reassign each sprite to another one, and you could only use 6 sprites horizontally, which means that the attack waves are out of the question. Only a part of the swarm could be handled that way. That could work, but it's a lot of work and finetuning. It's the only option that could ensure 50FPS.

(5 edits)

Yes, it's true, there are alot of sprites and they also move very quickly, which makes the whole thing not easier. But i think it should be possible on a A500, because even for the C64, a good Galaga port exists in the meanwhile, from Arlasoft. Of course not as good as the Arcade version, that's clear, because the C64 is a 8bit machine, but really well playable, i must say. Some 'tricks' were used there, because of the big number of enemies on the screen, but at last, it was implemented well (not perfect but well), which I would never have thought possible on a C64, because Galaga is not easy to port, especially for 8bit machines, i guess.

Sure, a 1-to-1 port of the Arcade version is a different story again, but a Amiga500 is technically much stronger than a C64 and there are alot of games there, running on a plain A500, that looks more impressive than Galaga. But you will definitely know more about programming on the Amiga than I do, i have only little experience with this. Interesting information about the Z80 and how it was converted.

Hardware sprite multiplexing could be a solution here, sadly i can not help (because Nekoniaew suggested that) in such points, since i haven't programmed a game on the Amiga yet, otherwise i would help of course. I only expressed my opinion on the game and things like the slowdowns can be mentioned, but that doesn't mean, that I think the port is bad. I think it's great, that you're actually doing the work, to port some of the best old arcade classics to the Amiga, and most of these ports are really good too.

(1 edit)

I did  not know about the manual rework of the transcoded Z80 code, thanks for the precision.

Dynamic sprite multiplexing is feasible, Silkworm does it constantly with the missile/bullet sprites and it works great even if sometimes one or two sprites cannot display because the game goes over the sprite-count-per-scanline limit.
Why do you mention 6 sprites as the horizontal limit? As far as I can see there is no horizontal scrolling so no sprites are "eaten" by the extra scroll DMA fetch, is the game overscan or is it because you are using the last two sprites for the player ship?

Maybe it would be worth using the Blitter for the player ship to gain two extra sprites for the ennemies.

This said, as you hinted, even 8 sprites per scanline are way under what Galaga displays so this would still be a challenge indeed. Maybe a combination of Blitter and hardware sprites would have to be used but this would complicate even further any "object multiplexer". For such a simple game, Galaga is indeed tricky to adapt.

In any case, good job!   👍

(6 edits)

Reply to the user nekoniaew - I already knew, that the A501 memory-expansion is not Fastram, because I had already written exactly that myself, in the first entry here. Back then in time, alot people called this memory Fastram though (I did too at the time), which was not correct, as it turned out later. Nevertheless, also the 512kb Slowram, which the A501 can deliver, was used in alot of good Amiga classic-games, back in the 90's, so also this memory can be used in a senseful way, maybe not here in this Galaga port, but in alot of other games. Buying an Indivision ACA board, only for a handful of newer games, may be interesting for some people, but not for me, because all the best Amiga classic-games work perfectly without such a board and only with the normal 7MHz and 512kb+512kb memory.

> because I had written exactly that myself in the first entry here
I did not see it but yup, I get your point.

As for buying extra fast RAM, yes, as long as a game does not need the extra bandwidth given by fast RAM, any additional RAM, even if slow, would be fine but here it looks like the game is heavy on DMA and CPU which means that it would benefit from fast RAM since this allows the CPU to do its job without being hindered by the chipset.

I also do think that there is a way to make Galaga to run smoothly without actual fast RAM on A500 but that would probably require a lot more work on the engine. It's up to JOTD to decide if that is worth it to him.

(2 edits)

What do you think, nekoniaow and jotd666, could 1MB Chipram solve this slowdown-problem in Galaga500? One of my four Amiga500 was modded back then in the 90's and has a switcher, with which I can switch between "512kb Chipram + 512kb Slowram" and "1MB Chipram and 0kb Slowram". 1MB Chipram was great in tools like Protracker back then, because it allowed song-modules, to be much larger and there are also a few games, that only works correctly with 1MB Chipram. But mainly, you benefited from it, in a few tools.

I have not tried Galaga500 on exactly this A500 so far, because it's in my old room, in my parents house. Must try it out, how the game runs there, in the next week. Nevertheless, if it runs faster there, this is also not the ultimate solution then, because the vast majority of A500 users, will surely not have modded their computer in this respect, but it's definitely interesting to try it out.

A full 1MB of chip RAM (or more) should not improve the situation because the problem lies with the CPU not getting enough access to memory, so only fast RAM would help here on the hardware side.

An internal fast RAM expansion would probably be the cheapest hardware way to solve the issue.

Software wise, you'd need to find someone capable of optimizing the hardware interface layer of JOTD's conversion, not easy.

Okay. Then let's see, what will happen?