Nice! PM'dAst 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).
A miracle when it works first time!
Re: A miracle when it works first time!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first 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"!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
- PROSM
- Manic Miner
- Posts: 476
- Joined: Fri Nov 17, 2017 7:18 pm
- Location: Sunderland, England
- Contact:
Re: A miracle when it works first time!
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.
EDIT: Changed wording slightly for readability
All software to-date
Working on something, as always.
Working on something, as always.
Re: A miracle when it works first time!
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.
Semi-related, this article shows one inventive way to achieve atomic operations on a single-processor system.
- PROSM
- Manic Miner
- Posts: 476
- Joined: Fri Nov 17, 2017 7:18 pm
- Location: Sunderland, England
- Contact:
Re: A miracle when it works first time!
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.
All software to-date
Working on something, as always.
Working on something, as always.
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: A miracle when it works first time!
Lovely.
Waiter! I’ll have what the gentleman’s having.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Re: A miracle when it works first time!
Of course sir. And perhaps for dessert..
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
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: A miracle when it works first time!
Oh, yeah . . . That hit the spot.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Re: A miracle when it works first time!
Think I'd better beef up the safeguards for sprites writing outside of screen memory...
as appears to have happened here. Man, what a show
as appears to have happened here. Man, what a show
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
Haha brill. How on earth did you get it to do that?!
Never used to do safeguards, but a while back, I started checking that D was below 88 before any pixel draw subroutine, and if so doing a JP NC, safety, that sets DE to draw safely in ROM.
Re: A miracle when it works first time!
I know, it's a ridiculous display isn't it?! I'd been tinkering with adding a write address offset as sprite data was written to the screen. I already had a check to make sure y <= 191 but hadn't figured on encountering larger x offsets pushing the write address outside of screen memory.
I probably could've zeroed in on the source of the bug sooner using ZX SPIN disassembler's conditional breakpoints, but I haven't yet figured out the syntax to check for a write to an addresses range..
That's a good plan too. It's always a toss up between speed and safety eh? Guess I've been leaning towards speed but it's catching me out occasionally when values go outside the range of initial expectations.
Probably a better approach is to add conditional assembly based on an EQU for a special "debug" build with these safeguards in place, which can be easily removed for performance in "release" code. Note to self: actually do this rather than talk about it as a theory!
Cosmium
https://cosmium.itch.io/
https://cosmium.itch.io/
Re: A miracle when it works first time!
One of my more unusual crashes:
I think it was the speccy rebelling against Dave Spicer's cruelty to Z80 registers.
I think it was the speccy rebelling against Dave Spicer's cruelty to Z80 registers.