lucienEn

I wouldn't think that's related to the update, that's more the display input settings unless this is PAL? Digressing from this thread, lot more portable obviously without 2600+ and using the Stella emulator with a joystick (I have the StellaAdapter which works great on Surface Go devices incl. the latest wireless one, probably Apple devices too, not sure). But to be clear I don't want to distract this thread with another topic, unless this beta is really causing that:-).

I assume that's PAL only or some units, since I see no missing sprites on NTSC with this 1.1 beta playing Jump & Run. They all flicker evenly as expected and I tried several levels:-).

Installed using video instructions without any issues on win11 and original usb cable. Verified Circus Convoy (ntsc) working. I wonder is it possible to test 4k games using the Harmony Encore? Just copy the bin file in root?

Great, thanks! I wonder now what format is best by having widest cartridge compatibility, i.e. 2600/Retron77. - AtariAge up to 64KB: https://atariage.com/store/index.php?l=product_detail&p=949. No SB support but perhaps 64KB is more than enough (EF). - Audacity games: eventually selling cartridges which have 128/256KB support: https://adgm.us/portal/products.html. Not sure if/when that will happen since that page hasn't been updated in years it seems I'm guessing 2600+ does not supports EF (Fatal Run shows supported) but will support SB with the upcoming update. I guess either way it's easy to switch the format later on in game development.

Thanks! Question is which code patterns, is there a Stella known bankswitching reference to give guidance for programming? For formats I could only find https://jjn.one/posts/atari2600-bankswitch/ but that's outdated now given it doesn't list SB that is used in Circus Convoy.

I might be able to answer my first question: looking at code I see org + reorg and my assumption that will define the total binary size. Then the next part is how does it know which addresses are part of the bankswitch? Does Stella just scan the binary for writes to well-known defined addresses and then do a mapping based on that? org $2000 rorg $1000

How does Stella know which bankswitching mode is used when building with Atari Dev Studio? I have 8K sample code and not seeing anything obvious. Also how can I specify in code which mode to use? E.g. could I use 'SB' mode that Circus Convoy uses as well which may not be known in the linker?

Would be great if OTG would be supported and use a SD card with the FW update on it. That should work cross platform and just requires cheap OTG cable (similar to Flashback updates). Not to go on a platform debate, but sadly Apple has been super exclusive with anything they do while gradually increasing market share. Pretty often it's iPhone and their walled ecosystem only, so I know how limiting that feels.

See detailed discussion here. Basically driving controller is more like a mouse giving relative changes. I tested driving controllers while ago in Stella and worked fine.

Since this is for Gold, I think you should post this here instead: .

Thanks very much. 2600 games hang too in Nexus. Takes about 10 min. and then freezes. Pretty much any game that I tested regardless which emulation. Without Nexus the 2600 games work without any issues.

I also have a brand-new SanDisk USB stick so not the problem and without Nexus no issues playing games from USB. Maybe some memory corruption over time. I hope someone could look into that and fix it. I also tried Nexus Slim but also hanging after a while.

Hi, I installed 1.1 and community FW and works great for AFB 50th Gold. However Nexus Pure works for about 15 min. in game and then freezes including 2600 games. Any idea? Haven't tried other Nexus packages yet but I assume they're very similar.

Almost like an old television set:-). It's pretty odd that there are no screenshots at all from Atari. You'd think at least for pre-order they could show something. If they are using Stella, wouldn't Realsports Boxing and Super Cobra work? They use F6 + E0 bankswitching. Weird thing is that both show as fail, yet Sentinel which is also F6 shows pass. So still not clear why some don't work. If Pitfall II wouldn't work it's a major downside since that's a pretty iconic game. EDIT: never mind Stella is not the issue, the dumper is as discussed elsewhere. But still remains unanswered why some F6 games do work and some don't. Also given Pitfall II uses a "non-standard" bank switching format I'm afraid there's a possibility it won't work. Unless they can build some library to detect which cartridge it is.

Flashback allows you to easily add any game and I think it would allow using the Retron and original controllers as well. I fully get it is great to be able to insert a physical cartridge (as long as it's not on my old Atari 2600 to preserve it). It's why it's so great Audacity games released Circus Convoy on cartridge which is amazing quality. But if Atari themselves releases something brand new that may not be able to play lot of these next generation games (but works on original HW), then that's just bad (weird enough the storage seems huge unless that's all in system files: 256MB eMMC fixed internal storage). I also understand the argument this is not for 'hardcore' gamers, but how many people have a big 2600 cartridge library that are not hardcore 2600 gamers? I still have a Flashback 2 (never got around trying to upgrade it with cartridge). That was cheap, so why wasn't it possible to do that instead? I'm going to guess most rather have original HW than 7800 compatibility. PS on a positive node, I'm potentially excited about more original 2600 controllers. I hope they really do feel like original and don't move too much around.

Does something like a Flashback Gold have better compatibility since it can play directly from a larger USB stick? I haven't heard much about emulation issues there. I assume better compatibility than both Retron 77 & 2600+? I don't fully understand the advantage of having a cartridge instead of a SD/USB slot since I would want to limit swapping old cartridges often to avoid wear & tear on these old cartridges. Unless it will work with a Harmony card which doesn't sound plausible at this point. I do have an old 2600 JR for HW compatibility homebrew testing and this can't replace that sadly.

Yes they used overlap I believe but in Stella debugger fill to that scanline and observe the patterns. Using my screen editor (which should also generate the ASM code for this), I can draw this pattern with ball size 4 and then leave holes in sprite 2:

Hi, I finished adding support for all object types in the screen editor (Win64 only however written in .NET Core so in theory more platforms possible). There are few expected limits on code generation. It supports up to 4 register writes and additional for PF1/PF2. Not planning to post more updates but as an editor only it should cover now almost everything: ScreenEditor2600 v0.7.zip Lucien

I noticed Pitfall 2 sets the positioning in the vblank area. That's another option to do the above without requiring to blank first 8 pixels and then apply all at once.

To give some background, I finished my editor to auto-generate all object types. In the editor you can indicate where you want to set the position of an object and with 'generate asm' I confirmed it's working now as expected (but there are lots of combinations so might be still some bugs left for me):

Yes just repositioning. Note this is auto-generated code so it will automatically keep track of what needs to be reset and I got it working now. Definitely do not need HMCLR. Thanks everyone for finding the issue.

By the way is there really need for HMCLR after setting one RESP,x register? You could clear only the one you changed, correct? Slightly more expensive but helpful in this case.

That is clear and working but I want to do another RESP,X on the next scanline. This works below to use instead of HMCLR, only clear RESM0: Kernel1_Setup ldx #2 lda #10 jsr SetHorizPos ; WSYNC + HMOVE + HMM0 + RESM0 Kernel2_Setup ldx #3 lda #11 jsr SetHorizPos ; WSYNC + HMOVE (apply HMM0) + HMM1 + RESM1 nop ; 6+2 = 8 cycles nop nop nop nop nop nop nop lda #0 ; 24 cpu cycles sta HMM0 Kernel3_Setup ldx #1 sta WSYNC sta HMOVE ; apply HMM1 dex nop nop nop nop nop nop nop nop nop nop nop sta HMCLR ; clear RESM1

Actually I could just do this: WSYNC+HMOVE+RESM0 WSYNC+HMOVE+RESM1+24 cycles+RESM0=0 WSYNC+HMOVE

Ah good catch. And I can only set HMOVE right after WSYNC, correct? If that is the issue I guess there is no way to do this unless I remove HMOVE at next scanline but then I need to blank out first 8 pixels. WSYNC+HMOVE+RESM0 WSYNC+HMOVE+RESM1 --> this needs HMCLR to avoid adjusting 2x RESM0 WSYNC+HMOVE+HMCLR