Cybearg

Your compiler doesn't know what the "return" command does? How about the attached instead, which ditches "return" for "return thisbank"? Could Atarius get pixelbounce to compile? pixelbounce.bas

I've tried that twice already, one of which you see in the video above, but I tried it as you said for a third time and it makes no difference. I still get the same errors (for pixel bounce): --> cycle74_HMCLR f07d --> WaitForVblankEnd f08f With Omega (as with pixel bounce above) all the byte reports are blank, but I also get: free ram: 9 DPC free RAM = 603 --> repo 1ab2 It technically compiles, but the results are a mess. See attached. omega.bas.asm omega.bas.bin

Oh, one of the reasons pixel bounce didn't compile for you may be because I forgot one of the necessary files you'll need. Attached. I'm not sure if that's a relief or not. I'm glad that it works, but that means that it's some other problem beyond my understanding and control. pb_multisprite.inc defines a different multispriteheader.asm (specifically, pb_multispriteheader.asm) which in turn defines a different multisprite.h (specifically, pb_multisprite.h), which simply remaps a few memory locations so that the missiles and ball are located immediately following the player memory locations. This was necessary in order to set up a loop that would use the missiles, ball, and players all as pixels in a single go. This relates to a thread that I recently made. pb_multispriteheader.asm

I assume that means that it didn't compile. What error(s) did you get?

It seems correct. Plus, I get the same errors when I compile directly from the command-line as the bB readme instructs, so that issue is separate from VisualbB. The confusing thing, though, is that it worked before. And now DPC+ doesn't compile when it should be able to. Again, can anyone else compile the games I posted? We could confirm whether the issue is my bB or the games I'm compiling if someone else could confirm or deny that they can be compiled using bB 1.1d

Well, one of the games (the pixel bounce one) spits out this error when compiling, even when I set the romsize to 4k (so space isn't an issue): --> cycle74_HMCLR f07d --> WaitForVblankEnd f08f Any ideas why?

It WOULD be nice if VbB would just ignore everything between asm ... end rather than complain about all the incorrect syntax. I tried cleaning out the folder (or rather, I made a new folder, installed build 566 in it, moved my projects over to the new folder, then deleted the old folder) and it doesn't seem to have solved any problems. Clearly bB is part of the problem, but I don't understand why these projects I was working on compiled perfectly before-hand but now won't compile, even with fresh bB installs and everything. This includes DPC+ as well as certain other kernel set-ups (see the attached game files in the above post(s)).

I have multiple bB directories, yes, including one that is in the same folder as VisualbB but isn't actually being used as THE bB folder. But, as you see in the video, I point to the directory that I want to point to, plus this has been the case all along, so why am I only having problems now after VbB went on its Assembly crashing spree? Did those files I posted work for anyone else?

I fiddled around some more. This is really quite frustrating. Some of the problems with me checking different games with and without bankswitching may have been due to the includes files I was using, but that's clearly not the whole problem. DPC+ doesn't work for me at all. Again. Also, there are other games that don't work for unknown reasons. For instance, the attached game has been working fine and I made no modifications to change that, but now it doesn't compile correctly. I get errors, instead: bytes of ROM space left --> cycle74_HMCLR f07d --> WaitForVblankEnd f08f Does it work for anyone else? And how about the Omega DPC+ game (also attached)? It worked perfectly for me until these problems. I would be inclined to agree that it must be a code problem, except, as I've said, there are games that I've been working on that compiled perfectly fine and I hadn't touched them during this problem and now they suddenly won't compile, neither from the command line nor VisualbB. I really don't know what to think as, yes, evidence points to the code being the problem, but then why has it been compiling perfectly well up until the Assembly crash in VisualbB? pixelbounce.bas pb_multisprite.h.txt pb_multisprite.inc omega.bas pb_multispriteheader.asm

Yes. When bB crashed on me the first time I added the Assembly, I immediately took it out, but the crashes continued (this was working in the 8k version), so I put the Assembly back in, cut out anything else I could, and make it 4k and it worked again, but now [almost] nothing else does. If there's a question about what does and doesn't work, I urge people to send me code to run so I can see what does and doesn't work. If I'm running my own stuff, I may know it should work, but no one else does, so maybe try suggesting some 2k, 4k, and bankswitched game code that's confirmed to work that I could try?

I was hopeful because I realized that I hadn't restarted in weeks, most likely, but no. Restarting didn't fix it, unfortunately. And apparently it's not just bankswitched games that don't work. 2k games don't work, either. EDIT: So anything that's not 4k won't compile, whether it's DPC+ or multisprite. HOWEVER! Sometimes 2k or bankswitched games will work with the standard kernel. Sometimes. I can't find any pattern, because I have some standard kernel 2k games that compiled at 2k and 4k, but if I increase them to 8k, it won't compile. Then, there are standard kernel 4k games that I can increase to 8k and they seem to still compile. I really don't know. And no, it's not a problem with my includes files because, as demonstrated in the above video, I replaced them all with the latest versions.

I've made a video to show what's going wrong, in case it's not clear from my descriptions above: http://www.youtube.com/watch?v=-b_YnDEgdQ4

Yes, you're right. Trying to compile via command line doesn't work for bankswitched games the same as it doesn't for VisualbB. I'll try replacing the directory, though I didn't change or remove any files. Something must have been changed or deleted on its own, because I didn't touch it. EDIT: I replaced all the bB DPC files with the ones that Atarius sent me (attached, for reference) and it still doesn't work, neither from the command line nor from VisualbB even though it worked perfectly before this whole mess. What could possibly be wrong? BB_dpc.zip

Not to be pessimistic, but I kind of complained about the flicker in M.M.S.B.C. II I still don't understand how that phosphor effect translates to a real television or how that is meant to disguise flickering.

If the memory can be read, it can be compared to check for a null value, though that may be very, very slow. Also, if you dynamically place your high score value at the next available location, you wouldn't know which position it is in to retrieve it.

That's pretty awesome, but what's the point of no one has an AtariVox? I think there's great potential if people can actually hear it, but if not, then it's just a gimmick. Is AtariAge going to sell AtariVox modules again, like it apparently used to? If the price was reasonable, I'd be very tempted to get one for development purposes, myself.

I thought of and tried pretty much the exact same thing, though I wasn't too pleased with how it looked. It looks more like a bunch of flies buzzing around than a convincing starfield.

Are the stars necessary for something, or are they for aesthetics?

Just in case someone skimmed the above post and assumed the issue was resolved, this is a bump to say that it's not. There are two separate problems going on: 1. VisualbB crashes when it notices the duplicate . used in the assembly code 2. bB no longer processes bankswitched games. If there is any bankswitching, postprocess.exe will crash and the compiling will fail. Non-bankswitched game code will still compile. Any ideas, anyone? What file(s) could be modified by a VisualbB error/crash to result in continued compiling failures?

I also get a rather large laundry list of errors (sometimes): DASM V2.20.07, Macro Assembler ©1988-2003 --- Unresolved Symbol List playerL0210_4 0000 ???? (R ) playerL0211_5 0000 ???? (R ) drawscreen 0000 ???? (R ) playerL0206_2 0000 ???? (R ) playerL0213_3 0000 ???? (R ) playerL0214_4 0000 ???? (R ) playerL0215_5 0000 ???? (R ) playerL0202_2 0000 ???? (R ) playerL0209_3 0000 ???? (R ) playerL0190_0 0000 ???? (R ) playerL0191_1 0000 ???? (R ) playerL0186_0 0000 ???? (R ) playerL0187_1 0000 ???? (R ) 0.pie 0000 ???? (R ) playerL0194_2 0000 ???? (R ) playerL0182_0 0000 ???? (R ) playerL0196_2 0000 ???? (R ) playerL0183_1 0000 ???? (R ) playerL0199_2 0000 ???? (R ) 0.resetgame 0000 ???? (R ) playerL0178_0 0000 ???? (R ) playerL0179_1 0000 ???? (R ) PF2_data0 0000 ???? (R ) PF1_data0 0000 ???? (R ) PF2_data1 0000 ???? (R ) PF1_data1 0000 ???? (R ) PF2_data2 0000 ???? (R ) PF1_data2 0000 ???? (R ) playerL0175_0 0000 ???? (R ) playerL0176_1 0000 ???? (R ) BS_return 0000 ???? (R ) 0.skipL0225 0000 ???? (R ) BS_jsr 0000 ???? (R ) Fatal assembly error: Source is not resolvable. Errors were encountered during assembly. EDIT: I still don't know what's causing the assembling problems, but VisualbB seems to crash in part because of the periods after defining areas in Assembly. It will snap me to the highlighted periods and if I hit enter, VisualbB crashes. As for the assembling problems, I seem to have fixed some of them by replacing my DASM.exe with another copy of the same thing (same version and everything), or maybe it was something else I did, but that's all I can think of. I'd already tried restarting and reconfiguring VisualbB multiple times with no change and only after I replaced DASM did things start working somewhat. I hasted to say "somewhat" because any bankswitched games seem to still not work, getting errors like the one I posted above.

So I was experimenting with replacing some duplicate sprites with assembly that would set pointers en masse to save space. Visual bB didn't like it and crashed. It didn't like it so hard, it's continuing to crash and/or spit out errors about my code, even if I revert back to working, previous, tested versions of the code. It even crashes when I try compiling other, completely unrelated projects that I know were working. I've never heard of a programming error so bad it transcends space-time and affects clean code. Anyone know what's going on? Somehow, it must have bugged out by vbB installation or something, somehow. What can I do to fix it? I typically get some bogus errors and then postprocess.exe fails and sometimes Stella opens a mess of a screen and sometimes it doesn't. If you're wondering what I did, I tried replacing a few sprites with this: asm .setWingDown LDX #<duckDown STX player3pointerlo STX player5pointerlo LDA #>duckDown STA player3pointerhi STA player5pointerhi LDA #9 STA player3height STA player5height LDX #<duckUp STX player4pointerlo LDA #>duckUp STA player4pointerhi LDA #9 STA player4height . end asm .setWingUp LDX #<duckUp STX player3pointerlo STX player5pointerlo LDA #>duckUp STA player3pointerhi STA player5pointerhi LDA #9 STA player3height STA player5height LDX #<duckDown STX player4pointerlo LDA #>duckDown STA player4pointerhi LDA #9 STA player4height . end ... with this at the end of the bB file: asm duckUp .byte %00000000 .byte %10000000 .byte %01110000 .byte %11111000 .byte %00111111 .byte %01110110 .byte %01100000 .byte %01000000 duckDown .byte %00000111 .byte %10001110 .byte %01111100 .byte %11111000 .byte %00111111 .byte %00000110 .byte %00000000 .byte %00000000 end The thing is, I've done something similar in the past and it worked just fine: asm .DotPlayer LDX #<playerDot STX player1pointerlo STX player2pointerlo STX player3pointerlo STX player4pointerlo STX player5pointerlo LDA #>playerDot STA player1pointerhi STA player2pointerhi STA player3pointerhi STA player4pointerhi STA player5pointerhi LDA #2 STA player1height STA player2height STA player3height STA player4height STA player5height . end ... and at the end of the file: asm playerDot .byte %1 end

That's pretty awesome! Is there some downside to doing EEPROM game saving that would make most people not want to attempt it? Does it significantly increase the price of developing cartridges or have some other big drawback?

Who's Fred?

I've asked this before and I don't think I got a response. I know that DPC dynamically allocates its memory, but there's got to be some standard of where bytes are typically put. I need to know both for the sake of modifying memory values and for debugging purposes (how can I check what value is in a variable if I don't know where that variable resides?). Does anyone know of a full memory map listing of where data is typically allocated? If not, could someone produce one?