"Arkanoid - The Hit Squad" mystery?

[beginner]

Hi everybody,

I finally had some time to play a bit more with my emulator (ZX Spectrum 48k) and I am back with yet another question .

There's no surprise that Arkanoid is not wkoring on it, since I do not have any floating bus support.
However, I thought I should give a try to Arkanoid - The hit squad, since it should work without the floating bus. And it does, sort of.

Everything seems to be working pretty well, except for one tiny, little problem: the ball is invisible

Any ideas why?
Could it be because of the way my emulator draws the screen?
It reads and decodes the display file only once per frame at the end of the frame (after the 69888 clock cycles).

Or could it be something else?

Cheers

[spider]

I don't think it would be an emulator issue.

Which emulator are you using ? And have you tried it in another one ?

I tried that release (Speedlock 5) and yes there's no ball with a +3 , interestingly its also devoid with emulation of a grey +2 as well.

Actually, its only missing on the one emualator I tried that being ZXSpin if its set to 7Mhz , at 3.54 its present even with a +3 loaded from the Tape Loader.

EDIT... Pic, running +3:

[beginner]

Hi @spider

I don't think it would be an emulator issue.

Which emulator are you using ? And have you tried it in another one ?

I've actually developed my own ZX Spectrum 48k emulator. I should have mentioned that in my first post.
So, in this case there are some chances that I might have implemented something incorrectly .

I also tried it on InkSpector 2.0.3 (48k machine mode) and there the ball is visible and everything works properly.

However, as you can see in the attached image, on my custom made emulator the ball is missing and I am wondering why .



Cheers

[^m00h^]

You should try Arcanoid 1,2 with pentagon fix in any emulator with pentagon support: https://vtrd.in/release.php?r=b01df4272 ... 49f1f08aa8

[geecab]

Hi there!

Bit of a long shot, but what might be happening here is the same thing I noticed a while ago when running FireFly using the zx spectrum emulator on MAME. I think it has to do with graphics being removed (In Arkanoid's case, the ball) after the game code decides the raster has gone past. I reckon if you run Firefly on your emulator, you might see the same issues I was seeing using MAME.

Here's a link to the mame forum I posted on regarding Firefly's missing graphics which resulted in a fix:
https://forums.bannister.org/ubbthreads ... ber=112363

Hope this helps! Respect to you writing your own emulator

[Einar Saukas]

Could it be because of the way my emulator draws the screen?
It reads and decodes the display file only once per frame at the end of the frame (after the 69888 clock cycles).

Arkanoid probably draws the ball AFTER each interrupt, but before the TV raster scan. So the ball appears on a real screen, but your emulator is missing it.

A simple solution for more accurate emulation is to copy each screen byte pair (pixel + attribute) into a separate internal buffer in your emulator, at the exact clock cycle that the TV raster scan would be reading it. Then change your emulator to read and decode the display file once per frame, except reading from your internal buffer instead of the Spectrum screen.

[AndyC]

Yeah, most likely the ball is drawn during the frame, the original use of the floating bus was probably trying to optimize that. Building up the display as the CPU executes will probably fix it and get your emulator closer to being able to render multicolour effects too.

[beginner]

Hi @geecab , @Einar Saukas , @AndyC

Thanks for pointing me to the right direction .
I did some quick tests and I can confirm that you are indeed correct!


@geecab

Respect to you writing your own emulator

Thank you for your kind words. I appreciate it

Cheers!

[spider]

Ah I had no idea it was your own emulator!

Much respect as said for "writing your own"

[beginner]

Ah I had no idea it was your own emulator!

Much respect as said for "writing your own"

Much appreciated!

Cheers

[beginner]

Hi everybody,

I'm back with a small update on this matter.
Maybe it will be useful to some other beginner emulator developer, like myself .

Halfway through the implementation I realized that even though I am now doing cycle based / on the fly screen reading / decoding, there will be games that won't work properly since I do not handle memory contention at all, which would lead to some out of sync stuff happening.
After finishing the implementation I can now confirm that indeed there are games that work properly when decoding the screen file at the end of the frame but generate some undesired artifacts when decoding the screen on the fly.

If I am not mistaken (and please do correct me if I am wrong) in order to properly handle memory contention my emulator should be cycle based instead of instruction based as it is now.

That would require me to do some pretty big changes to the core.
What I ended up doing instead, was to implement both screen decoding methods and select the one to be used by a command line switch when the emulator is started. Not the best method and certainly not the most elegant but it does the job for now and allows me to play even more games .

As a side note, I think that a proper floating bus implementation would also require a proper memory contention handling.

Cheers!

[AndyC]

Yeah, sounds about right.

You're basically following an accelerated path along how emulators were developed. The first ones just ran a frames worth of code, based on documented instruction timing and then rendered the video based on the current contents of video memory. It works, kind of, but as you notice isn't entirely faithful.

The next iterations tended to do something vaguely similar, but based on line-at-a-time rendering rather than entire frames. That way border stripes and various multicolour effects from back in the day mostly worked when they aren't too timing specific.

And then more modern iterations moved to proper emulation at the cycle level, allowing more accurate contention timings as well as display rendering of more nuanced colour change effects as seen in multicolour games.

Then the crazy next step is things like PAL emulation so that weird side effects of how the video is encoded can be exploited, as in things like Chromatrons Attack.

[beginner]

Thanks @AndyC .

This little project turned out to be more addictive than I would have thought. It is, however, also very satisfying .

Right now I am enjoying the "freshly baked" border stripes.
I decided that I'll always paint the borders on the fly / cycle based, no matter which one of the previously described methods I use to paint the rest of the screen. Just so I can have the stripes, even if sometimes they might be out of sync .

Cheers!