alex_79

Note that while the Concerto can play 2600 games, it is actually a 7800 cartridge and requires a 7800 console (It won't physically fit in the 2600 cartridge port).

Remember that none of the original games for the 2600 or 7800 support the track-ball native mode. There are a bunch of games for the 2600 (and only Centipede on the 7800, AFAIK) that have been hacked to support it and you can find those hacks for sale in the AtariAge store. (Roms for playing them in a flashcart can be found in the forums too). The trak-ball has a switch on the back to set it in "joystick emulation" mode, which will allow it to work in any game that support joysticks, but you lose the feel and precision of a real trak-ball in that way. Ensure that the switch is working and set it to "JS" position, unless you are playing one of those hacks.

You're right. Anyway it's much less noticeable than on your screenshot in the first post. It seems to be about 6.6% larger than it is tall. (4.6% on Gopher, and it's almost an exact circle on 6502.ts)

It doesn't look stretched for me in Stella, 6502.ts or Gopher2600. Unable to test on real hardware right now. Stella: 6502.ts Gopher2600:

Are you using PAL games? PAL and NTSC TIA have different palettes, so if you mix games and consoles from different TV standards the colors will be messed up. E.g. this is how the NTSC version of Pitfall! looks like on a PAL 2600 console:

Consoles from UK output on channel UHF 36 and use the "PAL-I" standard. Mainland Europe mostly used "PAL-G" standard for UHF (and "PAL-B" for VHF, which is the one used by consoles sold there). What happens in practice is that you can tune the signal on channel UHF 36 and the console from UK will display the image just fine, but without audio (because it uses a different audio carrier frequency). Anyway there's an easy solution: tune the audio inductor to adjust the frequency so that it matches the "PAL-G" standard.

The "last value on the bus" on the next instruction after a "RTS" would be the byte at the address stored in "Stack Ptr + 1" (lsb) and "Stack Ptr + 2" (msb). In the case of the "RTS" at $ffdd in bank 0, the address pulled from the stack is $0fff, which is the TIMINT riot register. The timer has not expired when the instruction is executed, so reading that address returns $00. If, with the Pluscart, reading from the write port returns the last value on the bus, then the opcode that the CPU sees at $f000 in bank 0 is $00, that is "BRK". And there's a valid interrupt vector in bank 0 ($1fbc, the same as the reset vector). So that might explain why it doesn't crash there. (I'm just guessing, I'm currently unable to test on real hardware and won't be for a while).

When accessing the write port of cartridge ram, the cartridge does not drive the data bus, as the CPU is supposed to do that with a write operation (to write data to ram). So, if you instead try to read from the write port, nothing is driving the bus and the value read is undetermined. Remember that the cartridge cannot differentiate write and read operations, so it behaves the same in both cases. This is the reason why cartridige ram needs separate write and read addresses. The actual result of that read can change depending on the hardware in the cartridge, the specific console, temperature, interferences from nearby electrical appliances, etc. I think on most modern implementations (Unocart, Pluscart, Melody board, etc.) you typically get the "last value on the bus", but we know for experience that in some cases consoles can (and will) behave differently, causing bugs hard to track down. Anyway, I remember testing actual superchip carts and the results were very different. It might be that either the the rom or the ram gets selected and drive the bus briefly while the address bus is not yet stabilized, but in any case, the results were not completely stable even on the few tests I did. I think that Stella returns a random, but static pattern when reading the write port, to approximate the results of those tests, and that's where that RTI opcode comes from. For developing purposes, I think that a good solution is to just randomize the results in case of undriven bits, so that programmers can immediately spot errors like that and fix the code early during developmenmt.

Definitely modified. Maybe it outputs composite video+audio.

Check which bytes differ. If the differences are limited to the four bytes at address "ff8", "ff9", "1ff8" and "1ff9", then you can ignore them (those are the hotspots). Yes. Dumping 2k games with the Retron will result in a 4k rom, with the game repeated twice (overdump). If you split the file in two 2k chunks, they should be identical and match one of the known roms.

In games over 4k, some of the addresses are used as "hotspots" to switch banks, and the value read from there can be undefined/unreliable, and depend on the method used to dump the games. If the game has extra ram on cart, the corresponding area in the resulting rom file can also change depending on the dumper used (its content is not used by the emulator, anyway). While those differences are irrelevant, of course they cause the hash to change, and so Stella cannot recognize the game. IIRC, the latest community build allows you to save the dumps on the SD card, so you can check your dumps against the known ones and see if this is the case, or if you actually found a previously unknown variation of a game (unlikely, but not impossible). @Thomas Jentzsch: maybe there's a way to workaround this limitation and allow Stella to ignore ram and hotspots when calculating the hash and recognize the rom also in those cases?

What I meant is that if you look closely, the smoothing of the inner circle extends beyond the area where the outer circle is flat:

After digging a bit more in the old rgvc newsgroup archives, I found this post where the author gives some technical details: The part highlighted in bold doesn't match what we see on the screenshot, which makes me think it is photoshopped (maybe merging different screenshots, each one from a program drawing only part of the screen. The author seems to actually have some knowledge about 2600 programming, or at least he studied the docs before posting. Here are the relevant messages about "The Core" that I could find in the archives after a quick search. The entire story seems fishy, to say the least.😄 thecore.zip EDIT: Finally, the "2600 Connection" newsletter, issue 66 (May/Jun 2001), page 6, under "News & Notes" says:

That screenshot looks quite suspicious to me. You need to use two players or two missiles to smooth the outer circle like that, and there aren't enough objects left to draw the two paddles, the ball, and to smooth the inner circle (which needs other two objects) without flicker. But since, according to the original website, the screenshot was taken from a real console using an hardware device ("Snappy"), some objects would either be missing or displayed as horizontal stripes (if the device captured two fields at once) in case flicker was really being used. Some "on-the-fly" color updates would also be required, as missiles and relative players share the same color. Quite a lot of advanced techniques for someone's first attempt at assembly programming: EDIT: BTW, the game was supposedly finished in 1998. This is from "rec.games.video.classic" usenet newsgroup, and is from November 1998: From: "Lee R. Krueger" <xxxxxx> Subject: Re: Where is "The Core " ? Date: 1998/11/12 [...] Newsgroups: rec.games.video.classic MGedeon216 wrote: > I have E-mailed the responsible party twice over the last 10 days and have not > received a response yet ! I am starting to get worried as I purchased 5 of > them. I dont like wasting money ,: ( > If anybody has heard any news on this very delayed project please fill me in. > Mike Gedeon : ) > > (www.videogameconnection.com ) > > below is the link to the Core site: > > http://www.plethora.net/~paulo/thecore.html Paul just emailed me the other day. I assumed he emailed everyone else. Here is his message: Take care, Lee *********************************************************** Since I e-mailed you last time a couple of months ago, here is what has happened: I have soldered almost half of the eeproms to the boards, but it has been fairly slow work. I have not had as much free time as I expected, because the transmission on my car went out in mid-September, so I've had to take the bus to work, and it takes an extra hour each way. (Repairing the transmission would cost more than the car is worth.) So I haven't been able to stay up as late to work on the soldering. I have also had a lot of weird things happen over the last month. For example, our cat peed in our dryer earlier this week, and I've spent the first part of this week taking apart the dryer and washing it out with bleach. Also, in the last two weeks, both of my children fell down and cut their head open. The second time, on Halloween, when we went to the hospital they used Dermabond, which is essentially sterile Superglue, to glue her cut shut. Well, the doctor was completely incompetent and glued our daughter's eye shut, and then tried using nail polish remover on her eye. Then the doctor left us, and told us to get her eye open, and then the hospital sent us home without fixing the problem. Her eye opened later on in the week, but I had to spend my time on that instead of getting other stuff done. (Our cat peed in the dryer the night of the day our daughter's eye finally opened.) This kind of stuff has been happening for the last month and a half, and so I have had trouble finding time to work on the game. However, I have still been working on it, and making slow progress. I'm really sorry that I don't have it out yet, but it will probably be two more months. If it isn't ready by the end of the year I will mail what I do have done, and mail the rest when it is finished. The instructions are back, but I still haven't done the box. (If someone else wants to do the box, please let me know.) I know some of you are probably tired of waiting. I still will refund anyone's money who doesn't want to wait any longer. I didn't realize I would have so little spare time, or have so many weird things happening to me. (I was promoted to head of my dept. for this year, and it is taking a lot more of my time than I expected, too.) Please e-mail me if you have any questions. One thing that I never mentioned because I wasn't planning on working on it is the fact that as I wrote The Core I also wrote a Yahtzee game for the 2600 just to try to see how certain things worked for it, such as the graphics and random numbers. I never added a computer opponent, and didn't concentrate on making it polished. However, I feel really bad about how long The Core is taking to get out. I'm going to try to polish Yahtzee and add a computer opponent after The Core is shipped. I'm going to have someone else who has time make a copy for each of you when I get done. (No instructions or box, just the cart.) This is one per person, not one per order of The Core. (I can't afford to do that. But yes, I am going to pay for it myself.) You will get this by the end of next year. That's probably how long it will take for me to get the spare money to have the carts for Yahtzee made. Again, I'm very sorry about the delay in shipping The Core, but I have been making progress, though very slowly. Thanks, Paul -- __________________________________________________________________

You can't fix that by changing components, as it is not an hardware problem, but a software one. The code in those games produces an out of specs TV signal that some TVs do not like. The only solution is to have a new cartridge made with a fixed rom (or play the fixed rom in a flashcart).

You can pass a small magnet over the label where the screw post is and see if it's attracted to it, revealing the presence of the screw.

Add the line TIA_BASE_READ_ADDRESS = $30 at the beginning of the disassembly, so it will assemble correctly with the "vcs.h" file from a current version of dasm.

I wouldn't call it a bug. It's just one of the many compromises done while designing the TIA to obtain the functionality required as efficiently and cost effectively as possible.

That's because, while the coarse positioning (RESP0) is immediate, the fine positioning (HMOVE) isn't. The "Tia Hardware notes" document linked above explains this in detail, but in short, each moveable object has a position counter that's only incremented during the visible part of the scanline, while it stays "dormant" during the Horizontal Blank part. The counter wraps around in exactly 160 TIA clocks, and when it does, the object is displayed. So normally each object will show up exactly on the same horizontal position on each line. If you write to RESP0, the counter for P0 is reset immediately, and it will show up on the new position starting from the next scanline (starting drawing isn't immediate, actually, so there's an offset of 4 pixels for Missile and Balls, 5 pixels for single size Player and 6 pixels for double and quad size players, which accounts for the differences you noted in the first post). HMOVE works differently. When you strobe that register, the position counter receives some extra clocks during the horizontal blank (the amount of which corresponds to the value stored into the high nybble of HMP0 after inverting bit 7, and so ranges from 0 to 15 extra clocks). Each one of these extra clocks will cause the counter to wrap around 1 pixel earlier, so it will move the object 1 pixel to the left. In fact this mechanism alone would only allow for movement to the left. That's why when you strobe HMOVE, in addition to providing the extra clocks, the Horizontal blank is extended by 8 pixels, which cause all the objects to move to the right by the same amount. The combination of the 0 to 15 pixels to the left caused by the extra clocks, and 8 pixels to the right for the extended HBLANK results in the -7 to +8 pixels fine positioning. During HBLANK, the estimated position in the debugger TIA tab is updated as the counter receives the extra clocks. (for each clock, the position is decreased by one, and each clock happens every 4 TIA clks, or 1.33 CPU cycles) and at the end of HBLANK, the position is increased by 8 again because of the extended Blank period. that's why you see it change, even when HMP0 is set to 0 (which corresponds to 8 extra clocks).

That's weird. Seems like the "two buttons" joystick functionality for the left controller is enabled in 2600 mode, which shouldn't be possible normally. Two button mode is achieved by strongly pulling up pin 6 of the joystick port. To do that, for the left port, both the TIAEN signal (green) and pin 22 of the RIOT (PB2, blue) need to be LOW, to switch on the two transistors (red and yellow). I'd check if those two transistors are good, and if there is any short in the areas near to those components before trying to replace the RIOT. A faulty RIOT alone (e.g. pin 22 stuck LOW) would only affect 7800 mode, 2600 games should work normally. (That's because TIAEN is HIGH in 2600 mode and turns off the first transistor).

It's extremely unlikely (basically impossible) that the chip contains anything other than the final version of the game. This is a pre-production sample/prototype of the mask rom, that is of the chip, not a prototype of the game itself (the code). Mask roms were(are) cost effective only in very large quantities, as the production cost is low, but the design phase before production can be started is a long and expensive process. Therefore, designing of the mask rom only started after the game was finalized and fully tested (which was done using eproms). It wouldn't make any sense to waste a large amount of money to design a mask for a WIP version of a game, because for any change of the code, you'd have to throw everything away and start over from scratch.

That doesn't work quite well, as "cache" and "active" don't uniquely refer to a specific register. The "new" register would be the "cache" one if VDEL is set, or the "active" one if VDEL is not set. The "old" register would be the "active" one when VDEL is set, and you'd need to find another term to indicate it when VDEL is not set, as the "shuffle" would still take place in that case. I think that would be confusing. The terms "new" and "old" are used in the Stella debugger documentation (you should be able to open the relative section of the manual if you have the TIA tab selected in the debugger and you press "F1" in Windows and Linux). The TIA Tab is already quite cramped, especially when using low resolutions, so adding labels to the registers and/or more verbose output in the "Queued Writes" area might not be a good idea. Anyway, it would be useful to mention in the manual that "shuffle" indicates the copy of "new" register into the "old" one performed internally by the TIA.

In the TIA schematics, the two registers are called "new" (the upper one in the debugger) and "old" (the lower one). The Stella programmer's guide calls the "new" one simply as "GRP0/1" and the "old" one as "GRP0/1 delay" register. You can only directly write to the "new" registers. The "old" ones are updated by the TIA itself. The Stella guide uses this diagram to show how, when the address of one of the GRPx registers appears on the address bus during a write operation, two writes actually occur: one to the destination "new" register, using the bits on the data bus, the other one to the other player "old" register, using the data from the corresponding "new" one. So, when you write to GRP0, the value is stored into GRP0 "new", while at the same time the TIA automatically copies GRP1 "new" into GRP1 "old". In the same way, when you write to GRP1, you're writing into GRP1 "new", while the TIA copies GRP0 "new" into GRP0 "old" . The above mechanism is always in place, no matter if VDELP0/VDELP1 are set or not. The only thing that VDELxx does is to select which one between the "new" or "old" register will be used to draw the screen. If VDELxx is set, the "old" register is used, else the "new" one is. (In the diagram VDELxx is represented as a switch, selecting one of the two registers for the output). E.g.: Not shown in the diagram, the Ball also has a "new" and "old" ENABL registers. (there's just one bit, so the Ball is either on or off, and hence the name. But you can think of the ENABL register as a single pixel "GRBL" register). ENABL "new" is copied into ENABL "old" whenever GRP1 is written to. Writing to ENABL sets the "new" register for the ball, but doesn't have any other effect. VDELBL selects if the "new" or "old" ENABL value is used for the output to the screen.

Did you try tuning the color pot? That's the very first thing I'd try in these cases. That's normal. The jailbars are the color information, which is not recognized by the TV (and a out of tune or oxidated/dirty color pot might be the cause) and therefore shown as part of the B/W image. When you use s-video, that part of the signal is separate from the B/W "luma" component, so you don't see them.

That's a pre-production mask rom, using a ceramic package. https://forums.atariage.com/topic/212415-pre-production-combat-rom/ https://forums.atariage.com/topic/339076-please-identify-this/