RevEng Posted February 16, 2011 Share Posted February 16, 2011 @RevEng: Thanks for posting gotchas and workarounds! Tempted to get my feet wet again (in bB programming). Definitely helps to know what the beta is capable and not capable of. No problem. I'm also trying to make it easier for batari to squash the bugs, so it's self-interest too. One more issue for the running list... setting COLUPF or pfcolors doesn't work. It looks like this is getting fetched from DPC in the kernel, but maybe the setup isn't working? (workaround by enjoying the color yellow) collision()s never clear, because the DPC kernel isn't hitting CXCLR up front like the other kernels. (workaround by adding a "CXCLR=1" prior to your drawscreen, or after your collision detections.) You can't call drawscreen from another bank when using the DPC kernel, due to the DPC setup using a plain jsr. (workaround by creating a drawscreen wrapper function in bank1, and use "gosub drawwrapper bank1" instead of a drawscreen) player0x=0, ballx=0, etc. all position the objects on the right-hand side of the screen. (workaround... no trivial one. All coordinate comparisons will need to take this into account, and then updated when this bug is fixed.) Quote Link to comment Share on other sites More sharing options...
+batari Posted February 19, 2011 Author Share Posted February 19, 2011 player0x=0, ballx=0, etc. all position the objects on the right-hand side of the screen. (workaround... no trivial one. All coordinate comparisons will need to take this into account, and then updated when this bug is fixed.) I'm torn on this one. The horizontal positioning routine uses cycle 73/74 HMOVEs which means the players will appear 8 pixels to the left of where they do in other kernels. A fix is to adjust all X coordinates in a big loop before the kernel and unadjust them after the kernel (and indeed the multisprite kernel does this.) Or, just say this is an artifact of the DPC+ kernel and leave it alone. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 19, 2011 Share Posted February 19, 2011 Does it need to? In "Chun-Li" the initial positioning uses the traditional sprite positioning with the HMOVE after WSYNC while all mid-screen repositioning uses cycle 73/74 HMOVES. It's configured to use the same X values for both routines and no adjustments are being done to X. Quote Link to comment Share on other sites More sharing options...
+batari Posted February 19, 2011 Author Share Posted February 19, 2011 I think I had a reason, but it could be simply because one of the multiplexed sprites was positioned offscreen while the others were onscreen and they could also share some data tables. Maybe just adjusting that one sprite would be enough, coupled with a bit of data replicating. Quote Link to comment Share on other sites More sharing options...
diogoandrei Posted February 24, 2011 Share Posted February 24, 2011 Just wondering... any chance for the new batari to natively support keypads? Quote Link to comment Share on other sites More sharing options...
+batari Posted February 24, 2011 Author Share Posted February 24, 2011 You mean keyboard controllers? Then probably not. There are some special challenges to reading them. They must be read one row at a time, and you need to delay for 480 cycles before reading each row. The timing is a real pain because it's short enough and requires enough accuracy such that it would be hard to put just enough useful work in between rows since bB abstracts the timing away from the programmer. Also, you can't just delay for the entire time as together the delays are long enough to take up nearly all of the time between frames so very little time would be available for code. Quote Link to comment Share on other sites More sharing options...
Pioneer4x4 Posted February 25, 2011 Share Posted February 25, 2011 Holy crap, THANKS!!!! I need to get back into this. What I wanted to do might be possible (for me, I'm sure others could easily) I needed several different semi-static sprites, and couldn't figure out how to do it. Now I don't need to! Quote Link to comment Share on other sites More sharing options...
Pioneer4x4 Posted February 25, 2011 Share Posted February 25, 2011 I also wanted to add a note about backups. (partially Atari related) My primary reason for backing up is personal digital photos. I have taken about 10,000 over the years, mainly my family. I CANNOT lose them. I used to use my old pc as a backup site. I would use robocopy scripts to make a file structure mirror my main PC. I did not have it automatically run. To me that is useless, say you delete/alter a file, then it gets backed up. You lose the previous version without even knowing it, even backed up. (maybe not if using incrementals and you can select when you want the restored file from...) I recently got a 2TB external Seagate for $89 at Wal-mart! I like that idea better, then if there is a fire or other reason for quick snatch (FBI, Family member with a sledge hammer...) you can just grab the 2tb and run. Also, to FORCE myself to backup. When I import pictures, I import to the backup drive, not my PC. Then I use a script to copy to my PC for viewing/editing. So I have to have them in 2 places before I even look at them. Lastly, Microsoft Mesh! You need Vista or 7, and install the Live software. You get 5GB of online storage, and it automatically updates. I keep current year photos there, as well as my Atari folder (lists, scans, code in progress, database...) It will even keep the data synched between multiple computers, and you can grant other Live members access to specific folders. That way I don't have to worry about my wife asking "Can you send me the pictures from the kids birthday, she can get them herself from anywhere. Quote Link to comment Share on other sites More sharing options...
diogoandrei Posted February 26, 2011 Share Posted February 26, 2011 You mean keyboard controllers? Then probably not. There are some special challenges to reading them. They must be read one row at a time, and you need to delay for 480 cycles before reading each row. The timing is a real pain because it's short enough and requires enough accuracy such that it would be hard to put just enough useful work in between rows since bB abstracts the timing away from the programmer. Also, you can't just delay for the entire time as together the delays are long enough to take up nearly all of the time between frames so very little time would be available for code. Oh, I didn't know things were that complicating when it comes to reading the keyboard controllers. But it was just more of a curiosity for me, keep rocking the new batari Quote Link to comment Share on other sites More sharing options...
+batari Posted March 6, 2011 Author Share Posted March 6, 2011 I posted a new build of the beta version to my blog: http://www.atariage.com/forums/index.php?app=blog&module=display§ion=blog&blogid=134& It doesn't have DASM - use your existing dasm.exe for this. 2 Quote Link to comment Share on other sites More sharing options...
jwierer Posted March 6, 2011 Share Posted March 6, 2011 Can you only have one C-style multiline comment block with /* and */? Seems like if I have more than one it won't compile. -Jeff Quote Link to comment Share on other sites More sharing options...
+batari Posted March 6, 2011 Author Share Posted March 6, 2011 (edited) Can you only have one C-style multiline comment block with /* and */? Seems like if I have more than one it won't compile. -Jeff Bugs are coming out already Looks like multiline comments currently cannot precede a label. If they precede anything else, they seem to work fine. EDIT: Found another workaround - start the /* at the beginning of the line. I've already fixed it on my end. Keep the bug reports coming. Edited March 6, 2011 by batari Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2011 Share Posted March 6, 2011 ...Keep the bug reports coming. Ok, you asked for it. The first byte of PF data on the screen isn't aligned with the other bytes. I took the sample program and changed the PF data to horizontal lines to illustrate... Quote Link to comment Share on other sites More sharing options...
+batari Posted March 6, 2011 Author Share Posted March 6, 2011 ...Keep the bug reports coming. Ok, you asked for it. The first byte of PF data on the screen isn't aligned with the other bytes. I took the sample program and changed the PF data to horizontal lines to illustrate... Fixed. Any more bugs? Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted March 6, 2011 Share Posted March 6, 2011 (edited) Silly question, but I just want to verify that my copy of Stella is working right. I took the version in the link about the new bB and replaced the files I already had. Anyway, when I run the sample program msdpc.bin here's what it looks like: Also, if I move my mouse across the playfield it moves the number 1 and messes with the foreground. I don't know if it's just me or not. Edited March 6, 2011 by jbs30000 Quote Link to comment Share on other sites More sharing options...
+batari Posted March 6, 2011 Author Share Posted March 6, 2011 Silly question, but I just want to verify that my copy of Stella is working right. I took the version in the link about the new bB and replaced the files I already had. Anyway, when I run the sample program msdpc.bin here's what it looks like: Also, if I move my mouse across the playfield it moves the number 1 and messes with the foreground. I don't know if it's just me or not. For some reason, the mouse in Stella moves both joysticks at the same time. Either use the keyboard, or change the settings in Stella to use a single joystick. To change the number you want to move, press the left joystick button. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted March 6, 2011 Share Posted March 6, 2011 Oh yeah, I already figured out that pressing the fire button changed which number to move. I was just confused about the mouse because I thought it was set to emulate a paddle, not the joysticks. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2011 Share Posted March 6, 2011 Fixed. Any more bugs? Nothing so far! Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 6, 2011 Share Posted March 6, 2011 (edited) For some reason, the mouse in Stella moves both joysticks at the same time. Either use the keyboard, or change the settings in Stella to use a single joystick. Yeah, that's annoying. You can fix that by unchecking the bottom option on this screen. TAB -> INPUT SETTINGS -> DEVICES & PORTS Edited March 6, 2011 by SpiceWare Quote Link to comment Share on other sites More sharing options...
jwierer Posted March 7, 2011 Share Posted March 7, 2011 Here is a sample music file using sdata. Compiles using previous releases, but not the current 1.1 beta. I get this error: DASM V2.20.07, Macro Assembler (C)1988-2003 music_little_lamb.bas.asm (1920): error: Illegal Addressing mode 'sta '. --> _begin f500 music_little_lamb.bas.asm (1923): error: Syntax Error ''. music_little_lamb.bas.asm (1923): error: Illegal Addressing mode 'sta +1'. Errors were encountered during assembly. music_little_lamb.bas -Jeff Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 7, 2011 Share Posted March 7, 2011 It looks to be happier if you add spaces... "sdata musicData = x" Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted March 7, 2011 Share Posted March 7, 2011 (edited) Thank you SpiceWare. That is an improvement. Edited March 7, 2011 by jbs30000 Quote Link to comment Share on other sites More sharing options...
+batari Posted March 7, 2011 Author Share Posted March 7, 2011 Here is a sample music file using sdata. Compiles using previous releases, but not the current 1.1 beta. I get this error: DASM V2.20.07, Macro Assembler (C)1988-2003 music_little_lamb.bas.asm (1920): error: Illegal Addressing mode 'sta '. --> _begin f500 music_little_lamb.bas.asm (1923): error: Syntax Error ''. music_little_lamb.bas.asm (1923): error: Illegal Addressing mode 'sta +1'. Errors were encountered during assembly. music_little_lamb.bas -Jeff This was an attempt to fix an outstanding bug in sdata (others reported different issues with it) and in doing so I added another bug. Anyway, it's fixed now. 1 Quote Link to comment Share on other sites More sharing options...
jwierer Posted March 7, 2011 Share Posted March 7, 2011 It looks to be happier if you add spaces... "sdata musicData = x" Thanks! That fixes the problem, though it still seems like a bug since it previously worked as-is. -Jeff Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 7, 2011 Share Posted March 7, 2011 Fred, have you fixed the less than 312 scanlines PAL50 problem with player1colors enabled? 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.