alex_79

Thank you for those screenshots! Now it would be great if someone could do the same test with a PAL-N console... PAL-N was used in Argentina, Paraguay and Uruguay. It's 50Hz like european PAL but with color subcarrier frequency very similar to NTSC and PAL-M. I know that PAL-N 2600s do exist, (there's a picture in this page showing the label) but I found no schematic nor pictures of the board so I don't know if they're based on (European) PAL or NTSC versions and if the palette is different.

What happened to VGWIZ's mold? If it's still usable maybe a deal could be made and it could be cheaper than making a new one. I don't think there's anyone else who could really be interested in it, so unless it's purchased by Atariage, it's just a doorstop...

It wouldn't work. The fb2/fb2+ has an extra chip (in addition to the Atari-on-a-chip) called "gizmo" which is a stripped down nes-on-achip. This chip executes the menu at startup (did you noticed that the menu has nes gfx?), then select the game from the flashchip before giving control to the Atari-on-a-chip. You cannot just connect the fb2 flash chip to a standard VCS and expect it to work. http://atariage.com/forums/topic/70550-flashback-2s-flashy-menu-sneak-peak/?do=findComment&comment=866303 http://atariage.com/forums/topic/80539-add-games-to-flashback-2/?do=findComment&comment=983082 The only thing you can use is the case.

PAL-M 2600 consoles use a NTSC TIA with an external board that converts the signal from NTSC to PAL-M. The resulting palette is different from the PAL TIA used in European consoles. I think it's the same or very close to the NTSC palette, as the rom from brazilian 2600 games looks good with NTSC palette in stella. It would be nice to have some screenshots from unmodded PAL-M console using a test rom to show the palette, so it can be added in stella as an option...

They're also a way to pass parameters to a subroutine. Jump to a mirror address according to the parameters that you need to pass before calling the subroutine and it can test the return address in the stack. (the 6507 is a full 6502 internally, so the program counter is 16 bit wide and all bits are stored in the stack when executing a jsr)

You can use the CuttleCart Playbin utility, which will play your binary directly without generating a wav file. Remember to select "Supercharger" as output, else it will generate audio for the CuttleCart which won't work. See here: http://atariage.com/forums/topic/247849-supercharger-and-wplaybin/?do=findComment&comment=3414680

Address line A11 is not connected to a 2k rom, so the rom is mirrored twice in the 4k address space. Addresses '$F7FC' and '$FFFC' both point to location '$7FC' in the 2k rom. These aren't the only mirrors you can use. In 4k rom, address lines A15,A14,A13 are ignored (those pins aren't present at all on the 6507), A12 must be '1' to select the rom and A0 to A11 are used to address the rom. This results in the rom being mirrored 8 times in the entire 16bit address space: $1000-$1FFF $3000-$3FFF $5000-$5FFF $7000-$7FFF $9000-$9FFF $B000-$BFFF $D000-$DFFF $F000-$FFFF In a 2k rom, in addition to that, A11 is also not connected and only A0 to A10 are used to address the rom, so in this case there are 16 mirrors: $1000-$17FF $1800-$1FFF $3000-$37FF $3800-$3FFF $5000-$57FF $5800-$5FFF $7000-$77FF $7800-$7FFF $9000-$97FF $9800-$9FFF $B000-$B7FF $B800-$BFFF $D000-$D7FF $D800-$DFFF $F000-$F7FF $F800-$FFFF You can use any of these mirrors in your program, as they all point to the same phisical memory.

.byte is not a 6502 instruction, but a dasm one, used to insert bytes values directly in the source. The .byte instruction itself doesn't translate into any value in the resulting binary. It is mostly used to insert data tables (like graphics, for example), but in this case is used because there's no way to tell dasm to just insert the BIT opcode without an operand (it would report an error). So the two bytes corresponding to the "lda (),y" become the operand of the BIT instruction (that is, the $2C value), not of .byte. All the data registers (A, X, Y) and every addressable memory location are 8 bit (1 byte) wide. So all load/store instructions read or write a single byte. When you specify a two byte operand, that's the address where that single byte value is to be loaded from or stored to. The lda (Player0Ptr),y has 1 byte as operand because it's a zero-page instruction and only the LSB of the address needs to be specified (the MSB is always $00 in page 0). Moreover is an indirect addressing instruction, so the operand is not the address of the value to be stored/loaded but the address of the pointer to the value (that is, the address where the address of the value is stored). It means: take the address whose LSB is in memory location Player0Ptr and whose MSB is in memory location Player0Ptr+1, add the value of Y to it and then load the value stored in the resulting address into the Accumulator. (and "memeory location Player0Ptr" means the address whose LSB is Player0Ptr and whose MSB is $00)

The instruction "lda (Player0Ptr),y" is not executed at all if the player is not being drawn on the current scanline, because it's skipped using the ".byte $2C" trick. it works because "lda (Player0Ptr),y" is a two bytes instruction: the first byte is the opcode for the "lda (),y or lda Indirect, Y" instruction ($B1, as per the table posted above by Spiceware), the second is the single byte indicating the zero-page address of the operand (Player0Ptr, which is $87 in this case). So, when you assemble the source with dasm, the "lda (Player0Ptr),y" is translated into the byte sequence $B1 $87 in the binary file. (The actual values are not relevant in this case, just the fact that they are exactly 2 bytes). If the player is not being drawn, the carry won't be set after "dcp Player0Draw", so the branch "bcs DoDrawGrp0" won't be taken. Therefore the following instruction will be executed (lda #0), then the 6502 cpu will read the next byte in the binary ($2C). This is the opcode for the instruction BIT Absolute, which is a 3 bytes instruction. (the opcode itself, plus 2 bytes indicating the absolute 16 bit address). The next 2 bytes in the binary are those of the "lda (Player0Ptr),y" instruction, which in this case are interpreted as the operand (the address) of the BIT instruction. So the three bytes $2C $B1 $87 are interpreted as BIT $87B1. Since the BIT instruction affects some of the flags but not the Accumulator, the latter will still be set to 0 and the following "sta GRP0" instruction will therefore clear the player graphics.

Short answer is no. To draw the ectomobile, a combination of player0 and player1 graphics is used. The program keeps making changes to color, position, number of copies and size of both objects while rendering the image. You need to rewrite that part of the code, not just altering a few bytes in a table in order to change it.

You might try to tune the audio inductor. You should use a plastic hex tool like those on this page, but you can also use a metal one. Tuning must be done with the unit powered on and connected to the TV. Keep in mind that a metal tool will interfere with the tuning, so you have to remove the tool after each (very small!) adjustement to check the results. Moreover the ferrite chore of the inductor is quite fragile, so be careful. (the plastic tool is safer also in this regard). I retuned the inductor in the past to convert the signal of a PAL-I 2600 (from UK) into a PAL-G one compatible with my TV (the difference is mostly in audio carrier frequency) and it worked perfectly.

That's normal and the result of the fact that the vcs video signal is mostly under software control and there's not a fixed vertical resolution, nor fixed scanline for the start and end of the picture. Not all of the 262 scanlines are visible on a TV screen and the actual visible area (number of scanlines) varies from one TV to another, as the vertical allignment does (first visible scanline). Stella uses default values so that in most games the image isn't cropped, which means that you often see black borders on top and/or bottom of the image, but you can change those in the "display" tab inside the "game properties" menu or through the command line. On a standard 525 lines NTSC signal there are 486 active scanlines that can be used for the picture (on 625 PAL signal, they are 576). Action-safe area is about 90% of that value and title-safe area is 80% (see here). Since the vcs video is not interlaced, you have to divide those scanlines counts by 2, so the title-safe area (that is, the one garanteed to be visible even on very old crts which crop the image a lot on the borders) is about 194 scanlines for NTSC, which is close to the suggested vertical height in the stella programming guide (192). Safe areas apply also on the horizontal direction, but the TIA already generates a signal which is narrower than the max display area. The result is that you can see black borders also on the sides of a game picture depending on the TV you're using. Since that part of the signal is not under software control and therefore is the same for every game, stella (correctly) never shows black borders on the sides of the emulated display.

Yes, it's ok for me. It takes some practice to master, which is fine. Agreed. Maybe it's because of the smaller play area compared to other games. The trakball is still an improvement, anyway.

Tested on real hardware. On v0.90 controlling the tube direction is indeed problematic, the trackball is too sensitive and the slightest movement cause an unwanted change of direction. I keep the button pressed all the time as well, so I think you could just make the tube to fire automatically and repurpose the button to change direction. Another idea could be to allow the direction to change only when you're not firing. Anyway, I like your solution in version 0.91. Move slowly to back away, and give a quick spin to change direction. It just feels quite natural to me. My vote is to keep it that way. I'm not sure about this, I need to play it a little more. It didnt bothered me that much, anyway. I'd say both player with the same controller, mostly because I don't think many people have two trackballs. Moreover you should take in account the possibility that the two trackballs have different protocols, which I guess would complicate things...

I found the sources and added them in the thread linked above.

The decoder program is in the zip attached in the cart dumper thread: http://atariage.com/forums/topic/185932-my-2600-cart-dumper/ I just checked it and the source is missing (while I'm sure it was included in previous revisions). I have it in another computer and I will be able to post it tomorrow. (I don't know if that could be useful, it's not an example of best coding practices, and probably comments are in italian mixed with bad english...) The executable is included, anyway, so you can try it with the dumper software (you can let it dump itself).

No, those adapters provide a standard rs232 serial port. The "VOX" part of the AtariVox (the speakjet chip) uses a UART serial protocol (like rs232), but with TTL levels (and if I remeber correctly, inverted logic). The eeprom (the savekey part of the AAvox), which is what you need for this application, uses a different protocol (I2C). Moreover, the AtariVox uses a custom pinout to match the signals available on the Atari controller ports, so you still need some rewiring even if you find a commercial adapter with matching signal levels and protocol.

I was aware of that at the time, but I couldn't use it (nor Batari's FB2 dumper), as that specific clone console uses a custom ic which integrates 6507, RIOT and TIA, plus some extra logic to read the console switches and the joysticks as a 5x3 keyboard matrix, to reduce the pin count on the chip. (only 8 pins required for 5 switches and 2 joysticks, instead of 13). Because of that, instead of the RIOT and TIA I/O pins, the matrix keyboard decoder pins are connected to the controller ports and the console can only use standard mechanical joysticks (made of switches without electronics). There's not power pin, no ground pin (the pin corresponding to one of the matrix columns is connected there instead), no RIOT I/O pins and no TIA trigger input (replaced by the 5 matrix rows pins), and no paddles inputs. There's no way to output data on that console, so savekey, serial communication, and even keypads or paddles cannot be used. As for the use in the 2600 music program, using the SaveKey/AtariVox will still require some custom adapter or, if the serial eeprom is socketed, an eprom programmer to transfer the content to a PC.

Just the usual taiwanese pirate hacks, actually. Sometimes you can find some previously unknown variation in those consoles. As an amateur programmer, my goal was just to see if I could do it, and after I had it working, I turned it into a more general cartridge dumper by adding other features such as bankswitch support and serial output. The audio method is still useful because despite the slow speed, it doesn't require any custom adapter. Probably you can reliably use higher speed if using a/v modded console and the routine can be optimized to take less cycles (in my dumper I wanted it to work also on stocK RF, and I focused on optimizing for space usage, as everything had to run from the riot ram). You could also implement serial communication (even bidirectional) in software through a controller port. You cannot reach the high speed transfer like if you use an external microcontroller as in the MCP, but for the small amount of data that you need for this application, it might not be an issue. In this case you only need a TTL to rs232 level converter to connect to a serial port (either a real one or a serial to USB adapter). There are also cheap TTL-serial to usb adapter which don't require the level converter.

What I did was to build an adapter using an in-line mono female socket, a male stereo plug and a short piece of wire. I only connected the tip (left channel) and base (ground) of the stereo plug to the mono socket. If you plug directly a mono plug in a stero socket, the right channel gets shorted to ground which in some cases might cause damage on the audio equipment (mp3 player, pc soundcard, etc)

I used that method a few years ago to dump the built-in games in a clone console that doesn't have bidirectional joystick ports. It was reliable (altough slow), and the console was not a/v modded (I connected it to a portable B/W tv through RF, then used the headphone jack on the TV to connect to the PC soundcard). http://atariage.com/forums/topic/185932-my-2600-cart-dumper/ Here is the routine I used. calling the "Playbyte" subroutine sends the value in the "byte" variable as FSK audio. A '0' (SPACE) is encoded as 1 period of a sinewave, while a '1' (MARK) is two periods at twice the frequency. The data format is as follows: 1 start bit (SPACE) 8 data bits (least significant bit first) 2 stop bits (MARK) Before starting the actual transfer, a leading tone ( a series of '1' ) was sent (calling the "Playbit" subroutine with the carry set), to help the decoding program to detect the start of the data. IF FAST ;1300 baud ; 1 bit = 2736 color clock cycles = 912 proc. clock cycles = 12 scanlines ; AUDF0 values SPACE = 11 ; 1300Hz PAL (1310Hz NTSC) MARK = 5 ; 2600Hz PAL (2620Hz NTSC) TIMER = 14 ELSE ;520 baud ; 1 bit = 6840 color clock cycles = 2280 proc. clock cycles = 30 scanlines ; AUDF0 values SPACE = 29 ; 520Hz PAL (524Hz NTSC) MARK = 14 ; 1040Hz PAL (1048Hz NTSC) TIMER = 36 ENDIF ;AUDC0 value WAVEFORM = 4 ; 01 (pure tone) ;AUDV0 value VOLUME = 15 ;------------------------------------------------------- subroutine Playbyte Playbyte jsr Play_Start_bit ;start bit sec ldx #9 .newbit ror byte jsr Playbit dex bne .newbit ;------------------------------------------------------- subroutine Playbit Playbit ;bit = carry bcs .mark Play_Start_bit ldy #SPACE .byte $2c ;BIT abs .mark ldy #MARK End_bit .tmr_lp lda INTIM ;riot bne .tmr_lp ;------------------------------------------------------- lda #TIMER sta WSYNC sta TIM64T sty AUDF0 rts ;x=0 ;carry set Here's a sample waveform (capture of the clone console through rf using Audacity).

It is generally a bad idea to have multiple controllers connected in parallel to the same port. There are some cases where it is safe to do so (e.g you can have 2 joystick only containig mechanical switches like the standard cx40 or one of them together with standard paddles), but other combinations won't work and could even cause damage to the controllers or the console.

Try the ALT-P key combination to toggle the phosphor mode. Stella has an internal database which allows to set some specific options for each game. Specifically, Paul Slocum's music kit has the "phosphor mode" enabled to avoid the flicker. When you change the rom, the md5sum doesn't correspond anymore with the one in stella database, so the default settings are applied (that is, the phoshor mode is off). If you want the phosphor mode active during development without having to set it on each new version, just use the command line option (-pp yes). http://stella.sourceforge.net/docs/#CommandLine

You need a NTSC demodulator/ external TV tuner (They were used to watch TV on a video projector or plasma TV without built in tuner). The VCR is the cheapest solution, though. If you're using a PAL game in a NTSC VCS, a PAL-to-NTSC converter won't work. The output of a NTSC 2600 will always have NTSC color encoding and channel freequency, even when using a PAL cartridge, but the framerate will be 50 Hz (because in the 2600 that aspect of the video signal is controlled by the software in the cart). I don't think that a video converter exists which can handle such a non-standard signal. Even in that case, the colors would be wrong, because PAL and NTSC TIA chips have a different palette. There's no way to overcome that unless you mod your console with the 2600RGB mod, which completely bypasses the TIA color generation circuitry (you still have the problem of the 50Hz framerate that most NTSC TV cannot accept)

I have that label variation too, and I don't think it's rare at all. If you look at the PAL "super football" carts on ebay right now, the majority of them where the end label is visible, have the misprinted one.