Dionoid

Hi, I have the same issues when debugging my F8 bankswitched game in Stella. However I found a specific combination of settings that seems to solve the debugging issues for me: In the Developer setting (assuming you're using these), uncheck "Random startup bank", or use Stella command line argument "-dev.bankrandom 0". This will make Stella always start in the second bank (@ $f000 - $ffff).Note: of course you should initially also test if starting your rom in the first bank works, as that can be tricky with initialization code. But once you verified that random-bank startup works, you should uncheck the "Random startup bank" option to get cross-bank debugging working correctly in Stella. Also, start Stella in debug mode (use argument "-debug"). This will jump right into the debugger at launch. You can just press "Exit" to continue the game or set some breakpoints already if you like. I think that this - combined with forcing Stella to startup in the second bank - forces Stella to load/show the correct labels and symbols for the second bank. Make sure that shared bankswitch code's label (a.k.a. trampoline) is in the range of the first bank (@ $d000 - $dfff), not in the second bank.Note: this can be achieved by setting the bankswitch label like this: BankSwitchRoutine = (. & $fff) | $d000 Make sure that the Reset vectors (at the end of each of the two banks) are within the range of their corresponding banks, so not pointing to an address in the other bank. When you do this, you will see that Stella (I'm using the latest 6.0 version on Windows) will show the correct addresses and labels in the disassembly tab. Just set a breakpoint at the start of the shared bankswitch code and step through the code to verify this. I'm not sure why F8 cross-bank debugging doesn't work in other cases; I guess it's a bug in Stella (see this thread). Hope this helps!

Thanks for sorting this out, Nathan! I have a Sony Bravia TV and putting it in Game scene mode really helped with lowering the lag. I think the lag is now down to 2 frames, which makes Amoeba Jump playable again on the Retron 77!

Wow, that is some very thorough testing, Nathan! Do you think that using a 2600-daptor helped to reduce the lag a little, and that there could be a difference in lag between the 2600-daptor and the default RS323 ports on the R77?

You're absolutely right. I was thinking about getting a 2600-daptor anyway, so maybe this is the right time. I see in the specs of the 2600-daptor that it transmits at 1K Hz, which means it has minimal delay. Is there anyone out there who owns a 2600-daptor and can check if the built-in ports on the Retron77 have a bit of lag compared to a joystick connected to the USB 2600-daptor? Measuring the lag exactly is pretty hard and requires special hardware, but I found that playing around with the game 'Adventure' can provide a sense of a possible lag.

Hi Steve, unfortunately I don't have a 2600-daptor to test this myself. I guess there will always be some lag because of the polling rate of USB devices (see this article)

I found that the game "Adventure" is an even better way to show the lag on the Retron77. Just load the game on a real Atari and on the first screen move and hold your joystick left for half a second, and then move and hold right for half a second. Keep doing this left-right movement for a minute, so your brain can get used to it. Now move over to the Retron77 and do the same. You'll probably notice the lag now. Btw I doubt if this is something that can be fixed in Stella. It's probably more of a driver/OS kernel/USB polling thing.

On the Retron77 it feels like the amoeba doesn't immediately respond to joystick movement, and also doesn't immediately stop when I stop moving the joystick. Really hard to put my finger on it, but like Nathan is saying, it feels like there is a tiny lag there. The good way to show the lag is to use Paul Slocum's Testcart, and then make a circular motion with your joystick. On real hardware you'll see the arrows moving in sync with the joystick movement. On the Retron77 I can notice a small lag there. Hope this helps [Edit: I found that "Adventure" is even better in showing the lag]

Thanks for your feedback! It sounds like you both prefer the original controls, and I think you're right. This is what went wrong: Yesterday I asked a few local friends (who never played my game) to test Amoeba Jump on my Retron77. The feedback I got was that the controls were too fast. This afternoon I asked them again to test my game, but this time on an actual Atari 2600, and now all of a sudden they liked the controls and were able to reach high scores. But it was exactly the same game! So, I was clearly jumping to conclusions yesterday, and the original controls appear to be fine on actual hardware. I think it's okay if it takes new players a few minutes to get used to the controls; because these long jumps are essential in reaching high scores. Note to self: emulation is good, but actual hardware is better

Anyone already tried to connect a wireless PS3 controller? I have a few of these controllers laying around. These 8bitdo adapters look promising [Edited: It seems the PS3 controllers have a weird bluetooth implementation and won't connect. I'll be looking for another wireless controller]

Nevermind, I found that after removing the sqlite setting files, the default phosphor settings work fine for me. I guess I was confused by the different options for phosphor, that don't seem to affect each-other when changed: the phosphor-blend control in the basic settings window, set to 6% by default the phosphor-blend control in the advanced settings window, set to 45% by default the phosphor button in the Commands windows, set to 'on' by default E.g. when I set 'phosphor off' via the Commands window, I still see the phosphor-blend set to 6% in the basic settings window. And when I change this phosphor-blend from 6% to another value, the advanced phosphor-setting is still 45%. I guess this is still work in progress?

I watched some people (and kids) play Amoeba Jump for the first time today, and some of them got frustrated with the fast controls. So I made a fix today, which slows down the horizontal speed of the amoeba. By default, the amoeba now makes shorter jumps with better precision. You can still make long jumps if you hold down the fire button while jumping. In that case you'll get the original horizontal speed up. This fix seems to result in better playability for people that are new to the game, so I think it's a good one. But I also would like to hear your feedback of course. New 1.5 version of Amoeba Jump is downloadable from the initial post.

I just played Draconian on the R77, and noticed there is no flickering at all using the default settings of the latest Stella R77 beta-2 build. While on my CRT's (connected to actual '2600 machines) I always see some flickering playing Draconian. I know I can change this Phosphor-blend setting myself, but shouldn't the default options in Stella be set to emulate a (good) CRT monitor as close as possible? Or is this a matter of taste?

Thanks for the info! I've ordered an USB OTG splitter right away. Question: looking at the numbering of the buttons, was 'Button 7' left out on purpose? Or does your gamepad has indeed 9 buttons?

I'm going to try out the new update this evening, and I'm very much looking forward to what the menu's offer. Quick question: what does these 'Button 3' to 'Button 9' mean? Is this a special kind of joystick that needs to be attached using the usb port?

The latest version is here: http://atariage.com/forums/topic/229152-new-pacman-for-atari-2600/?p=4131166

That warning is a flaw in the macro.h in my opinion. I modified my local version of macro.h to always do a 'nop 0' by commenting out the surrounding conditions. No idea why anyone would like to use 'bit VSYNC' here, because that instruction might change the flags.

Tower of Rubble multiplayer teaser video :-)

...do you mean that we will be able to show the Command dialog by pushing the button on the 2nd joystick? That would be cool. But how does that work with games that allow two joysticks?

+1 for using the aspect ratio button to show the Commands window. Question: Would it be an option to include the "TV Mode" to the Commands dialog, so you can cycle through the available modes (Composite, S-Video, RGB, 'Bad adjust' and Disabled)?

Hi @Thomas Jentzsch, do you have a small bank-switching example where the Stella debugger actually shows the correct addresses after switching to the non-startup bank? From that I think I can figure out the differences. I tried changing my code by moving the common bank-switch code to the end of the banks (just before the hotspots starting at $fff4) but that didn't fix the issue with the missing debug labels.

Great homebrew game you're playing there, @sramirez2008 Because of your positive experience, I've just ordered a "Trooper" myself. Let's see how it compares to my Suzo Arcade Turbo joystick (my favorite joystick for over 30 years)

Hi Thomas, I extracted the bank-switching code into a very basic example showing rainbow colors and doing a single F8 bank switch (from bank 0 to bank 1, and back again). If you run this example and in the Stella debugger set a breakpoint on the 'BankSwitch' label, you can step through the code and see the problem that after the bank-switch the addresses inside the debugger are not updated to reflect the correct addresses (i.e. they should be in the $3000 - $3fff range, but they keep showing addresses in the $1000 - $1fff range). Maybe I'm doing something wrong, but maybe it's a bug in Stella 6.0. Thanks! ;=============================================================================== ; F8 Bank Switch sample ;=============================================================================== processor 6502 include "vcs.h" include "macro.h" MAC COMMON_BANKSWITCH_CODE ;make sure we always start at label InitSystem in Bank 0 lda #>(InitSystem-1) ldy #<(InitSystem-1) ldx #$ff txs ; init stack pointer inx ; X = 0, because InitSystem is in Bank 0 BankSwitch = (. & $fff) | $1000 ; pha ; push hi byte tya ; Y -> A pha ; push lo byte lda $1FF8,x ; do the bank switch rts ; return to target ENDM ;=============================================================================== ; BANK 0 ;=============================================================================== SEG Code ORG $8000 RORG $1000 COMMON_BANKSWITCH_CODE ;=============================================================================== ; Init ;=============================================================================== InitSystem: CLEAN_START ; initialize zero page and stack GameLoop: VERTICAL_SYNC ;Now switch to code in bank 1 lda #>(LabelInBank1-1) ldy #<(LabelInBank1-1) ldx #1 jmp BankSwitch ReturnFromBankSwitch: ; 36 scanlines of vblank... REPEAT 36 sta WSYNC REPEND lda #0 sta VBLANK ; stop vertical blank ;------------------------------------------------------------------------------- ; Now display a screen of rainbow colors ;------------------------------------------------------------------------------- DisplayKernel: ; 192 scanlines of picture... ldx #0 REPEAT 192 ; scanlines inx stx COLUBK sta WSYNC REPEND ;------------------------------------------------------------------------------- ; VerticalBlank - enter blanking ;------------------------------------------------------------------------------- OverScan: ; end of screen - enter blanking lda #%01000010 sta VBLANK ; 30 scanlines of overscan... REPEAT 30 sta WSYNC REPEND ; back to game loop jmp GameLoop ;ending vectors ORG $8ff8 RORG $1ff8 ds 4, 0 .word $1000 ; RESET .word 0 ; BRK ;=============================================================================== ; BANK 1 ;=============================================================================== SEG Code ORG $9000 RORG $3000 COMMON_BANKSWITCH_CODE LabelInBank1: jmp *+3 ; jump to next instruction (maybe this fixes PC issue?) ; switch back to bank 0 lda #>(ReturnFromBankSwitch-1) ldy #<(ReturnFromBankSwitch-1) ldx #0 jmp BankSwitch ;ending vectors ORG $9ff8 RORG $3ff8 ds 4, 0 .word $3000 ; RESET .word 0 ; BRK

Weird, I do see the PC is showing the correct upper bits after bank switching, but the debugger doesn't seem to reflect the new bank addresses. Adding a dummy jmp *+3 as first instruction after entering the new bank doesn't help.

For some reason the Stella 6.0 debugger doesn't show me labels for Bank 1, but only for Bank 0. In Stella I do see that: Bank 0 is at $1000 - $1fff Bank 1 is at $3000 - $3fff And the symbols dump file also contains the correct labels for Bank 1 in that $3000 - $3fff range. But when I step through the debugger from Bank 0 into Bank 1, I see the addresses left to the assembly code stay in the '1xxx' range instead of switching to the '3xxx' range. Also, in Bank 1 it doesn't show any of the labels from that bank. So while Stella seems to know that Bank 1 is in the $3000 - $3fff range, it doesn't use that correctly in the debugger and for matching label names. Am I doing something wrong maybe?

Hi Thomas, I see in your macros that bank 0 will use: ORG $8000 RORG $1000 ...and bank 1 will use: ORG $9000 RORG $3000 Can you explain why this makes debugging easier than if you would just use RORG $F000 for each bank? Thanks!