orange808 Posted September 15, 2018 Share Posted September 15, 2018 I have a fresh install of bB and Visual Basic on this Win 10 machine (no previous installations to pollute my registry). I followed the instructions. I have the latest versions. I am familar with coding and Windows. The environment variables aren't an alien concept and they are right. Running as admin. So, when I look at the DPC+ examples, they run well enough. But, if I add a set romsize command, they all break. I tried multiple examples. I can change the romsize on Tinkernut all I want. Any suggestions? Quote Link to comment Share on other sites More sharing options...
orange808 Posted September 15, 2018 Share Posted September 15, 2018 Also, will add that this is an Intel x64 machine. Not an AMD or the new ARM x86 Windows emulation. Not an exotic environment. Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 15, 2018 Share Posted September 15, 2018 bB DPC+ is only 32k. You can't change the romsize. Quote Link to comment Share on other sites More sharing options...
orange808 Posted September 15, 2018 Share Posted September 15, 2018 (edited) bB DPC+ is only 32k. You can't change the romsize. Fair enough. I found the documentation to be somewhat ambiguous about this. It declares that the romsize is automatically set for you, but I didn't understand that sentence was implying that the romsize could not be changed at all. How about the multikernel framework with multiple DPC+ 32k parts? Edit: Apologies. Answered my own question. That won't work. The DPC+ kernel alone is too big to fit inside "containers" of 4k. Edited September 15, 2018 by orange808 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 16, 2018 Share Posted September 16, 2018 Be sure to refresh the bB page. Quote Link to comment Share on other sites More sharing options...
bogax Posted October 2, 2018 Share Posted October 2, 2018 Not really a bug I am frequently frustrated by having constant macro parameters treated as immediate values. Not really sure how to deal with that. How hard would it be to perhaps escape a constant to suppress emission of the "#" ? (best I could think of) Quote Link to comment Share on other sites More sharing options...
+Karl G Posted December 3, 2018 Share Posted December 3, 2018 There is a display problem with the rightmost digit of the score that can be exposed with a wide enough score font that I've reproduced on Stella and real hardware. Here's a simple example with the "husky" font with the score = 100. The problem goes away if the player objects are positioned one more pixel to the right (HMP0 = #$D0 and HMP1 = #$E0). husky.bas score_graphics.asm husky.bas.bin 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted December 5, 2018 Share Posted December 5, 2018 Is there a way to get rid of the "waterfall effect" when using colored sprites and a colored playfield in the standard kernel? If it were static I wouldn't mind, but it moves and ripples as the player objects move. Quote Link to comment Share on other sites More sharing options...
iesposta Posted December 5, 2018 Share Posted December 5, 2018 Request: This optimization I do that the bB compile passes should. It is faster assembly and uses less ROM. Can the compile stage find (between anything more complex than “=“) and put all the same value variables together regardless if they are on one line or four, and output more efficient & ROM saving assembly like this? This: Player0x=0: r=0 s=0 t=0 Compiles to this: lda #0sta Player0xsta rsta ssta t ——— And this same thing:Player0x=0r=0s=0t=0 Compiles to this:lda #0sta Player0xlda #0sta rlda #0sta slda #0sta t Another example is this one line compiles more efficiently over one value each line: DF0FRACINC=255: DF1FRACINC=255: DF2FRACINC=255: DF3FRACINC=255: DF4FRACINC=255 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 17, 2019 Share Posted February 17, 2019 The multisprite kernel seems to have a problem with the "noscore" option - the timing seems to be off when the score is disabled. I confirmed this with a simple program that just does a drawscreen loop as well as the 9 objects example on RT's site. multi.bas multi.bas.bin I have a fix for this issue. The problem happens because a "rts" is skipped when "noscore" is enabled. The original code for noscore in the Multisprite kernel is this: ifconst noscore jmp skipscore endif I've changed it as follows, which fixes the issue: ifconst noscore pla pla jmp skipscore endif Here's a patched version of the kernel for those who need the fix in the meantime: multisprite_kernel.asm 2 Quote Link to comment Share on other sites More sharing options...
Sknarp Posted July 27, 2019 Share Posted July 27, 2019 My apologies if this has been mentioned already, but I couldn't find anything in the search. inline ASM throws some warnings- "asm is not a recognized keyword" and more frustratingly "end is a duplicate label definition" if you use more than one block of inline asm, the latter has an annoying tendancy to pop up every time I write any line of code, anywhere in the program, which constantly snaps the window around to focus on where the warning is being generated from. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 27, 2019 Share Posted July 27, 2019 40 minutes ago, Sknarp said: My apologies if this has been mentioned already, but I couldn't find anything in the search. inline ASM throws some warnings- "asm is not a recognized keyword" and more frustratingly "end is a duplicate label definition" if you use more than one block of inline asm, the latter has an annoying tendancy to pop up every time I write any line of code, anywhere in the program, which constantly snaps the window around to focus on where the warning is being generated from. Are you using the latest version of VbB? https://atariage.com/forums/topic/123849-visual-bb-10-a-new-ide-for-batari-basic/?do=findComment&comment=3537039 1 Quote Link to comment Share on other sites More sharing options...
Sknarp Posted July 27, 2019 Share Posted July 27, 2019 No, apparently I have Build 566, I'll have to update. Thank you RT 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted September 10, 2019 Share Posted September 10, 2019 In Batari Basic, the if !x= statements don't seem to work for me at all. Perhaps I am doing somethhing wrong? I.e. when I write: ------------------------------------------- x=2 if !x=1 then COLUBK=Rand ------------------------------------------- Shouldn't this make the background color change? I could replace "COLUBK" with a goto statement and it still won't go anywhere. "if not" statements seem to be broken/utterly useless.. or am I writing them wrong? Please help. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 10, 2019 Share Posted September 10, 2019 Just now, freshbrood said: In Batari Basic, the if !x= statements don't seem to work for me at all. Perhaps I am doing somethhing wrong? I.e. when I write: ------------------------------------------- x=2 if !x=1 then COLUBK=Rand ------------------------------------------- Shouldn't this make the background color change? I could replace "COLUBK" with a goto statement and it still won't go anywhere. "if not" statements seem to be broken/utterly useless.. or am I writing them wrong? Please help. Yep, you're doing it wrong: https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#boolean https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#if Does "!x=1" work using any programming language? What are you wanting x to be equal to for something to happen? Quote Link to comment Share on other sites More sharing options...
freshbrood Posted September 10, 2019 Share Posted September 10, 2019 (edited) "The not-equal-to operator (!=) is not valid bB syntax. It does not work with batari Basic." Is there another way to say "if x is not equal to"? *Edit: My originial post was a typo. I meant to say if x!= Anyway.. If x<2||x>2 then goto.. seems to work. Same effect. Just uses a bit more memory than I'd like. Oh well. Thank you RT Edited September 10, 2019 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 10, 2019 Share Posted September 10, 2019 35 minutes ago, freshbrood said: Anyway.. If x<2 || x>2 then goto.. seems to work. Same effect. Just uses a bit more memory than I'd like. Oh well. If I'm reading that correctly, seems like you'd want to use "If x <> 2 then". 2 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted January 9, 2020 Share Posted January 9, 2020 (edited) On 6/11/2018 at 1:26 AM, Random Terrain said: Since I was already in the middle of it, I'm doing my own fix up of your program and I've come across more than one place where you use OR twice in the same if-then. That is not allowed according to the bB page in the Did You Know box. You are allowed only one OR for each if…then statement. This is an interersting design limitation in the BASIC RT, I'm curious because there is a similar but different design limitation with if's in SuperCharger BASIC - In bB this has to be two statements - if e=3 or f=8 or g=9 then goto myroutine SuperCharger BASIC allows multiple or's to be in one if statement like that, but you cannot mix or and and in an if statement, I imagine bB would have a similar limitation mixing them if it can only have one or per line. Edited January 9, 2020 by Mr SQL left out an or Quote Link to comment Share on other sites More sharing options...
Sknarp Posted January 12, 2020 Share Posted January 12, 2020 The Multisprite Kernel could use a little love, I can't say for sure that it is the Kernel or the emulator the Atari flashback uses but any game using it doesnt work 100% correctly- I even made a 4k game and with the stock MSK there is still an alignment issue. Everyone including myself thought it was because of my modifications but yeah it happens with a stock MSK. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted January 12, 2020 Share Posted January 12, 2020 It's definitely the limited emulator in the AFP that causes issues with the Multisprite kernel, and is not a bug in the Multisprite kernel code. The Multisprite kernel uses a technique called an early HMOVE to position the sprites, which hides the black lines on the left side of the screen that you see in many Atari games, but the AFP does not render it correctly. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 22, 2020 Share Posted January 22, 2020 8 hours ago, TwentySixHundred said: Just wondering if anyone else is have issues setting score fonts after the 1.2 update? It's throwing me this compile error segment: 1864 eqm vs current org: 1894 free ram: 0 DPC free RAM= 603 score_graphics.asm.retroputer (3): error: Origin Reverse-indexed. Errors were encountered during assembly. Thanks for the report @TwentySixHundred. Looks like I introduced a bug with the hex font addition. It's fixed in the github master. I've attached the fixed score_graphics.asm here, in case anybody needs it. I'll do an official github release in a week or two, to allow other issues to be reported and fixed. score_graphics.asm 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted January 22, 2020 Share Posted January 22, 2020 15 minutes ago, RevEng said: Thanks for the report @TwentySixHundred. Looks like I introduced a bug with the hex font addition. It's fixed in the github master. I've attached the fixed score_graphics.asm here, in case anybody needs it. I'll do an official github release in a week or two, to allow other issues to be reported and fixed. score_graphics.asm 4.24 kB · 2 downloads Thanks for the prompt fix ? 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted February 13, 2020 Share Posted February 13, 2020 Hi guys it was brought to my attention by @sramirez2008 and @Karl G that my game is crashing with this error message. After having a quick search on AA i have noticed this thread but there was no solution as to what actually was the issue. Does anyone know Is it was bB DPC+ bug or Stella or coder error? The crash also happened real hardware using the harmony cart so im assuming it's nothing on the Stella side of things. Before i left the house i enabled the Dev settings and sure enough it did the same. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 13, 2020 Share Posted February 13, 2020 My best guess without source, is that you're indirectly feeding the DPC÷ ARM bad data. Have you stepped on DPC memory,, directly written to arm queues, or otherwise done any under the hood access? Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted February 13, 2020 Share Posted February 13, 2020 9 minutes ago, RevEng said: My best guess without source, is that you're indirectly feeding the DPC÷ ARM bad data. Have you stepped on DPC memory,, directly written to arm queues, or otherwise done any under the hood access? Nothing that i know of other then collision detection with playfield and my fake "collision detection" when the warheads hit the ground. This led me to think the sub routine after was causing it. Sure enough i comment out a line and it works as "normal" however it will then crash at random without even executing the troublesome code. It's a strange one that's for sure, i have sent you a DM 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.