Page 1 of 2

Re: A miracle when it works first time!

Posted: Thu Aug 29, 2019 11:40 pm
by Cosmium
Turtle_Quality wrote: Thu Aug 29, 2019 9:06 pm For vertical clipping , if you use a lookup table to get the address of each row, you point rows 192-255 to somewhere harmless, ROM for instance. That way there is no loss of speed. I assume you hold the y address in a single byte so -1 would be 255.
Hey, that's an elegant solution!

Though I think it's handy to calculate ahead of time how many lines of the clipped sprite to draw. That way you can avoid drawing more than necessary as you would if you "blindly" wrote data into ROM over the course of the full sprite height.

Re: A miracle when it works first time!

Posted: Fri Aug 30, 2019 7:32 pm
by Cosmium
So I finished writing the part where the sprite should gracefully exit the bottom of the screen. Gave it a test and sure enough there were no "it works first time" miracles on display here either. Just an encore fireworks display! :)

Image

Luckily it was an easy fix and a silly mistake (aren't they always?!). I'd incorrectly assumed a register had a certain value in it after copying and pasting code. Ugh :roll:

I wonder what percentage of programming bugs are due to unfounded assumptions..

Re: A miracle when it works first time!

Posted: Sat Aug 31, 2019 6:58 am
by R-Tape
Ast A. Moore wrote: Thu Aug 29, 2019 10:20 pm Yup, even the release version of Exolon has a similar bug.
And so does Rallybug, or at least the paid-for version does. There's very few opportunities to actually reach the outer limits, but it's happen to me.

Re: A miracle when it works first time!

Posted: Sat Aug 31, 2019 12:34 pm
by Ast A. Moore
R-Tape wrote: Sat Aug 31, 2019 6:58 am
Ast A. Moore wrote: Thu Aug 29, 2019 10:20 pm Yup, even the release version of Exolon has a similar bug.
And so does Rallybug, or at least the paid-for version does. There's very few opportunities to actually reach the outer limits, but it's happen to me.
What’s that, you say? A bug in Rallybug? Figures. :lol:

Re: A miracle when it works first time!

Posted: Wed Sep 11, 2019 4:42 am
by Cosmium
Capture of the latest amusing bug while optimising my sprite routine. Think it needs a bit more of work. ;)

Funny how tiny and seemingly innocuous changes in the code can lead to such graphic disaster!

Image

Re: A miracle when it works first time!

Posted: Sat Oct 19, 2019 7:18 am
by Cosmium
Don't think I've seen this quirky one before :?

Check out the copyright year right after this latest programming crash:

Image

Re: A miracle when it works first time!

Posted: Sat Oct 19, 2019 8:30 am
by R-Tape
Is that 1882?! Clive hadn't even started going bald back then.

How is that even possible? Is 'overwrite ROM' enabled in you emulator?

Re: A miracle when it works first time!

Posted: Sat Oct 19, 2019 10:45 pm
by Cosmium
How is that even possible? Is 'overwrite ROM' enabled in you emulator?
I had a look at Spin's settings: "Allow ROM editing" and "Allow assembly to ROM" are disabled, and I've since fixed the bug, so I'm not even sure how it happened..

Actually it showed "(c) 1B82...". Wasn't even a number. Weird!

Re: A miracle when it works first time!

Posted: Sat Oct 19, 2019 10:59 pm
by R-Tape
Cosmium wrote: Sat Oct 19, 2019 10:45 pm Actually it showed "(c) 1B82...". Wasn't even a number. Weird!
Hex. Good to know that Sinclair research will outlive the common era!

Re: A miracle when it works first time!

Posted: Mon Dec 02, 2019 3:44 am
by Cosmium
A few days ago, while programming some fixed-point maths routines, I was suddenly rewarded with this festive-themed crash. Just before the (c) message it kinda looks like a full screens-worth of gaudy xmas wrapping paper, if you squint hard enough!


Image

Re: A miracle when it works first time!

Posted: Fri Dec 06, 2019 4:02 pm
by Seven.FFF
The wrapping paper is a classic runaway stack. Rogue bytes get executed as code, and it goes into a loop pushing pairs of bytes all the way down memory from the head of the stack to the bottom of memory, passing through the attributes and then the pixels as it goes :)

Re: A miracle when it works first time!

Posted: Wed Dec 11, 2019 3:53 am
by Cosmium
Seven.FFF wrote: Fri Dec 06, 2019 4:02 pm The wrapping paper is a classic runaway stack. Rogue bytes get executed as code, and it goes into a loop pushing pairs of bytes all the way down memory from the head of the stack to the bottom of memory, passing through the attributes and then the pixels as it goes :)
I bet you're right! I fixed the bug a while ago, but I do remember there was a lot of tricky stack handling going on in a loop, and I ended up simplifying by storing to memory locations instead. But I must say the 'wrapping paper' crash did feel like a timely festive treat when it happened :lol:

Re: A miracle when it works first time!

Posted: Wed Dec 11, 2019 11:14 am
by Sokurah
Cosmium wrote: Sat Oct 19, 2019 10:45 pm Actually it showed "(c) 1B82...". Wasn't even a number. Weird!
Sure it is. It's 7042 in decimal ;)

Re: A miracle when it works first time!

Posted: Wed Dec 11, 2019 12:46 pm
by R-Tape
I had a nightmare of a bug, that I solved last night. A compressed screen was decompressing into a right mess, and it wasn't always the same screen, or the same way. It turned out that I'd pasted a bit of code and forgot that it loaded a zero into an absolute memory address high in memory. So as the code built up, I got different effects in different places each time. Even though it was kind of fun to track it down, I should never have made that mistake in the first place. Argh!

Re: A miracle when it works first time!

Posted: Thu Dec 12, 2019 5:53 pm
by Ast A. Moore
Oh, I just realized that Quadron didn’t run on the +2A/+3, so I developed a bugfix for it. I only tested the demo version, so [mention]Cosmium[/mention], if you’re interested, PM me for details. I believe my fix should make it compatible with all Spectrums in all modes (48 and 128K).

Re: A miracle when it works first time!

Posted: Fri Dec 13, 2019 12:16 am
by Cosmium
Ast A. Moore wrote: Thu Dec 12, 2019 5:53 pm Oh, I just realized that Quadron didn’t run on the +2A/+3, so I developed a bugfix for it. I only tested the demo version, so @Cosmium, if you’re interested, PM me for details. I believe my fix should make it compatible with all Spectrums in all modes (48 and 128K).
Nice! PM'd :)

Re: A miracle when it works first time!

Posted: Fri Dec 13, 2019 12:23 am
by Cosmium
R-Tape wrote: Wed Dec 11, 2019 12:46 pm I got different effects in different places each time.
Those are the hardest to find and fix aren't they? And when you finally trace it back to the root of the bug, there's usually some incorrect assumption made (like in this case) causing that head-slapping moment of "oh of course"!

Re: A miracle when it works first time!

Posted: Fri Dec 13, 2019 8:36 pm
by PROSM
Cosmium wrote: Fri Dec 13, 2019 12:23 am Those are the hardest to find and fix aren't they? And when you finally trace it back to the root of the bug, there's usually some incorrect assumption made (like in this case) causing that head-slapping moment of "oh of course"!
They can be pretty fun to figure out though, even if they do waste time. For instance, I had a right corker of a bug in Postie's Peril at one point, where at a specific point on a specific screen, while the character was walking right, the inventory list would appear for no reason. No crashes, just the inventory popping up out of nowhere, at this precise spot. This bug occurred nowhere else in the game.

It turned out that the problem was in ZAD's keyboard driver. You see, I had written a custom interrupt routine to record each key that was depressed, 50 times a second, so that during the game loop, the main program could handle the inputs in its own time without a short key-press falling between the cracks, since without the interrupt, the keyboard would only be polled at the speed of the game (which can be adjusted to as low as 8 fps).

At the end of each game loop, the main program would reset the temporary keyboard matrix for the next loop, so that released keys were not carried over into the next loop. This reset was performed using an LDIR operation (you can probably see where this is going).

It turned out, that at this very specific spot, the timings aligned so that the interrupt was triggered during the keyboard reset routine. The new data is read into the matrix, the interrupt returns, and the LDIR starts to copy keyboard data down the matrix, making it look like other keys have been pressed. Incredibly, it so happened that the HL register pointed to the data for the keyboard row controlling movement at this specific spot. It got copied to the rest of the keyboard matrix, which, to the input handler, made it look like one of the inventory modes had been activated

The fix? Disable interrupts during the matrix reset. Why I didn't do this to start with is beyond me, but it wasted a good three evenings' worth of coding.

Oh well. :lol:

EDIT: Changed wording slightly for readability

Re: A miracle when it works first time!

Posted: Sat Dec 14, 2019 3:58 am
by djnzx48
How did the interrupt interfere with the LDIR? Did the interrupt routine overwrite the first byte of the keyboard buffer, which then propagated to the rest of the buffer?

Semi-related, this article shows one inventive way to achieve atomic operations on a single-processor system.

Re: A miracle when it works first time!

Posted: Sat Dec 14, 2019 8:11 am
by PROSM
djnzx48 wrote: Sat Dec 14, 2019 3:58 am How did the interrupt interfere with the LDIR? Did the interrupt routine overwrite the first byte of the keyboard buffer, which then propagated to the rest of the buffer?
It did overwrite the entire keyboard buffer, but only the 5th byte had any keys depressed (this contains the 6-0 row in the buffer, which is used for movement in ZAD games). After the interrupt returned, the LDIR continued, and it happened to contain the 5th byte's address, so the 6-0 row's inputs were duplicated across the rest of the buffer (which happened to be the right hand side of the keyboard).

It was bizarre how the timings aligned just so, because if there had been any other address in HL, the bug would've manifested itself as a complete loss of control of the player character.

Re: A miracle when it works first time!

Posted: Sun Apr 05, 2020 10:28 am
by R-Tape
Image

Coding's coming along nicely.

Re: A miracle when it works first time!

Posted: Sun Apr 05, 2020 11:04 am
by Ast A. Moore
R-Tape wrote: Sun Apr 05, 2020 10:28 am Coding's coming along nicely.
Lovely.

Waiter! I’ll have what the gentleman’s having. :D

Re: A miracle when it works first time!

Posted: Sat Apr 11, 2020 8:06 am
by Cosmium
Ast A. Moore wrote: Sun Apr 05, 2020 11:04 am Waiter! I’ll have what the gentleman’s having. :D
Of course sir. And perhaps for dessert..

Image

I had a little chuckle when a few straightforward (or so I thought) optimisations to sprite rendering resulted in this OTT crash! Still working on finding the bug :?

Re: A miracle when it works first time!

Posted: Sat Apr 11, 2020 10:36 am
by Ast A. Moore
Cosmium wrote: Sat Apr 11, 2020 8:06 am Of course sir. And perhaps for dessert..
Image
Oh, yeah . . . That hit the spot.

Re: A miracle when it works first time!

Posted: Sun May 10, 2020 11:28 pm
by Cosmium
Think I'd better beef up the safeguards for sprites writing outside of screen memory...

Image

as appears to have happened here. Man, what a show :lol: