DanBoris

There was a site that was doing basically that, Starroms, but unfortunetly they in-explicably closed up shop earlier this year, don't know if there was ever a public explination of why. Hopefully someone else will attempt this, since I agree with you selling old roms at a low cost would probably generate a lot of business. Dan

These guys are often *every* bit as comitted and genuine in their passion for MAME as any hardcore retro collector here on Atari Age. The guys who copy MAME sets on DVD as a service often have a policy page, and you can get a feel for what drives them by reading this. Almost ANYONE doing this is doing it as a passion, not as a business, and certainly not to get rich. I think it shows a tremendous lack of understanding to assume that they're "breaking the law" for monetary gain. As far as I've ever seen, most of the people who do this probably lose money in the long run. Trust me, as a member of the MAME development team, I understand the situation. Yes, you are correct not everyone is doing this for monetary gain but there are some that are. The MAME team has contantly had to battle with people who abuse MAME for non-legitmate commercial purposes. People who sell ROMS of disks and associate these closely with MAME by using the MAME name, or actually including MAME along with the ROMS (which is against the license), put MAME in a very negative light and may drawn the attention of the copyright holders. The MAME team does everything it can to protect the original goals of the project which are to document and preserve these games. They also support legitimate projects that secure legal rights to the games, in the hopes that more companies will allow thier games to be re-released in a legal manor. Dan

I am hoping that I can get a little help figuring this section out. I am pretty good with digital analysis, but my transistor theory is a little (ok a lot) rusty. The purpose of this section is to control the game state. Here are the things that I do know about this circuit: - When either /STOPG1 or /STOPG2 goes low, indicating that one of the score counters has reached the game ending score, the output of B3 (STOP G) will go high which stops the game. The high on STOP G will also set /ATRACT low, putting the game into Attract mode. - When a coin is inserted, COIN SW is momentarily closed which takes /SRST low, resetting the score counters. - Antenna is an external input that is used to detect a static shock to the machine. In theory is should prevent someone from shocking the machine into giving them a free game. I would appreciate any help deciphering how the rest of this circuit works.

I don't know anything about that specific site, but if these people have no problem breaking the law in selling something like this, they probably wouldn't have a problem ripping you off, and if they did you would have no re-course since you are buying something illegal. Dan

The first step in counting the score is to determine when one player or the other has missed the ball. This turns out to be very easy to detect because the only graphic object that can move off the visible screen is the ball. The circuit shown below ANDs the horizontal component of the video with the HBLANK signal to create the /MISS signal. Whenever there are graphics being displayed during horizontal blank, /MISS will go low indicating that the ball went off the screen. /MISS next passes through E1 where it is ANDed with /ATTRACT, this prevents the scores from incrementing during the attract mode. The final output signal is /MISSED which goes low when the ball is missed. The next parts of the score counter are two almost identical circuits that are used to keep track of the score, one for each player. When L is low, it means that the ball is moving right. When MISSED goes low indicating that the player missed the ball, the output of F5 will go high which will increment the score counter C7. The counter is actually composed of two chips, C7 which is a decade counter (which means it counts 0 to 9) and J/K flip flop C8 which provides the 10’s digit of the score. The final function of this circuit is to determine when the game is over based on the score. Pong can be configured to play games up to a score of either 11 or 15, this is set by switch SW1A. When the switch is in the 11 position, D8 ANDs together the 1 and the 10 output of the counter thus ending the game at 11. When the switch is in the 15 position, D8 ANDs together 1, 4 and 10, ending the game at 15. When the end score is reached /STOPG1 goes low ending the game

I saw a mint condition one go at an auction earlier this year, and although I can't remeber the actual selling price I don't think it went for over $200.00. Dan

Another good arcade close to New Jersey is Challenge Arcade in the Berkshire Mall (located near Reading PA, in the town of Wyomissing). When I walked into this arcade it was like stepping back into the 80's! They have a good number of classic arcades and pinball machines (as well as some newer games), and they are all in excellent condition, the operators obviously take good care of thier machines. You can get more information and see some pictures here: http://www.classicarcadegaming.com/locations/ca/index.htm Dan

Check out Ocean City NJ. They do not allow any form of "gambling" on thier boardwalk so you won't find any redemption machines in the arcades. When I was down there last year there were still a lot of classic video and pinball machines in thier arcades. Dan

While studying the score counters I was having a hard time figuring out how the score was credited to the correct player, it seemed that misses on the left side where scoring on the left side instead of the right. Turns out that I had a mistake in an earlier section, Ball Horizontal Control (Part 1). Turns out that I had the /HIT1 and /HIT2 counters reversed, the circuit should look like this: This is the proper description of how this circuit should work. The flip/flop H3 is used to control the direction of the ball. When the ball hits the left paddle, /HIT1 will go low, which will set pin 8 of H3 high, indicating that the ball should now move right. When the ball hits the right paddle, /HIT2 will go low, which will set pin 9 of H3 high, indicating that the ball should now move left. When MOVE is low, Aa will be 0 and Bb will be 1 which keeps the ball stationary. When L and MOVE are high, Aa will be 1 and Bb will be 1 which causes the ball to move left. When R and MOVE are high, Aa will be 1 and Bb will be 0 which causes the ball to move right. We will discuss the function of the CLK input to H3 in a later. The L and R signals indicate which direction the ball is currently moving and this is important to understanding the way the score counters work.

I think you will find the most people who are playing around with roms and emulators probably have an unzip utility installed. There are plenty of totally free ones available for example 7-Zip The ROMS might be zipped to save on bandwidth costs. Looking at Adventure the zipped file is 1K smaller then the unzipped file. This is not a big deal on a single download, but if you get 1000's of downloads it starts to add up. Dan

Taking a shot in the dark, are you trying to run these emulators by double clicking on the executable? If so that might be part (or all) of your problem. A lot of emulators must be run from a command line, I know that MESS and the Odyssey 2 emulator work this way. Be sure to read the documentation that comes with the emulator carefully, it will usually explain the proper way to run it. Dan

Although I have never actually seen a system damaged by doing this I can think of at least two logical ways this could damage the system. First, and most obviously you could physically damage the power switch. Secondly, the time when power is being applied to an electronic circuit is when it's under the greatest stress, so the rapid powering on and off may not necessarily kill the hardware but it could accelerator its failure. Dan

You can get most of that information off the parts list in the operators manual. You can find a copy here: http://www.arcadedocs.com/vidmanuals/S/StarWars.pdf Dan

Here is some information from the source code of the Atari800 emulator that might be helpful. /* ANTIC Timing -------------------------------------------------------------- NOTE: this information was written before NEW_CYCLE_EXACT was introduced! I've introduced global variable xpos, which contains current number of cycle in a line. This simplifies ANTIC/CPU timing much. The GO() function which emulates CPU is now void and is called with xpos limit, below which CPU can go. All strange variables holding 'unused cycles', 'DMA cycles', 'allocated cycles' etc. are removed. Simply whenever ANTIC fetches a byte, it takes single cycle, which can be done now with xpos++. There's only one exception: in text modes 2-5 ANTIC takes more bytes than cycles, because it does less than DMAR refresh cycles. Now emulation is really screenline-oriented. We do ypos++ after a line, not inside it. This simplified diagram shows when what is done in a line: MDPPPPDD..............(------R/S/F------).......... ^ ^ ^ ^ ^ ^ ^ ^ ---> time/xpos 0 | NMIST_C NMI_C SCR_C WSYNC_C|LINE_C VSCON_C VSCOF_C M - fetch Missiles D - fetch DL P - fetch Players S - fetch Screen F - fetch Font (in text modes) R - refresh Memory (DMAR cycles) Only Memory Refresh happens in every line, other tasks are optional. Below are exact diagrams for some non-scrolled modes: 11111111111111 11111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123 /--------------------------narrow------------------------------\ /----------------------------------normal--------------------------------------\ /-------------------------------------------wide--------------------------------------------\ blank line: MDPPPPDD.................R...R...R...R...R...R...R...R...R........................................................ mode 8,9: MDPPPPDD....S.......S....R..SR...R..SR...R..SR...R..SR...R..S.......S.......S.......S.......S.......S............. mode a,b,c: MDPPPPDD....S...S...S...SR..SR..SR..SR..SR..SR..SR..SR..SR..S...S...S...S...S...S...S...S...S...S...S...S......... mode d,e,f: MDPPPPDD....S.S.S.S.S.S.SRS.SRS.SRS.SRS.SRS.SRS.SRS.SRS.SRS.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S.S......... Notes: * At the beginning of a line fetched are: - a byte of Missiles - a byte of DL (instruction) - four bytes of Players - two bytes of DL argument (jump or screen address) The emulator, however, fetches them all continuously. * Refresh cycles and Screen/Font fetches have been tested for some modes (see above). This is for making the emulator more accurate, able to change colour registers, sprite positions or GTIA modes during scanline. These modes are the most commonly used with those effects. Currently this isn't implemented, and all R/S/F cycles are fetched continuously in *all* modes (however, right number of cycles is taken in every mode, basing on screen width and HSCROL). There are a few constants representing following events: * VSCON_C - in first VSC line dctr is loaded with VSCROL * NMIST_C - NMIST is updated (set to 0x9f on DLI, set to 0x5f on VBLKI) * NMI_C - If NMIEN permits, NMI interrupt is generated * SCR_C - We draw whole line of screen. On a real computer you can change ANTIC/GTIA registers while displaying screen, however this emulator isn't that accurate. * WSYNC_C - ANTIC holds CPU until this moment, when WSYNC is written * VSCOF_C - in last VSC line dctr is compared with VSCROL * LINE_C - simply end of line (this used to be called CPUL) All constants are determined by tests on real Atari computer. It is assumed, that ANTIC registers are read with LDA, LDX, LDY and written with STA, STX, STY, all in absolute addressing mode. All these instructions last 4 cycles and perform read/write operation in last cycle. The CPU emulation should correctly emulate WSYNC and add cycles for current instruction BEFORE executing it. That's why VSCOF_C > LINE_C is correct. How WSYNC is now implemented: * On writing WSYNC: - if xpos <= WSYNC_C && xpos_limit >= WSYNC_C, we only change xpos to WSYNC_C - that's all - otherwise we set wsync_halt and change xpos to xpos_limit causing GO() to return * At the beginning of GO() (CPU emulation), when wsync_halt is set: - if xpos_limit < WSYNC_C we return - else we set xpos to WSYNC_C, reset wsync_halt and emulate some cycles We don't emulate NMIST_C, NMI_C and SCR_C if it is unnecessary. These are all cases: * Common overscreen line Nothing happens except that ANTIC gets DMAR cycles: xpos += DMAR; GOEOL; * First overscreen line - start of vertical blank - CPU goes until NMIST_C - ANTIC sets NMIST to 0x5f if (NMIEN & 0x40) { - CPU goes until NMI_C - ANTIC forces NMI } - ANTIC gets DMAR cycles - CPU goes until LINE_C * Screen line without DLI - ANTIC fetches DL and P/MG - CPU goes until SCR_C - ANTIC draws whole line fetching Screen/Font and refreshing memory - CPU goes until LINE_C * Screen line with DLI - ANTIC fetches DL and P/MG - CPU goes until NMIST_C - ANTIC sets NMIST to 0x9f if (NMIEN & 0x80) { - CPU goes until NMI_C - ANTIC forces NMI } - CPU goes until SCR_C - ANTIC draws line with DMAR - CPU goes until LINE_C -------------------------------------------------------------------------- */

It's even more impressive to look at some of the later discreet logic games. I recently refurbished a Sega Monaco GP machine which was one of the last discreet logic games. It's amazing to think that game doesn't have a microprocessor. Actually in the case of that game I have wondered why they chose to go without a processor. It was released in 1980 and I can't image that it would have saved them any money going pure logic instead of a processor. Dan

Thanks! I was also quite curious about how they worked which is what led me to start writing this blog!

The ball vertical motion is controlled by a slip counter just like the horizontal. The counter is clocked by the /HSYNC signal so it will increment once per line. Since /VBLANK goes to the ENT input of B3 it will stop the count during VBLANK. When the two stages of the counter reach 255 the load signal will be triggered by B2. The upper stage of the counter is loaded with 0, and the lower portion is loaded with the output of the vertical control circuit. The values from the vertical control result in the following numbers of counts: 7 – 248 8 – 247 9 – 246 10 – 245 11 – 244 12 – 243 13 – 242 There are 245 visible lines on the screen (excluding the VBLANK region), so a value of 10 from the vertical control will result in no vertical motion, a value less then 10 will move the ball down on the screen, and a value greater then 10 will move the ball up on the screen. When the counter reaches a value of 252 the output of E2 will go low and stay low until the counter resets 4 counts later, making the ball 4 pixels high.

I have schematics for the Colecovision base unit on my web site http://www.atarihq.com/danb/Colecovision.shtml. In the upper right hand corner of page six you will see a box labeled "31", this is the audio coming from the expansion connector. It only passes through one component before getting mixed with the internal audio so it's very possible that the problem is in the expansion module itself and not in the base system. Dan

Depends on how much current the device you are powering will draw. Gernally the smaller the battery the less current it can provide. If you check out Energizer's site you will find the specifications for all thier batteries, that gives you a good idea what's available. Dan

The CPU can be stopped mid-instruction, but NOT mid-clock. Since the video clock runs at 7.16Mhz and the CPU at only 1.79 or 1.19 Mhz it could take up to 5 video clock cycles before the CPU completes it's current clock cycle. Dan Are you sure? The offical docs say there is an uncertainty in the amount of time a DMA startup will take. It takes 5-9 video cycles to halt the CPU. That doesn't sound like the CPU will stop in the middle of an instruction.... The lineram within the maria is double buffered, and that in addition to the amount of time the video chip holds HALT low for should be plenty to aleviate the need to halt the CPU in the middle of an instruction. Of course, I've never seen a datasheet for a 6502C, and thus don't have any way to prove what goes on at that level. At any rate, since the MARIA is read only, it probably doesn't matter.

Yes, you do lose the bottom 64 bytes of RAM on both pages due to the registers.

Yes, same message. Dan

Well, after pouring over the code for a couple hours I can confirm that there is an Easter Egg in Food Fight! Thanks to "audiemurphy" for starting me on the trail of this. Here are the steps to access the easter egg, which I have confirmed on the real hardware: 1. Play one game up to at least level 23. This is easy if you set the skill to beginner and start on level 16. 2. After that game, on the level select screen, select level 23. 3. Hold the pause button on the console and do the following sequence with the joystick: Up, Down, Right, Left, Up, Down, Right, Left. If you do that all right it should display the message. Dan

We are definitely on the trail of an Easter Egg here. By manually manipulating some memory locations as I traced through the code I was able to trigger the message. Still not sure what game conditions trigger it.

I think I spoke to soon! I looked at the code again with a fresh head, turns out I was looking for the wrong thing. I am pretty sure I found a piece of code that would display the message on the screen. For anyone who is interested, the code it at location $BD03 in the cartridge. Tracing back I find that the program gets to BB78 when you press the trigger on the title screen. From there if a bunch of conditions are met, it eventually ends up at BD03 to display the message. It will take some doing to figure out what all those conditions are. Dan