+Atarius Maximus Posted March 16, 2013 Share Posted March 16, 2013 You sound technically savvy, Cybearg. Back up our stuff and install a fresh copy of Windows. Pending that you can fudge it by running bB in XP compatibility mode which is really a virtual machine. Either way guarantees zero software corruption from the previous install. This could be the first telltale sign your OS is going south. I was thiking the same thing. You could get the free VMWare player and install a VM OS image that you could easily find by searching google. Of course, if you have a copy of Windows 7 that's not the home edition you can install XP mode as loon suggested. Reinstalling from scratch is painful, and I'm sure you'd rather find the root cause of the problem, but figuring out what your issue is seems rather elusive to everyone here so far. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 19, 2013 Author Share Posted March 19, 2013 Just to let folks know, I have the same issues, but I have been using Windows XP in VMware Player for my DPC+ stuff now. At least it's something. It's a bit slow, but Windows 7's XP Mode built-in VM is much, much slower. Too slow to run Stella properly. On a side note, that repo statement apparently relates to this, which I found in the .lst file, though I don't know what caused it or how to fix it: 461 1aab getbackearly 462 1aab a9 18 lda #<DF0FRACDATA 463 1aad 85 0e sta PF1 ; 69 (PF1L) too early? 464 1aaf 4c 39 5a JMP loop+$4000 ; 72 465 1ab2 466 1ab2 ifconst DPC_kernel_options 467 1ab2 COLfound 468 1ab2 ad 18 10 lda DF0FRACDATA 469 1ab5 85 0e sta PF1 ; 69 (PF1L) too early? 470 1ab7 4c 39 5a JMP loop+$4000 ; 72 471 1aba endif 472 1aba omega.bas.asm (473): error: Label mismatch... --> repo 1ab2 473 1aba repo 474 1aba ac 1f 10 ldy DF7FRACDATA ; 65 475 1abd a9 18 lda #<DF0FRACDATA ; 67 preload PF1L for next line 476 1abf - if ((>repo) > (>norepo)) 477 1abf - STA PF1 478 1abf else 479 1abf 8d 0e 00 STA.w PF1 ; 71 ; sta.w if page doesn't wrap 480 1ac2 endif Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2013 Share Posted March 19, 2013 Yeah, the "error: Label mismatch" means that rom before the problem label shifted between passes. In this case its probably the conditional "ifconst DPC_kernel_options" block. I'm at a loss as to why it's happening though. I can't reproduce it, and the dasm I'm using in Linux is usually very sensitive to rom shift. Is the 1.1d bB directory is before any other bB directories in the PATH variable? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 19, 2013 Author Share Posted March 19, 2013 It's the only bB directory that I have on my computer. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2013 Share Posted March 19, 2013 Try rem'ing your "set kernel_options collision" line and see if there's a difference. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 19, 2013 Author Share Posted March 19, 2013 (edited) Try rem'ing your "set kernel_options collision" line and see if there's a difference. That fixes the repo error, though without that line, the image I get is a skewed mess. Edited March 19, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2013 Share Posted March 19, 2013 The garbled mess is a known bug with bB 1.1d, which I reported a little while back. What your successful compile means is that you're having an issue with dasm+bB and shifting rom, instead of vbb. If you can compile on your other computers you should compare the dasm version there. (and make sure you don't have another dasm located earlier in your PATH) If you just want to work around this, you can copy the stock DPCplus_kernel.asm over to your project directory and comment out the "ifconst DPC_kernel_options" and "endif" right before the repo line. (if you ever change to not using the collision option, you'll need to undo this) Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 19, 2013 Author Share Posted March 19, 2013 If you just want to work around this, you can copy the stock DPCplus_kernel.asm over to your project directory and comment out the "ifconst DPC_kernel_options" and "endif" right before the repo line. (if you ever change to not using the collision option, you'll need to undo this) The stock DPCplus_kernel.asm? Is there another version that will be incompatible? So if I make this change, that'll fix the problem I've been having this whole time, but it will require the continued reliance on the kernel_option line, so if DPC+ ever gets fixed, I'll have to un-comment it again? Is that what you mean? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2013 Share Posted March 19, 2013 By stock, I mean the official one in your includes directory. If you copy it into the folder with your omega.bas file, bB will use it instead of the one in the includes directory whenever you build omega.bas. If you use different directories for other basic files, it won't affect them. You'll only need to ditch the DPCplus_kernel.asm in the directory with omega.bas when batari has fixed things or if you decide not to use "set kernel_options collision" for that game. But it would be better if you confirmed that your dasm is the same as your PCs/VMs without the compile issue. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 19, 2013 Author Share Posted March 19, 2013 It's the same DASM. I copied the same directories to my VM and it worked fine. It's the 2003 version that you see commonly included with the bB files. I'm not using the newer 2008 version. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2013 Share Posted March 19, 2013 Weird. Are both of your OSes the same bit version? ie. 32bit or 64bit? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 19, 2013 Author Share Posted March 19, 2013 Weird. Are both of your OSes the same bit version? ie. 32bit or 64bit? No, my main one is 64-bit Windows 7 but I'm emulating a 32-bit Windows XP Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 20, 2013 Share Posted March 20, 2013 Ok. Not really sure if that's significant or not. It's a difference, but I haven't heard of runtime quirks between 32-bit/64-bit before. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 20, 2013 Share Posted March 20, 2013 I'm not running BB, but I am running Win7 64 bit with DASM. I compared my copy of DASM to the one in BB, the one from a "bBWin7_64bit" folder. I don't know where I got that from as BB is stored in a lot of places! Anyhow, the versions are different according to clonespy. You can try it out and see if it helps. It is likely an older version then the BB one. Be careful not to mix them up now! dasm.zip Still, this all seems like it is barking up the wrong tree. If it was working before, then what made it broken now? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 20, 2013 Author Share Posted March 20, 2013 Still, this all seems like it is barking up the wrong tree. If it was working before, then what made it broken now? Beats me. It's rough because I didn't change anything--I just got a random crash and since then, no DPC+ stuff will compile, even though I've replaced essentially everything with confirmed working versions. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 20, 2013 Share Posted March 20, 2013 Try the DASM I posted, and see if that helps. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 20, 2013 Author Share Posted March 20, 2013 (edited) No difference. It's the same version as the one I've already got. The DPC+ games DO compile, mind you, but the result is colorful, garbled mess on screen and a screetching noise. omega.bas.bin omega.bas.asm oldkernel.bas.lst.txt Edited March 20, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 20, 2013 Share Posted March 20, 2013 No difference. It's the same version as the one I've already got. The DPC+ games DO compile, mind you, but the result is colorful, garbled mess on screen and a screetching noise. Seems like status quo for an Atari 2600 game. Should we close this topic now? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 20, 2013 Share Posted March 20, 2013 If the DPC bin isn't 32K, it didn't compile fully. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.