Windless

No. Because: - Being strong at a game generally requires more than knowing the game. (People who write the rules for tennis or soccer are not the one who win the world championships, same goes for videogames) - Some (hardcore) gamers know the games way better than the developers. (Big editors normally hire players to learn about their games.) You may have a look at this video which illustrates these two point (focus is on how long it takes to finish the game, not on the score, but the principles stays true) (video is not short, but very interesting imo)

yes (but) and yes. A longer answer if you are interested : The 2600, like most computers, is basically RAM, CPU, peripherals, buses, clock and programs: - Peripherals in the 2600 would be the IO ports (used for joysticks / joypads / buttons on the console) and the TIA (graphic chip of the 2600). Since we speak about offscreen cpu controled cars, peripherals are not concerned (more on that in the end of the post) - Bus in the 2600 (and most computers until the late 90) is wiring that connect the cpu to ram / peripheral / cartridge ports / ... So that let us three possible limitations: cpu, ram and program. For programs, there could be one limitation that is the quantity of ROM to store it (plus its data) on the cartridge. That is a limitation, but only if you want to implement complex and long algorithms, smaller one can probably be fit on the cartridge. So RAM and CPU are indeed the two possible limitation left. About the RAM, we would have to handle several things for each player. The position of course, the speed and maybe more (gear ratio, what the car "wants" to do if we do not want to recalculate this information at each frame, is it drifting or not... ?) One byte of data allows to store 256 different possible values. if we store the position of the car using just one byte (how much it advanced on the track), that would do 256 possible value and if this position changes at each frame, the longer possible track at 60 frame per second would be about 4 seconds. too short. We probably need to use two bytes for "how far on the track the car is", but we also want to know if the car is on the left or the right of the track. We may not need a full byte for it : screen is 160px wide, so maybe we can live with 128 different positions of the car, which can be stored on 7 bit and doesn't require the 8 bits of a byte. Maybe we can also save a few bits from the two other byte to store the other information we need, but we have a good enough estimation : we need 3 or 4 bytes per car for a simple behaviour. The 2600 has 128 bytes of memory but you probably need a few byte for the game (e.g. timer, score, calculating physics, ...) but we might be able to handle 20 - 40 cars in the RAM. That is without using ram extension on the cartridge, where you could get an addition 1k or ram and then CPU would probably be the limitation, not the RAM. About the CPU : thought it can be done, calculating things while the screen is rendering on the 2600 is not really great because you need the CPU to generate each line while the screen is displaying it, and even if you have a few spare time, switching from drawing the screen to calculation takes time and need to be done in precise timing. So lets assume you only want to calculate the cars action / behaviour / physics during the non visible part of the screen: that 70/262 of the available time. (a frame contains 192 lines, and there there is a duration of 70 lines where nothing is drawn by the TV, this is where we do all our calculation). A line duration is 228 pixel clock signal duration on the 2600 (a line is 160 pixel but there is a delay between each line), so we have the duration of 15960 pixels, and the cpu runs at 1/3 the frequency of the TIA to our code must run in 5320 cpu clocks. All the code won't be dedicated to the cars only, so we can round this about 5000 cpu cycle available for us. For a rough estimation, let's say we need to add to two byte of the position for each car, plus the left/right position of the car, increment / decrement speed... that would be about 10 instructions per car, and an instruction needs at least two cycles, that is 20 cycles per instructions. But then we need to more complicated things : taking decision (does the car turns left/rigt ? accelerate / brake ?) probably about 100-200 cycles per car. But this estimation of code duration until now only take into account several isolated cars. If we want some interaction between cars (e.g. detecting collisions or having the cars taking the other cars into consideration to take action), the problem becomes way harder because it evolve not linearly with the number of cars, but maybe something like the square of the number of cars. So a new answer is : we can guess (hard to say without actually programming and testing) that the CPU will be the limit, not the ram, if you want any interesting behavior of the cars. Now another point to take into consideration: if the cars have existence off the screen, they probably need to also be able to reach the screen. If it is only one or two car that is not a problem, but displaying more that 2 or 4 cars at the same screen height would be a problem on the 2600. So we probably need to cheat and have car that exist offscreen but stay away from each other, not something like mario kart manages to do. Then if we have this we would have very less interaction between the cars and maybe save some CPU... so maybe the CPU wont be the limit in the end.

Because : - I don't own a CX21 so I just can't do it myself if myself means alone - I think it is more fun (not only for me) helping people to handle a project that mean something to them than doing it for them. Doing it for them can even spoil it for the person who originally raised the idea (I've been spoiled by "helpers" more than once ^^) - I have tons of projects that I don't have time and energy to finish on my own side. I can add one, which has more constraints than the already ongoing ones because other people will wait after it, but it is nice to know other people want to get involved and this was not only a random question without real expectation behind. - I don't need to repair a CX21 and for several reasons I won't organize a group order nor open a store, there is no point in doing part of the work if nobody has time and will to handle other parts. If the problem is knowledge, that one is easy to fix we can help That being said, communication is hard and english is not my mother tong. What I wanted to say was definitively not "hey just do it yourself that's easy" but "that's something we can easily achieve as a community, where are we and how much help do you need ?"

"Breakout - This game (envisioned by Nolan Bushnell, and designed by Steve Wozniak) taught me the value of working smarter, not harder " Linkedin at it best

The pcb is really simple. If you have access to a scanner, making the gerber file would take about an hour, then ordering 5 pcb with ENIG (not the best plating, the only one you could afforde ^^) from jlcpcb would cost $20 with 1U plating, $35 with 2U (twice as thick). Do you have a caliper to take precise dimesions of the board ?

TL;DR : it's a "limitation of the hardware" which existe because atari made "deliberate choice" to keep the cost of the TIA (the video chip of the 2600) hence the 2600 low. First, you need to understand what a sprite is : on a more modern computer, eg the amiga or the atari st, you have some memory for the video screen. A component of the computer reads this ram while the electron beam travels though the screen and "tells" the tv which color to display the current pixel. You can add moving object on screen by replacing the data in video memory with ones showing something else, but this has to be done for each frame, background has to be restored, and you probably need to have an operation using a mask to decide which pixel are taken from the moving object and which one are ignored to keep the background (because handling arbitrary shapes is harder than using a rectangular shape and a mask). All this is both compute expensive and memory transfer expensive. Computers may have dedicated peripherals to do this task (e.g. the blitter on the amiga, the atari ste, sucessor later version of the ST, also has a blitter). But even with a dedicated peripheral which can do masking for free, the copy is expensive because there is a lot of ram to transfert, ram can't be accessed by several peripherals at the same time (so the CPU will suffer from "wait states"), and you probably need to keep a copy of the constructed background because the peripheral don't know how to reconstruct the current level from the tiles, so it consumes RAM. So there is another way to display moving objects : the (hardware) sprites. Data for the sprite is not transferred to video memory, instead the peripheral that generates the data for the monitor will do something like "I need to generate color for the 40th pixel of the 23rd line, but this is also the position of sprite 1, then I will look in the mask for top left pixel of sprite 1, and depending on the mask display sprite 1 or whatever is in video memory". This is way more efficient at runtime (no need to copy / move / duplicate any data) but comes with a cost when building the chip : for each sprite you need circuitry to compare the position and combine the sprite data with background and other sprite. So the number of moving objects a computer can display is a tradeoff between how much CPU and memory bandwidth needs to be available to do other things and how much designing and producing the dedicated circuitry costs. On the atari 2600, the cost reduction decision are... pushed to an extreme. The "background" only 20 pixels with 2 colors (which are repeated twice or mirrored to make 40 pixels that are four time larger than the moving object pixels), this was never designed to represent moving object (though you can do it if you can cope with a 40"px" resolution). The specification of the console were to be able to play a 2 player tank game shooting at eachother, so you have two sprites with 8 pixels width (which are in fact just a color and 8bits for a transparency mask) and two "1px" missiles (more and "enable / disable bit) that have the color of the corresponding player, and a "ball" because the design of the graphc chip is heavily based upon the chip that made all the pong / tennis cheap consoles possible. Each of these can be seen in the circuitry of the TIA : page 3 has the counter for the position of one player, counter for the position of corresponding missile, counter for "current pixel of the player", plus the 8 bits for the player (the player on the 2600 is only 8x1 because ram was sooo expensive back then, so you juste change the these 8 pixel between each line using the cpu) and that's just a bit of what you need (e.g. you need logic to handle writing to the position / graphic / color register, the color register, the logic to display either of the moving object depending on the mask, ...) Then NES came 6 years later, when design and production cost where much lower. It could implement more advanced technics and did not need to reduce the cost as much. Also, the video market had considerably grown (Zelda for the NES had a marketing cost of about 10 millions of todays USD, manufacturing cost past 100 millions) and justified investing more in development of the console. Plus Nintendo sold the console at cost and charged the editor to gain money.

I am starting to work again on this investigation* but still don't have access to a working TIA 2600. Could someone upload an oscilloscope trace** of PALI, PALS, and COL for a full line of this rom ? Thank you, W. * : just for curiosity, I don't expect anything coming out of it ** : data export, not just screen captures pal colors.a26

Hi, I wanted to conduct some tests on the PAL TIA (mainly trying to use from a Cortex MCU, but also trying to understand more precisely the relation between CLK, PALI, PALS and COL pins). Unfortunately the TIAs I could find on ebay is 54€ including shipping... more than I'd pay for a working 2600. Also I don't want to buy another 2600 because even if it has a socketed TIA, there is a risk I damage the chip during tests so and I have too much respect for the VCS to detroy one, I'd really prefer use a scavanged TIA fromn a dead 2600. Is there a place to buy TIAs at a decent price or is it the first thing that fail on most 2600 making it a rare replacement part ?

there is this rather "in depth" explaination that as many many typos and syntax error that I should correct one day, maybe it can help : https://gitlab.com/FTregan/bank-switching-rom-atari-2600

I'm currently unemployed 😕 Which means I'm going to have energy to work again on this project \o/

I was making the asumption that not many people owned a numeric pad ^^. BTW, I don't think these keypads really are a good option for a fast paced games. I made my custom keyboard compatible with them, but it uses 10 mechanical keyboard switches and the keys are in line, you just need to move your fingers one unit for 5 and 6.

I am trying to find a fast way to enter large numbers. I currently have a solution that works very well using a custom keyboard, but this means players would have to build a custom keyboard. So I'm thinking of using the paddle as a dial. Since I don't have my 2600 here and can code only on emulator, I'm wondering if I can realisticly use the paddle to enter a number between 0 and 999, or 0 and 255, or if the precision would be too low and I would have to enter 3 digits one after the other. The kernel of the game itself doesn't do much, so I can probably read SWCHA twice during a line, but : - I don't know how many lines it take at most for the capacitor to discharge (if it takes the full VBL, I theorically can distinguish 524 values, but if it discharges in only 10 lines, that would be only 20 possibilities with two reads per line) - I don't know how precise it is (if for a given position of the button the signal on SWCHA changes at a random line between 100 and 110, or if it would require too much agility and lubrification to select a position between 200 different ones, the quantity of distinguishable enterable values would be lower than the quantity of distinguishable durations)

This is why my question was "how many different positions can you reliably distinguish". I will add two informations : - in at max 2VBL (1/30s) - the values must be linearly distributed. So imagine you use the paddle to enter a number and you want the numbers equaly spread around the rotating button, how many different numbers can you enter if you want to read at least one every 1/30s ?

Hi, I don't have any hardware to test, so maybe some has the answer : if you do a calibration at start of the rom (asking the player to turn the button full left then full right), how many different positions can you reliably distinguish with you code ? thank you, w.

Yes, twice. I'll try once more Only the .A26 file appears. Off the wall, RealSports Soccer and Ms.Pacman (all PAL) all shows the same info.txt file. Pole Postion doe not eumerate (though the game work on the console) No ^^ I tried the command you gave, and also with `command:stellaext`, but that does not change anything. There is still only one 2ko file and the `info.txt` file shows the same persistent state. No. I could try emulating theme with a plucart, but that would probably change a lot of contexte. Yes, became abvious once I spotted it ^^