Jump to content


Popular Content

Showing content with the highest reputation since 01/28/2021 in Blog Comments

  1. 1 point
    You might also want to check out the Veronica project: https://blondihacks.com/veronica/
  2. 1 point
    Update: 2-6-21: Zoo Keeper won Best 2600 Homebrew (Port), Best graphics (Port), and Best Music + Sound (Port) in the 3rd Annual Atari Homebrew Awards.
  3. 1 point
    You are correct in that it does require it. In this case I'm using the Left+Right trigger as the Up+Down was causing the system to see a paddle controller in use. There are diodes installed off each input so they can't conflict with each other on the controller side or from the main logic side as only the NOR gate logic I used is able to see it and trigger the Pause function.
  4. 1 point
    Thanks for trying it. I fixed the letter T and made spacing changes on the letters. It now looks like this: Squaresville.otf
  5. 1 point
    Subject: Inconsistent timer behavior... what a RIOT! Hi @SpiceWare! (Others jump in if you can help me!) I've used your timer code as a starting point for my OverScan subroutine for a new game I'm working on. However, during running of my game, sometimes the RIOT timer count-down is not working with the divide-by-64 as expected, but rather seems like divide-by-1, so naturally the timer is wrapping around before I can catch it and I get a way-to-long overscan period so vsync does not happen. So I get a partial 87-line frame between each 262-ish frame (still working to get that exactly correct). During this behavior, in Stella the frame flashed and the RIOT registers subwindow shows TIMINT as $C0 and INTIM Clks always as 1. This weird behavior can last a few seconds to several seconds. Then can go back to normal for awhile. Real hardware seems to be affected the same way... I get occasional frame break up (on my LCD TV, it goes grayscale and vertical stripy). So it is acting like I am not storing to TIM64T but TIM1T, but my code is still definitely storing into TIM64T, which I can see occur in Stella IO window. Earlier in my kernel, for the main play area, I'm using the timer two other times with TIM8T when I'm updating player sprite positions and other sprite drawing preparations. I'm not sure if using those could leave my timer in a weird state. Now here is the funny part... if I immediately read INTIM after storing to TIM64T, it acts normally and I get a chance to catch the timer countdown and all is well. If this works consistently, I suppose I can leave it in like this, but it seems hacky. Note in the code below I commented-out the store to WSYNC to make sure I was not barely missing the countdown to 0. lda #32 ; set timer for 27 scanlines, 32 = ((27 * 76) / 64) sta TIM64T ; set timer to go off in 27 scanlines lda INTIM ; EXTRA READ HERE!!! SEEMS TO HELP PROPER DIV-BY-64 WORK. ; my game logic... OSwait: ; sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda INTIM ; Check the timer bne OSwait ; Branch if its Not Equal to 0 rts ; ReTurn from Subroutine If there is something subtle about using the timer I'm not taking into account, or good practices to cleanly reset the timer function, I would appreciate hearing about them and learning! -- Mike
  6. 1 point
    If this involves impossible joystick directions, beware that certain non-joystick controllers - trakballs, mice, etc - can trigger them.
  • Create New...