Thomas Jentzsch

We already requested a pseudo op which defines a new bank.

Correct. Even the TIA register names are just symbols. But since they are known, they are handled separately in DiStella and Stella.

Thanks for testing. Unfortunately I can only partially try reproduce your test results with 2600 controllers (because I have no Ranger controllers). And here the paddles work with 6.2.1. Have you defaulted the input settings (or deleted the sqlite files) between tests of different Stella versions? BTW: We removed paddle controls for the menu, because without automatic centering, a paddle attached will interfere with any other controller or switches input.

That looks pretty cool. Thanks for the info!

That I didn't know. And I didn't even know the first two names you mentioned (until I looked them up), so using your name would work as well.

No, "Mine"!

How about "Andrew Davie's"?

How should that work?

There are no such options. Also, you should cleanup ASAP, the risk you already recognized is very high. I suggest defining an area for temporary/local variables (e.g. tmpVar ds 10) and then do e.g. chefState = tmpVars + 2.

Not my kind of humor.

How about random losses? And the more often you die, the higher the chance of losing something. Not sure if that fits, because I am not into RPGs and don't know how this fits to the rationale given. IMO a Queen should have almost endless resources. Therefore she should be able to (mostly) replace equipment and gold. But eventually she will either run out of resources or lose motivation to further support a constant looser.

Very good start. Looking forward to it developing.

That's way too fast, IMO. Maybe you should contact Hyperkin and see how they react.

Got you now. With such a low resolution, I think the current code is (way) more than save. Alternatively you could just read once before and once after the kernel. That would almost double the distance.

Just 16 positions? Are you sure? That's the resolution of an Atari 2600 driving controller. Which usually is read only once per frame. I thought it has higher resolutions when you mentioned it acts like a paddle.

Being connected to a server opens a whole new universe of possibilities for the 2600.

An overturn within a scanline or so should be extremely unlikely at 75 DPI. But if the scans are quite a few scanlines apart, then it becomes more likely. How big the gap between scans can become, I don't know. And yes, testing will tell the truth. Impressive demo.

True, but slow movements (in your analogy "zooming in") may give odd results. If there are only one or two changes per frame and busy DMA, then there is a high chance the changes get misinterpreted by the code into opposite direction. But if you make sure, that two consecutive reads are within a reasonable number of cycles, you either get the reads or no movement at all. But never into the wrong direction. BTW: The C64 had DMA too, but much less interfering (just 40 cycles every 8 lines vs 63 cycles/line). I wonder why the 7800 is so different.

I think the code would "survive" longer, if you would eliminate bad reads due to too long intervals.

There is a Centipede homebrew or hack in the store which supports the Trak-Ball controller. The display seems pretty busy, so maybe it makes sense to look into the code.

Very impressive. Can the white noise between the vowels be reduced?

If a display steals a lot of CPU time, then the code may even detect the wrong direction. Maybe it would be better to also check the timer and dismiss all changes where the timer has run for too long between two reads? Do games for the 7800 and this controller exists? How do they handle this?

Yup, I looked up the memory map and it doesn't look good. Another weird idea I just had: Only use PLA! PLA each loop, except when going right. And PLA twice when going left. But that wouldn't save cycles (9..11 instead of the current 8). And then you could almost use 'inc/dec xPos' instead (11 cycles).

This is the best for now (and tested with Stella): .left ; 3 dex ; 2 bcc .cont ; 3 = 8 unconditional .loop ; sta WSYNC ; required for Stella!? lda SWCHA ; 4 asr #%00110000 ; 2 lsr ; 2 ldy lastTrack ; 3 Y = 0, 4, 8, 12 sta lastTrack ; 3 eor NextTbl,y ; 4 = 18 beq .left ; 2/3 ;.right eor #%00001100 ; 2 bne .cont ; 2/3 inx ; 2 = 8 .cont ; check timer: lda INTIM ; 4 cmp #TIMEOFFSET ; 2 bcs .loop ; 3/2= 9/8 ;total: 35 cycles NextTbl ; only every 4th byte used .byte %0100, 0, 0, 0 ; 00->01 = left, 00->10 = right .byte %1100, 0, 0, 0 ; 01->11 = left, 01->00 = right .byte %0000, 0, 0, 0 ; 10->00 = left, 10->11 = right .byte %1000 ; 11->10 = left, 11->01 = right So 4 cycles saved compared to the original code. And only one table used, so 16+3 bytes saved there. Unrolling would gain 1 more cycle. Then X and Y (alternating) would be used instead of 'lastTrack' (saves 4 cycles and 1 byte RAM). Also 'inx/dex' would be replaced by 'inc/dec xPos' (costs 3 cycles). Maybe one could use 'pla/pha' instead (saves 1/2 cycles). You would have to find an area where some 'pha' wouldn't do any harm. Not sure if that works on the 7800. One more question: Your code seems to indicate that you may want to check more than one controller. Is that correct? In that case, instead of repeating the code, a combined code checking both simultaneously would be more efficient.

@RevEng Couldn't you use TIMINT ($285) which triggers when the timer has run out? Or would that create varying scanlines?