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.
> 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.
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! 馃憤
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!
Thank you for the reply! This is great.
Maybe it would be a good idea to update your KickStarter campaign page to include a "very visible link" to this offer?|
Lots of projects do that by adding a "Late to the campaign? Get it" button on the right side of the Campaign picture, which is very visible and efficient.
Thanks again. ;)
