Blinky

The high byte with bit 4 reset. Yes indeed. VERY unlikely. then its to late already because the JMP opcode and LSB are already fetched. Using A12 or A10 could be used so the button would only work when a TIA/RIOT address or rom address below 1K is accessed. But I can't just hook the button to it and the latch reset because of the reset RC delay. So another chip would be needed which isn't worth it.

Some info about the AY chips at http://www.pong-story.com/gi.htm no schematic or pinout though.

Me too. Which doesn't do any good. Because the cartridge bank switching won't get reset. Yeah you're right I did'nt think it through well Right. JMP JMP() JSR are all the same. Me too. Yeah you're right I did'nt think that through well

its a NTSCversion not PAL.

But unfortunately there is none. You could add one to the Atari though. I think the possibility for a crash is very small. I think I can bring down the odds even furter by using some different code.

Hmm I just saw that if the JMP or a JSR opcode was at FFF6 or FFF7 (F7F6 orF7F7 when the button is pressed the CPU will probably crash

OK the single byte instruction will be CLD which is $D8 if only JMP opcode was fetched it will jump to JMP $D8D8 if JMP and LSB where fetched JMP $D8xx. Both are safe. if bank is switched while CPU is in FFF7-FFF8 area it will perform a ORA ($08,X) or PHP. I just see that JMP opcode must be at FFF9 in bank 0 as well to prevent CPU rollover to 0

OK (taking a deep breath) To be able to return to the menu. All that is needed is a push button and the 1st 2K bank. The button will reset the latches so bank 0 is selected (in 2K mode). The CPU is then going to execute the code in bank 0. To prevent the CPU from a crash, bank 0 is filled with one single byte instruction including the CPU vectors. The only exception are locations FFF6-FFF8 (and echo at F7F6-F7F8) which hold the instruction LDA $0801 which selects bank 1. Code is executed in bank 1 at FFF9 (or F7F9) where a JMP opcode will cause a jump to the NMI/Break vector (in bank 1) which starts the menu. The single byte instruction opcode in bank 0 must have bit 4 set so the vectors wil jump to a rom location where the instructions are executed to reach the LDA instruction.

Thats because I've just recently designed it. I'll keep it in mind. There could be a couple more I agree. To start up in bank 0 I keep the latch in reset during start-up. I don't see why I should add any morepull ups/downs. For the final design there will be an extra 74HCT175 for support 8Mbit EPROM and a return to menu switch (to reduce wearing of the power switch) if my theory works. I'm also wondering if there is somebody out there that could make a PCB of it. As I don't have the resources for putting it into production.

Hi Chris, I've analysed the schematics and addressing scheme carefully. Adresses should/are only read just like doing with ROM. There is nothing affected by reading any registers (Theres one exception for the RIOTs where the interrupt output pin is cleared. But since it is not implemented in the VCS. it can be ignored) and TIA and RIOT can not be read simmultaniously (because of A7 address line). Doing a write will only change a TIA/RIOT register value. The basic design uses addresses $0800 -$08FF (A7..A0) only. But the full version (which uses an extra 74HCT175) will use $0800-$FFF (A10..A0). I've choses $0800 as base so normal TIA / RIOT access will not change the selected bank. To be sure that when a game(if any) does access TIA/RIOT in range $0800-$0FFF) the lock bit can be set to prevent the bank from changing. I didn't document it as wel as you did. So I've added yours to my documentations Thanks

Yes. (read following completely before taking any actions) Some tips on removing it. Make a note of how the 4050 is positioned. Pin 1 is indicated by a small round dot, a notch in the chip at that side or its the bottom left pin when you read the chip from left to right. To remove the chip just cut all the pins at the top of the pins with a sidecutter and remove the legless chip. Now you can do two things. Solder the new chip to the old pins (could be a bit tricky). heat up each pin and pull the pin gently out. After removing all pins. heat up the holes and suck out the remaining solder with a desoldering tool (solder sucker). This is easier with an extra person holding one of the tools. After all holes are clear. Get out that that tooth brush again to remove any small bits of solder from desoldering. insert a socket into the holes with the notch in the right position, keep a little pressure on the socket so it won't fall out when you're holding the PCB bottom up to solder the pins, solder all the pins, check for shorts at the soldered socket and insert the chip minding the notch again and you're done. Note that once the 4050 is removed the atari won't produce a picture until the new chip is placed. Since the problem only happens using the 2nd controller button. You might want to wait on doing the repair.

It is used in later models. But not all 4 switches.The joystick fire buttons don't go through the 4050 in most of those later versions too. Probaby from a different production run.

The one with the problem is a 6-Switch ? Then probably the small 4050 chip is faulty. The fire buttons go through it , so do the video signals. It's a common chip and still easy and cheap to purchase. Unfortunately it is not socketed and needs to be desoldered. If you can handle a soldering iron and a tin sucker then you can do it your self. otherwise ask someone who can. If you want to try interchanging the RIOT/TIA (bigest) chips anyway: The one closest to the cart slot is the RIOT. The one in the center is the CPU. The one on the bottom is the TIA The chips have the same pin assignment and are interchangable. However there could be some minor electical differences (slightly different display). But thats nothing to worry about for your testing. Before removing the chips I recommend to put a small label(can be removed easely afterward) on them or mark them. So you know where to put them afterwards. You could mark them as T6,M6,B6 and T4,M4,B4 (Top/Middle/Bottom/6switch/4switch). Test B6/B4 first.

Hey ! thats great ! That means it could be put on my multicart design too Thinking of making a Star wars compilation. with a star wars liky menu (double border)

Maybe. Because the fire buttons are read by the TIA :wink: TIA might be bad. But you might want to try cleaning the circuitboard first and see if that helps. Open up your (6 switch?/4 switch?/2600JR?) Atari and inspect the PCB for dirt or goo or anything that might cause a short. Dirt can be cleaned with an old toothbrush, with sticky dirt or goo you'll need a cleanser too

It could save 66% on the data if I could(16 chars per title instead of 8*6 bytes). The problem is that there is not enough ram to create bitmap data from individual characters for a whole menu page and that there is not enough time available to do it on the fly for each title. Maybe it could be done using fixed spacing characters but then there would be less characters available for a title Currently I save space on reducing the height of a title using a different bitmap font. The demo uses 16 lines high titles because there are only 8 titles. but for 31 games I would use 8 lines per title to get 31 titles. By really sqeezing it. I could get 40 titles of 6 lines high. In case of a 1Mbyte rom with only 2K games (are there so many?) the proportional menu would take 13 2K banks leaving 499 for games and a fixed text menu with (12 chars) would just take 4 banks. I think just 9 banks less space for proportional text is not bad. But I'm open for any ideas to save on banks. Especially since I haven't written the menu to support that many games yet.

I designed a PAL mod for the Atari 2600 JR and delivers a great picture. schematics and screen shots at: http://members.home.nl/edwin.blink/atari2600/vdomod/ It might work on other Atari versions that uses a 4050 too. But I can't tell because I have no other hardware to test it on Having a habit on doing multiple things at once I haven't found the time yet to work on a how to.. discription. But there is a small info file for the time beeing. other PAL mod I found: http://www.radioactive3.fsnet.co.uk/atari2600.htm when you encouter other mods and it is not clear which system it is for then just look if pin 8 or 6 is used in the mod: pin 8 used = NTSC system pin 6 used = PAL system.

Just wanted you to inform of my new project. I designed a menu driven multicart that just uses 2 standard ICs with a couple of other components for the logic. This design suports 2K and 4K games put into a 8K..128K EPROM (another latch could be added to support EPROMs up to 1 Mbyte). The banking scheme used, uses address range $0800-$0FFF so a LDA $0800-$0FFF can be used to set the latch(es). I've chosen this range so normal TIA and RIOT access will not interfere with the banking scheme and for the possibility to patch $F8 (and other banking schemes) games. A total of 11 address lines are available, 9 are uses for bank select, 1 bit for 2K/4K mode so a 2K bank can be mirrored to 4K and 1 bit to lock the latch(es) for games that interfere with the banking scheme. Heres the BASIC design schematic. I wrote a 2K menu for it that displays game titles as 48 pixel wide proportional text. A menu bar to highlight the selected title is controlled by any joystick or B/W, SELECT and RESET switches to select a game. Game titles are stored as graphics and take up a lot of space. I managed to byte bust the menu code into 512 bytes. So there are 248 lines of 48 pixels available for storing game titles. I've made working 8-in 1 version in a 32K EPROM. But there is still a lot to do like a menu for supporting more 500+ games. and a utility to select games, patch the menu and generate a image of it. mmc_8_in_1_pal_.zip

I burned Vader vs Luke hack together with my finished 2K hires menu into a 32K eprom, ran it on the real hardware and .... discovered it needed another fix (see http://www.atariage.com/forums/viewtopic.php?t=55222 ) So here's Release 8 and it runs great on the real hardware vadervsluke.zip

While I was working on a Dodge'm disassembly for a hack I found some programming bugs where the programmer forgot the # for an immediate instruction like LDA WSYNC instead of LDA #$02 (happens to me sometimes too). I found the same bug in all NTSC and PAL dumps I could find. So I assumed that the last byte read was always floating long enough on the databus and just ignored it. But when I burned the game in an eprom, it showed annoying flicker/mirroring of the score as I would have expectred with the bug. So with the EPROM the bug does show. I asume that the output from a cart ROM stays active a little longer and keeps the last byte read from the ROM on the databus and (faster) EPROMS do not. Anyone had experiences with games that just didn't work well when burned on a eprom ? Also wondering if those pull down resistors on a 32 in 1 cart where added for simmilar problems.

I'm glad you like it. Offcourse you still need to hack your gfx into it

Nice Work. Looking forward to see more of it ! You could end the players turn when it touches the bottom of the screen as an extra difficulty so it won't show. On the obstacle idea. Maybe you could make some of the holes move or make them open and close periodically.

Someone would have in time. Anyway it was easy to fix. About the new control scheme. I took quite an effort but I managed to put it in. The PAL version had the least amount of spare bytes and for that version I had to use the last two ROM bytes to squeeze all the code snippets in. There are 6 game options now 1 to 3 with the classic controls and games 4 to 6 with the new pilots view controls. I must say beeing used to the classic controls its a quite a new challenge with the new control scheme. Besides this new feature I also fixed the classic double lane change bug that I had in mind to fix. But was forgotten until now. For the ones that don't now this bug and love to cheat a little on a two player game playing the classic or older releases of this hack: With normal speed you can change a single lane. But when the other player moves his joystick he will force a double lane change. So the other player can cheat a little by forcing the player to change two lanes and crash into him. So here is release 7 and this will really be the final one.I'll burn it into an eprom and play it on the real thing. Talking about that, is there anyone out there that could print a label for me ? vadervsluke.zip

I reverse engineerded the PAL game before I got started on the hack and I documented it pretty well(but with several misinterpretations I still need to change) and NTSC version too. It's much easier and saves a lot of time on hacking. The free page (not quite) you discribed Is used for the extra sprites and extra score digit. But theres no problem to free enough space for it if required. Mayby it could be a subroutine or JMP(xxxx) I need to look into it. When I add the new control method I wouldn't use the difficulty switch though. I would go for a game select hack to get 9 games: GAME 123 Normal control ,GAME 456 left/right control and GAME 789 driving controllers ? (anyone want to donate some ?)

Maybe you should push the joystick to the right a little earlier ? I'll keep your idea in mind.