Jump to content

Thomas Jentzsch

Members
  • Content Count

    26,569
  • Joined

  • Days Won

    3

Thomas Jentzsch last won the day on March 9 2015

Thomas Jentzsch had the most liked content!

Community Reputation

5,112 Excellent

About Thomas Jentzsch

  • Rank
    Thrust, SWOOPS!, Boulder Dash, Star Castle, Aardvark...
  • Birthday July 18

Contact / Social Media

Profile Information

  • Custom Status
    Always left from right here!
  • Gender
    Male
  • Location
    Düsseldorf, Germany, Europe, Earth
  • Interests
    Programming, (TV- :-) Sports, Travelling

Recent Profile Visitors

69,637 profile views
  1. Not my kind of humor.
  2. 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.
  3. Very good start. Looking forward to it developing.
  4. That's way too fast, IMO. Maybe you should contact Hyperkin and see how they react.
  5. 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.
  6. 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.
  7. Being connected to a server opens a whole new universe of possibilities for the 2600.
  8. 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.
  9. 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.
  10. I think the code would "survive" longer, if you would eliminate bad reads due to too long intervals.
  11. 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.
  12. Very impressive. Can the white noise between the vowels be reduced?
  13. 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?
  14. 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).
  15. 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.
×
×
  • Create New...