New Old Console?

[JB]

Again, I have no really useful input to offer here, so I'll just say the following:

VECTREX! VECTREX! VECTREX!

988378[/snapback]

 

Designing a new Vectrex is really beyond the ability of your average hardware developer. It would require very precise development of CRT hardware. That stuff is nowhere near as easy to get ahold of as it was when the Vectrex was created. (I mean how many people think, "Hey, we've got a bunch of extra Cathode Ray Tubes lying around. Let's make a portable game console!")

 

A developer could translate the vector commands to pixels in a framebuffer, but that kind of defeats the point.

I know. But a 6809 would bring a tiny part of the Vectrex into the future.

 

I HAVE heard it's a nice processor to work with, but I don't actually know anything about it.

 

 

That being said, there is a way to bring back the Vectrex as long as you don't mind a projection unit rather than a CRT unit. JB, I give you LaserMAME. There's a video of it in action here. Technology may have marched on, but it has offered us new ways to do the same cool stuff.

988419[/snapback]

Mmmm... I'd love to have one of those to fool with.

 

Or one of these, for that matter...

http://www.zektor.com/zvg/

 

 

 

As-is, I'm afraid I'll have to "settle" for my original GCE Vectrex, though I'll always lust after that color Vec prototype... Ah, what might have been...

[supercat]

In terms of screen resolution, since I'm retarded and thought I only had 192 scanlines to work with, things should probably be pushed out to 288 pixels horizontaly by 224 scanlines. This maintains an almost 4:3 ratio, but allows for 36 8-pixel background tiles across and 28 tiles down, a higher horizontal resolution than the NES.

988298[/snapback]

 

How are you planning on generating the chroma signal? And were you planning on 262, 262.5, or 263 dots per frame (there are advantages and disadvantages to each). Those answers may determine whether it's better to use a chroma-based or non-chroma-based dot rate.

[~llama]

Well, i found the most ridiculously in-depth scanline discussion i've found so far here... but now I'm all confused What are some methods of generating the chroma? How does the PPU do it? I'm looking through the TIA schematics right now, that should hold some answers. As for dots per frame, more research is required, so maybe I should shut up about resolution until I know how I'm going to generate my video.

 

At the moment, I may in fact go with the 6809 even though I don't really know much about it--if only because Jameco has new ones $5 cheaper than WDC has their 6502. The 6502 would let me use a 6522 VIA for each controller port though, and the VIA is a chip I'm pretty familiar with.

[supercat]

Well, i found the most ridiculously in-depth scanline discussion i've found so far here... but now I'm all confused What are some methods of generating the chroma? How does the PPU do it? I'm looking through the TIA schematics right now, that should hold some answers. As for dots per frame, more research is required, so maybe I should shut up about resolution until I know how I'm going to generate my video.

 

There are a number of ways of generating a chroma signal. Some systems generate an RGB signal and then process it into a composite signal. Others generate a chroma wave directly (e.g. using a tapped delay line or quadrature summation). On some systems, Chroma has a 'nice' relationship to the dot clock; on others it doesn't.

 

These issues are important because of the possibility of aliasing producing good and bad effects. Aliasing effects are most predictable when the chroma and dot clock have a simple relationship, though aliasing effects are usually less visible when they have an antiphase relationship.

 

At the moment, I may in fact go with the 6809 even though I don't really know much about it--if only because Jameco has new ones $5 cheaper than WDC has their 6502. The 6502 would let me use a 6522 VIA for each controller port though, and the VIA is a chip I'm pretty familiar with.

988472[/snapback]

 

What's so great about the VIA? You should be able to get timings out of your video subsystem, and for input or output ports there's not really much that beats a '373 or '573.

[~llama]

There are a number of ways of generating a chroma signal.  Some systems generate an RGB signal and then process it into a composite signal.  Others generate a chroma wave directly (e.g. using a tapped delay line or quadrature summation).  On some systems, Chroma has a 'nice' relationship to the dot clock; on others it doesn't.

 

These issues are important because of the possibility of aliasing producing good and bad effects.  Aliasing effects are most predictable when the chroma and dot clock have a simple relationship, though aliasing effects are usually less visible when they have an antiphase relationship.

 

At the moment I'm thinking about genererating the chroma wave directly with a tapped delay line. This seems to be a pretty effective way of doing it and I'd rather generate the chroma directly than process RGB. I'd like to keep the relationship between the dot clock and the chroma pretty simple to make things easier on me. As long as the aliasing is predictable and not terribly noticable, I'll be satisfied.

 

What's so great about the VIA?  You should be able to get timings out of your video subsystem, and for input or output ports there's not really much that beats a '373 or '573.

988612[/snapback]

 

There's nothing great about the VIA, I just am familiar with utilizing it. I'll probably look harder into the 373 before I make any real decisions there.

[supercat]

There's nothing great about the VIA, I just am familiar with utilizing it. I'll probably look harder into the 373 before I make any real decisions there.

988820[/snapback]

 

To use a 373 for input, just wire the latch wire high and the /OE wire to a chip select. Hook the D pins up to your inputs and the Q pins up to the data bus.

 

For output, hook the latch wire to something that goes high when it's time to latch (or use the 273 or 374 which are edge triggered). On the 273, there's a clear input which may be used if desired. The 373 and 374 have /OE inputs that may be strapped low or used other ways if desired.

 

Really not much to those chips. Another alternative, btw, is an addressible latch chip (I forget the number). Use that if you like Apple II-style 'soft switches'.

[~llama]

I'd be using them for input, so that sounds like a ridiculously easy method of doing so. /OE to chip select is all it takes?

[~llama]

Hmm... I've been thinking... what about a handheld? Cramming a couple FPGA's in a case couldnt be any bigger or tougher on batteries than a Lynx Mk. I, could it?

[jbanes]

Hmm... I've been thinking... what about a handheld? Cramming a couple FPGA's in a case couldnt be any bigger or tougher on batteries than a Lynx Mk. I, could it?

989177[/snapback]

 

Most off-the-shelf components in the hardware design world are designed to operate in and around 3 Volts. (That's 2 AA batteries.) My suggestion is to design your hardware with 3-3.3 Volts in mind, then work on a handheld version when you're done. If your voltage is a bit above your target, you can add a third battery or switch to a rechargeable pack.

 

The conversion to a handheld shouldn't be all that hard. (Just ask Ben Heck. ) Your greatest obstacle would be getting ahold of some LCD screens. Unless you have massive production runs, those things are expensive.

[~llama]

The conversion to a handheld shouldn't be all that hard. (Just ask Ben Heck. ) Your greatest obstacle would be getting ahold of some LCD screens. Unless you have massive production runs, those things are expensive.

989245[/snapback]

 

Yeah, I think the screens are going to be the biggest problem here, by far. 3.3v isn't too harsh of a voltage requirement, and I've always had a thing for handhelds.

[Zonie]

Keep it 8-bit.

 

I'd look at using a Z-80. I think most of the best games (except those from Atari) used the Z-80. You could also use a 8086 or 80286 (even though it's 16-bit). Use of the x86 architecture would enable many more programmers to pile on, as there is more recent experience with that instruction set than 6502 and Z-80.

 

Another Idea would be to use a passive 8-bit ISA backplane so you can take advantage of existing, yet vintage, IBM-PC hardware, like old early EGA video and 8-bit soundblaster cards.

 

The CPU board would plug into one slot, the video card in another, and the SBC in yet another.

 

Parallel/Serial IO cards can handle the controller IO.

 

Use a PC. power Supply, as, like all the aformentioned ISA boards, most of us have a box of them and hate to throw anything "good" away.

 

Also, old VGA cards can be synched up to RGB ARCADE Cabinet monitors.

 

There you have it... A box of parts that is easy to find, programming capability that is out there, and a powerful enough unit to play some really good games, and is possibly compatible with old 1980's PC games, some of which were very good.

 

Hmm...Sounds like I just described an early 8-bit IBM PC Clone. Maybe that would be a good platform too. The IBM PC debuted in 1981.

Edited December 26, 2005 by Zonie

[mos6507]

I think in the true retro console scene that the 6502 and 6809 are where it's at. Z80 is more for gameboy types.

 

I think the 65816 is a good choice in the sense that it is a very simple 16-bit extension of the 6502. It helps break you out of the confining 64K limit but without a lot of the added baggage of other 16-bit instruction sets.

 

With each step up in power comes an increase in complexity of the code necessary to drive the game. Soon you find you have to use higher level languages to manage it all and it really stops looking like a classic game system.

 

What is more important is the ideosynchratic sound and graphics hardware you come up with. That's where the fun comes in.

 

You keep the CPU as simple as possible, and the memory footprint rather constrained, so you are doing everything in straight assembly, and then you make a really flexible hardware platform and see how far you can push it.

 

But in the end you are really intentionally making something more constrained than it has to be.

 

If you want something truly state of the art then something like the GP2X already exists. It uses a dumb framebuffer and two processor's worth of brute force to do all the work. It just doesn't have the mystique of custom hardware.

[jbanes]

Keep it 8-bit.

 

I'd look at using a Z-80.  I think most of the best games (except those from Atari) used the Z-80.  You could also use a 8086 or 80286 (even though it's 16-bit).

989309[/snapback]

 

Just an FYI, the 8086 is a 16 bit processor just like the 80286. You might be thinking of the 8088 which was a 16-bit processor with an 8 bit data bus.

 

The Z80 was a clone of the Intel 8080, which was an 8 bit processor, but with 16 bit memory addressing.

 

The 8086/88 got around the 64K limitation by using a segmented memory scheme. The processor would first be fed a 16bit memory segment locator which would tell it the section of memory to work in. The program would then be able to address any memory within that 64K segment. This led to the development of C compilers with "small" (64K), "medium" (64K code, 64K data), and "large" (full use of all segments) memory models.

[~llama]

I think in the true retro console scene that the 6502 and 6809 are where it's at.  Z80 is more for gameboy types.

 

That's what I was thinking, too. All Atari programmers use 6502, so here at AA the 6502 would be the most popular. I also don't know anything about Z80 from the standpoint of hardware, whereas I've done a few small 6502 projects so I know what I'm doing with it (sort of )

 

I think the 65816 is a good choice in the sense that it is a very simple 16-bit extension of the 6502.  It helps break you out of the confining 64K limit but without a lot of the added baggage of other 16-bit instruction sets.

 

I should probably look into that. But the reason I don't want to go 16-bit, really, is exactly what you expressed:

With each step up in power comes an increase in complexity of the code necessary to drive the game.  Soon you find you have to use higher level languages to manage it all and it really stops looking like a classic game system.

Without programming in assembly, the system isn't really that much of a "classic." I know the Lynx is primarily done with C but... I don't like programming video games in C, I want to work with the full capability of the hardware, to push the limits.

 

What is more important is the ideosynchratic sound and graphics hardware you come up with.  That's where the fun comes in.

 

You keep the CPU as simple as possible, and the memory footprint rather constrained, so you are doing everything in straight assembly, and then you make a really flexible hardware platform and see how far you can push it.

 

Exactly!

 

But in the end you are really intentionally making something more constrained than it has to be.

 

But, aren't the constraints what makes it interesting?

 

If you want something truly state of the art then something like the GP2X already exists.  It uses a dumb framebuffer and two processor's worth of brute force to do all the work.  It just doesn't have the mystique of custom hardware.

989340[/snapback]

 

I'm not trying to be state of the art, I want this to be "purposefully obsolete," like the guys who build 4-bit processors out of TTL chips. I want to see exactly what those Atari/Epyx and Nintendo and Vectrex hardware designers were thinking, to work with the same kind of limits on technology that they had.

 

I also want to come up with something that's as fun to program as the 2600 or the 7800, something where the limits and quirks of the hardware are what makes the system fun to write games for.

[jbanes]

But in the end you are really intentionally making something more constrained than it has to be.

 

But, aren't the constraints what makes it interesting?

989474[/snapback]

 

I think that the definitive answer to this is: It Depends.

 

(Don't you just love firm answers? )

 

Ask yourself, would you use Wood and Cloth to build an airplane when lightweight Aluminum is available? Probably not. Wood and Cloth are very limiting in constructing a craft. There's very little to be extracted from attempting the feat unless you have nothing else at your disposal.

 

On the other hand, ask yourself if you would prefer a vase made of Clay or Pyrex? Probably the clay. It has an aesthetic and historical appeal that Pyrex simply can't match.

 

And here we come to the crux of the problem. Many people like the old game consoles because they're a piece of history. They have aesthetic, nostalgic, and historical value that is a shiny new device can't offer. But if you create a new device that's unrelated to the historical one, then it's questionable whether you can attract interest or not. Why would people want to work with this machine? So they can spend hundreds of hours coding for an intentionally limited device when they could recapture history by programming for a real device?

 

It's a bit like classic cars. People like classic cars because they're classic, not because they're limited. How many car enthusiasts create new cars at the level of a Model T without making an actual replica? Probably not too many.

 

I'm not saying you're on the wrong track. I'm just offering food for thought. You may decide that cloning the 5200 or 7800 would be a more interesting use of your time. Then again, maybe not. It's up to you to see if you can find a market.

[Zonie]

I meant "They're" instead of "it's" regarging the 8086.

[~llama]

Well... I don't think I could ever get the rights to do a handheld clone of an Atari system, nor would I want to, really. Perhaps something more obscure. Who owns the rights to the Astrocade, or the Arcadia, or even the Channel F? Who owns the rights to any of those systems? If they were okay with it, maybe I would consider a clone of those systems, but then again I dont have any games for said systems and also don't know how well they'd do as a handheld.

 

I guess I like the idea of virgin territory, but don't like the modern 2D gaming systems, things like the N-Gage and the current crop of Java games on cell phones. Handhelds have always fascinated me, especially the Game Boy and the Lynx, the forerunners of todays systems, and so I figured I'd enjoy designing a handheld console with the features I'd like my "retro" systems to have, things that could have been different about them (but not necessarily more high-tech)

Edited December 30, 2005 by ~llama

[~llama]

Any other "classic" systems that would make a good handheld system? Apparently I killed the discussion

[jbanes]

You didn't kill the discussion. I just keep getting sidetracked from replying.

 

To answer your concern, there's no reason why much of the older hardware can't be copied. The 2600 was copied by Coleco and MANY other companies. The courts upheld this right. So you'd be pretty safe as long as you're not stepping on someone's Patent. Since pretty much all the Patents that could possibly cover the Atari machines has expired by now, you're probably pretty safe in recreating, say, the 5200.

 

Nintendo was always a difficult one, as they had many heavy patents protecting their hardware. Since most of those patents have expired (or can be worked around), we're seeing a lot of legitimate NES clones hitting the market. (e.g. The Generation NEX)

 

Just don't try selling any software that you didn't create yourself, and you should be fine.

[Zonie]

Fairchild Semiconductor or possibly National Semiconductor probably owns the Chanel F. Did you ever play one? Seriously, forget about that one.

 

I was thinking the Astrocade when I made my first post in this thread and mentioned the Z80. It dies before it's time.