solidcorp

You don't really need a full emulator just the ability to do a small set of integer operations on a small number of registers - you could do that with shader subroutines if the shader truly supports branching. As a matter of fact I bet you could represent all the operations using texture operation on 8 bit colors (though the carry bit would be trickier to handle). That way you could use CUDA or Direct Compute to attack the problem. There is still a lot of ground to cover and each test needs to test 256 values and compare to a set of correct answers. Interesting problem, I wish there was someone who wished to contract this out for work. I think the genetic algorithms may have promise, though I have not really worked in this area. The results that come out of those optimization methods are ten times more complex than optimized assembly code, doing often unpredictable and apparently meaningless things to achieve a 100% correct result. I'd expect that for a 20 byte solution it would probably spit out a few pieces of code that look familiar but there may be some bizarre outliers that completely work.

20 bytes is 8*20 or 160 bits which can be combined in 2^160 combinations. (i.e. 4 bits = 2^4=16 values, or 8 bits is 2^8=256 values) Either way the number is intractably large on my machines Of course that would include unwanted opcodes like NOP and KIL, and there are illegal opcodes that have duplicate functions. If you limited the opcodes to some number n, then there would be be n^20 combinations. Crosschecking: If n=256, all possible byte values, then there would be 256^20 combinations which is the same as (2 ^ 8 ) ^ 20 or 2^(8*20) or 2^160. So, how many unique opcodes are there for the Atari 2600's 6507? (Thomas, you would be the first one I would ask this question)

This may seem absurd but with ROMs as large as they are now and cycles being a scarce as ever, this old technique may be merited in some circumstances. ; 259 bytes, 4 cycles (5 if table crosses page boundary) lda DivXBy5,x .align 256 DivxBy5: .byte 0,0,0,0,0,1,1,1,1,1,2,2,2,2,2 .byte 3,3,3,3,3,4,4,4,4,4,5,5,5,5,5,6 .byte 6,6,6,6,7,7,7,7,7,8,8,8,8,8,9,9 .byte 9,9,9,10,10,10,10,10,11,11,11,11,11,12,12,12 .byte 12,12,13,13,13,13,13,14,14,14,14,14,15,15,15,15 .byte 15,16,16,16,16,16,17,17,17,17,17,18,18,18,18,18 .byte 19,19,19,19,19,20,20,20,20,20,21,21,21,21,21,22 .byte 22,22,22,22,23,23,23,23,23,24,24,24,24,24,25,25 .byte 25,25,25,26,26,26,26,26,27,27,27,27,27,28,28,28 .byte 28,28,29,29,29,29,29,30,30,30,30,30,31,31,31,31 .byte 31,32,32,32,32,32,33,33,33,33,33,34,34,34,34,34 .byte 35,35,35,35,35,36,36,36,36,36,37,37,37,37,37,38 .byte 38,38,38,38,39,39,39,39,39,40,40,40,40,40,41,41 .byte 41,41,41,42,42,42,42,42,43,43,43,43,43,44,44,44 .byte 44,44,45,45,45,45,45,46,46,46,46,46,47,47,47,47 .byte 47,48,48,48,48,48,49,49,49,49,49,50,50,50,50,50 Also, in many circumstances you don't need 100% accuracy. For example if dividing velocity or measuring distance, some error is allowable. In those cases I would multiply by 1/5 in fixed point. which is the same as multiplying by (256/5) / 256 - which is the same as multiplying by 256/5 and just looking at the high byte which is what most of the routines above do. The errors are coming from integer math, i.e. 256/5 being 51.2 and not just 51, so just using the upper 8 bits for the shift and add multiplication is not always exactly correct but is rarely wrong and not wrong by more than one and is always near the correct answer. Another example: For division by 7 I would use 256/7 which is 36.5714.... when just multiplying by 36 (by shifting and adding for 00100100b) the errors encountered in the result were due to the missing .5714. The very clever addition of 4 plus carry at the right time above would appear to resolve the error for integers ranging from 0 to 255. If I needed more precision I would add more bits like this: 1024/7 = 146 (10010010b), Since the first 1 bit is in the high bit, this has 8 bits of precision and would probably yield the correct answer - unfortunately I don't have time to write a test routine to demonstrate. I love this thread. P.S. Here is the crummy little Ruby script I whipped up to generate the table: #!/usr/bin/env ruby for i in 0..256 val = (i/5).to_i if i==0 line = "DivBy:\t.byte\t" elsif i%16 == 15 puts line line = "\t.byte\t" else line << "," end line <<"#{val}" end

The routines are so short, I wonder how long a brute force attack would take? Current code is 20 bytes - just combining random bytes, it is one of 2^(160) combinations: 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 That's kind of a lot, even on hundreds or thousands of PC's. A genetic algorithm may be able to find a solution in a human lifetime. It would be cool to see the code optimized for size and optimized for space.

( I absolutely LOVE this thread )

That Disney stock certificate is cool. It looks like you used to be able to get Atari Stock certificates on eBay for under $10, the ones on there now are climbing in price capitalizing on the recent news no doubt. My one share is still worth way more to me.

They're dog treats and I knew I should have cropped that picture.

I already own enough Atari

Hey, look what I found! I bought some Atari stock when I worked there and sold all but one share in 1993 after I left the company. I had them send me a stock certificate as a souvenir. I dug it out of the archives (catacombs, crawl space, whatever...) last night.

Seconded!

From same article I quoted earlier: "But its financial position has not improved markedly thanks to its debts to London-based BlueBay Asset Management, and it now needs $5.25 million of financing to keep running." That's just to continue operating, not pay off its debts or bring new or old products to market.

It doesn't look like Atari US is closing but rather looking to split from Infogrames. As the Huffington Post article suggests "It is thought the company could now be sold to an outside buyer, or a team of backers led by CEO Jim Wilson."

When I'm done there may be some extra manuals and boxes but not many. I ordered only a handful of extras to cover unanticipated problems so I won't know how many I will have until all the cartridges have shipped.

Where did you hear that? Never heard such a thing? The history of Madden Football is pretty interesting... http://en.wikipedia.org/wiki/Madden_NFL#1980s:_Creation Paraphrasing: Trip Hawkins did approach Atari about making his football game idea between 1982 and 1984 but wanted to use his childhood hero Joe Montana. It's not clear whether he was looking to make an arcade or home game. Madden was actually his third choice and wasn't approached until 1984. The first Madden was released on the Apple ][ in 1988, so it would be doubtful that there was any real chance of a 2600 or 5200 version of the property we know as Madden today.

Great news! (that I haven't posted to Kickstarter yet) I just got the shells for this week - all 106 halves, potentially up to 53 cartridges worth if they are all perfect... and so far they look great. That's more than double a usual week. Even if your cartridge isn't in this batch, this means you will still probably get yours a week earlier than expected. Whatever you find yourself doing this weekend think of me, at the factory, putting in overtime on the Star Castle 2600 assembly line.

I know and I'm sorry. We are shipping orders as fast as the shells can be cast and in the order that they were ordered on Kickstarter. There are only 83 more Kickstarter orders left and we have been averaging 20/week with some recent weeks over 30. I expect the rest to be shipped over the next 4 weeks. Your order is 56th in line today so I would expect to ship it in 2-3 weeks. Like I said, I'm sorry about the wait, there really is nothing that can be done to speed up the process. I'm just making sure everyone gets a quality cartridge. Thanks for your patience, I know it's been a long wait.

Also check pages 15 & 16 in the Handy Specification from AA here - that is where I learned it all. (I use the Windows Picture and Fax viewer to see the multipage tif)

I'm not sure if these do what I think they do but I think they do From http://www.monlynx.de/lynx/hardware.html $FC08,$FC09 VIDBASL,H Base Address of Video Build Buffer $FC0C,$FC0D VIDADRL,H Current Video Build Address There are similar values for the collision buffer.

Right off the bat (section 1.1.4) I found this 2's compliment signed integer gotcha - it's an oldie but a goodie! if ( x<0 ) x = -x; // assume x positive here (WRONG!) This is because there are two numbers in the set of base two integers of a given size that are their own negative: 0 and 2^(bitSizeOfType). i.e. To negate a signed two's compliment integer, you toggle or flip all the bits and increment the number, considering the byte -128 (0x80): 10000000 toggled 01111111 incremented 10000000 => thus, it's its own negative. The paper looks like it has all the bit and math tricks I know and much much more.

Very cool! You probably should use a series current limiting resistor. I'm not familiar with the layout of the 2600 internal PCB's and I can't tell from the video whether the LED is powered by the 7805 regulated 5V supply or by the raw voltage coming in from the transformer (14V or 15V depending on the schematic, probably pulsed DC from a rectified 9V transformer, filtered by 16uf and 2200uf caps and regulated by the 7805 in the 2600) , but I'd strongly recommend using the 5V regulated source. 1K ohms is probably too large: A typical red LED has a forward voltage drop around 1.48V and likes 15ma to 20ma of current. 5V(supply)-1.48V(LED voltage drop) = 3.52V(to be dropped across the resistor). Applying Ohms law E=I*R: 3.52V = 20ma*R or 3.52V / .02A = R so 176=R. The nearest common resistor values are 150 and 220 ohm. I hope that's useful. Cheers!

I was looking for the woman who worked with John Skruch when I worked for Atari and I found THIS! I hope this is not a repeat post, but this is AWESOME! http://www.digitpress.com/library/books/book_atari_lynx_hint_book.pdf I always loved the Zarlor Mercenary "Game of Life" egg and the Chips Challenge Mandelbrot generator. Notes: The RoadBlasters egg is wrong - you have to be holding a button when you drive into the tree. Toki eggs were unknown to Sunnyvale apparently (hehehehe).

Thanks, and I really don't know. As far as I know I was the only one who did it and we had to take a lot of pictures, especially in that first year. I was in the Lombard Illinois office and I'm sure at least John Skruch and Leonard Tramiel must have known about it. They could have just as easily done it in Sunnyvale.

hahaha, you are not even close to the first one to laugh. I'm sure Craig Erickson and Steve Ryno had more than a chuckle about it. And 25kv zing from a monitor - holy crap - I'm glad you weren't seriously hurt.

Be careful! There is high voltage inside a running Lynx, even when using batteries - remember, there are tazers that run on AA batteries and they use voltage multiplying circuits similar to fluorescent ballasts. I found out the hard way... The Lynx backlight, while nice, is uneven and shows up in photographs. To address this at Atari I opened a Lynx (Mandy) just for photographs. We would "flip" the translucent LCD screen out of the shell on its ribbon cable onto a white photographic light box where we would take the pictures that I think you see in all the press materials and catalogs. The photographers needed me to set up the Lynx, run, and play the games. It was a little challenging to use the Lynx controls perfectly still while the display was dangling on its delicate cable. Occasionally I would have to reposition the screen to square it up or re-center it. Once, I accidentally touched the backlight power supply which arced and burned a hole completely through my thumbnail. It stunk and hurt like hell. The Lynx was fine. D. Scott Williamson

This is an awesome paper on computational math http://www.jjj.de/fxt/fxtbook.pdf Matters Computational Ideas, Algorithms, Source Code In depth explanations of various computational and math techniques, tricks, and gotchas. The first section deals with integers and binary and is totally relevant to 6502 programming. It's a great reference, getting into details of various math operations with an eye on pitfalls and optimization. ( Thinking of you [and DiMath] when I posted this Selgus! )