Is the 1977 Bally Arcade Superior to the 1982 Atari 5200?

[Is the 1977 Bally Arcade Superior to the 1982 Atari 5200?]

I agree with all of that.

 

My Astrocade was stolen. Found it in the wild for like $30. It didn't have a power supply, but it wasn't hard to make one. The system does run hot. Really hot. Frankly, for it's time, it performed well and I enjoyed the games. Didn't get to program on it. Wish I had.

 

Love the controllers. The games were mostly spot on too. Controls made sense, response good. It's very enjoyable. Feels a bit like an Odyessy 2, but not quite so set in stone as far as graphics go. Somebody, somewhere, should do UFO! on the Astrocade. Would rule.

 

Had it gained a larger following, it would have given the Intelly a run for the money. Looks to me, from the FAQ http://www.ballyalley.com/faqs/astrocade_cart_and_hardware_faq.txt

 

...than it had the necessary interrupts to modify the screen attributes on the fly. Given this, like the VCS and other consoles of the time, more color and sophisticated titles were possible, though not on par with the 5200, essentially a gaming computer, where the Astrocade was a gaming machine that could be used more like a computer.

[Is the 1977 Bally Arcade Superior to the 1982 Atari 5200?]

It has a color palette similar to the Atari. 4 color display standard. I don't know if racing the beam tricks are possible.

[Adding to the Y register]

Of course. same with those rice crispy treats.

[Adding to the Y register]

Just a teeeeensy bit. Really, I was intending more along the lines of saying this is silly in that way is just as silly as the silly itself is. Also hippies.

[Adding to the Y register]

Punching the hippies is like:

 

Indexing with the accumulator, Shifting the Status Register, Comparing the Program Counter, NOP relative decimal mode, Rotating the Interrupt... lol all day long man.

[Adding to the x Register]

Yeah, maxing out the original hardware is totally in bounds. If my earlier post was taken as "don't use 'em", I didn't mean it that way. Really, I was objecting to the goofy logic presented as a reason to use them.

 

There are some similar discussions in Apple land, but those machines saw both the CMOS chip and the 65816 used, all while able to run software from older NMOS 6502 chips.

 

As a result, illegal ops were not used much, or where they were, things got patched. Honestly, things still get patched as I see projects to get programs to work under PRODOS, or with some hardware card or other.

 

In Atari land we never saw these things happen, so an Atari 8 bit is an Atari 8 bit, same as a VCS is a VCS... So the argument for not using illegal opcodes is much weaker. Same for C64 land, and there the lower CPU clock puts even more incentive to get every last bit of performance out of the thing.

 

The prudent thing to do is to use the defined opcodes where maximum compatibility with newer / derivative 6502 designs is desirable. Where it's not? Game on man!

[Adding to the x Register]

nonsense

 

Not at all: http://www.pagetable.com/?p=39

 

The documented instructions are the supported, and intended instructions. Anything else that happens to do something, isn't supported and not intended. Many of those instructions do odd, but useful sorts of things. A few of them make sense, and maybe only in some addressing forms, etc...

 

Nobody "forgot" anything here. Those guys knew what that chip did. And, if we are speaking about hardware design, the 6502 took a LOT of shortcuts for cost and time to market reasons. Some of the intended operations actually work by some parts of the chip over driving other parts of the chip, for example.

 

And if you go looking in the data books, these undefined instructions get NO mention at all. They are just blanks in the opcode table. Later on, as new instructions are actually defined, the descriptions clearly state the old behavior, or original behavior as "undefined", some can only be terminated by RESET.

 

MOS Technologies and Commodore included this about the undefined opcodes: "...cannot assume liability for the use of undefined opcodes"

 

This isn't just UNDOCUMENTED, it's actually UNDEFINED. Big difference there. They are not intended to be used.

 

Additionally, they were consistent across a lot of CPUs because the layout was not modified. They didn't have the sophisticated tools we have today. Changes were kept to the absolute minimum.

 

I agree with showing users "raw" to the metal, "take over the machine" style, and that includes undefined opcodes. This is so they can read and understand code that is out there. Makes perfect sense.

 

I don't agree with all the "keep it compatable" comments made here. That's nice and all, but really it's up to the programmer.

 

To me, it breaks down this way:

 

If you release source, others with enhanced / modified machines are free to port the work and return those changes to the community. No harm, no foul, no worries.

 

If you release binaries, compatibility might mean more in that more users can run the software. This may or may not matter to you. However, those running enhanced / modified machines still do have the tools to patch it and make it work anyway. No harm, no foul, but maybe some worries.

 

Most importantly, if you write it, write it! Have fun, make it work, enjoy. Don't let others drag you down and away from writing it. That sucks.

[Was the Coco3 competing against the Amiga and Atari ST?]

One additional thing... let's say a "real" 256 color option is hidden or whatever.

 

Where does that data come from? Would GIME suddenly start up more DMA, say 320 bytes per line for a 320x200 mode taking 64k to display?

 

That is a lot faster RAM access.

 

Edit: nope, the rumor says 320 pixel byte mode, and that it did not work reliably in the first run of GIME chips. So it must have doubled the DMA. The text below then isn't right at all. Perhaps the higher DMA is why it didn't work reliably...

 

 

 

More likely, given the lack of palette registers, colors would be absolute, just as they are when artifacing. Without the extra data, resolution would go down to the 160 pixels also seen when artifacting.

 

I doubt the higher speed DMA would have been in the picture, meaning the most likely RGB display comparable thing to do would be to setup a pack of resistors that would graduate the color levels in a fixed way, absolute color, no redirection 160x200 style. The byte data just gets dumped right to the display pins through the resistors, each value fixed In terms of the color it gets associated with.

 

Honestly, something like that could be in the chip, and maybe it will get decapped someday for people to go looking.

[Was the Coco3 competing against the Amiga and Atari ST?]

That's as true as it is for ANY colors delivered on composite. We have the tint control for that.

 

If you are referring to the two basic phase arrangements possible, excluding non standard color burst reference signals for now, the CoCo 3 has a toggle for that. You can just ask for one, and then it's always the same one. From there, artifacting actually does deliver consistent colors. And... if somebody were to toggle that while also playing with the scroll register, some very interesting things happen... Need to revisit that someday too.

 

But, keeping it really simple, also keeps it consistent. Set the pixel clock, color burst phase, palette entries, and go. That will deliver consistent results on every display I've seen and tried.

 

Variations we've seen in Atari land, for example, come from differences in the models and how the signal output is done. There was CTIA and GTIA, and various circuits and timing delays associated with those variations. Some of the GTIA computers have subtle timing differences, and those variations do impact artifacts. This is an "artifact" heh... of production changes, not any inherent problem with the technique itself.

 

And it's all of limited use on the Atari anyway. There aren't enough high res pixels and or intensities available to get more than a couple artifact colors, and or use of the different background colors requires DLI and friends, which all boils down to the multi-color display options delivering much better results.

 

Some Apple 2 games got ported and used the artifacting. And there are reasons for that too that can go beyond simple art reuse. One is object movement. On a 4 color, 160 pixel mode display, it's not possible to position something "half a pixel" and that makes movement steps coarse, like the pixels are. However, a white object, for example, or black one, can be positioned at the higher resolution, 320 pixels in the case of the Atari. Movement can be "half-pixel" and that means mixed motion is possible. Color objects position coarse, monochrome ones can position fine. That's little tiny details... but real details.

 

The CoCo 3 is consistent, though there were two GIME chips. I'm not sure they vary in this particular way, and I have very little info on their differences, nor how common the variations are. I think one is not very common at all. And the CoCo 3 actually does have enough pixels and grey levels to make great artifacts. It's possible to reproduce a ton of displays seen on the Atari machines. Moving them, etc... is a different thing obviously. But in terms of what one can put on the screen to begin with, it's comparable, and there is complete pixel freedom on the CoCo 3, and enough RAM to actually use it, though a 128K machine is cramped. But, that's what I've got.

 

I'm not so sure about the C64, and it's pixel art... That palette is good, and the C64 does output a different signal, so the blending might not work out so well. I should try that actually. The CoCo Palette isn't as good, and doesn't contain quite the right values, but it's close, and it can match things up pixel for pixel otherwise.

 

I, with some help from Eric, have cloned a lot of old computer displays on the Propeller. One problem was variations between the color burst reference and the pixel clock. He wrote an all software driver that does deliver a consistent signal, which I've done some work on since, and it performs very consistently. It matches my CoCo 3 and Apple computer very nicely. Apple machines didn't vary at all, until the GS. And the GS abandoned the old circuit found in the earlier machines. That experience over time clarified how artifacting works and what the various machines can do and why.

 

Side note: The GS actually has the old data coming off a pin. I don't have one, but it appears the old circuit could be added, and then the GS might actually compare with the CoCo 3 in this kind of color.... It's on my list. And there are all those GS games I never played too.

 

So really, NTSC TV's themselves have some variance, and that's what tint is for. I've driven a pretty wide range of displays with a real CoCo 3, and the color set is stable for a given set of palette entries. Old 80's era TV RF and composite, various capture cards, newer 00's TV composite, my current HDTV plasma and older LCD all show the same colors given the same setup. Some work with others, when I revisited this a few years ago, didn't reveal any variance either. Jason Law got an NTSC capable device in Australia that rendered the same things mine did here. That's how the pictures in my blog got done. He did a great job matching things up with a paint program. From there, it just needed to be converted into a bitstream for cassette, which is what I used at the time.

[Was the Coco3 competing against the Amiga and Atari ST?]

On a side note, what are people programming their CoCo 3 with these days?

 

I've got mine, the pak Roger made, cable for drivewire, and cassette, composite display. At one point, I looked at that IDE, but it just didn't click for me, but it did have some nice example code.

 

What are people using?

[Was the Coco3 competing against the Amiga and Atari ST?]

Sure it counts. "Any" system really can't do what the CoCo 3 does, because most of them either don't fetch enough info per scan line, or their video signal output isn't of the type that allows that info to be exploited in the same simple, basic way. Frankly, I've not encountered another one, but for the little Propeller micro-controller, which can clone the CoCo 3 display near perfectly.

 

This method of generating color was the only method used on the 8 bit Apple computers, BTW. When those users hooked up their displays and saw color, just as a Color Computer user can hook up a display and see color, it's the same thing. If it were not, I would think we would have seen an awful lot of references to "fake" colors, but what we did see was references to resolution and colors possible. Cards were made to deliver those colors to RGB monitors later on. Same colors, different display path. And it was common to just run two displays as well. Get the higher resolution monochrome off one, and color graphics off the other. That's the setup I have today, and when I plug my CoCo 3 into that video connector, I get the same thing I get with my Apple, only more of it, and at a bit better high resolution. (640 compared to 560)

 

The PC users who used a composite display to play nice 16 color games were seeing fake colors then?

 

It's as real as writing the bytes and seeing the colors. No different from any other composite display out there. And if you do it on a nice, studio type NTSC composite display, it looks very good. If one wants them in a nice order, a simple one page table takes care of that.

 

Additionally, not every system can do this. For artifacting to make any real sense on NTSC, the colorburst signal and it's phase must have a consistent relationship to the pixel clock, and it needs to be non-phase changing. Go and try artifacting on an NES, for example.

 

That Rainbow article does also mention palette changes, which were recently used on the PC, along with text mode abuses, to get 1K colors on a CGA. The Rainbow suggestion of 4096 colors being possible is high IMHO, and the real potential is more like 1K colors. To me, those are burdensome due to the requirement that screen palette register changes would be required each frame, slowing things down as well as complicating them. But, somebody somewhere will probably do a static image or simple thing that shows a lot more than 8 bits of color. It's there. The machine does it. And if they do, it won't flicker like some of the other dynamic palette change techniques currently do. And that article was 92? Surely people were doing this before then. I was, writing nice, pretty fractals to tape. It's not a hard thing to find either. So it's not like a special, or hidden thing. Artifacting was common practice at that time.

 

Had Tandy actually stated this back in the day, this entire discussion would be reversed nicely, just as it has been for Apple users forever. What a user experiences is the same either way. Maybe that would have conflicted with selling RGB monitors or something?

 

Atari computers feature a 160 pixel multi-color mode, offering a few colors per scan line. Same for C64, etc... Those machines DMA some number of bytes per scan line, and those bytes get converted into color signals. The CoCo 3 can DMA 160 bytes per scan line, and can do so without bogging the CPU down, and in this way, it's very similar to the Apple 2 machines, which work the same way, though they only do 40 or 80 bytes per scan line, and the color products reflect that lower amount of information.

 

A DMA of 80 bytes per scan line can deliver up to 640 bits of info. On an Apple, some are wasted, leaving 140 pixels, each with 4 bits of info, which means 16 colors. The CoCo 3, doubles that, and it offers 8 bits of info, and across 160 pixels, where that information is unique, the color set reflects it in the display, resulting in the colors seen. It's doing the work, one byte per pixel, just as any device capable of 8 bits per pixel would do the work.

 

That's actually impressive! The 6809 can chug along at full clip, where most systems impose CPU wait states.

 

Really, one difference is color redirection. Not all machines offered this either, or if they did, it was in coarse, fixed sets of color options. CoCo 2, PC CGA, etc... On a CoCo 3, one can use the 320 pixel mode to get a lot of colors, employing both techniques! A few palette color entries can be dedicated to palette changes, allowing for color cycling without drawing, while the remainder of the 16 palette entries can be used to artifact, resulting in ~64 color mixed mode type displays. When one wants to work this way, set both nibbles of a screen byte to the same palette color, and it won't artifact. Color cycle, do whatever. Set them to different entries, and they will artifact. User decides what they want from there.

 

Pretty powerful stuff!

 

What I never understood is this whole "real" vs "fake" idea. People have spent much time and energy squeezing capabilities out of other machines. Today, we've got Ataris, C64's and others doing very spiffy things! Are those not real? Why? We've got nice productions centered on some of them, and a pile of great demos too! A quick look at C64 high res pixel art shows the use of NTSC and PAL artifacting, depending on where it's done. What do users see? A great picture...

 

Oh well. Same discussion, same product today and here it seems...

 

GIME can do some really spiffy stuff, so can ANTIC, VIC, VIC 2, et al. Eventually, we will see all that the others can do, while GIME sits in a bin somewhere, seriously under used.

 

Perception really is reality in that sense.

 

**Maybe a circuit to map the composite display onto the spiffy RGB monitor would improve things here. Would be the same colors, but maybe they would be more real colors seen on a real display or something... who knows? I've often wondered about that.

[Was the Coco3 competing against the Amiga and Atari ST?]

Heh...

 

The thing has a 256 color mode, and it works on an NTSC TV, and it makes Atari type graphics, and even offers a very similar range of colors. All anybody has to do is set the 640 pixel mode to 4 colors per pixel, set the palette entries to black, dark grey, light grey and white, and go write one byte per pixel. Easy.

 

Had this been exploited at all at the time, gaming would look very, very different on that little machine. And those 8K blocks sort of work out nice, given that screen memory model. 32K / screen page, 64K for two, swap with the MMU. Just saying...

 

When running a CoCo 3 this way, you get 160 pixels by whatever vertical arrangement you want to setup for. 160x200, 160x100, etc...

 

If anything, the mythical modes took away from what the machine actually did. I found out one day by making a mistake. Took one look at the screen, thought "WTF?" and wrote a little program to just display all the bytes. There they were. Lots of colors. Today we know others knew back then too. I believe Sundog made a graphics library or something, I've not ever seen, but I did see discussed after doing this type of color got mentioned a while back.

 

Frankly, when I read about the "in search of 256 color mode" discussions, I bought a CoCo just to demonstrate what it would actually do. And it was amazing the amount of "no, that won't / can't possibly work" that I got in response. Seems people really, really, really want that mythical mode... The thing is at anything over 160 pixels, it basically would eat the entire 6809 address space, meaning one would have to swap pages constantly to do anything.

 

So, I got a CoCo 3, and that's a good thing. Should never have parted with the one I had originally.

[Profanity]

I believe that.

[Was the Coco3 competing against the Amiga and Atari ST?]

That is my thought on both points.

 

Well, that can be done on composite on a Coco 3 now.

 

About 233 unique colors result from the 640 pixel mode, writing bytes at a time, with the 4 colors set to black and the three Luma values.

 

That is how those images linked above were done.

[Was the Coco3 competing against the Amiga and Atari ST?]

That is what I saw. Bill Buckles has recently been working on improved dither for the Apple and it's artifact colors. IMHO, the movie output can be improved considerably combining both techniques.

 

http://www.appleoldies.ca/bmp2dhr/

 

IMHO, the "real" mode seems like a test, or some other feature, and it never made sense to me. How do the more graduated color level actually get output?

 

Never went looking for it. Suppose somebody could de cap a GIME and go looking for real.

 

On the other hand, NTSC artifact color works well, and it can be used with very little fuss. A little creative palette management in the 320 mode would yield more colors too, in a way very similar to how the PC guys exploited CGA.

 

And, if scan line doubling is used, one gets a byte per pixel, graphics 7 type mode that would be fast.

 

There is also the idea of PAL type artifacting too. I don't have a PAL CoCo, or I would have already done it. The technique is used on many other machines from that era, just as the NTSC style was.

 

Horizontal resolution could be better in PAL. There is a little opportunity for somebody to do new things there, IMHO.

[Was the Coco3 competing against the Amiga and Atari ST?]

Yeah, check these out: http://atariage.com/forums/blog/105/entry-6693-color-computer-3-artifact-art/

 

http://atariage.com/forums/blog/105/entry-6701-a-well-known-image/

http://atariage.com/forums/blog/105/entry-6683-more-color-computer/

 

NTSC composite display required. Resolution is 160x200 or so lines, depending on vertical GIME setup.

 

Jason Law figured out quick image conversions.

 

When I had this machine in the day,I was rendering nice fractals on the TV, and had started on some graphics... but I only had cassette and just didn't progress too far. Thought I would have seen the technique used, but never did.

 

It is now. I shared it a while back, and some coco users ran with it, one guy playing movies. No link to that one.

 

FWIW, more colors are there to be had, but somebody is going to have to set up a screen with interrupts and palette entry changes.

[Was the Coco3 competing against the Amiga and Atari ST?]

Those graphics made sense for BASIC.

 

Some games did use low resolution.

 

The Coco had lots of clone games that seemed to give it a non legit feel. Many in my community also called Radio Shack, shit shack. This rubbed off on the computers for sure.

 

IMHO, the 3 didn't get fully exploited. It's quite capable for an 8 bitter.

 

Maybe somebody will go through and patch or write some 256 color software. That, to me, would have made quite a difference back then, but it went unused.

 

Rad Warrior is one I think about from time to time... That one probably could be spiffed up, particularly in 512k. It came on cart too.

 

Compiled sprites were not used back then either. Not that I know of. 6809 chips can move a lot of RAM by abusing the Stack. One byte per pixel graphics seems a great fit for the technique, demonstrated a while back.

 

I never did get into the Nitro much, though a few of us jammed on FLEX. From what I see today, that level of systems programming being available must have made the machine attractive to embedded types.

 

Most Coco users I knew either got stuck with it, or were tech, HAM radio types.

[Let's talk 3D graphics]

Yeah, that's exactly it. The real great thing about Elite is there is just enough there to sketch out possibilities. From there, one can go and do things, dream, explore, and just kind of experience it all. Very nice. Once you know how to play some, the game just doesn't get in the way, and I found myself reading the little descriptions, picturing each world in various ways, that "theatre" working nicely enough. Totally get why this game had the impact it did. Really is a treasure. And I'm kind of stunned nobody knew of it where I grew up. We totally missed this one. As I've said, I would have played the crap out of this thing. Best scenario would be to have a friend there, take turns, map stuff out, plan trades, kills, etc...

 

But I got a few nice hours on a Saturday, enjoying my Apple. Worth it.

 

"Stick and ropes", yeah a lot of my childhood was outside imagining all sorts of things, often with friends, and we incorporated whatever was there into the whole thing. Good times.

 

On a side note, having kids can spark this again. We've had some of those same times. Get a weekend free, and be somewhere outside, far away from it all. That little spark comes back, and it can go for hours. Long hours too. Good times. Recommended.

[Prince of Persia]

You can gain a lot of insight about this game by reading how it was developed originally: http://www.jordanmechner.com/downloads/makpopsample.pdf

 

Looks like the old HTML format has been removed. Maybe the wayback machine has it...

 

Anyway, it's all one unified thing. The tools used to render things got used for the level editor, game action, and various animations and scenes. It's all built off the tile engine being worked on right now.

 

The Apple 2 version did include one nice, double high res, 16 color title screen that got loaded in. After that, everything is running on the game engine.

 

And it's a fun game! Worth playing.

[Was the Coco3 competing against the Amiga and Atari ST?]

Hmm... yeah that's a slow down for sure. Hard to deal with those old PCB's. I can probably do it... Good to know somebody here has a stash.

 

If anything, bumping the CoCo to 512K is probably the bigger bang for the buck upgrade for me.

 

Right now, I've an Apple card project to chip away at. But maybe one day this coming winter, when there is a lot of inside time for the CoCo.

[Let's talk 3D graphics]

Okie Dokie.

[Some real work in GEOS from back in the day..]

Nice.

 

I did some similar things on an Apple, but I didn't keep an archive.

 

One could do a lot with basic tools. To this day, I still knock out stuff in Paint. It's just dead simple and fast.

 

Nice work.

[Was the Coco3 competing against the Amiga and Atari ST?]

The CPU does not wait for RAM refresh on a coco 3. At 4mhz, it will be very fast.

 

Dang, I should mod mine and get a 6309...

[DIY Z80 Build]

Yeah.

 

It's binary. Each address line has two states, and there are X unique states given Y address lines. 8 address lines = 256 states, or %11111111 etc...

 

He's talking about I/O, and that's a special operation that addresses communications using some of the address lines so that the memory is just memory. In this way, another address space is created, and the I/O happens in that address space instead of being shared with the memory space.

 

6502 systems don't have this facility, and everything gets stuffed into the 64K address space, I/O, RAM, ROM, etc...

[Profanity]

It is acceptable behavior. This stuff is as offensive as any of us thinks it is. This goes with free expression.

 

Everyone has taboos, some more than others. And some of us have few, or maybe none too. I have very few for sure. Some people have problems with couples displaying public affection, or various articles of clothing, for example. Others don't care. And we all get to do that.

 

Time and place disagreements go all ways too. The people who want purity of some sort are also enforcing standards the same as people expressing themselves in various ways are.

 

We've all got options. We can talk about it, perhaps come to some mutual agreement for a time. We can leave. We can do lots of things.

 

Going back to the people and clothing example. Bare midriffs are offensive to some people. They get to say stuff about it, and the people showing some skin can care about that or not too. All get to make choices for themselves, but not others.

 

This means people who really do seek a high degree of purity need to make choices to that effect. They can pick times and places where there is less of what they find objectionable, can form clubs, etc... And it's on them really. They are the ones really offended, and that is OK. But, they may be among others who see it entirely differently, not offended at all.

 

Offended is what we think it is, and it's as important as we think it is too.

 

The law and government really has no role here, leaving it to us, but for very clearly defined harm, which is things like "fire in the theater", or actionable threats, etc... those are crimes.

 

Profanity, blasphemy, and other forms of expression aren't criminal things for these reasons.

 

Private entities, such as here on AA, can and often do regulate expression. That's fine. Some places may regulate it a lot, Disneyland style, others might not regulate it much at all. Everybody is free to make their choices and go from there.

 

Those guys making profanity laced videos aren't doing anything wrong. And they are accountable for that too. If a lot of people look down on them for it, then they look down on them for it. It's up to the people producing things to value that and maybe they want to modify how they do things, or not. All up to them.

 

And that goes back to lazy profanity as opposed to higher value profanity. I don't think too much of people who just use a lot of it. I happen to really enjoy people who know the difference. Everybody varies in this, and that's again what free expression is all about.

 

 

 

Can't people show some class and use a better vocabulary?

 

Sure they could. And your remedy for their speech you don't like is more speech, or making other choices, like avoiding their speech in the future. They either care about what you think, or they don't, and that's OK.

 

You make your choices, they make theirs.