SeaGtGruff

There should be some RGB value trimming for some of the colors. I don't know if you took that into account, but the final version you posted looks really good!

I took Trebor's new 7800 NTSC palette and made a Stella-compatible version for the 2600. (See the original thread here.) First I removed the odd-numbered colors. A Stella palette file includes the PAL and SECAM colors, too. For the PAL colors I just copied the NTSC colors, replaced hues $1, $E, and $F with hue $0, and scrambled the remaining hues ($2 through $D) into the PAL order-- so the "PAL" colors are really NTSC colors, just reduced in number and scrambled. For the SECAM colors I used the SECAM colors from Stella's default palette. The attached stella.zip file contains ten files-- nine pictures plus the stella.pal user-defined palette file. The nine pictures (shown below) display the default Stella palettes, the Z26 palettes, and the user-defined palettes, for NTSC, PAL, and SECAM. Stella's default palette - NTSC: Z26 palette - NTSC: User-defined palette - NTSC: Stella's default palette - PAL: Z26 palette - PAL: User-defined palette - PAL: Stella's default palette - SECAM: Z26 palette - SECAM: User-defined palette - SECAM: stella.zip

I made a Stella-compatible version for the 2600. I'm posting it in the emulation forum.

Thank you! I'm looking forward to trying these out.

Atari 2600 -- You forgot to mention the joysticks. They wear out or break easily, especially after a lot of "intense" usage.

I use DIS6502. It's designed for the Atari 8-bit computers, but you can also use it to disassemble Atari 2600 ROM files (or any other programs written in 6502 machine code) if you replace the default equates file with equates for the target machine. I've created an equates file with address labels for the TIA and RIOT if you're interested (attached). One shortcoming I'd like to see fixed is that DIS6502 doesn't support labels for address $0000, but that's not a big deal. You need to load a 2600 ROM as a "raw" file, then specify the starting address-- in many cases that would be $F000, but I always scroll down to the end of the ROM file to see what address page the RESET vector is pointing to, then I use an appropriate starting address. For example, if RESET is pointing to $D21A, I would use $D000 as the starting address. Note that if you want to load a bankswitched ROM you'll need to split it into multiple files-- one bank per file-- but if each bank uses different addresses you can load them one after the other with the appropriate starting addresses and have all of the banks loaded at the same time. DIS6502 will automatically disassemble the code as best it can, but that doesn't always work very well with Atari 2600 ROMs because DIS6502 doesn't know the best place to start disassembling from. I usually undo all of the automatic disassembly, then begin manually disassembling the ROM by changing the last 4 or 6 bytes to labels, and disassemble from the addresses (labels) that the vectors point to. It can be a bit tedious, but you can save your disassembly and continue in a later session if necessary. Also, once you've saved your disassembly you can load it into some other editor and modify it as desired-- for example, changing $00 to its appropriate read or write label. The attachment contains the following equates files. You should unzip the attachment into the folder where DIS6502 is installed and overwrite the existing atari.equ equates file. 2600.equ - These are the equates for a normal Atari 2600 ROM. 2600tigervision.equ - These equates are for a Tigervision ROM (3E or 3F bankswitching), which moves the TIA equates to $40 and above. 800.equ - This is the default Atari equates file, which I renamed because the equates are for the Atari 8-bit computers. atari.equ - This is basically a copy of the 2600.equ file, renamed so DIS6502 will start up with the Atari 2600 equates (it automatically loads the atari.equ equates file by default). I commented out the $00 equates. atari.equ_save - This is a renamed copy of the original atari.equ file, exactly the same as the 800.equ file except for the name. 2600.zip

Well I'm hoping the MIDI2600 will still be sold in the store, because I'd like to buy one. It's still listed, but you can't add it to your cart. The guy who created it is no longer selling it, so I'm worried that means the AtariAge store won't have it anymore, either.

I've collected a lot of 2600 emulators. My copy of VCS2600 has a date of 10/20/1996, but that's the "r7" (release 7?) version. VVCS was also released in 1996 (v0.60 was dated 07/25/1996). A26 (v0.15) was also released in 1996 (12/11/1996). And V2600 (v0.81) was dated 03/25/1997. I don't know when the initial versions of those emulators were begun or when they were released.

I don't remember the name of the game (I want to say Choplifter but I'm not sure), but I read there was one where the red, white, and blue of the American flag was done with artifacted colors. And I'm not sure which chip or chip version the Ultima games were designed for, but I know that Ultima III looked like crap on my GTIA XL and XE computers-- the grass and water colors were totally wrong.

"If you blend it, they will come (out with a newer chip version that shifts the color signal slightly and makes your artifacted colors different)."

As far as game compatibility, don't some games *require* the CTIA for proper (intended) color artifacting? I'd keep the CTIA computer for those games, and play the rest on a GTIA computer.

I've been thinking that proper "fixing" of the sound code might require adding a separate thread for the sound, otherwise I'm not sure you can emulate the way the frequency counter can lag when changing frequencies, or other possible quirks resulting from changing the audio control register at different points during the poly-5 and poly-4 output streams-- for example, the WAV files I ripped from my heavy sixer show that sometimes the wave pattern of the poly-5 output stream can be flipped upside-down (1s and 0s interchanged). Is multi-threading a possibility, or is it pretty much ruled out?

Sometimes if one label wasn't found you end up getting a bunch of unresolved symbols instead of just the one. In this case I'm guessing that "mul8" is the culprit, because it's a routine found in the "div_mul.asm" include file, which is *not* included unless you tell bB to include it. Try adding the following line at the beginning of the program and compiling again: include div_mul.asm

Abraham Lincoln in the 24th-and-a-Half Century: Communist Zombie Killer

I was initially disappointed with the game when I bought it way back in the day, mostly because it's just the one screen that never changes. But I played it anyway, and found that I *kept* playing it. Yes, the difficulty ramps up, but that helps keep the one screen more challenging. I got to be pretty good at the game, meaning I could rack up a fairly respectable score before finally losing my last spare life, but I don't think I ever rolled the score.

I'm not familiar with MADS, nor am I familiar with Atari 7800 programming, but in general you can't have code that uses the same physical addresses, such as org $8000 org $8000 org $8000 When writing bank-switched games for the Atari 2600 with the DASM assembler, the normal procedure is to code the ORG addresses so they define a continuous and contiguous set of ROM banks. Note that for this purpose you can start with an ORG of $0000 if you want because the ORG addresses will define the memory within the finished ROM image file, but for the 2600 it's common to start with ORG $1000. So if you wanted to assemble a 16K ROM for the 2600, made up of four 4K banks, you could use ORG addresses like this: ORG $0000 ORG $1000 ORG $2000 ORG $3000 When it's compiled, the ROM file will be a 16K file with no "gaps" between the banks. But then you need to use RORG to relocate the code in each bank so the addresses fall within the proper area of the address space, like this: ORG $0000 RORG $9000 ORG $1000 RORG $B000 ORG $2000 RORG $D000 ORG $3000 RORG $F000 Those aren't the only RORG addresses that would work for the 2600-- you could also use RORG $1000, RORG $3000, RORG $5000, and RORG $7000, for example. For the addresses you listed, I would suggest something like this, or some equivalent with a different starting address: ORG $0000 RORG $4000 ; fixed code and data in 16k rom ORG $4000 RORG $8000 ; bank0 code and data ORG $8000 RORG $8000 ; bank 1 code and data ORG $C000 RORG $8000 ; remaining banks filled with $ff ORG $10000 RORG $8000 ; remaining banks filled with $ff ORG $14000 RORG $8000 ; remaining banks filled with $ff ORG $18000 RORG $8000 ; remaining banks filled with $ff ORG $1C000 RORG $8000 ; remaining banks filled with $ff ORG $20000 RORG $C000 ; fixed bank 7 code and data The ORG addresses would give you a 144K ROM image file, but the RORG addresses would control what addresses are used inside each bank.

I redid my old example to do random colors. test_player1colors_in_RAM.bas test_player1colors_in_RAM.bas.bin

I found this old example I made of pointing player1's color table to RAM. It scrolls through all 128 colors, but it should be easy to change it to do random colors. set kernel_options player1colors dim p1color = a dim p1color_row1 = a dim p1color_row2 = b dim p1color_row3 = c dim p1color_row4 = d dim p1color_row5 = e dim p1color_row6 = f dim p1color_row7 = g rem * now set the player1color pointers rem * to the address of variable a (or p1color) asm LDA #<p1color STA player1color LDA #>p1color STA player1color+1 end rem * define the player1 shape player1: %00111100 %01111110 %11111111 %11111111 %11111111 %01111110 %00111100 end rem * set the initial color for each row p1color_row1 = $00 p1color_row2 = $02 p1color_row3 = $04 p1color_row4 = $06 p1color_row5 = $08 p1color_row6 = $0A p1color_row7 = $0C rem * position the player player1x = 76 player1y = 48 rem * now do the display loop loop drawscreen rem * cycle the colors p1color_row1 = p1color_row1 + 1 p1color_row2 = p1color_row2 + 1 p1color_row3 = p1color_row3 + 1 p1color_row4 = p1color_row4 + 1 p1color_row5 = p1color_row5 + 1 p1color_row6 = p1color_row6 + 1 p1color_row7 = p1color_row7 + 1 rem * adding 1 instead of 2 makes them cycle a little slower goto loop Edit: Pasting the code didn't work too well-- use the attached source instead. test_player1colors_in_RAM.bas test_player1colors_in_RAM.bas.bin

How about pointing player0color to a section of RIOT or Superchip RAM and then changing that RAM to random color values?

Have you seen this page? Edit: Eh, you beat me to it while I was searching.

Ahh, nevermind! I just realized that my Crimson Editor tools are set up to compile with the bB version 1.1 files no matter *which* folder my program code happens to be in, so I guess "1.01" is equivalent to "1.1." I do have a whole bunch of different versions of batari Basic zip files, but I'll have to do some more testing to figure out which version of the compiler was the first one to allow "on...gosub."

There are quite a few free hex editors out there. If you load the ROM in a hex editor you can search for a particular hex value. Also I believe Hack-O-Matic 3 lets you view hex values as their equivalent TIA colors. That doesn't mean that if you find a particular color or hex value that it's necessarily being used as a color value, because it might be an assembly opcode, or the lo byte or hi byte of an address, or some piece of non-color-related data.

I don't know if 1.01 is still posted on the web somewhere (I would think so, if 1.1 is currently in "beta testing" phase)-- but if not, I probably have a zip of it that I could send to you later tonight. Note, if you try to PM me it probably won't work right now as my box is 100% full. I'll clean it up later tonight to free up some room, then PM you.

A low-pass filter lets low frequencies through and filters out high frequencies, whereas a high-pass filter lets high frequencies through and filters out low frequencies, right? What about a high-pass filter, does any of that look like a high-pass filter? I ask because I was thinking Atari might have wanted to include a high-pass filter to help prevent any possible damage to the speakers of TV sets. That is, if the AUDCx=0 and AUDCx=11 settings put out a steady stream of 1s, isn't that like an "infinitely low" frequency signal? Would setting AUDCx to 0 and AUDVx to 15 and leaving them like that have the potential of damaging or wearing out a TV's speakers? Wasn't Atari responsible for inadvertently damaging some people's TV sets in their earliest videogames (before the VCS) because the game images got burned into the phosphors from being left on too long, and that's why they made sure games included a color-cycling routine when left on without any input from the user? That experience may have made Atari all the more aware of the need to prevent any possible damage to the speakers. Also, would a low-pass filter and/or high-pass filter help in preventing RF interference from the VCS? Edit: My question about RF interference may have been dumb (I freely admit my lack of knowledge in these areas). I was thinking in terms of the different ranges of frequencies used in radio or TV or whatnot. I guess a low-pass filter would help in filtering out very high frequencies from the harmonics created by some of the poly waveforms. My main reason for wanting to know if the VCS includes high-pass, low-pass, or band-pass filtering is because I want to understand how much of the filtering I see in my audio recordings of the VCS are coming from the VCS itself versus from the method I used to record them (VCS to VCR to DVD recorder, etc.).

The DPC+ kernel is optional in bB 1.1, just like the multisprite kernel and bankswitching are optional. As for whether or not you can make your own carts for a DPC+ game, I'd guess that you could-- but you'd have to buy enough Harmony/Melody carts to do your own production run, and any other materials or hardware that might be necessary.