SpiceWare

We're looking to add Kaboom! Deluxe! to the Hack section of the AtariAge Store. We'll need a label, anybody up for that?

Overproduced by quite a bit! Solar produced 134 kWh more than I used, though efficiency loss of charging/discharging the PowerWall drops that down to 113 kWh. After thinking about that, I decided to increase the backup reserve on my PowerWall to 70% to reduce the loss. Of course my billing cycle is the 16th to the 15th, so whether or not I end up with a credit on my next bill remains to be seen.

Thanks! There's a Q & A (Questions and Answers) in the comments below each entry of the Collect Tutorial. Step 4 - 2 Line Kernel and Step 5 - automate Vertical Delay have the most comments, so the 2 Line Kernel is probably one of the most difficult parts of 2600 development for people to understand. Within the Q & A for Step 4 you'll find a more detailed explanation of DoDraw, additional information on how the .byte $2C trick works, and so on. If you still have questions after reading thru the Q & A then post your questions there - it's better if they're together with the tutorial instead of scattered around the AtariAge forums.

I've been pondering on this - maybe it's related to only having 1 Powerwall, which supports everything except AC and car charging. Might be that a power loss when those are active results in #3.

There's a bit of variance with the clock used in Pitfall 2, so different cartridges will sound different. As of 6.1 Stella has an option for you to set the DPC clock, from the change log: This was implemented in issue 502, which includes a reference to this mappers doc: The Stella implementation is defaulting to 20,000 which matches what you've come up with.

You might want to take a look at how Pitfall did it. @Thomas Jentzsch's disassembly of it can be found at minidig. ; Scene generation: ; The 255 scenes are randomly generated through a "bidirecional" LFSR. This ; means, that the process of generating the next random number is reversible, ; which is necessary to allow traveling though the jungle in both directions. ; The random number defines the scene with the following bits: ; - 0..2: type of object(s) on the ground (logs, fire, cobra, treasure etc.) ; - 3..5: type of scene (holes, pits, crocdiles, treasures etc.) ; - 6..7: type of the tree pattern ; - 7 : position of the wall (left or right)

You don't. If you need data from another bank you would need to call a subroutine in the other bank.

This looks like a game properties issue, brought up on FaceBook. Guy's trying to play Im Schutz der Drachen but the joystick doesn't work. Stella IDs it as Dragon Defender, and has it configured for MindLink: If I switch it to Joystick I can control the dragon. I checked DefProps.hxx and found 3 versions of Dragon Defender in there, but only this specific MD5 is configured for MindLink.

Most of the time it's fast enough. It's switched over 24 times in the past year and I've only had to reset clocks 2 or 3 times.

$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 (was out of town 10 days with AC set to 90°F) $53 for September, was $297 last year $42 for October, was $235 last year $18 for November, was $108 last year $28 for December, was $99 last year $12 for January, was $103 last year $25 for February, was $93 last year $1 for March, was $93 last year $7 for April, was $112 last year $364 to date, was $1987 last year Something to also consider is that $364 includes car charging for local driving. Charging costs for road trips was $185 - and that included 2 trips to Wisconsin. April

I've encounter 3 different scenarios with power failures: cutover so fast I don't even notice cutover that flickers the lights. Clocks keep their time, but non-UPS computers might shut down slow cutover that causes lights to briefly cut out, clocks to lose time, and non-UPS computers to shut down I suspect the difference is due to what happened with the power. My guess would be #1 occurs with a clean cutoff, #2 with a power surge, and #3 with a brownout. As such, I've kept my computers on UPSs.

You can change the color registers at any time during the scanline. You can use Stella's Fixed Debug Color mode to get an idea of what's going on. To toggle it use COMMAND-PERIOD on a Mac, or ALT-PERIOD on Linux or Windows (if you're running an older versions of Stella use COMMA instead of PERIOD). An example would be Congo Bongo. In the area I drew the red box in: The brown ground, the green cliffside, and the far yellow cliffside are all drawn using the playfield, which is drawn in purple when using debug color mode. These are the colors of everything - note there are 3 PF registers, which are used twice on each scanline. Each PF register has a slightly different shade of purple.

You left out the 3 cycles for sta RESP0 - (15*2 + 3) * 3 = 99. As for the rest of the difference I believe it's caused by a propagation delay within TIA, but don't know specifics. I do know the results are slightly different for the ball and missiles, I cover that in Step 11 - add the ball object of my tutorial:

DPC+ started as an expansion of DPC - namely a larger ROM size, improved music, and replacing the unused DPC features with others. The ability to call custom ARM code was added late in the design, its use is not required though most DPC+ games do utilize it. I'd recommend to start with the DPC+ Demo I posted, it does not require custom ARM code support. Be sure to check out the comments in the DPCplus.h file, such as this: ;---------------------------------------- ; Random Numbers ;---------------------------------------- ; DPC+ provides a 32 bit LFSR (Linear feedback shift register) ; which is used as a random number generator. Each individual byte of the ; random number will return values from 0-255. The random numbers will follow ; an exact sequence, so it's best to clock them at least once per frame even if ; you don't need the value (this allows the amount of time it takes the user to ; start the game to select a random starting point in the sequence) ;---------------------------------------- RANDOM0NEXT DS 1 ; $00 clock next 32 bit number and returns byte 0 RANDOM0PRIOR DS 1 ; $01 clock prior 32 bit number and returns byte 0 RANDOM1 DS 1 ; $02 returns byte 1 of random number w/out clock RANDOM2 DS 1 ; $03 returns byte 2 of random number w/out clock RANDOM3 DS 1 ; $04 returns byte 3 of random number w/out clock You will need to refer to Stella source files CartDPCplus.cxx and CartDPCplus.hxx for some of the details, such as: void CartridgeDPCPlus::setInitialState() { ... // Initialize the DPC's random number generator register (must be non-zero) myRandomNumber = 0x2B435044; // "DPC+" ... } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - inline void CartridgeDPCPlus::clockRandomNumberGenerator() { // Update random number generator (32-bit LFSR) myRandomNumber = ((myRandomNumber & (1<<10)) ? 0x10adab1e: 0x00) ^ ((myRandomNumber >> 11) | (myRandomNumber << 21)); } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - inline void CartridgeDPCPlus::priorClockRandomNumberGenerator() { // Update random number generator (32-bit LFSR, reversed) myRandomNumber = ((myRandomNumber & (1U<<31)) ? ((0x10adab1e^myRandomNumber) << 11) | ((0x10adab1e^myRandomNumber) >> 21) : (myRandomNumber << 11) | (myRandomNumber >> 21)); } The 0x10adab1e = LOADABLE, and is the signature in the ROM that the Harmony uses to detect a custom cartridge bankswitch driver like DPC+ and CDFJ. I think there's a finished game or two that used DPC+ without custom ARM code, but don't recall which off the top of my head. @iesposta might know.

Here's the DPC patent. Note that table 1 shows all the registers at addresses $000-$07F, but they're located within the cartridge so are actually at $1000-$107F and the mirrors at $3000-$307F, $5000-$507F, ..., $F000-$F07F. DPC contains a number of features that were not used in Pitfall 2 - ways to read data fetchers with nybbles swapped, bytes reversed, rotated, etc. Since nothing used them they haven't been emulated. Some AA topics that could help: How exactly does the Pitfall 2 DPC work? - specifically replies by @batari DPC Music demo by @cd-w DPC Sprite Demo by me

Tesla released an update that lets you better control how the car charges during a power outage: While reading up on it in I spotted a section on how to monitor the system during a power outage that includes a link to Connecting to Tesla Gateway. After following those instructions, to connect your computer/mobile device to the Gateway's WiFI, you can monitor the system via your web browser.

You're welcome! Part 7 - Menu of the CDFJ tutorial goes into detail on how it works, just need to scroll down to the section titled 48 pixel 2 color kernel to see it. CDFJ takes advantage of the ARM chip, but it's not required to create this - @Omegamatrix posted a demo here using a stock 4K ROM:

As @splendidnut points out, that'd be VSYNC. You can turn VBLANK on & off mid-scanline to hide stuff, which is how we originally implemented the two-color 48 pixel kernel that we originally developed for Stay Frosty 2's menu title: However, it's noticeable if the display is mis-adjusted. A clearer example of this using Frantic, display adjusted OK: Display misadjusted:

Output from Stella matches my hardware: Most likely Javatari is not emulating mid-scanline changes to VBLANK correctly.

The loop is basically: Scanline 1: update playfield, update player Scanline 2: update player, calculate values for playfield - but save results for next scanline Using Stella you can see the overspill doesn't occur on the very first frame. Load the ROM hit ` to enter debugger click in the prompt box to give it focus type reset type frame type frame type savesnap type frame type savesnap What's happening is the values in the TIA register only change when you tell them to. If you don't want what's shown at the bottom to repeat at the top then you must change them before the top becomes visible again. Simple fix would be in NextFrame - where you see this: lda #0 sta PFIndex ; reset playfield offset just add 3 more lines: sta PFIndex ; reset playfield offset sta PF0 ; reset playfield sta PF1 ; reset playfield sta PF2 ; reset playfield The shearing occurs because the video output is turned on mid-scanline: ; Wait for end of VBLANK TIMER_WAIT lda #0 sta VBLANK The way to fix that is to add a sta WSYNC so the video output is turned on at the start of the scanline: ; Wait for end of VBLANK TIMER_WAIT sta WSYNC lda #0 sta VBLANK scene.zip

192's the usual target mentioned when talking about the 2600, not 196. It comes from Atari's original in-house documentation, the Stella Programmer's Guide, where you'll find this: Due to how TIA works, the programmer can change those - such as increase the picture to 200 scanlines while decreasing Vertical Blank to 33 and Overscan to 26. The tradeoff of doing that is you get fewer cycles of CPU time for game logic. I checked my games once and found my screen sizes ranged from 182 to 202. You may also find my tutorial to be useful.

No color for PAL happens when an odd number of scanlines are sent to a PAL TV, so wouldn't be the problem. How far down the screen the score is, plus the Funvision at the bottom, implies it's the pirated PAL version.

Past few days have been awesome for production. Additionally it's been in the low 70s, so I was able to open up the house instead of using AC. Next few days will be back into the 80s and rainy, so production will be down and AC will be back on to combat humidity. Will be interesting to see if I manage to finally overproduce for a month or not.

The colors are different for NTSC, PAL, and SECAM 2600s. You can run the ROMs in Stella, use CONTROL + F to switch the display format from PAL to NTSC, and compare with the colors you see with your actual cartridge. NTSC PAL PAL running on an NTSC 2600 NTSC running on a PAL 2600

I guess the February 22nd update wasn't clear - the source code was lost.