ScumSoft

For the last few days I've been getting erroneous errors, for instance the latest: EggVentureNTSC.bas.asm (10549): error: Illegal character ':'. However the error is not on this line but somewhere above it. I've quintuple checked for out of place colons, and found none. The error seem to be related to whitespace, and/or comments. As removing them or adding/subtracting blank lines also let it then compile. I just now added some more legit code such as: temp1 = temp1 and BZZZZZZ! it breaks again, so something is causing it to be VERY temperamental as of late. I've been reworking the entire game, making changes little by little to ensure I wasn't breaking things along the way and this seems to crop up out of nowhere. Any encounters with this issue before? any ideas what might be going on? It compiles once white space is added or removed on random lines it seems... VERY strange issue.

No mod needed, just tell your code to check for both being pressed like this: if joy0up && joy0down then goDosomething

DPC chip was originally used in Pitfall2 and acts as a co-processor. Only Stella currently has support for this chips operations. And in short it allows more things to happen on screen than normally possible while also adding more memory. [edit]Clarification, the DPC+ is redesigned by Fred Quimby(batari) for the Harmony cart, and takes the features a step further. The game can be played on the Harmony/Melody(hardware) carts as well as Stella(emulator) which currently has moderate DPC+ support.

You have to use Stella 3.4.1 since it's a DPC+ game @Byte Knight, you can't really solve the flicker on the virutal players, once they are within 5 scanlines of each other they will flicker. The flicker get's increased by half the more virtual players are around the same scanline. You can reduce the flicker though by using player0 and player1 for the dragon, and a virtual sprite for the player. Unless the player is within 5 scanlines of the dragon, the dragon shouldn't flicker at all.

Wait...Are you reading through every topic?

Seems like it would be an interesting game, look forward to the finished result!

Well that's the problem with tackling bugs that were already fixed I'm very pleased with the quickness of bug squishing, carry on.

GASP! It's fixed, now all my EggVenture bugs on the Harmony cart are gone! Tis a fine day for feeling good. Thanks for looking into it batari! REALLY appreciate the support you give. I added temp1 = temp1 right after each bank declaration and it fixed it.

I think I figured out the stack issue, it's more of an oversight than a bug I believe. The stack pointer is decremented before the write to it, so push $FF into stack 200 and it ends up at stack 199 Try and pull from stack 200 and you get the wrong value, instead pull from 199 and you get your #$FF back.

I don't have a statements.c file to look through, so this'll be done on your ends I suppose. [edit]n/m I found it

In DPCstartup.asm change: lda #<USERSTACK STA DF6LOW lda #(>USERSTACK) & $0F STA DF6HI To: lda #<USERSTACK STA DF7LOW lda #(>USERSTACK) & $0F STA DF7HI

Could always name it Epoch Adventure and introduce a time machine

Yep the latest build also falls apart, you now get red playfield streaks down the screen then it eventually all turns blue. Fixing the stack pointer also did not help my EggVenture issues either.

Latest build doesn't run even in Stella (3.4.1) on my end. Gives an ARM exception fault.

Damnit jim I'm a programmer not a math major! Comment all this algebra and call me in the morning. In otherwords I'd love to help but I can't sit here and decipher what all your code is trying to accomplish. dim your variables to proper names and comment your code so we can figure out whats going on.

Space Taxi!

I just ran into the issue where everytime VisualbB was started it came up with the "New start wizard" dialog, this crept up on me out of nowhere. I read the bB thread and starting on Page 17 others ran into the same issue but had no real fix for it. In my case and perhaps everyone elses, XP(SP3) compatibility mode got enabled somehow on the visualbB.exe Uncheck this and everything works fine. Just thought I would share this bit of info.

You can easily accomplish this in ASM, however to do color changes in batari Basic you need to set the player colors per scanline which requires you to override the drawscreen function with your own. This way you won't have to setup player0color tables for each scanline color, per frame! Right now there isn't an easy method for these visual effects that I know of. [edit] I can't find an easy method to do this without replacing routines.

There seem to be some inconsistencies in the way Stella and the real Harmony cart handle the DPC+ arm header code. Stella I think is said to use it's own DPC+ routines and does a pretty good job getting things done, but bring the same DPC+ game onto the harmony and things start falling apart. Is there a way to have stella ignore it's own internal DPCplus.arm routines and instead read the ones inside the games rom? This would make DPC+ developing much nicer for all the new games coming out, as we could track down issues much quicker.

I don't recall seeing how much stack space is available, but yes my game uses the stack quite a bit, I think 8 bytes last I checked.

@batari I've tested with the DPCplus.arm in the DPC+ programming thread and it does the same thing. @Jrok, all the builds seem to be unstable and bounce the screen like crazy. Looking in stella your scanline count is fluctuating quite a bit, your not getting to a drawscreen in time.

Good idea, this calls for some tests! I'll see if I can get something similar working. [edit] I've tried a few things, but during compile it names the player0 objects as player(randomID)_0 so I lose my pointer references. Otherwise this would update the player0 objects as needed: Mask_P0 rem MASK PLAYER0 if player0x <= 17 then goto maskL if player0x >= 153 then goto maskR return maskL asm lda #<(pointerplayer0) sta DF0LOW lda #>(pointerplayer0) sta DF0HI lda player0x and #7 tay ldx MaskDataL,y .applymaskL sax DF0WRITE dec player0height bne .applymaskL end return maskR asm lda #<(pointerplayer0) sta DF0LOW lda #>(pointerplayer0) sta DF0HI lda player0x and #7 tay ldx MaskDataR,y .applymaskR sax DF0WRITE dec player0height bne .applymaskR end return data MaskDataR %11111110 %11111100 %11111000 %11110000 %11100000 %11000000 %10000000 %00000000 end data MaskDataL %01111111 %00111111 %00011111 %00001111 %00000111 %00000011 %00000001 %00000000 end

I've been trying to track down this bug myself. If you find what is really causing it let me know! Like I mentioned in the EggVenture thread, you shouldn't have to rewrite everything every frame, all this does is hide the corruption that's still occurring. I do believe there is a pointer running amuck unseen until it starts writing erroneous data into the Graphics bank. Those that are rewritten every frame stay alive so to speak, but the rest gets a screen wipe. Those streaks are the playfield, in my game you can fly into them and it causes the collision to register a hit with the PF.

Pffft, I'd do it for free just to see the game get done!