Tjoppen

DIsassemble (or look in Stella's debugger), look at where it does STA ENABL, then think really hard and change the appropriate ones to two NOPs ($EA $EA)?

Updated the talk page with all prods from my thread on pouet: http://pouet.net/topic.php?which=8537&page=1 Serious business

I've been experimenting a bit with the SCORE flag myself. Didn't know bB supported it. Neat little demo.

Certainly. The problem is lack of ROM space for anything else. I've worked out how to cut the size of the tables down down enough to make something like this a pratical effect. I might incorporate something similar in a future prod..

The Byte Before Christmas will use both joystick (left) and paddles (right). In Bell Hopper you can switch between either controller by pressing either controller's button. It works great

Thank you I've of course scored a bit higher than a few millions.. Too bad the cartridges got delayed by RL stuff, but hopefully we'll be able to get them out within a reasonable time.

For further comparison, I managed to squeeze a recording of myself saying "Hello world! 1-2-3-4. He saw the cat." into 4k with not a single byte to spare. Unfortunately I seem to have misplaced the binary and the project itself. This annoys me a bit, but hopefully I'll find it later.

See this thread: www.atariage.com/forums/topic/184034-question-digitized-sound-on-atari-2600 Basically, you either bang out PCM data in AUDV0/1 every couple of scanlines (raw or compressed) or you write a really clever encoder that picks AUDFx/AUDCx values every frame that best matches the input audio's spectrum. As for size: A two syllable word is what, half a second? If you use raw 4-bit 8 kHz audio that's 2k of ROM. If you use something like my 1-bit ADPCM encoder that goes down to 512 B + 64 B tables. AUDFx/AUDCx values for 25-30 frames is less than 100 B depending on how you pack them.

Don't forget that as soon as you want to make money off of something like this, you're an entrepreneur. Signed manuals/cartridges is an idea I've mulled over - that would probably win you over a whole bunch of collectors. I wouldn't expect to make much money though, as others have pointed out. Ah, and DRM is a mostly pointless endeavour, partly due to this community being rather small and partly due to the Church–Turing thesis.

>I am guessing the 128 bytes of RAM are mapped in Zero Page. What addressed RAM locations are available to the programmer? $80-$FF >Is there enough room to write useful rewriteable code? Well, there's 128 bytes.. Subtract maybe eight bytes for stack and overall state. One of my demos makes use of a ~100 B kernel where constants are modified during VBLANK. >When turned on will the 6507 sometimes randomly be in BCD mode? Should I always do a CLD to make sure it is in binary mode? I think so >Is the reset button a hard or soft reset? Does the hardware do a hard reset right after power up? Soft. >What are "mirrored" addresses in the 2600 memory map? How are they used? Certain adress pins are ignored in some cases. Usually you don't have to worry about it - just use whichever adress is OK. >Does DASM support undocumented, but often used, opcodes? Yes. >On a stock VCS and 4K cartridge what is the address of the first opcode to be run on power up? I am guessing $E000. Reset vector is at $1FFC (aka $FFFC) >The VCS was introduced when all TVs were Cathode Ray Tube based. Any modification to code/timing needed to be made for modern TVs with LCD, Plasma, LED, etc. displays? Nope, assuming said TV takes a normal PAL or NTSC RF signal. >What make and model of PROM do you recommend for cartridges? The cheapest? The machine runs at ~1 MHz, so speed is no issue. >How do you get the binary code from the PC to the 2600 for testing? PROM burner each time or perhaps some type of DIY serial device? Harmony cartridge >Does anyone manufacture the handled cartridge cases, ala Air Raid, Enduro, anymore? Those are SO cool. No idea >Any public domain graphic driver subroutines that handle drawing and raster timing efficiently? Best to write them from scratch for the specific game? You mean kernels? It's usually best to write them from scratch IMO. >How much should a used 2600 VCS console sell for? Is it better to get the 7800? Any caveats to look out for when shopping for one? Maybe $50-$70 USD?

Commence link dump: Binaries and source code: http://www.acc.umu.s..._by_Tjoppen.zip Pouet page: http://pouet.net/prod.php?which=57530 Youtube: http://www.youtube.com/watch?v=tQ4S6NgT0s8

DASM is rather buggy, and the code is... not pretty. It also does not adhere to C99 and pretends to maintain compatibility with 80s computers.. So yeah, I'll have to check out CA65.

You guys might like this, so I thought I'd post it here as well: http://pouet.net/prod.php?which=58185 http://www.youtube.com/watch?v=NFF1LLYxBxI

4096?

I like it

I can confirm that Stella's PAL colors differ from those of the real machine. Yes, different hues have markedly different intensities. Stella gets sad if you start doing unusual stuff like foregoing VSYNC. Most importantly the audio starts stuttering - try running xSqueeker and you'll see. There's also an alignment issue if you let sprites roll around the edges of the screen. Like if you have P0 and P1 in the same position and set HMP0 = $10 and HMP1 = $F0 and repeatedly do HMOVE they won't meet back up in the same place - on a real machine they do. The above applies to Stella 3.4.1 - I don't know how the latest development version behaves. MESS deals with the above much better. Also beware that none of the emulators seem to deal with lack of VSYNC "properly", as in showing the screen rolling. edit: The message here is that if you don't have a console + flash cart (like Harmony) you should get them or ask someone that does to test your prods before release.

Looks entirely doable to me. There's rarely more than two moving objects per row (or even on screen) and the backgrounds could be done using an assymetric scrolling playfield. It might need more RAM to hold the playfield data to enable scrolling. You could perhaps make a rather clever kernel that rotates the data into a line buffer, like the rotozoomers in my most recent demo does. That'd probably mean an 8 line kernel (approx). Then your biggest concern would be ROM for the levels.

Laptop, Makefile (make, make run, make dist), DASM, gcc (for generators), kdevelop, git (both for version control and offsite backup via push), Stella, Harmony.

Ah, that makes sense. In fact, detecting that the data bus is being driven isn't terribly hard. For each data pin you do something like put a series resistor and measure the voltage across it. If the 6507 is reading then the voltage across the resistor is zero. If there's a positive or negative voltage over the resistor then the 6507 is trying to write a bit that differs from what you're reading off of the RAM. A voltage of zero can also mean it's trying to write what is already in RAM. If you check all eight data pins and either of them has a non-zero voltage then you've got a write. You can't detect the 6507 attempting to write what is already in that position in RAM, but that's obviously not an issue. edit: You might have to couple the above with somewhat tricky timing logic though - probably an RC circuit to delay the write-enable (WE) signal. Summary: Stick an XOR gate on both ends of a resistor on all data signals, OR all eight XOR outputs together and AND that with CS -> WE.

TL;DR The cart has no R/W line - A7 or A8 is used for that instead, hence the separate memory areas. The 6507 has 13 adress lines (A0..12), not 12. Page 0 has the TIA and RAM mapped to it, at $00-$2C and $80-$FF respectively Page 1's upper half is a mirror of the lower half's RAM (A8 is ignored). Not sure if the TIA is mirrored too Page 2 ($0200-$02FF) is used by the PIA/RIOT (upper half at least) Pages 16-31 ($1000-$1FFF) are used for the cartridge, hence A12 == CS What may be confusing to some is that most coders here prefer to say the ROM starts at $F000. Remember that there are no A13..15 pins though, so it's really $1000. Very mysterious how that can work without an R/W pin. My guess is 4A50 uses deep knowledge of 6507 signal timings to accomplish this. The documentation I found seems to back this up: "Unlike most 2600 RAM+carts, RAM may be read and written at the same address without restriction." [1], together with only D0..7, A0..12 and power being available to the cartridge must mean something funny is going on. [1] http://www.casperkit...lla/cartfmt.htm , "fixed" version at http://www.acc.umu.s...s/vcs/4a50.html

xSqueeker is up: http://pouet.net/prod.php?which=58051

Sadly, we're still missing an upload of "xSqueeker" (see http://pouet.net/res...ich=438&when=11 ). Perhaps we should pester the guy (Szuwarek) or Grey/MSB. And yeah, the demos do work on the real thing (mine at least). I remember clearly because I had to fix a VBLANK mistake to stop the screen scrolling (oops). Here's a short summary of how my effects work, in the hope of more/better future prods: Text scroller: Just a frame buffer drawn using an asymmetric playfield Twister: Mostly tables and clever use of the priority flag in CTRLPF. HMxx values are computed on the fly Rotozoomer: A one-line buffer (two bytes, GRP0/GRP1) computed on the fly, x and y coords accumulate dx and dy respectively and are compared to form each pixel. Optimization could have allowed 24 horizontal pixels I think Plasma: In each line, look up leftmost pixel in table and stick in COLUBK, then do 10x ADC #Imm + STA COLUBK, where the #Imms are modified during VBLANK (self-modifying code). Stagger and interlace for 22 horizontal samples Pinwheel: 768 bytes of bitmap data form eight frames of one quadrant of the shape, mirrored horizontally and vertically (sort of). The few cycles left over were enough for the greet graphics

I haven't encountered it on PAL since doing some major optimizations. I was hoping this wouldn't happen in the NTSC version since I moved half of the logic to overscan. It's basically due to a perfect storm of circumstances leading to the logic in vblank just barely taking too long, which is rather hard to debug. One minor idea I had for "fixing" this is to check for negative INTIM values, like: WaitForVblankEnd lda INTIM #if !PAL bmi WaitForVblankEnd_Overflow #endif bne WaitForVblankEnd WaitForVblankEnd_Overflow ... The attached binary does this for both INTIM loops in the NTSC version. Please try it out and see if the problem persists. It should at most manifest as a rare slight vertical offset to the screen instead of a massive "flash".. Bell Hopper (NTSC INTIM hack).bin

It is like the national debt but lower. I'm determined to beat Tjoppen's high score. So far I'm at 8,87521745E17. I've actually gotten quite a bit higher while developing and fine-tuning - somewhere around 1e30 - 1e40 Regarding cartridges, that seems like a fair bit of work (box design, manual, not counting fabrication). However, I'm not opposed to this being part of a holiday cart as I saw someone suggest. Finally, it's good to hear the NTSC port works fine. Hopefully I'll remember to make future projects more portable.

Glancing at the code it looks mostly DASM compatible. What kind of errors are you getting? I confess I haven't attempted to asssemble it myself. Don't forget that you need a " processor 6502" line at the start of the file.