SpiceWare

Terms used in the Stella Programmer's Guide, you can find a link to it in Step 1 of my tutorial. You can see an example in Step 9 where this is Reflected: and this is Normal: An asymmetrical playfield means you're updating the PFx registers twice per scanline so they don't show the same image on the left and right sides of the screen.

I spotted two issues in the comments of your source that will lead to problems getting the critical updates done at the proper time. 1) the cycle count for WSYNC: sta WSYNC ; (3 3) Wait for the previous line to finish lda pf0dataleft,y ; (4 7) load left pf0 data into the acumulator sta PF0 ; (3 10) and store it Cycle is reset to 0 after the WSYNC, not 3. sta WSYNC ; (3 0) Wait for the previous line to finish lda pf0dataleft,y ; (4 4) load left pf0 data into the acumulator sta PF0 ; (3 7) and store it Also make sure the instruction before the stay WSYNC finished by cycle 73. If it finished on 74 or later you'll end up with an extra scanline that'll likely cause problems. 2) Putting time-critical updates in the comments like this is very smart thing to do: sta PF2 ; (3 48) and store it (right PF2 MUST hit on cycle 48 to avoid writing too soon or too late) However, that 48 cycle update of PF2 is only if you're using Reflected Serial Output for an asymmetrical playfield. You're using Normal Serial Output which has different critical times. These are the cycles* I've used. PF0L 56-21 PF1L 66-28 PF2L 0-37 PF0R 28-49 PF1R 39-54 PF2R 50-65 Those ranges are for the cycle the store instruction finishes on. Ranges for PF0L (and PF1L) look odd at first, but those just mean store should occur on or after cycle 56 (and 66) of the prior scanline and on or before cycle 21(and 28) of the current scanline. My guess would be you're trying to alter the data for PF0 and PF1. Their output is the reverse of what you'd expect. See Step 3 of my Collect Tutorial. * Note it's entirely possible I'm off on a value in that list as I've not done extensive testing on the ranges.

I tried out a few game controllers that work in the Tesla. $15 Logitech Gamepad F310 for Windows $47 Playstation 4 $25 PDP Wired Controller for Xbox One old Logitech RumblePad 2 I had lying around One thing to note right off is even if a controller is plugged in the position of the steering wheel is still read. So make sure the wheel is straight or you'll have trouble playing your game. They all worked great for Beach Buggy Racing 2. The onscreen labels show A, B, and Y for the power-ups regardless of which controller was plugged. The PS4 controller used X, O, and Δ respectively. The RumblePad 2 likewise used 2, 3, and 4, so the button locations for all controllers were mapped to the same physical positions. When a controller is used the game does not auto-accelerate your buggy, use the right trigger for that. Left trigger for brakes. They all worked about the same for the arcade games. Main issue with all of them is the analog stick is not calibrated well. For Asteroids, Lunar Lander, Gravitar that's not a problem. For Centipede, Millipede, Missile Command, and Tempest you do not have fine-control, so you'll easily overshoot your position. Super Breakout is flat out unplayable. Secondary issue with the arcade games is the button mappings are not consistent between controllers. For most games that's not an issue, but it is for Missile Command because the position of the bases does not correspond to the position of the buttons on the PS4 controller: □ middle X right O left Nor on the RumblePad 2 1 middle 2 right 3 left For the other two they're fine: X left A middle B right For me that's a shame because as a longtime Playstation owner (original, 2 and 3) I prefer the PS4 controller for both how it feels in my hands and how the controls themselves are laid out. The PDP controller feels fine to me, but the layout is odd. The F310's layout is fine, but the shape doesn't feel as nice as the other two. Because of Missile Command I recommend going with a controller for Xbox or Windows. For Windows make sure it's buttons are laid out like the Xbox, so not like the RumblePad 2. I decided to keep two of the F310 controllers in the car. While I've not played it head to head yet, I did test out 2-player Beach Buggy Racing with 2 controllers plugged in. Strangely enough both players auto-accelerated at the start, but once I hit the left trigger for brake I had to hit the right to resume moving. I initially used an old USB 1 hub to plug them into a single port, it worked fine. I now have a Jeda USB Hub, which I highly recommend.

The 20 was just a guess. Step thru the program with the TIA tab visible and you'll see the source of the problem: TIA Output is in the middle of the first bit for right side PF1 Bit pattern in A is %10010000 A was just written to PF1 Bit pattern in PF1 is still %00101000 Queued Writes, there's a 2 clock delay for writes to a playfield register to take effect After stepping one more instruction: Bit pattern in PF1 is now %10010000 Queued Writes have been processed So the write to PF1 occurs too late for the right side. If you change that SLEEP to 19 you'll see: Note: it's possible you'll need to adjust the SLEEP value again when you get the data in place for PF2.

17,100

Secret Quest uses F6SC, 16K of ROM + 128 bytes of extra RAM, which is used by Jr. Pac-Man. The Jr. Pac-Man cartridge works just fine, so I would expect the same for Secret Quest - at least with the Stella 6 R77 software installed.

I installed Stella 6 on my R77, it's easy to do and highly recommended. My Solaris cart works just fine. I don't have a Secret Quest cartridge, but the ROM works fine. The emulator on the original SD card that came with my R77 stopped working for some reason. I looked but was unable to track down the original software to reflash the SD card, so I have no way to test if a stock R77 works with them or not.

Adjust the delay loops as needed to get back to 262 scanlines. Remember the title screen kernel repeats everything twice, so if you removed 10 rows of 0's you need to delay a total of 20, not 10. I noticed the extraneous pixels before, that's how the image is in your data tables. Looking at the M and G in the lower-left: They are drawn using this data: I made a a minor edit using Stella to this: and they now look correct

Nice! You can eliminate those padding bytes and save a lot of ROM by putting a WSYNC loop above and below your title screen kernel. Something like: ldy #32 BeforeLoop: sta WSYNC dey bne BeforeLoop ldy #96-32 ldx #2 ScanLoop_TitleScreen ... dey bne ScanLoop_TitleScreen ldy #32 AfterLoop: sta WSYNC dey bne AfterLoop rts

Atari NTSC vs PAL vs SECAM

A new option to Download My Data showed up in the app. When you tap it it asks where to put the data, I opted for email and sent it to myself. The daily view lets you select the date - it's a little kludgy though, you tap < or > to move between dates. Data is broken out into 5 minute buckets for daily data, daily buckets for monthly data, and monthly buckets for yearly data. data_today.csv data_yesterday.csv data_august_1.csv data_week.csv data_month.csv data_year.csv

To double up the playfield scanlines like you want, make your KernelLoop something like this (untested). The X register controls how many times each Y value is used. ldy #$60 ldx #$02 KernelLoop: sta WSYNC lda $1100,y sta PF0 lda $1160,y sta PF1 lda $1200,y sta PF2 SLEEP 20 ; try other values too, this is a guess lda $1260,y sta PF0 lda $1300,y sta PF1 lda $1360,y sta PF2 dex bne KernelLoop ldx #$02 dey bne KernelLoop rts

Yes, no image. I stepped thru the code again and the X loop is basically making each time thru the Y loop output 2 scanlines. However, due to how the playfield works, that will automatically give you the wrong results. Even if your timing was correct for the playfield updates you'd get the wrong visual every other scanline: scanline with left and right looking correct scanline with prior scanline's right side values on both the left and right side scanline with left and right looking correct scanline with prior scanline's right side values on both the left and right side ... I also spotted another issue with the playfield updates. You're reading from the table at 1200 for both PF2 updates. I did a little ROM hacking by shifting the right PF2 updates and changing the middle to use a JSR to an RTS instruction and 4 NOPs - that wastes 20 cycles, the equivalent of a SLEEP 20. Seems like the second PF2 would be using data at 1360, so I changed that as well but turns out there's no data there. ROM duckgame-dgs-hack.bin

I used the Developer Key COMMAND-COMMA on my Mac (ALT-COMMA on others) to switch to debug color mode. Purple is used for the playfield, with different shades for PF0, PF1, and PF2. Then hit the ` key (to left of 1, above TAB) to enter the integrated debugger. Next Right-Click in the TIA Display and select Fill to scanline That will advance the program to that point in time. Everything below is greyed out to show it's part of the prior frame. That little white dot on the left edge is the current position. If you step thru the program a few times you'll see the following: So basically you're writing the playfield values for the right side of the screen before the left side has finished being drawn. Looking at this part of the program, you do sta PF2 twice in a row for some reason. Replace the second one with a SLEEP macro to delay when the updates for the right side occur. I'm guessing around a SLEEP 20 would do it. Also remove that ldx #$05/dex/bne loop.

10,600 This could use an update. 🤔 DAOT Diabolical Automata Orbiting Threat

light sixer - crashes right away after hitting FIRE to starting a game 4-switch - game starts playing after hitting FIRE, but within a few seconds the screen starts to jump up/down, become scrambled, then crashes evil7800 - plays just fine

Depends on the TV, most can handle some variation from the specs but the further from 262 the greater the chance it it won't work for somebody. You also need to make sure it's consist over time. If you normally output 270, but sometimes output 271, then the screen will noticeably jitter up/down whenever the count changes.

$73 for May, was $130 last year (solar only active for half this billing cycle) $35 for June, was $180 last year $60 for July, was $235 last year $10 for August, was $302 last year Do note that I was out of town for 10 days during this billing cycle, during which time my AC was set to 90° F

No, though having 263 scanlines will cause the color to become black and white on PAL consoles. They require an even number of scanlines for the color to work correctly.

In Stella load up Combat and in the debugger enter the command trapwrite RESP0. You'll find that the reset is only used at the start of a game to set initial positions. After that HMP0 is used to move the tank left/right. Same for RESP1 and HMP1 for the other tank. For the player's shots the RESMP0 and RESMP1 registers are used to center the shot within the tank, then the HMM0 and HMM1 registers are used to move the shots left/right. You can also reference the source for Combat, it's available at MiniDig.

Hmm, I just tried both versions of the demo on my Encore. Both start up fine, I can see the splash screen and title screen, but both crash when I try to start the game. My C=1084S handles PAL frame rates just fine, I've used that ability with my Amiga since '91, so it's not that.

Added links to examples and a 4th issue, "Guest" posts.

The horizontal lines are actually kind of nice, would be useful to break a long blog entry into easier to see sections. Is that something that could be added like the super/subscript was?

Good to know, I'll stop with this experiment then. Syntax highlighting of code blocks for 6502/assembly would be nice - would that be something easy to add?