Flying Shark

[Sinphaltimus]

Well, it's also been reported on some emulators, but not always. I wonder if this is just a case of being that close to the edge? Remember that on real hardware, the CPU clock can vary by as much as 10% between machines (+/- 5% from the rated - I've owned machines that I measured near both ends of that). The VDP clock has much tighter accuracy. Could this just be a case of a slower clock being more susceptible and a faster clock getting over the edge? We've seen more and more tight races as we've been pushing the hardware harder over the years.

 

Funny this is...on my two consoles. With f18a the music starts at a bpm and under graphical load it slows down to about the speed my non-f18a console plays it at.

So I think the slower non-f18a console might be playing it as intended and keeping up just fine but the f18a version is gaining some performance boost that it cannot maintain so as opposed to the music slowing down, it sounds like it's just going back to normal speed. If indeed the non-f18a console can be considered normal speed.

 

That's just the gut feeling I got playing around with it on both.

[Asmusr]

I found the problem with the music timing on F18A: I'm reading the VDP status and was using JGT to check for no interrupt. But on the F18A, unlike the 9918A, the status is apparently often zero, so adding a JEQ solved it. Perhaps a difference in how the 5th sprite number bits are used?

flying-shark-8.bin

[Omega-TI]

^

Final version?

[Asmusr]

^

Final version?

 

Eh? I have only completed half a level out of four. With my current progress it will take at least 3 months before this is finished.

[Omega-TI]

 

Eh? I have only completed half a level out of four. With my current progress it will take at least 3 months before this is finished.

 

Thanks. Good to know. I don't always make it into the DEV section and don't have a lot of time to follow everything. When it's done, I'd like to add a link to the appropriate file.

[Omega-TI]

I'm not sure if I'm the only one, or if my eyes are just getting worse... the little white balls used as ammo, appear to get lost in the busy backgrounds (at least to me).

[Willsy]

Deleted

Edited December 11, 2017 by Willsy

[Asmusr]

Deleted

 

Was it a joke about small balls?

[+OLD CS1]

Giggedy.

[Asmusr]

Anyway, some of the next things to implement (from the ZX Spectrum version) are:

• Smart bombs. These are the B icons. Activated by holding down fire for a while. Destroy all enemies on the screen. Are left after shooting some enemies (not sure about the pattern).
• Power ups. Activated by shooting all enemies in the longer waves and picking up the resulting S icon. Give double shot, triple shot, maybe more?
• Bonuses: If you shoot a wave while having a power up a 1000 pt bonus icon sometimes appear.

[+nanochess]

 

Just a bit of detuning. Here are the modules for MOD2PSG2 so you can see.

It was kind of difficult to find the right version of MOD2PSG2. It's the latest beta of 2008.

 

I've learnt something.

 

Thanks!

[matthew180]

I found the problem with the music timing on F18A: I'm reading the VDP status and was using JGT to check for no interrupt. But on the F18A, unlike the 9918A, the status is apparently often zero, so adding a JEQ solved it. Perhaps a difference in how the 5th sprite number bits are used?

 

TL;DR: I think the difference is probably where the internal sprite counter sits when it is not counting sprites. Based on this information, I would suspect that the 9918A counter sits at 31 until sprite processing starts, and the F18A resets its counter to zero when in the idle state (not processing sprites). Can you please check what the sprite number is on the stock console while you are successfully checking for interrupts using JGT?

 

Longer version:

 

The 9918A and F18A use a counter to track the sprite number during sprite processing. This counter is used directly in the construction of the VDP status byte, and it has been shown on a real 9918A that while sprites are being processed during a scan line, as long as a 5th sprite has not been detected, the sprite number value in the status register will change along with the counter. I had to make a firmware change to implement this behavior in the F18A since it is used by software that use sprites to detect specific scan lines and do scan line effects.

 

However, when sprites are not being processed (any time the scan line is outside the active video area), the sprite counter should be static and remain at whatever the last value in the counter was. It just so happens that in the F18A when sprites are not being processed the counter is reset to zero, and that is reflected in the status register. Since using JGT works on a real 9918A when checking for the interrupt, I suspect that the 9918A does not reset its sprite counter until it starts actively processing sprites. If that is the case, then in the 9918A the sprite counter is probably sitting at 31 most of the time, or some sprite number if there were more than 5 sprites on a line, and that would be reflected in the status register, and subsequently make JGT work most of the time.

[Asmusr]

 

TL;DR: I think the difference is probably where the internal sprite counter sits when it is not counting sprites. Based on this information, I would suspect that the 9918A counter sits at 31 until sprite processing starts, and the F18A resets its counter to zero when in the idle state (not processing sprites). Can you please check what the sprite number is on the stock console while you are successfully checking for interrupts using JGT?

 

Longer version:

 

The 9918A and F18A use a counter to track the sprite number during sprite processing. This counter is used directly in the construction of the VDP status byte, and it has been shown on a real 9918A that while sprites are being processed during a scan line, as long as a 5th sprite has not been detected, the sprite number value in the status register will change along with the counter. I had to make a firmware change to implement this behavior in the F18A since it is used by software that use sprites to detect specific scan lines and do scan line effects.

 

However, when sprites are not being processed (any time the scan line is outside the active video area), the sprite counter should be static and remain at whatever the last value in the counter was. It just so happens that in the F18A when sprites are not being processed the counter is reset to zero, and that is reflected in the status register. Since using JGT works on a real 9918A when checking for the interrupt, I suspect that the 9918A does not reset its sprite counter until it starts actively processing sprites. If that is the case, then in the 9918A the sprite counter is probably sitting at 31 most of the time, or some sprite number if there were more than 5 sprites on a line, and that would be reflected in the status register, and subsequently make JGT work most of the time.

 

That makes sense, but one thing is unclear to me: even if the F18A sets the lower 5 bits to zero during blanking, wouldn't it set the interrupt bit at the same time, so the status would still not be zero? The only way it would be zero is if I read the status register during blanking, and then read it again before blanking ends, or what?

[matthew180]

Remember, "blanking" includes the horizontal blank period, which happens for every scan line. A video frame is really larger than the active video, by quite a bit actually. For example the timing of a 640x480 VGA frame is really 800 pixels x 525 lines, but only 640 pixels x 480 lines are "active video", the rest are time for things like the hsync, vsync, front porch, back porch, etc., i.e. all the extra stuff needed to sync the monitor.

 

I just talked it over with Tursi and I'm pretty sure the problem is what I explained, and I will make a fix for that in the next firmware. The only unknown right now is, if all 32 sprites are processed and there were none that triggered the 5th sprite flag, will the 9918A's counter be sitting at 31 or will it have rolled over to 0? I suspect it will be at zero since that is easier in hardware, but only a test on real hardware will tell for sure.

[artrag]

It could be sitting at the highest plane before the terminator 0D0h.

From what I remember the counter in the status register is not zeroed after the sprites are displayed

Edited December 14, 2017 by artrag

[matthew180]

There is one case that needs to be tested where the sprite count may end up on zero: when there are 32 active sprites, but no more than four on any given scan line. In that case the entire list would need to be scanned and there would never be any 5S flag set. The theory is that the sprite counter will roll back to 0. However, it may also stay latched at 31.

[Asmusr]

There is one case that needs to be tested where the sprite count may end up on zero: when there are 32 active sprites, but no more than four on any given scan line. In that case the entire list would need to be scanned and there would never be any 5S flag set. The theory is that the sprite counter will roll back to 0. However, it may also stay latched at 31.

 

I don't know if this is any help, but I tried to make a special version of my game where I displayed the VDP status byte as my score.

 

Right after an interrupt was detected the F18A usually showed 128 while the 9918A showed 131. 'Usually' here means with 3 active sprites (2 for the plane and one for the shadow) and a terminator after in the sprite attribute list.

 

If I checked the status at a more arbitrary time the number varied more, but the most common reading was 0 on the F18A and 3 on the 9918A (corresponding to the numbers above minus 128 for the interrupt bit). Again with 3 sprites.

 

I think you need a dedicated test program if you want more detailed results.

[Asmusr]

Latest version has smart bombs (hold down fire) and allows you to pick up power-ups (after shooting some whole waves) that will give you double or triple shot.

 

I still haven't expanded the number of enemies.

 

The game sometimes crashes for me on hardware, but I hope it's only because I'm using a flaky nanoPEB.

flying-shark-8.bin

[digdugnate]

ooh, a new version! i will throw on my TI and test after dinner tonight.

[+remowilliams]

Latest version has smart bombs (hold down fire) and allows you to pick up power-ups (after shooting some whole waves) that will give you double or triple shot.

 

New features frighten me, I'll have to retire from the community now.

 

 

just kidding... : D

[fabrice montupet]

Wow! Where does this stop? You always push the limits! I like so much!

[artrag]

Greetings for this new release !!

I've a couple of minor suggstions:

About bombs, why not blanking the screen for a frame out of two with white or yellow flashes 2 or 3 times ?

About double shoot, while the plane is moving left or right, the distance between the two bullets should reflect the inclination of the plane.

It should be slightly less than the distance when you shoot while moving forward.

Edited December 19, 2017 by artrag

[digdugnate]

i played on my TI, i couldn't get it to crash (cept where i ran into stuff onscreen!)

[Asmusr]

Greetings for this new release !!

I've a couple of minor suggstions:

About bombs, why not blanking the screen for a frame out of two with white or yellow flashes 2 or 3 times ?

About double shoot, while the plane is moving left or right, the distance between the two bullets should reflect the inclination of the plane.

It should be slightly less than the distance when you shoot while moving forward.

 

Good suggestions. Will do.

[Asmusr]

I followed Artrag's suggestions and I think both the smart bomb and the double shot look better now. I also added music to the title screen - right now just the second level music but I plan to replace this later.

 

Edit: and now there's also one place where you can pick up a smart bomb after shooting a tank.

flying-shark-8.bin