Making a game console from parts like 6502,z80 etc possible

[Drew Sebastino]

with that you need a special Yamaha DAC, and those chips are power hogs and run really hot.

Because everything uses digital signals now anyway, is there the possibility to not use the DAC? You'd have to convert the signal anyway though to work with any kind of used format, (lump it together with graphics and use HDMI) but I imagine you'd have to use an FPGA for that. At that point, you might as well use the FPGA to generate the sound in the first place though.

Has anyone ever thought of "Frankensteining" parts from various old computers/game consoles together to form something? It couldn't be produced large scale, but I doubt what you're wanting to do would be either. You'd also be destroying whatever you'd be taking the chip from (so it's not like you're going to target a Neo Geo or Sharp x68000) but if it's not working in other ways and it can't be fixed without replacing everything else, then go right ahead. I've always wanted to see if you could kind of create your own Supergrafx type system out of the SNES or something.

[lidnariq]

Ever since that discussion about the possibility of upgrading the SNES's PPU to 128 KiB from its default 64 KiB of RAM, I've been playing around with the idea of a more arcade-shaped SNES with bankswitching. Maybe combine VRC2-style bankswitching with 4MiB of RAM ('cuz 64 Ki address space ÷ 8 regions = 8 Ki regions ; 8 Ki regions × 256 = banks = 2 Mi address space)

It's be tricky with mode 7, but.

[Dwedit]

One obvious problem with using old technology is the voltage of parts. Old stuff is 5V, newer stuff is much less.

[Banshaku]

If I would have to implement the sound/video part with an FPGA, at first I would go with something simple so that I would have something running but something what I would like to do is to have multiple type of sound on it. For example, I would like to have presets like nes, sms, vrc6, namco-163, gameboy, genesis fm etc that you could select via programming but could make custom presets with channels from different implementations. Same thing for video mode, different mode to represent specific console. That way you could simulate a style that you want based on specific console specs.

But... I guess that must be quite hell to develop all those things but that is something that would be great. Basically a console that is not a nes/sms/genesis etc but allows you to select some presets to emulate some of the style/limitation of those.

Maybe for now I should just focus on restarting a homebrew project on any of those old console until I know enough about electronics. Still, I should try to plan that project someday, would love to make it. Old style programming, not an android something micro-console that allow you to do games like previous generation with no OS in the way, just the console as-is.

[Drew Sebastino]

One obvious problem with using old technology is the voltage of parts. Old stuff is 5V, newer stuff is much less.

Well, I'm pretty sure you can use resistors to decrease the voltage. I have no clue about increasing it though. What number of volts do most electronics run at now? I had always thought it was 5V still. Is it as low as 1.5V? I'm probably way off.

[lidnariq]

You can not use resistors for voltage translation. Or at least, can only use it one direction (high to low), and it draws extra power over proper translation. So don't.

Most hobbyist level electronics are 3.3V now. Commercially mass-produced things are often in the 1.8 to 2.5V range. Current CPUs often run somewhere around 1-1.3V.

[Drew Sebastino]

can only use it one direction (high to low)

Yeah, so they're only useful for lowering voltage.

it draws extra power over proper translation. So don't.

What are you supposed to do then?

[lidnariq]

Proper translation, like I said. There are ICs specifically designed for this purpose, for both up and down translation..

[whicker]

These days the programming I do at work is quite dull (IOT related, MQTT messaging/aggregation of streaming, basically the testing of a pipeline, making vm for that etc)

Banshaku:

Kind of strange that what you find boring I'm finding quite fascinating. If only I could somehow come up with an MQTT client for the newer Siemens PLC's (S7-1200, 1500) I'd be a hero... for a bit anyway. Yes, I know there's a github of S7-300 code, but that's written in the godawful obsolete Statement List language (STL). Enough digression.

I guess what is your ability level? Have you bread-boarded circuits before? Do you know how to create an address decoder and wire memory off of address lines? A microprocessor (Z80, 68000, 6502, 80x86) has just the Address and Data lines (and its handshaking signals) exiting the chip, with the expectation of wiring up external memory and peripherals like serial, video, sound, and I/O registers, (and interrupts and DMA, for the brave). IMHO the Commodore VIC-20 schematic is super awesome to describe what is needed. One single page shows wiring for the entire system, with off-the-shelf parts (except for the video chip itself, the 6560). Maybe not so many tiny memory chips nowadays, of course.

Do you just want to tinker with software programming? Might I just suggest microcontrollers like the Parallax Propeller or Teensy 3.2 or ESP8266 then? A microcontroller has the CPU and peripherals and memory (RAM, sometimes FLASH) internally wired already inside the chip, leaving mostly just general purpose I/O pins to interface to the outside world.

[Bregalad]

So now your question has been reduced to "Are there reliable sources for new-old-stock retro video and audio chips?"

Actually Yamaha and other manufacturer made many dedicated audio chips which were mass produced, so this is pretty much a given.

On the other hand I do not think there was such video chips, each video chip was specific to a particular game console or computer... unless I'm mistaken. I'm still unsure how arcade games had their graphics rendered, but I think it was mostly ASICs, alas.

[lidnariq]

Looking around, it seems the TMS9918 and its immediate siblings may have been the only "video game PPU on a single chip" that wasn't explicitly designed for one specific console. ... although there's some wiggle room in that definition given the wide variety of companies that manufactured MSX computers.

[Banshaku]

@whicker

What I had to do was reseaching if mqtt clients exist for specific platform, build test environment for an api developped by an offshore team with little to no documentation, figure out why it fails because doesn't follow the specs or forgot to implement then try to test the api to see if it does follow the requirements. Not that pleasant compared to if I had to develop code for iot devices and see if they interact well with an already build environment or tests clients for specific embedded devices or something like that.

As for my skill, except for soldering and started to read a book about electronics, I do not possess the skill to make such a project and I'm totally aware of it. When I'm too busy I like to do research on future projects that I would like to work on to know how feasible it is. I find it very fun and refreshing to do so and it helps me deal with my stress by learning more about something I would love to do even though it not possible at the moment. I apologize if it feels like wasting people time but I got a lot of information from that thread and I'm very grateful about it.

My lack of knowledge will be the biggest hurdle for now. I need to learn more about electronic but don't really know were to start. My programming background will hopefully help but I don't know by how much.

[Bregalad]

Looking around, it seems the TMS9918 and its immediate siblings may have been the only "video game PPU on a single chip" that wasn't explicitly designed for one specific console.

Hey, very cool. I had no idea such a chip existed. It's features aren't so exciting or anything, but the concept is cool. I wonder whether it's possible to have multiple copies of such chips and combine their signals somehow in order to get better graphics (more sprites and multiple backgrounds).

[TmEE]

TMS chips actually have provisions for master/slave confs for multiple chips environment, that carried on to MSX, SMS and MD (all made by Yamaha) also which can sync to external video source. All these chips have a signal that tells when they're outputting the far BG color also (!YS signal).
There's also some new stuff from them that might be useful : http://www.yamaha.co.jp/english/product ... ontroller/
And perhaps sound too : http://www.yamaha.co.jp/english/product ... generator/

[Bregalad]

I wonder why/how it's possible/feasible to use a video signal from another chip as an input to a PPU. For me it sounds much simpler to use a digital palette index as input rather than using an analogic input video signal. This should make synchronization particularly cubersome (but if both chips are identical which would be the case here, it wouldn't be as problematic I guess).

So with 2 or 3 daisy chained TMS9918 I guess it's possible to get pretty decent graphics at minimal cost, the major problem is that fine scrolling is not implemented, and that sprite priority is hardcoded between BG layers and is not flexible.