RevEng

There's a pretty straightforward way to grab that info in stella - if you hit the ` key you can enter the debugger and then choose the tia tab. Looks like the color is $36.

Huh? I thought we were just posting in a web forum. Did I miss the part where someone declared this a war? And if it is a war... what is it good for?

Right, it's not the kernel, it's the bB code. The reason using too many cycles is undesirable is because it causes the overscan part of the TV frame to have too many lines, which is quite likely to cause screen jittering or rolling. The "ideal" TV frame generated from a 2600 game is made up of these parts and these line counts: [VSYNC.............3 lines] [VBLANK...........37 lines] [VISIBLE SCREEN..192 lines] [OVERSCAN.........30 lines] The main part of your basic program runs in the overscan part of the TV frame until it hits a drawscreen command, at which point the rest of the frame parts are drawn. When overscan time beings again, control is returned to your basic code, just after the drawscreen command. One way to avoid using too many cycles is to have multiple drawscreens strategically placed in CPU-heavy parts of your code. This approach won't work in the main loop of the game, as each drawscreen in your main loop will reduce the overall framerate, but it works well enough for screen setup code. If you take this approach, you may want to set the colors of all screen elements to black until the screen is completely drawn, to avoid showing the screen as it's being built-up. It's also worth mentioning that your basic program can also run partially in vblank with the vblank keyword, and similarly you don't want to use too many cycles there either, or else there will be too many vblank lines, which will cause jittering or rolling.

Definitely a solid start! I agree that more distinct room features could help. I'd also like to see matching up-stairs and down-stairs. I don't know if you noticed, but your room drawing routine is using too many cycles. Since you're after rings, why not call it "rings of the lord", and add some shadow riders.

Ok, here's the problem in a nutshell... I need 3 temporary bytes of ram, plus the tempN variables. The bB guide says that aux3-6 are reserved exclusively for minikernels, but that's not entirely true. These same bytes are also used for various optional functions in the score display. (aux3=pointer to lives shape or pfscore1, aux4=life color or pfscore2, ...) It looks like there just isn't any free ram that I can borrow without colliding with some optional bB feature. So the following version uses aux3, aux5 and aux6 as before, unless your basic program has dimensioned bmmk1, bmmk2, and bmmk3, in which case it uses them instead... rem *** one example... rem *** the following are temporary bytes for the bitmap minikernel dim bmmk1=var44 dim bmmk2=var45 dim bmmk3=var46 bitmap_mk.asm.txt

Ok, I'll take a look at the scorepointer conflict. I have a feeling I know what it is, though fixing it will take some doing.

I knew, but it's a good point to explicitly state. If you're doing anything intensive in a titlescreen loop, it's probably a good idea to double-check you're not pushing more than the usual 262/312 scanline counts. (alt+l in stella)

Many 3D games suffer for the digital-only controls, to the point that they implement an analog control through the capacitive touchscreen, like StarFox Command, Mario64, Ridge Racer, etc. Nintendo has acknowledged this shortcoming by including an analog joystick-nub with the the 3DS.

It's glitching because the bottom of your data doesn't quite match up with the top, so when you reset the index there's a visible jump. You basically have this... copyright 2011 [5 lines] [3 blank lines] aegis [5 lines] [3 blank lines] logo [7 lines] [1 blank line] copyright 2011 [5 lines] ...with a window 8 lines tall. Since you want the "copyright 2011" to switch when it's at the top of window, you need to include the 3 lines underneath the text as well... copyright 2011 [5 lines] [3 blank lines] aegis [5 lines] [3 blank lines] logo [7 lines] [1 blank line] copyright 2011 [5 lines] [3 blank lines] Here's the image file with the blank lines added... 48x1_2_image.txt And you'll need to change the "if bmp_48x1_2_index>21..." to "if bmp_48x1_2_index>24...".

No worries. I'm just glad to hear there's nothing for me to fix!

Ok, so that's the start. Every once and a while bB spits out an incomplete binary due to a syntax error or similar issue, and except for the bad size its not obvious there was a problem. Just to make sure I wasn't missing anything, I copied your 48x1_1_image file into one of the examples and it compiled and displayed just fine. If you comment out the draw_48x1_1 line from titlescreen_layout.asm does everything compile fine? If so, maybe you've run out of space.

In some jurisdictions they're clearly illegal... in the U.K. and Australia, for example. A lot of the news you read about raids and seizures are in these regions. I don't believe there's been a defining ruling in the U.S. or Canada, and since the devices are used for more than piracy, it's a bit of a grey area. I don't believe customs will hold up a small shipment of these, but I don't even play a lawyer on TV so I can't give you definite advice.

Provided you know that all of the recipients have DSes and not DSIs you should be good. Last time I checked, with a DSI at the latest firmware you'll need something more expensive than a R4i.

I'm sorry to hear that. Nothing ventured nothing gained, I guess.

The file itself looks fine. Its set to be the first copy of the 48x1 data. Are you sure there isn't another file also set to be the first copy of 48x1? If not, post or PM all the files and I can see what I can do about it. [Edit - also, make sure the .bin file created was the right size]

You're welcome... glad to contribute anything to help Seaweed Assault become a reality!

I don't see a way to do it without using memory, but you might be able to get away with using a temp variable if your score addition happens in a fairly compact chunk of the code... dim sc1=score+1 rem ** save the thousands digit without the hundreds digit. rem ** do this right before your score additions routines... temp6=sc1&$f0 rem ** score addition routines happen here. nothing that overwrites rem ** temp5 or temp6 can happen here. That includes "drawscreen". rem ** now check if the thousands digit changed... temp5=sc1&$f0 if temp5<>temp6 then gosub bonuslife ...this assumes that your score addition routine won't ever add more than 1000. If that's not true, you could expand the above routine to also track the ten thousands digit.

I see this on my stock 7800 with a real food fight cart.

Looks like one of the player reflect registers was set after the game, and its carried into the titlescreen. Try "REFP0=0:REFP1=0" before calling the titlescreen kernel. I'll add this to the kernel itself in the future.

The same could likely be said about any 2600 game. When I brought the Flashback 2 home, Adventure quickly became one of my kids' Atari favorites. Maybe without the nostalgia factor Adventure doesn't appeal as much to adults, because we've had our imaginations dulled by the grind of the world.

I think it's stack memory. Try this version of the bitmap_mk.asm... bitmap_mk.asm.txt ...don't forget to remove the .txt extension. If it doesn't work out better then post a .bas.

Neither is the SC ram really with melody, but if its "no accessories" I guess that would mean no bankswitching.

Keeping it 4K and non-SC will certainly give you more choices if you're planning on a cart release.

Instead of "open dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin" try: ./dasm RiverRaid.asm -lsomename.txt -f3 -v5 -oRaid.bin

Nice... I look forward to the results!