Cybearg Posted October 24, 2014 Author Share Posted October 24, 2014 The only files I changed were scoregraphics.asm and DPCplus_kernel.asm Yeah, I really have no idea why it's on the fritz for me. I'm more suspicious of vbB itself, since it has shared computer-wide configurations regardless of where it's being run from. Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted October 24, 2014 Share Posted October 24, 2014 Did you use the configuration wizard when switching stuff before? I also find restarting the computer never hurts. At this point I suggest building a new project (and my new DPCplus_kernel.asm file). Start with basically nothing and just try to get the score to have more digits. Then keep slowly adding in stuff until it breaks. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted October 24, 2014 Author Share Posted October 24, 2014 (edited) Did you use the configuration wizard when switching stuff before? I also find restarting the computer never hurts. I was under the impression that was the only way to do it. And yes, I've done the computer restarting thing, though it doesn't really make much sense to me. What about bB would cause lingering changes that could be cleared by restarting your computer? At this point I suggest building a new project (and my new DPCplus_kernel.asm file). Start with basically nothing and just try to get the score to have more digits. Then keep slowly adding in stuff until it breaks. Alright. I made a new project and thought I'd start with as basic as I could get: set romsize 4k set tv ntsc scorecolor = $0E main drawscreen goto main This won't compile. Don't know how to really step back from there. segment: fffc vs current org: 10004 2869 bytes of ROM space left B:\vBTest\New Project\default.bas.asm (1952): error: Origin Reverse-indexed. Errors were encountered during assembly. However, this will compile: set kernel DPC+ const splitscore_2_4 = 0 dim splitKernelVar = z const SPLIT_KERN_BIT = BIT_7 goto main bank2 bank 2 main scorecolors: $40 $42 $44 $46 $48 $4A $4C $4E end drawscreen goto main It works with additional scores right up until this point: .byte $00 ; | | $FF70 .byte $7E ; | XXXXXX | $FF71 .byte $60 ; | XX | $FF72 .byte $60 ; | XX | $FF73 .byte $7C ; | XXXXX | $FF74 .byte $60 ; | XX | $FF75 .byte $60 ; | XX | $FF76 ; .byte $7E ; | XXXXXX | $FF77 ; .byte $00 ; | | $FF78 ; .byte $60 ; | XX | $FF79 ; .byte $60 ; | XX | $FF7A ; .byte $60 ; | XX | $FF7B ; .byte $7C ; | XXXXX | $FF7C ; .byte $60 ; | XX | $FF7D ; .byte $60 ; | XX | $FF7E ; .byte $7E ; | XXXXXX | $FF7F Any additional bytes cause it to crash during compilation. It only allows 7 out of 8 bytes of E. If I uncomment one more byte, I get: segment: 1fd4 eqm vs current org: 1fd5 free ram: 0 DPC free RAM= 603 -1 bytes of ROM space left in bank 1 B:\vBTest\New Project\default.bas.asm (1453): error: Origin Reverse-indexed. Errors were encountered during assembly. So at least I'm running out of ROM here before trouble arises. That doesn't really tell me much about why I get problems at other times, though. Edited October 24, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted October 25, 2014 Share Posted October 25, 2014 Alright. I made a new project and thought I'd start with as basic as I could get: set romsize 4k set tv ntsc scorecolor = $0E main drawscreen goto main This won't compile. Don't know how to really step back from there. segment: fffc vs current org: 10004 2869 bytes of ROM space left B:\vBTest\New Project\default.bas.asm (1952): error: Origin Reverse-indexed. Errors were encountered during assembly. I meant start a new DPC+ project and start building it up to do what you want it to do, until it breaks. But in the above output it is telling you why it breaks. The origin is reversed. If you look in the .lst file you will find this: 1654 f467 ; feel free to modify the score graphics - just keep each digit 8 high 1655 f467 ; and keep the conditional compilation stuff intact 1656 f467 - ifconst ROM2k 1657 f467 - ORG $F7AC-8 1658 f467 else 1659 f467 - ifconst bankswitch 1660 f467 - if bankswitch == 8 1661 f467 - ORG $2F94-bscode_length 1662 f467 - RORG $FF94-bscode_length 1663 f467 - endif 1664 f467 - if bankswitch == 16 1665 f467 - ORG $4F94-bscode_length 1666 f467 - RORG $FF94-bscode_length 1667 f467 - endif 1668 f467 - if bankswitch == 32 1669 f467 - ORG $8F94-bscode_length 1670 f467 - RORG $FF94-bscode_length 1671 f467 - endif 1672 f467 - if bankswitch == 64 1673 f467 - ORG $10F80-bscode_length 1674 f467 - RORG $1FF80-bscode_length 1675 f467 - endif 1676 f467 else 1677 ff9c ORG $FF9C 1678 ff9c endif 1679 ff9c endif As you can see you've set the romsize to 4K, so none of those statements are compiled (remember you can tell that by the "-" to the left of it, and the the current byte index is $F467, which will only increase if new bytes are added or an ORG is used). It's actually the "else" case at the bottom setting the origin to $FF9C. The idea of this particular origin is to push the score graphics to the end of the rom (as far as possible) to give the user as much free bytes as possible for their game program. In this case you can see you have bytes from $FF67 to $FF9B free to use. But at this point you are still using the particular scoregraphics.asm I gave you with some extra digits in it, so it will never fit with that origin. In fact to fix that you have to adjust the ORG $FF9C. If you wanted to add one digit (8 bytes tall) then: ORG $FF9C - 8 or two digits: ORG $FF9C - 16 or three: ORG $FF9C - 24 And so on. Of course I'm not sure why you are trying to do this with a 4K rom in the first place. Your old projects of course won't compile with that scoregraphics.asm, as they probably don't have any bytes to spare. Now you're probably wondering why it says you have 2869 bytes free. This is the bytes free between $F467 and $FF9C, which you can see in the list file. $F467 = 62567 (decimal), $FF9C = 65436 (decimal), and 65436 - 62567 = 2869 bytes free. These bytes occur before scoregraphics.asm, and not after. That's why we are subtracting the bytes we need from that origin. That origin statement is also found in scoregraphics.asm, so go there to change it if you ever need to do so for your projects. However, this will compile: set kernel DPC+ const splitscore_2_4 = 0 dim splitKernelVar = z const SPLIT_KERN_BIT = BIT_7 goto main bank2 bank 2 main scorecolors: $40 $42 $44 $46 $48 $4A $4C $4E end drawscreen goto main It works with additional scores right up until this point:.byte $00 ; | | $FF70.byte $7E ; | XXXXXX | $FF71 .byte $60 ; | XX | $FF72 .byte $60 ; | XX | $FF73 .byte $7C ; | XXXXX | $FF74 .byte $60 ; | XX | $FF75 .byte $60 ; | XX | $FF76 ; .byte $7E ; | XXXXXX | $FF77 ; .byte $00 ; | | $FF78 ; .byte $60 ; | XX | $FF79 ; .byte $60 ; | XX | $FF7A ; .byte $60 ; | XX | $FF7B ; .byte $7C ; | XXXXX | $FF7C ; .byte $60 ; | XX | $FF7D ; .byte $60 ; | XX | $FF7E ; .byte $7E ; | XXXXXX | $FF7F Any additional bytes cause it to crash during compilation. It only allows 7 out of 8 bytes of E. If I uncomment one more byte, I get: segment: 1fd4 eqm vs current org: 1fd5 free ram: 0 DPC free RAM= 603 -1 bytes of ROM space left in bank 1 B:\vBTest\New Project\default.bas.asm (1453): error: Origin Reverse-indexed. Errors were encountered during assembly. So at least I'm running out of ROM here before trouble arises. That doesn't really tell me much about why I get problems at other times, though. This also makes sense because you have too many bytes. Really though you don't need more than the "A" and "B". Unlike the other rom size options the DPC+ kernel doesn't use an ORG statement before the score graphics, so you can keep adding graphics provided you have the bytes. You don't need all the way up to "E", just add "A" and "B" and start building you code little bit by little bit to see if it works. Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted October 27, 2014 Share Posted October 27, 2014 Any luck with this? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted October 27, 2014 Author Share Posted October 27, 2014 (edited) Any luck with this? Sorry, I'll give it a try in a few days. I've been a bit occupied lately. Also, since what I've got is working and fiddling with all this stuff is frustrating (because the line between "works" and "doesn't work" seems entirely arbitrary), I'm not overly inclined to keep messing with it. I'll give it a try again in a few days. I just don't understand why this would reveal anything different. Either it's something wrong with my version of bB (which makes no sense to my mind) or it's a ROM boundary issue, unless there's some other probable cause that's not been mentioned, I'd say we have it narrowed down. Edited October 27, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted October 28, 2014 Share Posted October 28, 2014 I just don't understand why this would reveal anything different. We don't know exactly what is breaking, but building up your DPC+ rom with little bits of code should tell us where it starts going south. Split score is working, and I believe something small would be stopping 2 more digits being used. Before I forget to mention, a DPC+ game is 32K (32,768 bytes). If you are getting a black screen check the rom size first. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted October 30, 2014 Author Share Posted October 30, 2014 Found the problem. If I have set kernel_options collision(playfield,player1) ... Things won't work. If I remove it, having only 2 extra score digits is perfectly fine. Isn't that kernel option required to avoid some bug or something, though? 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 30, 2014 Share Posted October 30, 2014 Re: ^Above question. There was a bug in one of the official versions whereby it would mess up the screen if it wasn't used. That was fixed. But if you want the first Y coordinate of a specific collision, you still use that kernel option. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted October 30, 2014 Author Share Posted October 30, 2014 Hmm... Well, the ability to know the y-coordinate of a collision would be very convenient, though I can maybe make do without. Any idea why that kernel setting would be the cause of this issue? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted November 1, 2014 Share Posted November 1, 2014 There was a bug in one of the official versions whereby it would mess up the screen if it wasn't used. That was fixed. But if you want the first Y coordinate of a specific collision, you still use that kernel option. I wasn't sure, but I checked and that info is in the DPC+ collision detection section: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_collision_detection Is the NUSIZ0 problem mentioned in that section still true? Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 1, 2014 Share Posted November 1, 2014 Is the NUSIZ0 problem mentioned in that section still true? Yeah, its still an issue. We just don't have the free bytes left to enhance the soft-collision to support NUSIZ variations. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted November 1, 2014 Share Posted November 1, 2014 Not perfect but I'll take it. On the Sega Genesis side I can either detect that a collision happened (period) or resort to soft collision for potentially over 80 sprites. Ick. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted November 1, 2014 Author Share Posted November 1, 2014 (edited) Any insight on why setting kernel_options collision(player1,playfield) causes trouble with scores greater than 10 digits? Edited November 1, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
iesposta Posted November 1, 2014 Share Posted November 1, 2014 Any insight on why setting kernel_options collision(player1,playfield) causes trouble with scores greater than 10 digits?I, myself, couldn't say why that happens. I've seen other strange things. I have a subroutine that sets player0 colors and data. That is all it does. There is one spot where if I put a gosub to that it crashes real hardware. I have to duplicate the code in just that one spot. The other gosubs in the same bank work just fine. Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted November 1, 2014 Share Posted November 1, 2014 I have a few ideas. I did notice that when you enable that settings DPC_kernel_options starts getting compiled in and code is a little shifted. I'm taking a look but first I'm cleaning up the DPC+ source code as I can't follow it. The spacing is not consistent. So I'm cleaning it up and freeing cycles as I go. Then I will set up the compile options so that the number of bytes is always even whether it's compiled in or not. Next I double check the cycles, and make sure the page branching is all good. After that if the game is still malfunctioning it might be in the DPC+ code. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted November 1, 2014 Author Share Posted November 1, 2014 I have a few ideas. I did notice that when you enable that settings DPC_kernel_options starts getting compiled in and code is a little shifted. I'm taking a look but first I'm cleaning up the DPC+ source code as I can't follow it. The spacing is not consistent. So I'm cleaning it up and freeing cycles as I go. Then I will set up the compile options so that the number of bytes is always even whether it's compiled in or not. Next I double check the cycles, and make sure the page branching is all good. After that if the game is still malfunctioning it might be in the DPC+ code. Even if you can't find a solution to this bug, I hope you release that cleaned up DPC+! Every spare cycle/byte counts! Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted November 2, 2014 Share Posted November 2, 2014 Even if you can't find a solution to this bug, I hope you release that cleaned up DPC+! Every spare cycle/byte counts! Yes, I will. First I must kill this bug. I've identified the area where the bug is occurring. Actually I'm talking about the bug with this test rom here: frozen.bin In Stella 4.1.1 it is frozen. I can't test it on real hardware until late tonight or tomorrow as the TV is being used right now. If someone else can then please report your results. It does however to appear to be a legitimate problem though, and I will attempt to explain my understanding of it below. Basically it looks like a fast fetch register is getting tripped when it shouldn't, and the game takes a dive... You can follow the code is executing, and it reaches here: 590 1aa5 ae 84 02 ldx INTIM ; 68 timed for 192 lines 591 1aa8 f0 60 beq exitkernel ; 70/71 . . At this point FASTFETCH mode is on. When the branch does get taken it is a forward branch crossing a page boundary. Cycle by cycle, this is what is happening: Relative addressing (BCC, BCS, BNE, BEQ, BPL, BMI, BVC, BVS) # address R/W description --- --------- --- --------------------------------------------- 1 PC R fetch opcode, increment PC $F0, $1AA8 --> $1AA9 2 PC R fetch operand, increment PC $60, $1AA9 --> $1AAA 3 PC R Fetch opcode of next instruction, $85, $1AAA --> $1A0A (NOT $1B0A, as PCH not fixed) If branch is taken, add operand to PCL. Otherwise increment PC. 4+ PC* R Fetch opcode of next instruction. $A9, $1A0A --> $1B0A (fetching LDA# IMM)!! Fix PCH. If it did not change, increment PC. 5! PC R Fetch opcode of next instruction, $20, $1B0A --> $1B0B increment PC. Notes: The opcode fetch of the next instruction is included to this diagram for illustration purposes. When determining real execution times, remember to subtract the last cycle. * The high byte of Program Counter (PCH) may be invalid at this time, i.e. it may be smaller or bigger by $100. + If branch is taken, this cycle will be executed. ! If branch occurs to different page, this cycle will be executed. . . That branch initially grabbed the LDA# opcode from the address below. This will cause corruption in DPC+ while fast fetch is on. 494 1a0a a9 08 lda #<(P0COLOR) 495 1a0c 8d 50 10 sta DF0LOW . . In Stella the code continues and does branch to $1B0A, and the next instruction is JSR $5E9B (which is JSR $1E9B+$4000 in the code for some reason). When it jumps to that subroutine it actually goes to the Break routine at $1FD4 and starts resetting the game. So the game only plays the 1 frame before breaking and starting over. The game appears frozen because the same start to the game is drawn over and over. Here is the list file if anyone wants to look further, but I think this is the problem. frozen.list.txt If this is the problem then we should be able to build macros that will check for this and break the rom during compiling. It would spit out an error message that the user might not understand, but at that point they will at least be able to ask for help with said error message, and not be banging their head on the keyboard for a few hours. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted November 2, 2014 Author Share Posted November 2, 2014 I just tested both frozen.bin and my own bugged game on real hardware--they both work fine. I didn't notice any strangeness whatsoever: no rolling, tearing, strange sounds, or any evidence of the game being caught in any loop. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 2, 2014 Share Posted November 2, 2014 If this is the problem then we should be able to build macros that will check for this and break the rom during compiling. It would spit out an error message that the user might not understand, but at that point they will at least be able to ask for help with said error message, and not be banging their head on the keyboard for a few hours. Ran into similar problems with Stay Frosty 2 and certain revisions of the 7800. My 7800 is one of the problem revisions. I wrote a short program that would scan the listing from DASM to for problems. I was able to fix all the crashes I encountered. Additional checks could easily be added to it. evil7800.zip Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted November 8, 2014 Share Posted November 8, 2014 I didn't do much Atari during the week, but here is the current progress. I have a DPCplus_kernel.asm and score_graphics.asm file in the zip below. Ideally the user should be able to replace their files with these and they will work for DPC+ and non-DPC+ BB games (I.e. the score_graphics.asm file won't screw up other files). Omega_DPCplusBB.zip You should also be able to build regular DPC+ games without issue. If there are any incompatibilities I would like to hear about them. So far the main trouble seems to have been emulation. I'm waiting for Darrell to get back to me next week with some tests to know for sure... so no bug report yet. I did find another issue besides the one I posted. Stella didn't seem to like $A9 being the low byte in the operand of a JMP address. I still have to test that on real hardware too. The good news now. You can have an extra six digits worth of graphics for DPC+ at any time. I have simply left place holders for these graphics as A-F in the score_graphics.asm file. There was no cost for this as I was able to cut out lots of bytes and there was enough space for the extra six digits as well as any kernel options. The new DPCplus_kernel also offers split score and centred score at no cost. I have gone through and cleaned up the code quite a bit, but it still would more work to make uniform to the rest of BB. I'm probably not going to do that. Here's how you use everything as it is: Extra Graphics For extra graphics A-F (you can modify these and make a "Game Over" display for example): 1) Put " const DPC_EXTRA_DIGITS = 1" at the top of your .bas file. All capital letters and underscores are important. 2) Dim some new names for each score byte, "dim sc1 = score", "dim sc2 = score+1", "dim sc3 = score+2" 3) Above "drawscreen" set the digits you want: sc1 = $AB sc2 = $CD sc3 = $EF drawscreen This displays A,B,C,D,E, and F in the score display. If you do have a score you want to keep intact, then you need to copy that score before you overwrite it with these extra digits. Afterwards copy the score back (do this right after main). I haven't actually tried this yet, but in theory it should be that easy. I'm hoping someone will try this for me. You should now be able to toggle between the final score and "game over" with this method Split Score You can toggle between a split 2_4 score and a centred score at any time. What is required is one bit to be set when you want split score, and cleared when you want centred score. You get decide what bit of what variable you want to use:) 1) Use " const splitscore_2_4 = 1". Punctuation is important. 2) Choose which bit to use in that variable. You set the bit with some predefined values, BIT_0, BIT_1, BIT_2, etc... all the way up to BIT_7. Punctuation and underscores are important. Here I use bit 7: " const SPLIT_KERN_BIT = BIT_7". 3) Choose a variable to use with splitKernelVar. Punctuation is important. Here I use variable z: " dim splitKernelVar = z". Summary: const splitscore_2_4 = 1 const SPLIT_KERN_BIT = BIT_7 dim splitKernelVar = z Finally To turn it on in game: rem Turn split screen ON during game. temp1 = #BIT_7 splitKernelVar = splitKernelVar | temp1 And to turn it off during the game (make a centred score) rem Turn split screen OFF during game. temp1 = #BIT_7 temp1 = temp1 ^ $FF splitKernelVar = splitKernelVar & temp1 Note the # is really important here otherwise BB will make BIT_7 as zeropage (not LDA #imm), and that there are better ways to do above examples. These were just the first thing I had going where BB didn't throw a "complex statement detected" or try to make the immediate load a zeropage load. A zeropage load here will cause hard to find bugs later. I bet BB will have something built in to set/clear bits, but I didn't check. 3 Quote Link to comment Share on other sites More sharing options...
+Omegamatrix Posted November 8, 2014 Share Posted November 8, 2014 I said above that you have to modify the score before drawscreen and right after main. Looking at the code some more I think it really is just before and after drawscreen. You only need to do this if you are switching between extra graphics and a regular score. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted November 8, 2014 Author Share Posted November 8, 2014 Just tested on Stella and on real hardware. I can confirm it works! I didn't see anything amiss, nor did I really modify my code, aside from adding the DPC_EXTRA_DIGITS const. I'll keep the warnings in mind as I move forward. Thanks much, Omega! Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 26, 2020 Share Posted January 26, 2020 On 11/7/2014 at 11:38 PM, Omegamatrix said: The good news now. You can have an extra six digits worth of graphics for DPC+ at any time. I have simply left place holders for these graphics as A-F in the score_graphics.asm file. There was no cost for this as I was able to cut out lots of bytes and there was enough space for the extra six digits as well as any kernel options. The new DPCplus_kernel also offers split score and centred score at no cost. I have gone through and cleaned up the code quite a bit, but it still would more work to make uniform to the rest of BB. I'm probably not going to do that. When I load score_graphics.asm into the VbB score editor, A through F are listed, but when I go to select any of them, VbB spits out an error. Do you know of a way to edit those extra characters besides loading the score_graphics.asm file into a text editor? Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted January 26, 2020 Share Posted January 26, 2020 36 minutes ago, Random Terrain said: When I load score_graphics.asm into the VbB score editor, A through F are listed, but when I go to select any of them, VbB spits out an error. Do you know of a way to edit those extra characters besides loading the score_graphics.asm file into a text editor? I also had trouble with the score editor, so I just changed it in notepad. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.