EricBall

You'd be surprised. Skeleton+ is freely downloadable, yet people still buy the cart.

From watching Top Gear, the challenge of the Nürburgring is it is dang long. So trying to anticipate each corner can be very difficult. There's also the challenge of the other drivers (and occasional wreck / debris) and that your insurance is void. Taking a lap with a local might be the better way to go.

In the second video at 0:56 on the second bounce you can see the front bar of the roll cage buckle then collapse on the third bounce.

On an NTSC 7800 a single 14.3181818MHz (4x NTSC colorburst) crystal is used to generate both the MARIA (and thereby the pixel and CPU/TIA) clocks. The color output is this clock divided by 4 and hue/phase via a tapped delay line (same as the TIA in the 2600). However, the PAL 7800 uses a separate 4.433MHz PAL colorburst crystal to generate the color output. TVs are relatively tolerant of variations in signal timing, but not in colorburst frequency or phase (especially PAL). Curiously the schematics for both the NTSC and PAL 7800s have a 14.31818MHz crystal, which is different than the 14.1875MHz measured by nichtsnutz. It would be interesting if someone could open a PAL 7800 and see if they can read the frequency off the crystal.

Hi Harry. A good explanation except you've reversed DLL and DL. The Display List List entries point to Display Lists which are then used to display several lines. And if a sprite moves between zones the Display List entry for that sprite is put in the appropriate Display List.

The Propeller has two "native" languages. Like any microprocessor, Propeller Assembly (or PASM) is the human version of the machine code executed by each processor. But like 8-bit computers of old the Propeller has an onboard interpreter. However instead of being a version of Microsoft BASIC, this interpreter is for a new high level language called SPIN. The SPIN interpreter itself is written in PASM, but the initial code for any Propeller program is in SPIN (which can then start additional SPIN or PASM code). SPIN source code is compiled into bytecode to save space (since the Propeller only has 32K of onboard RAM available to SPIN), kinda like BASIC typically tokenized programs - although the compiling is done offchip. Anyway, SPIN has access to all of the Propeller's features, including the video generator. This has always seemed a little pointless to me. Although the video generator can be used to for other reasons, SPIN is too slow to generate video. Or is it? Last night I proved myself wrong by generating NTSC video with just SPIN code. It's admittedly low resolution (20 pixels across and only 1 color + black), but I'm hoping to improve that somewhat (I'm shooting for 32 pixels and 4 colors.) Useless - yep. Well, unless you want a giant 2 character display. The problem is the processor is fully utilized, so there's no advantage to using the SPIN routine instead of a PASM driver which would also require a processor but would provide higher resolution and more functionality.

According to Wikipedia CV games could be 24K or 32K, so it may just be a fault of the emulator or maybe you need to do something special to enable all 32K. According to the CV FAQ cartridge ROM is $8000-$FFFF (32K) "broken into 4 sections, each enabled seperately". Older games (i.e. Donkey Kong) often had smaller ROMs than later games due to costs (e.g. Combat was a 2K cartridge even though the 2600 could support 4K without bank switching).

Actually, it looks like the WM+ can be had from eBay for ~C$10, so that's not as bad as I thought.

Yes, Sony has probably lost a few customers over this. But businesses are often short sighted. So the threat of piracy today is worth more than lost sales tomorrow. Also, how many PS3 owners said they'd never buy Sony after the rootkit fiasco? I my mind there are some bigger issues at stake here around ownership and control. Sony has basically said that you do not own your PS3 or it's software - you only purchased a license to use it. And Sony is within the EULA to revoke that license at any time, without compensation. Furthermore, they have the power and ability to do so because your PS3 is probably connected to the PSN. And I strongly suspect Microsoft has similar terms in it's EULA, they just haven't exercised them in as blatant a fashion. (Although banning consoles could be taken as an example on an individual basis.) And now it's up to the Honorable Judge Richard Seeborg to stick to the letter of the law and the EULA or to see beyond it to a world where physical ownership is meaningless.

Ack, I didn't realize Skyward Sword needs WM+. Sigh I'll still get it, but I hate spending $$ on add-ons. Is there anything on the 3DS on your wishlist?

I think both of those graphics modes fall into the same class as the Amiga Hold-and-Modify (HAM) mode - great for static, pre-rendered graphics, not very useful for an actual game. (Then again, Tower Toppler uses artifact color intelligently, so never say never.) Also, I'm not sure that similar effects couldn't be generated on the NES. Umm... The NES PPU has a total palette of 25 colors: background + 4 sprite palettes of 3 colors + 4 tile palettes of 3 colors. Each sprite could use any of the 4 sprite palettes and each group of 2x2 8x8 tiles could use any of the 4 tile palettes. So it's certainly possible to use 25 colors on a single scan line. 8 way scrolling would require extra RAM in the cartridge, but it's fully supported in hardware.

All files available from: http://dockets.justia.com/docket/california/candce/3:2010cv01811/226894/ Well Sony has fired back at the Amended Complaint with two barrels: a Motion to Strike and a Motion to Dismiss. I haven't gone too far into them, but Sony's first point is the five plaintiffs have different complaints and one didn't even install OtherOS! So Sony's point is if the the five plaintiffs are representative of the class, as a whole, then the court can't assume a class really exists. Ouch!

With the renewed interest in 7800 Development, I've created Atari 7800 Programming with the info I previously had in the Atari 7800 Programming wiki. If anyone is interested in contributing (or culling info from AA) please let me know.

The DPPH & DPPL registers give the 16 bit address of the first display list list entry. Each DLL entry follows the previous in memory. Each DLL entry contains a 16 bit address of the first entry in the display list used for OFFSET+1 lines (the DLL "zone"). (Each display list entry follows the previous in memory.) Each direct mode display list entry contains a 16 bit address of the bottom right sprite data. The current OFFSET value is added to the high byte of the bottom right address to get the address of the current line sprite data. After each line, the current OFFSET value is decreased, unless it is zero in which case MARIA uses the next DLL entry. Each sprite uses one (or more) display list entries. Sprites wider than 32 bytes need more than one entry in a single display list. This is also try for sprites which wrap around horizontally. Sprites which span more than one DLL zone (typically 8 or 16 lines), either because they are tall or moving vertically, need more than one display list entry in multiple display lists. Dynamically building display lists is a lot of work and takes a lot of time.

Except the 7800 doesn't have a playfield. It does, however, have indirect or character mode where the display list entry points to a string of characters (tile indexes).

I think the DS has at least a year if not two years of life before the 3DS has a large enough installed based to supersede it. And although I have earmarked some Best Buy giftcards for buying a 3DS, so far I'm only really interested in Kid Icarus and the Zelda remake.

Easy stuff first (i.e. answers exist in the forum) Display List List Help Sample 7800 source code Sample 7800 source code using (ZP,X) It's a time & effort issue. Maybe if you want a tool like batari BASIC you can assist GroovyBee with his toolset.

The only logic I can see is somehow the cost (to Square Enix) to offer the download option is higher than their sales estimates. In particular, I believe that Sony doesn't provide the server infrastructure for online games and this may extend to PSPGo downloads too. I don't think the testing would cost much more, given once the game is downloaded the game should play the same. (Unless Square Enix was doing some UMD-only I/O which didn't have a drop-in PSPGo equivalent.) There also may be piracy concerns, although I'm not sure whether UMD is any more secure.

No, each opcode is well defined and performs a very distinct operation. However, because each opcode is very simple, you need many of them to accomplish each task. So k = i + j would break down into at least three instructions in 6502 assembly: LDA i ' load the byte in RAM with the label i into the accumulator ADD j ' add the byte in RAM labeled j to the accumulator STA k ' store the accumulator to the RAM address lableled k (Labels are handled by the assembler and would need to be defined elsewhere.) Now imagine what a more complicated operation would be. Writing in assembler requires you to think in small steps. All of the chips are controlled via specific memory addresses. So STA WSYNC writes a byte to a memory address used by MARIA which causes it to halt the 6502 until the start of the next line. And yes, although the assembler will do a certain amount of work for you (turning labels in to addresses, instructions into binary values, etc) you, as the programmer, are responsible for most of the work. I'm not sure what you are asking. On startup the 6502 reads the address stored at the reset vector (I can't remember the specific address offhand) and starts executing at that address. On the 7800 that's the BIOS ROM which displays the Atari logo then tries to determine whether the cartridge is a 2600 or 7800 cart then executing the cart. But to start learning 6502, you might want to try Assembly In One Step. You need to remember the 7800 was first released in 1984 and it contains only 4K of RAM and the CPU runs at 1.79MHz, i.e. a thousand times slower than today's computers and a million times less RAM. The 7800 does have a graphics engine - the MARIA chip, which is capable of displaying hundreds of sprites onscreen and can create a display without the processor having to update it every line like the 2600. What the 7800 doesn't have is a graphics library (other than the one Groovy Bee created for his use). But that's a good thing because you can write your code optimized for your game rather than dragging in functions and features which you aren't using.

One interesting datapoint: Kingdom Hearts: Birth by Sleep by Square Enix for the PSP will not be available for download on the PSP Go. (I don't know the logic.)

Heh, I just realized I have a second limiting resource: the big screen TV. Guess who wins between me playing a game and my wife watching Brothers and Sisters?

Quite correct. What I gave is not a valid NMOS 6502 addressing mode. STA ($7B,X) is a valid mode but does the add before the address fetch.

Assembler is the human readable version of the processor's native language. A good 6502 example is: STA ($7B,Y) Which translates to: 1. read the two bytes stored at hexadecimal memory addresses $7B and $7C as a 16 bit value (LSB first) 2. Add the current value of the Y register to the 16 bit value 3. Store the current value of the A register using the 16 bit value as an address Assembler is termed a "low level language" - each instruction is a very small & simple step in the program. An Atari 7800 game will contain thousands of instructions. And each instruction (i.e. STA) can be used for multiple functions. In the above example the instruction may be creating or updating a 7800 Display List or changing which character is displayed onscreen, or ... Without comments to provide context determining what each instruction does (on the macro level) is extremely difficult. (Which is the main challenge of disassembling a game.) The power of assembly language is there is nothing between you and the hardware. You are in complete control of the CPU. But that also means you need to create code for everything. The Atari 2600, 5200 & 7800 don't have bitmap displays. To display something onscreen you have to feed the graphics processor (the TIA, GTIA & MARIA respectively) the required data (and, in the case of the 2600, at the correct time). There's no plot(x,y) command, just a lot of STA instructions. I understand your disappointment with the sound capabilities of the 7800. For compatibility GCS (the creators of the 7800) included the TIA from the 2600 (which provides graphics, sound & paddle inputs on the 2600). For cost reasons Atari didn't include the POKEY from the 5200 (which provides sound & paddle inputs). Thus the 7800's sound is the same as the 2600: 5 bit frequency divisor (32 "pitches") and 4 bit LFSR selector (10 "waveforms") which produce around 200 usable "notes". But the notes aren't like a piano, nor is there a lot of ability to generate sound effects. I also wouldn't expect to accomplish anything, other than learning some basic assembly, in 5 days. But if you're up to the challenge, I'd recommend starting with the 7800 Software Guide. It gives all the details of the 7800 hardware and Display Lists.

It could be argued that many downloadable games have already hit the $5-$10 price point. The real question is whether the price of AAA games, in a downloadable/online format, will also follow this trend. I don't think so unless developers & publishers find ways to dramatically reduce the costs to create & market (not just distribute) a game. The question then becomes whether high cost AAA games can continue to exist in a world of cheaper games. And, on a personal note, my limiting resource is not money but time. I could easily buy another game with my discretionary spending. But I don't because I don't have the discretionary time to play it. There are also numerous ways people can play games at very low costs (emulation/homebrew, "free-to-play", older used games) that cost isn't a factor if you set your expectations properly.

Something for the C64 fanboys, but no-one else. I mean, look at that keyboard, and then look at the one you are typing on. Notice some differences?