jbanes

1. The 7800 doesn't have problems with horizontal scrolling. That's the Colecovision. The SMS added a new mode to the VDP to make scolling a more reasonable affair. Vertical scrolling what is tricky on the 7800. (Ratsa-fratsa, 'holey' DMA, ratsa-fratsa, I don't see anything "holy" about it, *grumble*) 2. "Speed", in the context of in-game motion, is an illusion. (Lunchtime, doubly so. ) To make something go faster, you simply move the object more pixels per frame than you would otherwise. 3. The greatest difficulty for the 7800 is in rendering all the background tiles on the screen. Scrapyard Dog seems to have done it, but everyone seems to still be arguing over how it did it. There you go. The 7800 should be able to do that, with some damage to the background. Just don't count on Operation Thunderbolt being ported.

Battlezone and Star Wars are both possible. Perhaps even likely, given that both use wireframe models. In the case of battlezone, you've got one color to work with, so you only need to plot the lines. Note that you'll need to use 160x192 mode to keep the amount of memory down. It might be possible to use 320 hi-res mode, but then the X coordinates would overflow a single byte of data. (Remember, we want to keep memory down!) What's needed for rendering: 3 bytes of graphics data for each pixel mode (e.g. In 160x2 mode: 10, 01, and 11) A run of 32 filled bytes of pixels (This is for Step 4 of footnote [3]) A good understanding of Bresenham's Line Algorithm[1] A simple 3D engine[2] The requirements for the 3D engine are: Ability to do projection computations per vertex (This is as simple as screenx = x/z, screeny = y/z) Ability to rotate and translate vertexes in 3D space (This requires some matrix math) 16 to 32 bits of storage per vertex (Depending on how large your world is.) Fixed point math library capable of handling 16 or 32 bit numbers What's needed per vertex: 1 byte for the X starting point on the screen 1 byte for the Y starting point on the screen 1 byte for the X ending point on the screen 1 byte for the Y ending point on the screen Code to switch the two so that starty < endy What's needed per line: An 8 bit value containing the current x location of the line. An 8 bit counter used to figure out the number of pixels needed before the next Y increment Code to create DL entries for runs of pixels.[3] The smallest case is a single pixel. The largest case is a 160 pixel run. As usual, your biggest challenges are memory and CPU. Assuming we're talking about 30 triangular polygons at any given time, we find that we'd have about 90 vertices to concern ourselves with. Those 90 vertices would take about 180 bytes of memory for 16 bit number, or 360 bytes for 32 bit numbers.Given that these are triangles, you would have a worst case of two lines per polygon on the screen per scanline. That works out to 60 lines per scanline. Assuming approximately 2 DL entries per line drawn, this gives a worst case of 60 DL entries per scanline. At 5 bytes per DL entry, you'd need 60 * 5 = 300 bytes per scanline, plus 2 bytes for the terminator, plus 3 bytes for the DLL entry. For 192 lines, that's 58,560 bytes of data. (!) Realistically, you'd try to trim down these requirements by taking advatage of many known quantities. For example, you can insert blank DLLs with long offsets for scanlines that contain empty space. Objects that are far away can be replaced with fewer polygons, thus reducing the load. Objects that don't zoom or otherwise change (e.g. moon background, score, number of tanks remaining, etc.) can be replaced with sprites. Limiting the number of close-up objects would also reduce the number of lines drawn per scanline, thus also limiting the number of DL entries. Using these screenshots as a reference, the worst case appears to be around 17 lines per scanline, and it only gets that high for a select few scanlines. Someone with more experience than I could probably compute the likelihood of running out of Maria cycles for drawing. For those scanlines, you'd probably see flickering from the hardware's inability to keep up. Starwars would be effectively the same sort of engine, except that you'd need to deal with more colors (which means finding a solution for neighboring pixels of different colors!), and likely quite a few more objects to deal with. I won't sugarcoat it. Starwars would take some major Cheating Like Hell to make happen. Battlezone has relatively little happening on the screen at any given time, and thus makes a perfect candidate. But Starwars would easily stress the Sally and Maria beyond their capabilities. If you wanted a true-to-arcade experience, then you'd want to load the cartridge with spare RAM and a coprocessor to generate long runs of data that would appear to the Maria to be large sprites. If you're willing to bleed the game of many elements, you might be able to sacrifice a lot of detail to get things down to a level that a plain-jane 7800 can handle. Good luck to whoever wants to try their hand at this! [1] http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm [2] http://en.wikipedia.org/wiki/3d_projection [3] The code would be something like this: If first pixel is the left half of a pixel AND there is only one pixel, make a single 160x2 entry with the left pixel. If first pixel is the right half of a 160x2 entry, make a single byte 160x2 entry. Compute the number of bytes needed to fill the rest of the line. Divide by two. (The division can be accomplished with an LSR instruction.) Using the number in step 3, make an entry for 32 (or is it 31?) dual-pixels that need to be filled. If the last fill is less than 32, use that number instead. If the number in step 3 was odd before division, make a single, left pixel entry onto the screen. (The carry flag is the easiest way to check this!)

Actually, your explanation makes perfect sense. Incrementing the program counter would skip the next instruction rather than fetching two bytes of the indirect address. So the ALU is used to increment the 8 bit portion of the address to fetch the second byte. For example: Let $4004 = $10 Let $4005 = $0a 1. The processor hits the instruction JMP ($4004) 2. The processor fetches the absolute address $4004 3. $10 is found to be the low byte of the address 4. Add 1 to the low byte of the Absolute address ($04 + $01 = $05 | ( $40 << 8 ) = $4005) 5. The processor fetches the absolute address $4005 6. $0a is found to be the high byte 7. The bytes are combined to form the address $0a10 8. $0a10 is loaded into the Program Counter (aka Instruction Pointer, depending on your terminology) In the case of this bug, the following happens: Let $4000 = $09 Let $40FF = $10 Let $4100 = $0a 1. The processor hits the instruction JMP ($40FF) 2. The processor fetches the absolute address $40FF 3. $10 is found to be the low byte of the address 4. Add 1 to the low byte of the Absolute address ($FF + $01 = $00 | ( $40 << 8 ) = $4000) 5. The processor fetches the absolute address $4000 6. $09 is found to be the high byte 7. The bytes are combined to form the address $0910 8. $0910 is loaded into the Program Counter In order to fix the problem, there obviously needs to be a step 4.5, similar to the step 4 you gave: 4.5 If the carry flag is set, increment the high byte. ($40 + $01 = $41) Does that make sense?

I have a theory on that. (Which is bolstered by vdub's excellent correction to my understanding of the JMP bug.) The 6502 uses 8 bit pages of data, of which it addresses directly. When you cross a page boundary, it needs to reconfigure the memory controller to address a new page. (i.e. An early form of segmented memory.) When the JMP goes to pull the indirect address from memory, it first tells the memory controller which page to address. Then it uses 8 bit addressing to get the two bytes. The first one is returned fine, but the second one causes the 8 bit address register to wrap. Thus, you end up with the wrong value for the second byte. Excellent! Thanks!

Now that makes sense. Given that DOS was unnecessary overhead (not to mention on a floppy disk itself), many of the disks were bootable. I remember that there were several software titles that did made use of DOS, though, but couldn't legally distribute DOS on their disks. The install instructions for these generally started with making the disk bootable (probably with the 'system' command, or the equivalent for the day; I don't remember), then rebooting into the game. I was always worried I'd accidently wipe out the game. Hard drives, actually. The arrival of the hard drive meant that you could run DOS without swapping disks. As a result, software packages that relied on DOS became much easier to run. The huge variety of IBM PC clones that began appearing probably also contributed to a nervousness about relying on the hardware directly rather than DOS's (pathetic) abstractions. Besides, as games got larger they needed to span more than one disk. The hard drive neatly solved that problem. Correct.

Is there something wrong with these adaptors? Yes it does. The manual tells me that the fire buttons stop your fishy. So there.

Two Words: Shark! Shark! That is all.

Thanks guys! That answers nearly all my questions. So to recap: 1. Yes. The 6502 will halt immediately. 2. Correct. 3. The extra cycle stems from opcodes that address in combination with a register. The register may push it over the original page boundry, demanding that the memory controller reset to a new page. 4. Close, but move the blank bit: N V x B D I Z C 5. Still waiting for someone to comment. That's my understanding as well. The 6502's memory wrapping apparently caused a bug in the JMP instruction. From what I understand, if you jumped to the end of a page, the next instruction would read $xxFF and $xx00 rather than $xxFF and $xxFF+1. The issue wasn't fixed until the 65C02.

I have a few questions on the 7800's design that I hope someone doesn't mind answering. Sorry if these have been answered before, but I haven't been able to find the necessary documentation. Thanks in advance! Can the processor be halted in mid-instruction? i.e. When the Maria sets the halt line, the processor is supposed to halt in preparation for DMA from the Maria chip. However, most instructions take at least 2 cycles. Some instructions take as many as 7 cycles. Would the 6502 stop in mid-instruction, or would the Maria be forced to wait up to 6 cycles? The documentation mentions long TIA and memory controller accesses as a possible delays, but it doesn't specify the instructions. There seems to be some confusion on how (indirect),y memory addressing works. To verify, the indirect address is an 8 bit value that points to a 16 bit, little-endian address in the zero page of memory. That 16 bit address is then added to Y to produce the final address. Correct? Many opcodes take an extra cycle if the page boundary is crossed. However, none of the documentation seems to suggest which page we're working in relation to. Absolute addressing is particularly confusing, as it's in relation to nothing. The 6502Sim package appears to test against the zero page (0x0000 - 0x00FF), but I'm not certain that's correct. I would tend to assume that the current page would be defined as whatever page is currently flowing through the memory controller. i.e. I should look to the Instruction Pointer for the current page. Does anyone know which one is correct? PHP and PLP can be used to get and retrieve a byte representation of the processor's internal flags. Does anyone know which order these are in? I've been assuming the following, but I haven't found any docs that confirm it: 7 6 5 4 3 2 1 0 x N V B D I Z C The TIA/Maria registers appear to be mapped into the Zero Page of memory, and the stack area (0x0100 - 0x01FF) is interrupted with Shadow Memory. (0x0100 - 0x013F) Does the 7800 Sally map the zero page and stack pointer to some other address, or are the Zero Page and stack pages cut down to 192 usable bytes each? Thanks again for your help!

Maybe you can help me out here, because I've been trying to figure this out for the longest time. What exactly does MobyGames mean by "PC Booster"? I can't seem to find the term used by anyone other than MobyGames. As best I can tell, it seems to be their nickname for the PCjr architecture. i.e. Most sites say that King's Quest came out for Apple II, Amiga, Atari ST, and PCjr. But MobyGames says Amiga, Apple II, Atari ST, and PC Booter. Any insight?

It's true that most games targeted the IBM PC platform as a whole rather than the PCjr in specific. It probably meant that the games were missing some PCjr exclusive features (e.g. better sound capabilities), but they were fun to play anyway. I remember playing MS Flight Simulator, Links Golf, Crossfire, "Win, Lose, or Draw", California Raisins, Where in the World is Carmen Sandiego (after a system upgrade to 640K), and many others. The PCjr never became the Atari/C64 killer that IBM had intended, but developers did make games for it. Of course, no PCjr discussion is complete without ragging on the built-in "game" that IBM put in the ROM code. If you exit BASIC after the machine boots, you'll find yourself on a screen with a small character and a key. The only hinderance to grabbing the key was a pen with a hole at the top. (It looked like the ghost pen in PacMan, except bigger.) If you ran into the pen and grabbed the key, your character would begin falling down screen after screen as the computer played a little ditty. Once the tune stopped, you saw a picture of a keyboard on the screen. If you pressed a key, the character would drag it onto the screen from one side, and lay it on the keyboard image. There was nothing more to do at this point, other than punch a bunch of keys. Be that as it may, I still had to flip the disk on many games. I have explicit memories of having to pop the IBM PC port of Tink Tonk out of the drive, flip it over, and reinsert it for the game to continue. It's quite possible that this was done for compatibility with the early IBM PCs that didn't have double-sided disks. You know, now that I think about it, Tink Tonk and Tinka Tonk must have been taking advatage of the extended CGA modes in the PCjr. The colors were definitely not the standard palletes found on CGA adaptors. In fact, I remember it being just as colorful as the Atari version I linked to above. (The case was the same, too.) So there was at least two more. According to Mobygames, Crossfire also used PCjr modes, so that's three. (Although, I remember getting the game on a floppy, not a cartridge. Go figure.) Poking through a bit more, it looks like Mobygames knows of 39 games that use the PCjr modes.

Are you playing the same 2600 version the rest of us are? Quit holding out on su, dude. We want to see the super-cool version! If the Intellivision version is "squashed", then the 2600 version would be outright flattened. Granted, you're not going to get square pixels on a home television. (At least not on the televisions of the early 1980's.) But the playfield design of the 2600 pretty much pales in comparison to what the INTY could do. And I don't believe for a moment that those flickering squares are eggs. This is true. If you were a bit off, your chef wouldn't climb. That being said, I find the Atari controls to be more frustrating. Perhaps it's because you get used to sliding the disk around as you pass the ladders, but the Intellivision controls seem easier to adapt to.

Wow, I haven't seen a cartridge for the PCjr since... well... since I had a PCjr. FWIW, the only cartridge I ever saw was PC BASIC. While there were a few others on the market, the cartridge format never took off like IBM expected it to. Double sided floppies (from the days when you actually flipped the floppy over to access the other side) were much more popular due to their high storage capacity. They weren't as durable as cartridges, but no one really worried about it at the time. As a bonus, many small-time game producers were able to create PCjr games on inexpensive floppy disks. Some of my fondest memories of gaming on the PCjr was a Q*Bert clone with Ice Cubes (Cubert, get it?) The game came on a floppy disk in a plastic snap-sleve. Not even a box! So, to get back on the topic, the carts you have may be fairly rare, but I doubt that they're worth much. I don't know of anyone who thinks of the PCjr as a "collectors machine". Anyone who wants to run the old CGA games is probably already doing it using an emulator like DOSBox. The experience is mostly the same, save for the lack of that $#$! infrared keyboard that was always out of alignment or needed its batteries replaced. I never knew that I was missing a keypad until I had one... Both the PC and PCjr used a 4.77MHz 8088. Many of the games were calibrated to that clock rate and instruction cycle count, and got really messed up on future machines. When the XT came out, many of the machines defaulted to 4.77MHz for compatibility. By hitting the right key combination (CTRL-F8, I think), you could put the machine in "Turbo" mode which would kick it all the way up to 8MHz.

I can't believe anyone is arguing this. Even in jest! The INTV version wins, hands down. Its only fault is the #@[email protected]! control disc. I'm sure that a 16-way controller sounded like a good idea at the time... Strictly speaking, though, Burger Time is an exception. Many of the games for the Intellivision are far more cerebral than their Atari counterparts, and have complex control schemes for managing the game at the 50,000 foot level. Arcade game don't seem to port all that well as the controller can get a bit finicky at just the wrong time.

I actually like Atlantis. However, IMagic generally went for the graphics rather than gameplay. All their games were very pretty to look at, but failed to hold my attention for more than 10-20 minute bursts. (With the exception of Beauty and the Beast, that is. But that's for my INTV. ) Compared to IMagic, Activision produced graphically inferior games. However, their gameplay was always top-notch. A perfect example of this is Enduro. I just can't put this stupid game down! All you do is pass cars, cars, and more cars. Yet it really grabs you and yanks you into the game. You feel the frustration as you miss the next level by 2 cars. You feel the exhiliration as you zip by cars at maximum speed, trying not to get creamed. You feel the triumph as you hear the flag tune, signifying that you've scraped through another day. The graphics may be simple, but Activision just nailed this game. As for Atari Pinball, I have to agree that it's boring. The paddles move so slowly that it never feels like you're actually hitting the ball. Every time I load it up, all I can think of is, "Ok, if we replace the playfield graphics with double sized sprites, the bumpers will be round and able to shake when hit, then we can use the playfield to show ramps in the background, extend the table downward with a scrolling playfield..." You get the idea.

No argument here. My only point is that it's silly to support the SMS by calling the NES a ColecoVision ripoff, when that was exactly what that SMS was. The NES was a custom design that had a lot more in common with the Ataris than it did with the ColecoVision.

How odd. As it so happens, I was just amusing myself over the fact that the SMS was nothing more than a ColecoVision with a souped up VDP and sound system.

Radio Shack: You've got questions, we've got blank stares!

http://advsys.net/ken/build.htm I could be wrong, (it has been known to happen), but I don't think he's talking about what you think he is. Either that, or we're actually talking about the same thing and just misunderstanding each other. To use a little ASCII art to explain, this is the vertical cross section of rays being cast: | |------O | \|/ | / \ | You'll note that the vertical coordinates of both the source and the destination are the same. If you simply shift the casting downward, both coordinates will move like this: | | | |------O | \|/ This produces a "crouching" effect (or a stilting effect in the other direction), and is how Doom can support vertical movement up stairs, and off ledges. Without the ability to shift vertically, Doom would have been stuck to a single plane like Wolf3d was. So if that doesn't produce a pitch effect, what does? The answer is that you need to shift the end of the ray, without shifting the origin. i.e.: | |------O || \|/ |V / \ | | | /O | /\|/ | / / \ |/ Getting this result is quite simple: 1. Shift the ray coordinates down as if you're crouching. 2. Use the vertical hypotenuse, in addition to the horizontal hypotenuse, in the length calculation of the ray. 3. Shift the sliver selection down to pull slivers representative of the Angle of Attack. i.e. Normally the center of the ray would always collide with a wall. After pulling the dest coordinates down, it may collide with a floor instead. On a strictly horizontal plane, this may put the viewer below the floor. You instead need to grab a vertical sliver from either side of the floor to the wall. Now, I personally feel that this is a "good enough" rendering.[1] However, the truth is that it's we're mixing a vertical parallel projection (y = y, throw away the z) with a horizontal perspective projection (x = x/z). The result is that everything will look right as long as the viewing angle is parallel to the horizontal plane, but will begin to skew horribly as soon as the vertical viewing angle changes. To see this, compare these two screencaps: Raycaster OpenGL You may notice that the vertical lines in the "Raycaster" link are all perfectly vertical. If you look at the OpenGL image, you'll notice that the vertical lines slant outward from the center. Also, if you compare the short wall toward the back, you'll notice that the horizontal slant doesn't seem to change between the two. Only the wall-section dividers seen to change from vertical to slanted. This can be corrected by casting rays in both the horizontal and vertical directions. Of course, then you have a raytracer. Thus an easier solution is to interpolate the correct location to read a sample from based on a corrective formula. As you might imagine, this is a lot more expensive. Of course, that is how I believe it works. I could still be wrong. There are only two ways to be 100% sure about the Build engine itself: 1. Decode the Build Engine source code. (Good luck, it's not that easy to read.) 2. Ask Ken Silverman. If it's important enough to you to figure out how the Build Engine works (say, you're working on an Atari engine based on similar principles), then both options are worth your time. Though the second option is probably faster. (rolls eyes) Do you really want to be dragging that out again? I say tah-may-toh, you say toh-mah-toh. I say emulating a framebuffer; you say who gives a damn, it's still a framebuffer. There's really no point in arguing it further. [1] There's some discussion on doing this for a Voxel Terrain engine on flipcode.

Difficult to say. In theory, the 7800 can do a much lighter blue. In reality, it seems to depend upon the system. I just reduced the shade of the blue for the mockup, to simulate the darker look of the 7800. Actual results may vary.* * Past results are not indicitive of future returns. ♫ Do not take if you are pregnent or have a heart condition. ♀ May cause epileptic siezures during extended play. Always make certain to stand at least 10 feet away from the television. Ω Why are you still reading these?

Aaaaah, I see. The darn 'A' is redundant, but it didn't occur to me that the DASM authors might have taken that into account. Thanks!

Does anyone know if accumulator mode addressing is supported by DASM? A simple example program like the following doesn't assemble due to "unresolved symbol" 'a': processor 6502 org $0000 asl a Yet according to all the documentation I can find (example: here), accumulator addressing is supposed to be available on the ASL instruction. The LSR, ROL, and ROR instructions appear to be similarly affected. I'm using a recent Mac compile of DASM. (Whichever version that is; I can't find a reliable version number on it.) I've also tried it on Windows with the most recent version, and DASM simply fails to assemble it with the message, "More than 10 passes, something *must* be wrong!" Any insight?

The developer has released it for free on their website. It should work on a modern Windows machine. If it doesn't (or you're using another OS), grab a copy of DOSBox.

Not really. The look up/down functionality is a hack that causes extreme distortion of the image. It's essentially just shifting the entire scene up/down to let you see beyond the normal viewport bounds. You're probably thinking of Raven's hacks to the Doom engine. The skewing in the Build engine is caused by a failure to correct for warping effects, not an inability to pitch. If you write a raycaster, you'll notice the same effects on the horizontal plane, giving the image a weird "fish bowl" effect. The problem is caused by mixing polar coordinates with cartesian coordinates, resulting in a spherical image being mapped onto a flat plane. A bit of math is always used on the horizontal plane to correct for this. However, when the rays are pitched upwards or downwards, the math becomes more complex due to the unexpected vertical angle. It can be corrected for in a similar fashion, but the correction would have to be applied to every pixel. Thus it was easier to simply leave it a bit warped in those days. Note that several "voxel rendering engines" (a misnomer if I ever heard one) used angled raycasting to produce realistic terrain effects. However, the angle was usually fixed in these engines, thus making it easier to correct for distortion. There's an example of such an engine here. Weird. I've never had any trouble getting to it. I've attached the game and a screeny just in case you're interested. Java 1.4 or higher is required. Robotron4096.zip

Pitch is supported by the build engine. Otherwise, you're correct. However, when you get down to it, the math isn't all that different. Take my Robotron 4096 game as an example. Instead of casting a ray per pixel-column, I computed the center of each polygon, cast a ray to determine distance, then scaled the bitmap to match. Using this method, it becomes quite easy to rotate the camera, then compute the proper rotation of the polygon centers. If you're making a game ala Wing Commander, you can perform a few transforms on those computations to find the correct, pre-rotated sprite. (Note that for an XWing-type game, using a low poly-count and lack of textures would make it a lot easier to compute the vertex projections and fill in the scanlines instead.) The point that I'm getting to is that raycasting has a lot in common with other psuedo-3D projection methods. As a result, the performance of a raycaster can be a useful measuring stick against which to estimate the performance of other methods. It all comes down to accounting for the differences in engines when doing your guesstimations.