Secondly, I've been looking for this over the forum and the wiki, but I can't seem to find any information for making a split-screen/HUD. I believe I saw once a link that provided very useful examples and code, but I can't find it anymore.
If the CPU really interprets $02 as an instruction there must be some severe logic flaw that it's running the codes from incorrect addresses. For example, if you have something like:
C100: A5 02 ;LDA $02
the programme counter should be running the code from address $C100, it would only attempt to interpret the byte "02" as an instruction if at some instances it's running the code at address $C101.
For the split screen thing, some starting pages could be this and this.
The implementation of a HUD/status bar depends on the type of scrolling that you are using, and whether you want the HUD at the top or bottom of the screen. If you are only scrolling sideways, the split point for the HUD is usually detected with a sprite 0 hit. Make sure that a solid (i.e. not color 0) background pixel collides with a solid sprite pixel in the first sprite (sprite 0) near the split point and that will cause bit 6 of $2002 to go high, so you know it's time to modify the scroll.WJYkK wrote:Secondly, I've been looking for this over the forum and the wiki, but I can't seem to find any information for making a split-screen/HUD. I believe I saw once a link that provided very useful examples and code, but I can't find it anymore.
The horizontal scroll can be modified freely during rendering, you just have to write to $2000 and $2005 like you normally would. The vertical scroll can't be modified so easily, so instead of making the second $2005 write it's best that you read $2002 instead, which will clear the latch that selects between first and second writes.
If you want a status bar at the top, when all your PPU updates are done (including setting the scroll for the status bar), wait for the sprite hit flag to go low (this will happen at the end of VBlank, or immediately if there was no hit during the previous frame, but that doesn't matter), and then wait for it to go high again. If you placed the pixels correctly, the flag will change and you will change the horizontal scroll for the gameplay window. After that you can resume the game logic (i.e. exit from the NMI, if that's where you are doing the PPU updates).
If the status bar is at the bottom, after the PPu updates you resume the game logic normally. Once the game logic is done, wait for the hit flag to go high, and change the scroll for the status bar. This sounds simpler than a status bar at the top, but there's a big problem: if your game logic takes too long, and you miss the sprite hit, you'll get annoying visual glitches (the screen will jump, the status bar will flicker, etc). So only use this method if you are ABSOLUTELY sure your game logic will always finish before the hit.
If you are using a mapper with IRQs (it will be harder to manufacture carts in large quantities, since these mappers haven't been cloned by the community yet), replace the sprite hits with IRQs, and you can have your status bar anywhere.
Code: Select all
.enum $0001 Frames .dsb 1 SecondsOnes .dsb 1 SecondsTens .dsb 1 MinutesOnes .dsb 1 MinutesTens .dsb 1 NUMBERS_BASE .dsb 1 .ende