alex_79

Video_Pinball_schem.pdf

CLUM is indeed composite luma, that is the analog B/W composite video signal I was talking about in the previous post. CCOLOR is just color( or chroma). "Composite color" doesn't have any meaning. The extra "C" is probably just a typo in labeling the IC pins. No because, as I said in the other post, that analog composite signal is useless for an UAV board, as it needs 3 separate, digital "luma" signals and a digital "sync" one, none of which can be found on a single chip junior. You can for sure get s-video and/or composite out of that console, but not with an UAV board. Since the console is quite rare, I'd probably just leave it as is and search a more common 3 chip Jr for modding purposes...

There is no schematic of the production single chip Jr console. The "Jan" schematic available is of an early prototype and doesn't match the actual consoles that are out there. The most obvious difference being that the chip in the schematic is a 48 pin one, while the actual "Janice" produced is a 64 pin one (see also this thread).

The signals needed by the UAV mod (3 digital "luma" signals and 1 digital "sync" one), are not available anywhere on a "single chip" junior, as the Janice chip combines those internally and only outputs a single B/W composite video signal on pin 29 (and the color information on pin 31). So the UAV cannot be installed there, although it should be quite easy to obtain a composite and/or s-video signal out of it with a simpler mod. Here is the pinout of the Janice chip (taken from this Ben Heckendorn's video). Note that the known "Jan" schematic available online is of an early prototype and doesn't match the production one. The main difference is that the Janice chip in the schamtic is a 48 pin IC, while the one found on the actual 1-chip Jrs is 64 pin. There's also a "Jan Programmers' guide" which also has a pinout for a 48 pin chip, and that doesn't match the one in the schematic! 2100_single_chip_console_NTSC.pdf JAN_programming_guide.pdf So, tracing the board would surely be nice, but a scan of it with the components in place wouldn't help much, as they cover some of the traces. You'd need to A - remove every single component, taking note of each of them (part number and/or value) and where it goes in the board B - scan the bare, unpopulated board on both sides. That's what has been done e.g. here for the SECAM model.

A high res scan of the board is only useful to trace it if you completely desolder every component first (and if you take note of the value/part number of each component and where it goes on the board). Note also that the "Janice" chip doesn't have the separate digital luma and sync outputs like the standard TIA, but only a single composite analog luma signal. So the UAV is not suited for this console. Anyway, please open a new thread (with a sensible title) for this in the main 2600 forum or, better yet, in the hardware forum, as it's completely off-topic here. The purpose of this thread is to list the serial numbers of known single-chip Jr. consoles, not discussing how to add a video mod to them.

All 2600 consoles and compatibles/clones have the same capabilities. But you could detect extra hardware attached to it (savekey, AtariVox, Pluscart internet connection, etc) It's possible (it's used sometimes to dump cartridges using the 2600 console itself), but it's not 100% reliable (pulling out the old cart doesn't cause problems usually, but the program crashes sometimes when you insert the new one), and likely not 100% safe too. Not something you want to use in a game.

Yes, it looks a sort of shrink wrap. The edges look weird, though, as if it's folded there.

They're not duplicated, but resized and repositioned on each scanline. Single step through the code in the debugger while looking at the TIA tab to see exactly how.

I find the board interesting too. There's an unpopulated footprint for another 24 pin chip below the ZIF socket, six pads probably intended for switch(es) or jumpers on one side, and way too many components for a simple 2k/4k board: 4 ICs, plus 3 resistors and a capacitor are visible on the picture. The board could likely be configured for bankswitched games, although it only seems to be set up for simple 2k and 4k ones (the couple of jumper wires visible in the pic might be a modification to disable bankswitch). It would be nice if it could be traced.

The ball shares color with playfield, not with missiles and players. Also note that the players can also be set to 2x or 4x size and the missiles/ball also to 8x size. Plus each object can be repositioned on subsequent scanlines, and they can be interleaved. Number of copies and size can be changed on each scanlines too. Objects with lower priority will only be seen through the "holes" of the ones that are on top of them, creating what seems a high res multicolor sprite. If you have the rom, then just enable the "fixed debug colors" (ALT+"."), and/or turn each object on or off with ALT+ one of the letters from "Z" to "N" on the keyboard.

Apparently it is possible to add a "featured" list to the board index page that will show those topics: https://invisioncommunity.com/forums/topic/397705-hq-featured-topics/ Anyway such list doesn't seem to be currently enabled on AA.

I don't think that would help. The rom posted in 2015 has a bug and it won't work anywhere, no matter how you swap the banks or what board you use. The one that Thomas posted will work just like Rom Hunter's one. The bytes that differ between the two are irrelevant, as they don't change in any way the flow of the program. It's likely an hardware issue with the board itself, IMO. By your description It seems to always start in one bank, which is the one with the starting light animation, then it switches correctly to the other one (straight road) to start the game, but it fails to switch back to the previous bank (curve road) when it needs to. A faulty logic gate in one of the ICs, or a cold/broken solder joint might cause this. I disagree here. It's extremely rare that the actual hardware inside the cartridge is documented, and therefore i believe it's best to just use a standardized format for each bankswitch scheme that does not depend on the specific hardware implementation. Also, contrary to what happens with eproms, you can't find an intrinsic order of the banks in case of custom chips that contain both the rom and the bankswitching logic, even if you decap the chip (which is a destructive process) to document it. You can just know what data the 2600 will see on the bus depending on what bank is selected. The order in which you put that data in a file is up to you, and if the bankswitch is already known, you'd better just use the same format already established. The same apply if you dump the cartridge from the connector (which is how most games, including prototypes are preserved). What's inside the cartridge is a black box and you cannot know what is used to store the data and how is arranged. In any case, with the "standard" rom, and the documentation (e.g. the schematic) of the actual board you want to use, you can always determine if and how the data needs to be rearranged for that particular situation. Which also means that if you know the specific board used by a prototype, you can always and uniquely determine exactly what was on the original eprom. No information is lost in preserving the rom using the "standard" format instead of the content of the eprom itself. No major (nor minor) oversight happened. And nothing needs to be corrected.

In the Supercharger hack above, the "STPM" routine in the Monitor, used to write to the Magicard cartridge RAM, has been changed to handle SC RAM instead. Of course it is much slower, so there will be timing issues in complex programs, but as far as I remember all the examples in the manual worked with that SC hack, simply by changing the routine address and by not using the $400 offset for the address to be written to. At the time I did that hack, the Harmony didn't exist and my goal was simply to be able to try the monitor program of the Magicard on real hardware, because I was fascinated by the idea of being able to enter and execute code using the 2600 console itself. Full software compatibility wasn't my goal and you're of course right that isn't possible by using a Supercharger.🙂

I had to search a bit in some old backups, but I found a few different wip versions of it. In later versions I made more changes, making use of the other 2k bank in the Supercharger, adding the ability to load data using the supercharger audio input, dump of processor status and register on a "brk" instruction, etc. I never finished it, though, and I don't remember at what stage of completion it was when I stopped. Moreover I have no documentation for it. so I'd need to go through the source and understand what it does... This one is an early version and doesn't differ too much from the original, so you should be able to try the examples in the manual with minimal changes. The zip includes PAL and NTSC versions, both in binary form or audio, and the ".pro" files that, if kept in the same directory of the binary (or if you launch the rom from within the zip file) will tell Stella to enable the keyboard controllers. Stella autodetection in fact seems to fail for these particular roms. Magicard_SC-wip1.zip I haven't documentation for this version either, but this is what I can guess after a brief test and look at the source: Apart for some cosmetic changes (there's no blinking cursor, the "shifted" and "unshifted" modes are distinguished by the text color, reset switch doesn't clear the screen buffer), the main difference is that you have an extra 1k of ram available at $1400-$17ff. The only way to write to cartridge ram is to call the STPM monitor subroutine (which is quite a bit slower than the original one, because of the way the Supercharger RAM works). Since there aren't separate read and write addresses like in the original, you must not add the "$400" offset when using the STPM routine. Also the addresses of the various monitor routines differ from those in the original, so you have to change them whenever they're used in a program, using the ones below instead: Magicard SC Monitor Subroutines DSPL: $fa6f STPM: $ffc1 STSC: $ffc2 CALP: $ff7c ONEC: $fb67 DOLN: $fcb3 BFIL: $fd9b SCRL: $fd72 NUMC: $fc9c ENCL: $fca5 PSHD: $fd62 INCB: $fc88 BMPB: $fc8a INSN: $fc6e ADTY: $fc3a INLN: $fc28 Other Monitor Addresses RSET: $feea MAIN: $fefe DISA: $fda5 CWRT: $fce3 CRED: $fd38 HEXD: $fe29 GO: $ffd4 RELC: $fe7f As said in the first post, I haven't tested the cassette write and read routines, as the interface I built using the schematics in the manual never worked. (I have found a schematic of a different circuit that might work, but I haven't found time and motivation to give it a try yet) Keep in mind that this is an unfinished wip and I haven't looked at it in more than a decade! There might be bugs. BTW, I also have newer versions of the ones in the first post, with bugfixes and enanchements, and I will eventually post them sometime in the future when I finally get a chanche to test the cassette loading/recording function with a working interface.

None of the above... I didn't alter or hack the rom. What I posted is not a 2600 rom anymore, it's the data that needs to be burned into an eprom so that when installed in the board using the circuit shown above will result in a physical copy of the rom you posted. In fact, if you dump such a cartridge with a cart dumper (that is, from the connector, not reading the eprom directly), you obtain the original rom, not the one with the data swapped! The 2600 community established a standard way to arrange the data in the rom file for each bankswitching scheme. That standard doesn't necessary correspond to the dump of a physical rom chip inside the cartridge itself. In fact, the "roms" we use do not contain any information about the specific hardware in the cartridge. Many times the cartridge is dumped from the connector without opening it, so we don't have that info at all. The cartridge might have the data split into multiple rom chips, and/or arranged differently. It depends on the hardware of each specific cart. (here, another example of a cartridge design, where the dump from the eprom isn't a valid 2600 rom and doesn't match the one you'd get from the connector). So, if the proto board used a circuit like the one above, the file I posted is what was actually on the eprom, but the one you posted is the corresponding 2600 rom to preserve.

That's actually correct: in every 6502 based system, including the 2600, the stack is in page 1. It just happens that in the 2600 page 1 is a mirror of page 0, so it's easier to consider the stack being in page 0 too, as it uses the same physical memory as the zero page ram.

Yes, that looks indeed to be the case by seeing clips of the game (e.g.from this video). And I would have been very surprised of the contrary. IMHO, there's just no chance that the current Atari would develop a new game for the VCS.

@Supergun: Try this one: Turbo_RH_swapped_banks.bin I have this schematic in my docs archive, which I think was drawn by Kevin Horton, and according to the description was traced from a "Time Pilot" cart. If your board uses this circuit, it will bankswitch to the upper half of the 8k eprom when accessing address "fff8", and to the lower half of it when accessing "fff9", which is the opposite of what's conventionally assumed for a 8k binary file using the "F8" bankswitching scheme. The attached binary is just the one posted by @Rom Hunter with the two 4k halves swapped, and it should solve your issue if this is the reason.

The unused (by Pitfall 2) features might also not be entirely documented. See this old post by @batari on this subject:

On a side note, in the pictures that are on Atarimania and AtariProtos, the eprom is installed backwards. The notch of the chip should point to the right, like it was originally in the pictures posted in the first pages of this thread. The pics on Atarimania show also the back of the pcb, and it's visible how it has been modified to accept the "2564" eprom used for this proto, while the board was originally designed for the "2764" type eprom, which has a slightly different pinout.

There are pictures of disassembled Air Raid cartridge, e.g. on Atarimania: http://www.atarimania.com/game-atari-2600-vcs-air-raid_16186.html Seems to be pretty safe to open, without tabs that can be broken in the process. It could be easily fixed, IMO, by gluing a replacement support (3d printed?) for the pcb on the inside (or gluing the broken one back if the pieces are still inside), and carefully straightening the bent tab by applying some heat (the missing one isn't a problem, one tab is sufficient to open the cartridge port dust cover on old 2600 consoles). Anyway, if you intend to sell it, it's probably better to just leave it as is and let the buyer decide if he wants to fix it or not.

While the label is a (extremely poor quality) copy of the "Pac-Man Arcade" one sold in the AA store, from the screenshots the rom looks actually @DINTAR816's Pac-Man 8k, probably the one he posted just a few days ago. He also states in the description "made from new rom"...

Use the console switches! They're there for a reason!

Here you can find some docs and schematics.

That looks like the console crashing, not an issue with the video signal. Maybe a power issue? I'd check the power supply, power switch, voltage regulator and related capacitors. Given the off spec signals that many 2600 games output, and the fact that the mod outputs analog video, CRTs are the most compatible displays.