whats better 2600 or intv burgertime?

[whats better 2600 or intv burgertime?]

Hm... if there were an emulator supporting some configurable DirectInput interface, one could use Atari joysticks via Stelladaptor... anyone having success trying something like that?

 

Is there something wrong with these adaptors?

 

That's cheating, it doesn't use the fire buttons

 

Yes it does. The manual tells me that the fire buttons stop your fishy. So there.

[whats better 2600 or intv burgertime?]

Two Words: Shark! Shark!

 

That is all.

[7800/6502 Hardware Questions]

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.

 

Also: I don't think any of the indexed zero-page opcodes handle zero-page page-crossing; I think if

$FF = $00, $100 = $F0, $00 = $E0, and Y = 3, then

   lda ($FF),Y

Will load the accumulator with the value found at address $E003, not $F003!

 

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.

[7800/6502 Hardware Questions]

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!

1. 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.
    
   
2. 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?
    
   
3. 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?
    
   
4. 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 

   
    
   

5. 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!

[IBM PC Cartridges]

Thats only for the PC Booters

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?

[IBM PC Cartridges]

There aren't many diskette-based "PCjr." only games at all. King's Quest is the only one I can think of (A PCjr. specific version of M.U.L.E. is also supposed to exist.)

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.

 

IBM's PCjr. diskette drive was double sided so you didn't have to turn over the disk (as were all but the earliest 5.25" PC Floppy Drives.)

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.

[whats better 2600 or intv burgertime?]

I have to say that I think they are very close, with the edge barely going to the INTV.

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!

 

Perhaps I didn't play the arcade game often enough, but the 2600 port's pacing seems all right to me. Certainly the graphics look much better on the INTV, but the lower resolution of the playfield, and the way everything has to be 'squashed' as a result, lowers my opinion of the INTV port.

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.

 

Actually, if I remember correctly, *both* ports have the problem (or perhaps this is a "feature") of offering no slack whatsoever in the controls. Unless you're aiming exactly in the direction you're supposed to be going, the chef ain't movin'. No diagonals allowed. That gets annoying.

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.

[IBM PC Cartridges]

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...

 

I think I remember something about the PCjr having a faster processor than what was in IBM's regular desktops at the time.

 

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.

[whats better 2600 or intv burgertime?]

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.

[negativity]

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.

[What was second to the NES?]

After looking over documentation about it, I think they did quite a nice job of "souping it up".

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.

[What was second to the NES?]

NES was a cheap redux of 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.

[Radica Space Invaders > 7800 joystick]

Radio Shack: You've got questions, We've got cellphones.

 

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

 

[What lucasfilm Ltd games should've been on 7800?]

04/24/1994: Added "fake" LOOKING UP & DOWN after discovering that it wasn't too difficult to shift the screen up & down. 3 days later, the same effect mysteriously appears in Apogee's other game that they were working on at the time, ROTT. What a coincidence!

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.

 

Riiiiight. And the Atari 800 doesn't have a frame buffer.

 

(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.

[the 7800 vs nintendo nes (could the 7800 have done better?)]

Is that the lightest blue the 7800 can produce?

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?

[DASM Weirdness]

Just remove the "a"

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!

[DASM Weirdness]

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 7800 vs nintendo nes (could the 7800 have done better?)]

I miss EGA Trek. Anyone know if it's available on the Intraglobal Web-o-tron anywhere?

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.

[What lucasfilm Ltd games should've been on 7800?]

Pitch is supported by the build engine.

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.

 

The link you posted doesn't seem to be working for me.

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

[What lucasfilm Ltd games should've been on 7800?]

The thing with raycasting is that it's very special-purpose-- it does not support pitch or roll of the POV angle, and it's primarily used for rendering terrain. Pretty much useless for a space combat game.

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.

[What lucasfilm Ltd games should've been on 7800?]

Furthermore, Numen isn't particularly relevant to a discussion on free-form 3D rendering, since it's based on a ray-cast engine.

If I may point out, Duke Nukem 3D was based on a Raycaster known as the Build Engine. Since pretty much the entire discussion revolves around hackish algorithms to accomplish 3D rendering, I'm not certain that Raycasting can be so easily discounted.

 

Just saying. Carry on.

[Cheating Goodwill :-)]

Asshole.

 

He already went back to Goodwill, apologized, and fixed it. What more do you want out of him? A pound of flesh?

 

(Be warned. I hear he has a very good Italian lawyer. )

[the 7800 vs nintendo nes (could the 7800 have done better?)]

I'm just saying, is SMB the ultimate NES game? The paragon of what is possible using NES hardware (baring extreme hardware assist cartridges).

 

That's a difficult question to answer without hashing out all kinds of technical details. Thankfully, it doesn't matter. As I was saying, it's all about perception. SMB is the de-facto platformer. That means that all other platformers will be compared to it.

 

Based on the schematics, the HALT pin is output only and is used to indicate whether the (SALLY) 6502 or MARIA is driving the bus.

 

It seems you're right. Digging through the documentation bit more:

 

The cartridge slot is larger for 7800 mode cartridges. The

additional lines are: three (3) address lines (now all 16 address

lines appear on the cartridge connector); the READ/WRITE line, so

that RAM may be added to any cartridge very simply; the phase 2

clock line in order to add another microprocessor on the cartridge

and have it synchronized with the existing Sally chip; an audio

line so that one may mix in audio signals generated on the

cartridge; a composite video line, so that external video signals

may be included; and the HALT line, to enable the cartridge to

distinguish MARIA ROM accesses from SALLY ROM accesses.

 

So Atari/GCC were obviously expecting expansion processors to always work with the Sally rather than replace it. Still, it's pretty cool that Atari/GCC were thinking about these things.

 

Personally, I've got an itching to port Xero to the 7800. The heavy sprite capabilities of the hardware would make a shoot 'em up like this a perfect match.

Exactly. No / limitted background & large amount of sprites.

 

BTW, good work on your Ball Demo. It proves almost the exact case I need to do a port of Xero.

[What lucasfilm Ltd games should've been on 7800?]

Ummmm... and Bill Gates' inaccurate prediction on the subject of PC RAM requirements is relevant how?

 

It's goes to show that even people who should know what they are talking about, aren't always right.

 

Can people please stop repeating this? Two minutes on Google can easily prove that Bill Gates never uttered those words. No one knows where the rumor started, but it certainly wasn't Gates.

 

Harry, as a programmer you should really know better than to say naive things like that. Some of the best coders in the world spent decades banging on 8-bit hardware trying to create fast polygon engines, so by this point it's really quite safe to assume that there's no magic algorithm hiding in the bushes that could let 7800-class hardware suddenly do something on the order of TIE Fighter.

 

From a purely technical standpoint, a 3D engine is doable. You'd need some horizontal slivers of different lengths to power the fill routines, and you'd be juggling the DLLs like you were a circus performer, but it is possible. Whether it's practical or not is another matter. I just don't know if the 7800 has enough horsepower under the hood to do it without an extra coprocessor or seven.

 

And as for your pre-rendering idea, perhaps you forget that the 7800 doesn't have any scaling or rotating hardware.

 

You could take the Wing Commander route. The IBM PC AT didn't have rotational hardware either. The game worked off of pre-renderings[1] of all the ships. This made the perspective jerky, but it was quite a feat for its time. Again, the biggest limitation for the 7800 hardware is a lack of RAM and CPU power. You can scale the sprites in memory, then juggle the DLLs to draw more/less data, but that could require as many as 64,000 operations per image. Computing a simple line scaling (ala bresenham scaling[2]) or nearest neighbor[3] scaling would be extremely expensive. You might have to drop the framerate, which means using even MORE memory. Again, a coprocessor could help here.

 

Honestly, I'm not sure there are many instances where you want to be shoehorning a 3D engine into this hardware. It may be possible, but unless you've got a killer title like Rescue on Fractalus lined up, you just aren't going to want to spend the time and money on it. A homebrewer could probably do up some cool demos. But a full game? Probably not. The support infrastructure of Atari doesn't exist anymore. Without it, it would be extremely difficult to produce the necessary software and hardware to get it done right.

 

[1] Wing Commander Graphics Viewer

[2] Bresenham scaling (Errata)

[3] Nearest Neighbor Intepolation

[Previous 7800 HSC Rounds]

I'll trade roles with you, jbanes. If you work on a 4,000 volt system and deal with the VA, I'll watch paint dry for you.

OOOOOooooooo! What does

this

do?

 

BZZZT!

 

.....fffffff.....

 

Hmmm.... On second thought, maybe I should stick with drying paint.

 

Just hang in there, shadow. With enough time, patience, and prayer, things will start looking up soon enough.