I noticed that when I first run the Space Invaders clone I've been working on after powering on the system my extra lives aren't displayed in the bottom right as they should be. After this, if I BREAK, or do a hard reset, everything works as normal. I'm literally doing this:
LDA #3 \total lives
STA &7D \life store
JSR livesREM \show remaining lives
The code that shows the extra lives is irrelevant because it obviously works. All it does is loop through the number of total lives minus one and display them. And it reads the life count from &7D. This is the same whether the machine has just booted or not. And the number of lives IS correct. If I play and I die and lose a life, and I have 1 extra life which then correctly appears. But the "invisible" extra lives only occur after powering on.
This happens both on a MiSTer Multisystem & PC emulator (B-em), so it's not a MiSTer system issue (which is where I've done all the development). It's not really a problem as I know the code works, but it's weird. Just wondering if anyone has any thoughts as to why it happens.
Strange startup behaviour
Re: Strange startup behaviour
This kind of thing is usually some uninitialised memory location or similar. I'd be tracing the code to see what's happening - a few instructions in there wil probably be an "Oh!" moment.
Castle Defender, Untitled Dungeon Game, Night Ninja, Wordle, Waffle, Acorn Island, Beebchase, Ghostbusters
Re: Strange startup behaviour
AGGGGGHHHHHHHHH! F@$@ S@I& B@%%@CK£! You may have surmised that I found it. 
It was SO stupid. I was looking in the wrong place, although the offending code was just a few lines down! I finally found it when just out of sheer desperation I put a BRK statement after the OSWRCH call that should have been displaying the ship character, and lo and behold a single ship appeared. I had previously thought that maybe the colour setting was wrong and the ships were being displayed but in black instead of white, but now that I saw that a ship was actually being shown in white it dawned on me that the ship must be being overwritten as the code reverse prints the total lives from right to left on the right hand side and the last one gets blanked out so that it vanishes leaving just the 'extra' lives. Except as I moved from right to left I was subtracting the char width which I store in a memory location rather than using a fixed value of 64 (for Mode 5). As soon as I saw that I realised that the subtraction value must be 0, so all the lives would just be overwriting each other, with the last iteration of the loop blanking out the only life you could see as they'd all be being written to the same position on screen. The idea was initially that if I wanted to switch to a different Mode I could just change the contents of the char width store as I use it in a fair few places which is why I stored it in memory.
And of course you were right, while the life counter had been correctly initialised, the char width doesn't get initialised until slightly later, and remains in zero page memory which is why it always worked on subsequent restarts but never from a power off state.
Man that was really annoying.
Thanks
It was SO stupid. I was looking in the wrong place, although the offending code was just a few lines down! I finally found it when just out of sheer desperation I put a BRK statement after the OSWRCH call that should have been displaying the ship character, and lo and behold a single ship appeared. I had previously thought that maybe the colour setting was wrong and the ships were being displayed but in black instead of white, but now that I saw that a ship was actually being shown in white it dawned on me that the ship must be being overwritten as the code reverse prints the total lives from right to left on the right hand side and the last one gets blanked out so that it vanishes leaving just the 'extra' lives. Except as I moved from right to left I was subtracting the char width which I store in a memory location rather than using a fixed value of 64 (for Mode 5). As soon as I saw that I realised that the subtraction value must be 0, so all the lives would just be overwriting each other, with the last iteration of the loop blanking out the only life you could see as they'd all be being written to the same position on screen. The idea was initially that if I wanted to switch to a different Mode I could just change the contents of the char width store as I use it in a fair few places which is why I stored it in memory.
And of course you were right, while the life counter had been correctly initialised, the char width doesn't get initialised until slightly later, and remains in zero page memory which is why it always worked on subsequent restarts but never from a power off state.
Man that was really annoying.
Thanks
Re: Strange startup behaviour
I have had the same working on BCP. The workspace includes not only the viewport dimensions, which can result in nothing being drawn if no part of the design is within the viewport; butsome JMP () vectors, which are used for calculating rotated and flipped co-ordinates within a part; this saves having to choose the correct routines every single time (and also, the addresses are carefully chosen so I can use a cheeky BIT on the destination address to tell whether to draw pads lengthwise-on or widthwise-on, and which side of the board is being drawn on.) This created havoc if not initialised properly!
Luckily, I was deliberately trying to play nice with BASIC; so it was possible, and easy, to overwrite an instruction with RTS, drop out early and examine some memory locations to work out exactly what was amiss.
Luckily, I was deliberately trying to play nice with BASIC; so it was possible, and easy, to overwrite an instruction with RTS, drop out early and examine some memory locations to work out exactly what was amiss.
Re: Strange startup behaviour
I have a load of memory locations I print out as debug info when I drop back to basic, which have been useful for other bits of debugging, but it just wasn't helping here because by the time I get to see them everything is initialised, and if I check them before the machine code runs then the contents are mostly zero or garbage. With hindsight, I could have used a couple of RTS instructions to drop back to BASIC to review the info early, but in the end putting the BRK in worked out well as it let me see right away what the issue was. It's not pretty, but it worked.