RevEng

Not as it's presently coded. The Atari 8-bit computer version of Petscii Robots expects the snack snes adapter, and the 7800 version uses the snes2atari standard. (wiki link with signal breakdown and driver coming soon) We chose not to go with snack because of it's use of paddle lines, and the timing complications for 7800 and 2600 that paddle reading brings. Plus availability in North America seemed to be an issue for snack, while the snes2atari is a super minimal design, so we were able to make them locally.

Yeah, it's there in a few compilers unofficially, and in C++14 officially.

Sure, but C and most of it's descendant languages don't support binary literal values, so that's not possible here.

You should only use the a78 extension when your rom has an a78 header present. Yours doesn't, which is why people have trouble running your stuff. What you shared is a .bin file. Check out the A78 Header Specification document for more info.

You'll get no arguments here.

Excellent! Good job all around, folks!

Yep, good point! Well spotted.

// ---------------------------------------------------------------------------- // StoreCell - write mode // ---------------------------------------------------------------------------- static inline void maria_StoreCellWide(byte data) { if(maria_horizontal < MARIA_LINERAM_SIZE) { if (data) { byte *ptr = (byte *)&maria_lineRAM[maria_horizontal]; if (data & 0xB0) // high { *ptr = (maria_palette & 0x10) | (data >> 4); } if (data & & 0x0B) // low { ptr++; *ptr = (maria_palette & 0x10) | (data & 0x0F); } } } ...

Yeah, it's not cycle accuracy. At the high level, the problem is the emulator is rendering transparent colored pixels into the buffer, instead of skipping them. I don't see a reason for it in the code, yet.

I know it's not being used in the game, but is the glitch still present if kangaroo mode is compile-time disabled in your source?

Ah, my lack of familiarity with your source strikes again. When I saw the "missing" transposition, I thought I had it. Ok, back to the analysis.

Try this update... // ----------------------------------------------------------------------------// StoreCell - write mode// ----------------------------------------------------------------------------static inline void maria_StoreCellWide(byte data) { if(maria_horizontal < MARIA_LINERAM_SIZE) { if (data) { byte *ptr = (byte *)&maria_lineRAM[maria_horizontal]; if (data & 0xcc) // high { *ptr = (maria_palette & 0x10) | (data & 0x0c) | (data >> 6); // P2 D3 D2 D7 D6 } if (data & 0x33 ) // low { ptr++; *ptr = (maria_palette & 0x10) | ((data & 0x03) << 2) | ((data & 0x30) >> 4); // P2 D1 D0 D5 D4 } } } [edit 1 - updated to fix the nibble tests too] [edit 2 - had to fix the nibble test again. ugh.]

Yeah, my bad. I mixed up your write and non-write functions. Thanks! Nope. It's just a regular sprite. Palette 0 for 160B really means P0+P1+P2+P3.

For the write-mode graphic modes, you should only be using the top bit of the palette. I'm not that familiar with your source, but I think I have this right... static inline void _maria_StoreCells4(byte data) { if((maria_horizontal) < MARIA_LINERAM_SIZE) { byte *ptr = &(maria_lineRAM[maria_horizontal]); #ifdef KANGAROO_MODE_SUPPORTED if (memory_ram[CTRL] & 4) { if (data & 0x03) *ptr-- = (maria_palette & 0x10) | (data & 0x03); else *ptr-- = 0; data = data >> 2; if (data & 0x03) *ptr-- = (maria_palette & 0x10) | (data & 0x03); else *ptr-- = 0; data = data >> 2; if (data & 0x03) *ptr-- = (maria_palette & 0x10) | (data & 0x03); else *ptr-- = 0; data = data >> 2; if (data) *ptr = (maria_palette & 0x10) | (data); else *ptr = 0; } else #endif { if (data & 0xC0) *ptr++ = (maria_palette & 0x10) | ((data & 0xC0) >> 6); else ptr++; if (data & 0x30) *ptr++ = (maria_palette & 0x10) | ((data & 0x30) >> 4); else ptr++; if (data & 0x0C) *ptr++ = (maria_palette & 0x10) | ((data & 0x0C) >> 2); else ptr++; if (data & 0x03) *ptr++ = (maria_palette & 0x10) | (data & 0x03); } } maria_horizontal += 4; } i.e. all references to "maria_palette" in the original h_maria_StoreCells4() should be "(maria_palette & 0x10)" ...my guess now is the 160B robber object has a palette index that's neither 0 nor 4, but some other number.

Ok, bad guess on my part then. Lewis, would you mind shooting me the *.list.txt file in PM? I have another idea here, but I'd like to confirm.

Best guess off the top of my head, is the transparent index for the robber in the game is mapped to one of the alternate transparent indexes, and the emulator isn't handling the other transparent indexes correctly. Assuming the maria object is using pallete 0, the value->color mapping for any 160A pixel (which is 2 bits) breaks down like this... 0=transparent 1=P0C1 2=P0C2 3=P0C3 Assuming the maria object is using pallete 0, the value->color mapping for any 160B pixel (which is 4 bits) breaks down like this... 0=transparent 1=P0C1 2=P0C2 3=P0C3 4=transparent 5=P1C1 6=P1C2 7=P1C3 8=transparent ... etc. So for transparency, you want to skip the pixel update if (value&3)==0, rather than value==0. If I'm right with my guess, that is.

Ok, I know others are thinking it, but I'm gonna be the one to say it. A game this beautiful needs a physical cart release, even if it's as a somewhat re-skinned clone... Call the game MCMXLII (I know it was a joke, but it's definitely avoiding infringing on the 1942 trademark), WWII Pilot, Wartime Pilot, or something else. You have a composition and pokey master interested in making music, which can be equal-but-different to the arcade - maybe some adapted music of Wagner, Prokofiev, or Holst, So much opportunity here.

It's a wonderful achievement, to be sure. Pokey emulation is painful enough on it's own, let alone needing to deal with interfacing to weird 7800 signal timings, and designing around our messed-up supply chain! 👏👏👏

There are two crystals in a PAL 2600, 3.54 MHz and 4.43 Mhz.

He did, once or fivece.

Fixed point numbers are pretty minimally implemented in 7800basic and bB. They really only have extra code for addition and subtraction in variable assignment statements. For arrays, function arguments, etc., the statement isn't even aware the fixed point variable is a 2 byte value, nor does it have 2-byte handling code. The pattern I tend to follow is to dim by grouping the "hi" components together, and then the "lo" components together. When you need to act on them in loop, you can stuff the values in a temporary fixed point variable, act on the variables how you want, and then pull the values out back into the "hi" and "lo" components. So something like this... dim playersxhi = var10 ; to var14 = 5 values dim playersxlo = var15 ; to var19 = 5 values dim speedhi = var20 ; to var24 = 5 values dim speedlo = var25 ; to var29 = 5 values dim tempcalc = var30.var31 ; set this up as a temp place to calculate and store the sum dim tempcalchi = var30 dim tempcalclo = var31 dim tempx = var32.var33 dim tempxhi = var32 ; easy access to the "hi" component of the fixed point number dim tempxlo = var33 ; easy access to the "lo" component of the fixed point number dim tempspeed = var34.var35 dim tempspeedhi = var34 ; easy access to the "hi" component of the fixed point number dim tempspeedlo = var35 ; easy access to the "lo" component of the fixed point number rem ** Set the speed for player 1 and player 2 ** speedhi[0] = 1 : speedlo[0] = 128 ; 128 is 0.5 of 256 speedhi[1] = 1 : speedlo[1] = 64 ; 64 is 0.25 of 256 rem ** Set the X position for player 1 and player 2 ** playersxhi[0] = 10 : playersxlo[0] = 0 playersxhi[1] = 15 : playersxlo[0] = 0 rem ** stuff the needed values into our temp fixed point vars tempxhi = playersxhi[0] tempxlo = playersxlo[0] tempspeedhi = speedhi[0] tempspeedlo = speedlo[0] rem ** do the calculation tempcalc = tempx + tempspeed rem ** pull the temp calculated values out, back into the appropriate vars tempxhi[0] = tempcalchi tempxlo[0] = tempcalclo Instead of using [0], you could of course just use a fixed point directly, but the point of my example is to be easily extended to any number of variables by putting a loop around the logic. The overhead of pulling and storing the variables may seem a lot, but in the grand scheme of things it's not. This is just my pattern for doing things to a bunch of fixed point numbers. Other people may have other patterns.

7800 dev has a bit of a steep curve between starting and getting intended game stuff on the screen. IMO dealing with data structures that need to be perfect in 6502 assembly makes it a tougher playground than the 2600, let alone the 8-bit computer family. That said, you seem to be past the tough bit now. Welcome to the party!

Correct

Every time plotmapfile hits a chunk of characters with a different palette, it has to create a new character object. So it's normal that using characters sticking to one palette throughout your plotmapfile would generate a lot less data than spreading the characters on your display across 2 or more palettes. Nothing leaps to mind as to your corruption issue, though.

Hah! I didn't have the faintest glimmer of recognition, since they fit into the game perfectly. Glad you were able to make use of them!