EricBall

Note: I did get my son a used 2nd gen Shuffle from eBay. Yep, I noticed that. I guess they had enough people complain about the 3rd gen Shuffle being too small and needing Apple headphones. I'm a little confused about the 6th gen Nano. It's almost an upscale Shuffle - no video (not that watching video on a 2.2" QVGA screen was super-duper). But I guess it puts the focus back on being a music player. I wonder if it still has games or if they also got lost. And why multitouch on a 1.5" display? I do think that FaceTime on the Touch is a great idea. Now we just need to get FaceTime clients for PCs.

As everyone else has indicated, to start programming any PC and an emulator will get you going. Start simple and add complexity over time which should avoid the problem of the emulator doing more than the console is capable of, at least at the beginning. (Starting small and incremental enhancements is also good to keep up your enthusiasm & drive.) And once you have something working, reach out to the community. You may not have a RAM cart, but others do and many will help at least sanity test your work in progress. However, I have to ask - if you have no assembly experience, why start with the 7800? You are probably better off starting with something which can be programmed at a higher level and with better documentation and a larger homebrew community. batari Basic for the 2600 comes to mind. The problem with the 7800 is it requires a lot of code to get something to appear onscreen. The 2600 is a little easier in that respect (although some code is required to make a stable screen).

It appears Sony has been granted an extension of September 10th to respond. In related news, an OtherOS case in Australia has been dismissed with no clear winner. No damaged awarded, both sides must cover own costs. It sounds like the judge felt the EULA gave Sony the right to make changes, including removing OtherOS.

In actual fact, the first 16 bytes of the Propeller binary image don't appear to contain any code. However, I'd rather avoid any chance that someone could figure out a way to embed code in those 16 bytes. I'm just surprised that the literature I've read doesn't indicate this weakness. For Output FeedBack (OFB) mode where only the encrypted IV is used as the input to the next Cipher function, the lit indicates if the plaintext for any block is known then the ciphertext for any arbitrary plaintext can be generated for that block. Generating new IVs for each message is supposed to address this issue, but for my environment the IV is either static (stored onchip) or stored with the code (and therefore subject to duplication/reuse). CBC mode does away with the known plaintext risks by putting the plaintext behind the Cipher function.

Using the GEAR emulator I've confirmed the Key Expansion routine generates the correct output (and takes 4K+ cycles). Found two bugs and one optimization. Next I get to start tracing through the cipher routine. Thank gods for the NIST example data which shows the data at each step. One more bug and SubBytes + ShiftRows done. MixColumns + AddRoundKey is next. I just ran it and it fails. Sigh... It's working. Two more bugs squashed. Now I need to work out the Inverse Cipher routine. (Similar, but different and slightly more complicated, and may not optimize as nicely.) Each of the bugs has been fairly simple: 1. SHR instead of SHL to multiply by 2 2. AND #4 instead of AND #3 for MOD 4 3. ADD #3 instead of ADD #5 when I wanted to add 4 then add 1. 4. MOVD instead of MOVS (update destination rather than source) 5. ROL instead of ROR So, not logic problems per-se. More like typos. Do what I mean, not what I say.

Drat. I just figured out that Cipher Feedback mode (aka CFB) fails horribly if the plaintext of the first block is known. CFB mode works by encrypting an Initialization Vector, then XORing it with the plaintext block to produce the ciphertext block. The resulting ciphertext block is then encrypted and XOR'd with the next plaintext block to produce the second ciphertext block. And so on. The big advantage is decryption re-uses the encryption routine. But say you have a case where the first plaintext block and the ciphertext block are both known. (Not unrealistic as the first block is often a well defined header.) Then it's possible to determine the encrypted IV and use that to create the first ciphertext block for an arbitrary plaintext. So there's a slight possibility an attacker could create an arbitrary first block which would contain enough code to beep out the encryption key. Cipher Block Chaining mode (aka CBC) should defeat this because the plaintext of the first block is "behind" the encryption. So even if you have a known plaintext all you can do is generate the same ciphertext. The disadvantage is CBC mode requires the decryption routine.

One of the knocks against the Propeller is it has no code protection, unlike PICs and other microcontrollers with onboard EEPROMs. And although the protection may be less than perfect, I can understand many companies are not willing to have their IP in an easily accessible state. IMHO the way to remedy the situation is to include a small amount of onboard OTP storage for an encryption key and integrate a decryption routine into the bootloader. But for that to work someone (i.e. me) needs to code up the crypto routines. So I've been learning all about AES and working out how to code the routines in Propeller Assembly. I've coded up a first attempt at the encryption routine and it's surprisingly compact - less than 1K. I've done some cycle counting and it's over 14K cycles per 128 bit block! At 80MHz that works out to 88K per second, so that's not too bad as far as load time is concerned, adding less than a half a second for 32K. The biggest time sync is the combined ShiftRows + SubBytes routine which has to do a table lookup for each byte and reorder the bytes in the four 32 bit columns at just under 1K cycles for each round, and there are 10 rounds per block. And although crypto sounds big and scary, it's actually not that complex. The toughest part is keeping the byte order straight when reading the spec! (Like the 4 bytes which make up the 32 bit column are shown as [a0 a1 a2 a3], where a0 is the LSB!) AES breaks down into four or so main subroutines (SubByte which does a table lookup, ShiftRows which mixes bytes between words, MixColumns which does a matrix multiply on each column, and a routine to do a polynomial multiply by 2). The parts which operate on the 32 bit columns are easy on the Propeller, but the byte operations are painful! My next step is to wrap the code in something I can use to view the results then start going through the sample data and make sure everything works.

business realities vs. open sharing It all depends on what you want to accomplish. I'm sure you realize that programming for an obsolete console isn't going to put food on the table. However, it might still generate some "mad money". In my case (others may have a different experience) the license for Skeleton+ allows for anyone to download & play the game on an emulator or RAM cart or even make a cartridge for personal use. And yet I've sold well over 100 cartridges. So there definitely is a market for the physical cartridge even if a "free" alternative exists. Now whether I would have had better sales if the free option were not available is an interesting question. My instincts say the opposite might be true as the free option expands the market.

A single sided DVD could hold 7.4 hours of CD audio (2 channel 44.1KHz 16 bit PCM), more with compression.

Well, since it's AFAIK also the only Greenpeace game in existance, it probably won't happen again anytime soon. Some future day the "Playing..." series may see another Greenpeace game, but first it'll continue with something else. So which is it? As per Wikipedia hunting of whitecoats has been banned since 1987.

Free download of Grand Theft Auto and Grand Theft Auto 2 as Rockstar Classics I've played both and IMHO GTA was more fun than GTA2.

It appears the Didj is definitely hackable based on a simple Google search. Whether it's capable of GTA is a different question. The bigger question is whether you are capable of creating a GTA clone for any system. (Not a slight against you, but GTA ain't a small game.)

Linear Feedback Shift Registers PseudoRandom Number Generator

I haven't kept up on 7800 emulator accuracy, but it's certainly possible that: 1. writing color registers doesn't cause color stretching, or 2. writing color registers causes stretching on real hardware, but isn't emulated correctly 3. writing color registers causes stretching on real hardware and in current emulators Of course, if the side effect only occurs under some circumstances (i.e. only while DMA is active) then you may get a combination of all three possibilities.

A typical LFSR PRNG will go through runs where the numbers are predictable. You could use that to make the a kind of introduction for the first N rooms.

Very nice.

5^5 = 3,125 so you are correct. BOGUS would be another. Hmm.. 5 letter words using only those five letters... The trick is going to be vowels. BG, BS, GB, GS, SB, and SG aren't typical two letter combinations in words so almost all words will be CVCVC and CVVCS constructs, and VV is either OO or OU. That's 3x2x3x2x3=108 and 3x2x3=18 combinations.

SPIN (the high level language for the Propeller microcontroller) doesn't use braces - only horizontal spacing. i.e. if bSomething1 doif1true() doif1true() if bSomething2 doif2true() doif2true() doif1true() else doif1false()

Note: don't use WSYNC outside of the DLI, if you have a DLI.

I found a more current docket. It looks like to get more current you'd need a PACER account. The top three law firms were given joint custody of the case. They've also filed an Amended Complaint which makes a pretty good case against Sony. Interestingly enough, Sony has yet to respond to the complaint - although they were granted an extension to July 29, 2010. The Amended Complaint was filed July 30th so either something has delayed the posting, they were granted an automatic extension by the Amended Complaint, or they decided not to respond. The next scheduled item appears to be a case management conference on Sept 2.

I found a circuit diagram and I'll see if I can decode the cartridge pin out. Since the cartridge just connects the pins together, the number of behaviours is fixed. The games came more from how the onscreen display was interpreted using overlays and game rules.

You think they could have found a bigger TV for the players to crowd around.

You should always, always do things you are passionate about. That's the only thing which will keep you going when it gets frustrating. When programming the 2600 you must keep it's limitations in mind: 1. 128 bytes of RAM. Yes, there are more & more carts which can get beyond this boundary; but it's tough to use that extra RAM for "working" storage. Don't forget that 128 bytes has to include space for stack usage. 2. Very limited graphics capabilities: each line has a 20 bit playfield, two 8 bit sprites, and three 1 bit objects. Yes it is possible to go reuse those elements on a single line, but there are still limits in what can be done. Which leads to... 3. 76 CPU cycles per line. Each graphics trick, from changing sprite colors to repositioning sprites & HMOVE tricks to asymmetric playfields to 48 bit sprites, requires CPU cycles and often precise timing. Combining tricks increases complexity and often leads to code bloat with multiple kernel routines to handle each case and combination. Which leads to... 4. 4K address space. Yes, bankswitching can get you beyond this, but you only have 4K to use at any time. And though it's often possible to make the space/speed tradeoff, there are limits to how much space you can throw at the problem. 5. Color and sound. You have a choice of 128 muted colors and two channels of LFSR sound with limited frequency selection. Yes, it is possible to generate PCM audio, but it requires a lot of ROM space and CPU time during the display. Other general advice: 1. Dream big but start small. Get something working first the build on it. Small incremental changes will keep you going. 2. Don't try to create the final version first. Don't try to create the "ultimate" display kernel at the beginning - do something as simple as possible. 3. Build around the display kernel. The kernel is the most time and timing constrained code. The rest of your game should be written with the kernel in mind. 4. Be prepared to start over. You will almost certainly rewrite the kernel more than once in order to incorporate new features which will probably mean rewriting large chunks of other code. 5. Make backups, lots of backups. Not only because you may need to undo something you just broke, but you may need to go back to an idea you discarded. 6. Make notes & comments - lots! Document all design decisions and any tricks, even stuff you didn't end up using. You'll inevitably end up asking yourself "why did I do that?", so leave yourself the answer. 7. Cycle counting isn't just for the kernel. Know how long your other routines take. 8. Start with a plan - figure out the basic gameplay and where the 2600's limits are going to impact you most. 9. Playtest, not just yourself, and then listen to the feedback. Also test on a real system, not just an emulator. 10. Steal ideas then make them your own. See what others have done and also learn from their mistakes.

IIRC a major reason I Love Lucy survives is it was shot on film and the film was kept. (I think under someone's bed!) Other shows didn't survive because the film or tape wasn't kept (or was recorded over even), or was lost to fire or just the ravages of time.

The advantage of 40 pixel with 4 pixel spacing drawn with 5 sprites is the center is just aching to be used for the center baddie IMHO.