[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 96 KB, 1750x1716, Untitled.png [View same] [iqdb] [saucenao] [google]
9603717 No.9603717 [Reply] [Original]

Unleash your autism and design your own console architecture. Here's mine.
>68000 CPU clocked at 8MHz
>128KB main RAM
>16KB bitmap VRAM
>graphic mode 0: a tile bitplane controller similar to that of the TMS9918 (used by MSX, pc engine, and sega master system alike) and VIC-II chip, up to 320x240 PAL resolution, 32 colors out of 512, uses 32K of the main RAM and eats up a few cycles during memory access
>graphic mode 1: bitmap raster chip similar to the Atari GTIA chip but with twice as much graphics memory (16K VRAM), 240x180 PAL resolution, pixel doubling and graphic mirroring features, DMA, and no hardware collision detection, useful for 3D graphics or anything that works better in bitmap
>bus controller to alternate between mode 0 and mode 1
>sound: 6-8 channel PSG with selectable waveforms for each of the channels
>storage: 64 pin cartridge, hardware ROM decompression system, floppy drive expansion with 512KB additional RAM, uses continuous spiral floppy disk format just like the one found in Mitsumi QuickDisks
>interconnectivity: data port to be connected to audio tape or CD players
>price: more expensive than PC-Engine but more affordable than the Mega Drive, floppy expansion would be around the same price as the console or slightly less
>release date: shouldn't be further than 1986 or 1987, the custom chips are based on existing hardware solutions and shouldn't require too much R&D, the rest could be built from off-the-shelf parts

>> No.9603718

>>9603717
Features:
>high speed 2D graphics with 32 colours on screen simultaneously, pretty shabby colours compared to the PC engine, but it could run street fighter and mortal combat games without any issue except for reduced colours
>2D tile graphics could be altered on the go without a blitter just like the VIC-II, allowing for some impressive tricks
>high speed bitmap graphics with relatively low latency between the CPU and the display screen, helps running 2.5D or 3D games faster than the Atari ST and Amiga do, but sprite/tile graphics can't be used in this mode because the CPU needs to hog all the memory bus all the time
>game publishers can choose between cartridge, floppy, audio tape, or even CD, giving them more freedom and lower price for the consumers
>hardware decompression routine, allowing denser ROM capacity and cheaper carts
>continuous spiral disk reading, floppy software is completely loaded into the RAM in one go
>audio jack, could be used to store and load save states and software into and from an audio tape, 16 bit CPU should be able to transfer data on a tape faster than an 8 bit one
>overall, an affordable 68000 console released before the mega drive and snes, inferior 2D graphics due to the smaller colour memory and simpler 2D architecture, but roughly equal framerate, higher resolution, and faster 3D graphics

>> No.9603806

>>9603717
Never happens as you go bust due to insanely long development time.
The design becomes a running joke in the /vr/ fantasy console scene due to retarded blunders such as sharing ram with an obsolete vdp that also has its own ram. Is that gonna be a DIP-128? Or are you gonna multiplex things to fuck it up even more? Maybe some monstrosity with embedded ram? Save yourself time and money and use a superior off the shelf part.
The disk system is mocked for it's retarded disk format and regularly referred to as "what if sega designed the fds"
Fantasy console designers regularly piss themselves laughing when they read about how the kid who designed this imagined that a 16bit cpu would make transferring data to/from an audio tape faster.

>> No.9603838
File: 152 KB, 602x421, main-qimg-5881ab18173295043254dfa178b15f55-328798028.jpg [View same] [iqdb] [saucenao] [google]
9603838

>>9603717
Meh.
I build mine in 1954.
>Weight: 30 tons
>Size: 7 ft x 3 ft x 100 ft
>RAM: 200 words Magnetic core
>Graphics: lol
>sound: humming and clickity clack
>Electomechanically assisted vacuum tube blast processing
>Storage: female workers have to remember what goes where and proceed to plug jumper cables in the correct order allowing for various games to play
>price: 6 gorillions

>> No.9603839

>>9603806
It's like constraints and timing isn't a concern. Might as well add a floating-point unit, a parallellized kernel, and a QAM demodulator DSP for tape drive games.

>>9603717
If I would release a console made in the early 80s, I'd take some cues from the NES and have the cartridge rom work as the video memory. Have the video processor draw from cartridge while CPU does game calculations, then have the CPU read from ROM during the blanking area. 6502 based of course. Maybe make the video part with a coprocessor instead of just a sequential DAC. Perhaps the money spent on processing power can be recuperated by having less RAM. Is this a retarded idea?

>> No.9603872

>>9603806
Cool it man, I'm just having some fun here. Mock it all you want, I'm still listening to your suggestion cus I'm not dedicated enough to spend my time reading the papers.
>sharing ram with an obsolete vdp that also has its own ram
It's only a framebuffer.
>multiplex things
Nope, I don't think you'd need that when the two graphic modes aren't supposed to be used in a parallel manner.
>Save yourself time and money and use a superior off the shelf part.
Would be nice to have a list of what were available at the time. Bitplane format bitmap on the ST and Amiga seemed to be slower than how ANTIC and GTIA produced bitmap graphics, yet those two chips were only addressing 8KB.
>The disk system is mocked for it's retarded disk format
The FDS wasn't retarded, it was a good format for indie devs to thrive.
>16bit cpu would make transferring data to/from an audio tape faster
It could help reading smaller and tighter pulse lengths, I guess. Would be useful for data storage nevertheless. Storing save states in an SRAM card would be expensive.

>> No.9603878

>>9603838
You could make some cool mechanical or electromechanical game system in 1954, like a solo roleplaying game with an open world map and randomized event organizer. Could be done with a few dices and paper cutouts though.

>> No.9603925
File: 94 KB, 1200x574, Nintendo-Famicom-Family-Basic-Keyboard-wCart.jpg [View same] [iqdb] [saucenao] [google]
9603925

I would just make Famicom based home computer with floppies and 64k ram and spend some funds on promoting and maintaining indie developer scene around this system.

>> No.9604000

I make a basic console on the level of the C64 or Famicom but the games come on laserdisc+cartridge.
The laserdisc is utilized not for only for music and FMV, but for artwork that is combined as a layer over which sprites are drawn.
Laserdisc players can seek to a single frame and display it as a picture.
I use this in a similar manner as the PS1 and Saturn used pre-rendered background graphics.
Additionally I use my power of hindsight to invent the rhythm game genre and beatmania, DDR, and guitar-hero style games in 1985 with 8-bit graphics overlaid on a FMV with laserdisc quality audio. I think it will be a smash hit. Expensive system, but very popular at parties.

>> No.9604105

>>9604000
That sounds like a cool idea, but you didn't need a laserdisc for that, maybe a VHS player would suffice. And with the popularity of sampler music on the Amiga and such, you probably didn't even need a video player. Why 8-bit graphics? In 1985 for a system of that price you'd have to do 16 bit.

>> No.9604107

>>9603839
>Is this a retarded idea?
Atari Panther tried to do that I think.

>> No.9604121

256 z80 processors operating in parallel

>> No.9604136

>>9603839
Also need to add a second 68k for reasons

The prg/chr method the nes used was a simple and effective solution. Obviously could be improved on but a good place to start

>>9603872
That's all the mocking you'll get from me on that. I'm also just having some fun.
Doesn't matter if your ram is used in parallel or not. It still has to be connected. If you put everything on the same bus things have to wait for other things and it impacts performance. This is why the TI part you're basing it on has its own dedicated ram on a separate bus. If you want it to also access the main ram you need to connect to it. Simple as.
What's available at the time depends on when you actually make the thing. If it's launching in 87 you'd probably do a last minute redesign to use whatever the latest version of that flavor of vdp was. Probably v9958.
Disk format and disk system are two totally different things. The format used by the FDS is completely retarded. Read up in how it works you'll understand why.
Audio tapes are an extremely low quality media and can't reliably handle more than a few thousand bps at standard speed. No CPU can change this and you'd be shooting yourself in the foot gambling with peoples save data to save a few seconds. Like the FDS they're also not random access so you're basically making a doubly retarded storage system here.

>> No.9604147

>1984
>512k RAM expansion for a home console
Always funny seeing retards.

>>9604000
The cost of laserdisc machines alone will cripple you utterly.

>> No.9604159

Hear me out:
It's a sphere

>> No.9604168
File: 111 KB, 1200x1200, Atari_7800_with_cartridge_and_controller.jpg [View same] [iqdb] [saucenao] [google]
9604168

I'd design an Atari 7800 and release it when it should have been released, in 1984, then lobby some 3rd party companies to make some cracking arcade conversions, thereby changing history and putting a stop to Nintendo's eventual dominance in the American market and turning Atari back into the powerhouse it was a few years prior.

>> No.9604306

The most interesting hardware chooses one area to be good at and goes hard in that area.

Dual Z80 at 6mhz, they were about $5 each in the 80's. Each cpu has 8k ram each. Graphics chip is also memory mapped to 2nd cpu with 8 kb. Both cpus have 4kb that only can accessed 1 at a time to copy data to each other. One cpu is for the game data and the other cpu is to control the graphics. Graphics chip does 320x240 but since there is not enough memory it would be heavily tiled. Zx speccy style colour attributes except that colour pallete can be manipulated by timing of the pulses sent to the chip as well as the normal bit data. Customizable colour attribute tiles can be moved around for more detailed areas. Can change timing of attribute tiles from the pulses from cpu at will to change the width and length of colour tiles. The hue would be controlled by timing from the cpu so maybe you could get many thousands of colours. Eg black would be 1 cpu tick and white would be 100 ticks so anything in between would be gray. Combine that with the 16 main colours for many different shades and thousand of colours. Colour pallate can be manipulated by cpu in the analog domain. Simple bit shifting to allow for smooth scrolling and using softsprites from 2nd cpu.
Cartridge connected using upper 32kb of first z80, your choice to use whole 32k or use half the bits for bank switching. Dual pokey for sound because it sounds cool.
Result, 8 bit system with many thousands of colours and not that many more transistors than zx speccy.

>>9604121
lol, probably could even run quake.

>>9604168
and give it the pokey, having each game have a sound chip in it just seems like a bad idea.

>weird one if video games turned out to be super niche
nes or sms with 2 video chips stacked so you have 2 layers of 8 bit graphics.

>>9603717
genesis/snes would of had way more detailed graphics with 128 kb of vram but I doubt the typical ignorant normie at the time including me would have noticed.

>> No.9604569
File: 144 KB, 740x446, SMScube2.jpg [View same] [iqdb] [saucenao] [google]
9604569

>>9603717
Well, I just want to share some pure unstoppable autism I've found by clicking on "surprise me". The guy made a few console concepts
http://androidarts.com/SEGA/SEGAcube.htm
http://androidarts.com/SEGA/SEGAcube.htm

>> No.9604581
File: 93 KB, 740x339, Gamegear.jpg [View same] [iqdb] [saucenao] [google]
9604581

>> No.9604585
File: 257 KB, 740x1074, Famicube2r3bflat.jpg [View same] [iqdb] [saucenao] [google]
9604585

>> No.9604591

>>9604569
Dude, when YOU learn to draw low-cut panties as good as this guy, then YOU will have right to call him autistic.

>> No.9604689

>>9604136
>It still has to be connected. If you put everything on the same bus things have to wait for other things and it impacts performance.
Read this carefully man >>9603718
"sprite/tile graphics can't be used in this mode because the CPU needs to hog all the memory bus all the time"
Those two chips not meant to be run at the same time. A game or a level could only select one of them at the start. That's what I've been saying.
>If it's launching in 87 you'd probably do a last minute redesign to use whatever the latest version of that flavor of vdp was.
Didn't take that long for NEC and Sega to redesign their VDPs from existing chips. This would be a combination of
>Probably v9958.
Nah I wouldn't. It would preferably use the unified main RAM to reduce the system cost. I'm thinking something like a modified VIC-II with more data pins could handle it. There's only 16KB of VRAM and it's used as a framebuffer in bitmap mode only, which is a separate chip.
>The format used by the FDS is completely retarded. Read up in how it works you'll understand why.
I've mentioned how it works. A continuous data stream like a vinyl record. which makes random access impossible. But it was really cheap, much cheaper than a disk drive with random access. That's what the 512K RAM is for, the disk would dump all the data there at once. If random access was possible you wouldn't need that much memory.
>Audio tapes are an extremely low quality media and can't reliably handle more than a few thousand bps at standard speed. No CPU can change this and you'd be shooting yourself in the foot gambling with peoples save data to save a few seconds.
I suppose a 32 bit CPU would be able to read both the sound channels at once which would improve transfer speed tremendously, and it could handle a slightly higher bps. Of course it can't get any faster than 1KB/s probably no matter what you do, but that's alright. The whole 128K of RAM could be filled in like 3 minutes, good enough for indie devs.

>> No.9604707

>>9604147
>1984
>512k RAM expansion for a home console
I said it'd be launched in 86 or 87. 512K is pretty good for future proofing, that's about as spacious as the average sega genesis cart. The price of floppy drive never did go down, while the price of RAM took a nosedive in the late 80s. Pairing a cheap FDS-like floppy drive with a ton of RAM would be a wise decision I figure.

>>9604306
My console would have 32K of tile VRAM and 96K of work RAM unified in a 128K chip, and a separate 16K VRAM for the bitmap. It wouldn't look as good as the genesis or turbografx, but it'd come out before either of them, and have a sophisticated bitmap feature, faster than Amiga's and ST's. The games would also be far cheaper, you could decompress a lot of data on a 128K unified RAM.

>> No.9604719

>>9604569
>>9604585
Are these supposed to be released in the 80s? I don't think there's enough space in the PCB for 80s RAM chips in there, which usually came in 4KB to 16KB. The C64 used 8 8K chips. Also, why did he put the power brick inside the console case? 80s power adaptors were notoriously unreliable, you could melt your whole console or put it on fire if you put it in there.

>> No.9604735

>>9604707
>512K is pretty good for future proofing, that's about as spacious as the average sega genesis cart
Yeah, that's a ROM chip. You're talking about RAM here. Sega lost the market because they decided to put a whopping 750KB of RAM in the Mega CD, which made the system cost about an extra hundred bucks over the Duo that had 250K. Just to give you an idea of the price you're talking about here, in 1991, 4 years after the launch of your retard machine, a Super System Card V3.0 with 256k of RAM, nothing else, was 10,000 yen, or about 100 bucks. You're talking about TWICE the amount of RAM, FOUR years earlier.

Do you not understand how expensive your add-on would be?

>> No.9604784

>>9604735
>Sega lost the market because they decided to put a whopping 750KB of RAM in the Mega CD, which made the system cost about an extra hundred bucks over the Duo that had 250K.
The Sega CD had a 68000, a sound chip, and a custom graphics ASIC on top of the 750K RAM. The retail price of DRAM was $300/MB in 1986, according to this data:
>https://jcmit.net/memoryprice.htm
That would be $150 for a 512K RAM, at worst, and a continuous floppy 3 inch 256K drive would probably cost less than $80, that's how much the FDS retailed for.
>a Super System Card V3.0 with 256k of RAM, nothing else, was 10,000 yen, or about 100 bucks
The first version of that card was produced in 1988, the year of RAM drought. RAM was a lot cheaper in the previous year. Also manufacturing hardware in a bulk helps bring down the cost. In 1989, it would be the cheapest way to play 16 bit games.

>> No.9604803

>>9603925
That's just a pricier and inferior C64.

>> No.9604818

>>9604784
>The first version of that card was produced in 1988, the year of RAM drought
The first version of that card had 64kb of ram.

>on top of the 750K RAM
Yeah, and it retailed for 50,000 yen.

Even if we argue you can get your add-on built, it'll be a 250 dollar proposition if you're selling it at COST. By the time you add a margin, who the hell is going to be paying these kinds of prices for a home system when they could just get a PC?

>> No.9604827

>>9604818
Not sure what NEC was doing, the retail price of 1MB PC RAM was $45 in 1991, must've been even cheaper out of the factory. The HuCard needed to be slim and compact so they probably couldn't use an off the shelf PC RAM stick. Either way, it's retarded to use the price of a console accessory to support your argument about RAM prices.

>> No.9604936

>>9604689
>Read this carefully man
Sprite/tile shit should work just fine no matter what the CPU is doing if they're running in separate ram that's only connected to the vdp.
>Those two chips not meant to be run at the same time.
What two chips?
>It would preferably use the unified main RAM to reduce the system cost.
So scrapping your original design of separate vram?
>I'm thinking something like a modified VIC-II with more data pins could handle it.
Nope. You need both data and address pins. That's how the chips work. Unless you put everything on the same bus or/and multiplex, with the associated issues, as previously mentioned.
>But it was really cheap, much cheaper than a disk drive with random access. That's what the 512K RAM is for.
lol. That ram alone is going to cost twice as much as a real drive. Plus the cost of the shitty drive. So your solution is not only worse but more expensive.
>I suppose a 32 bit CPU would
You suppose wrong. I gave you a simple summary of how it actually works. Do more reading and less supposing, I suppose.

>> No.9605095

>>9604803
C64 is worse than NES

>> No.9605117

>>9604147
>The cost of laserdisc machines alone will cripple you utterly.
Not really. They had decent sales on the high-end consumer market.

>> No.9605535

>>9604936
>Sprite/tile shit should work just fine no matter what the CPU is doing if they're running in separate ram
VIC-II works during half clocks, it needs a segmented RAM but not a separate one.
>What two chips?
Yeah you didn't even read my OP posts.
>So scrapping your original design of separate vram?
The separate VRAM is for the bitmap mode.
>Unless you put everything on the same bus or/and multiplex, with the associated issues, as previously mentioned.
I'm saying this for the third time. The VIC-II like tile chip would remain idle during the bitmap chip operations. The bus alternating only happens once in the beginning of a game or a level because it would be a slow routine.
>That ram alone is going to cost twice as much as a real drive. Plus the cost of the shitty drive.
The whole thing would cost like $200. I'm basing it on retail price list for RAM chips in the 86-87. The Mitsumi QuickDisk was pretty reliable save for the weak motor belt.
>You suppose wrong
I didn't. The datasette doesn't read the second track of the tape. A 32-bit CPU could do that.

>> No.9605550

>>9605535
>doesn't read
I mean it does, but both the tracks have the same pulse patterns, so it's all a mono track.

>> No.9605662
File: 444 KB, 1430x915, SMScubeBig.jpg [View same] [iqdb] [saucenao] [google]
9605662

>>9604719
IIRC, the Famicube is pure fantasy, but the SEGACube is suppose to be more in-line with what was actually commercially available in the late 80s. But neither are running on the idea that they'd be as mass produced as the actual SMS or NES.

>> No.9605749

>>9603717
I'd probably just do a cheaper home consolized version of a late 80's computer architecture like the Amiga or Atari ST, seems to me the best way to do a console in the late 80's to very early 90's that wouldn't just be stepping on the toes of what Nintendo, Sega, and to a lesser extent NEC/Hudson were doing with the 3rd/4th generation home consoles

>> No.9605768

>>9604168
While you’re at it, fix the stupid dpad on that thing

>> No.9605927
File: 586 KB, 545x1000, Automita..png [View same] [iqdb] [saucenao] [google]
9605927

>>9603838
I built mine in 1905.
>Weight 230 pounds
>Size 6 ft x 3ft x 3ft
>Penny arcades are all the rage
>The spring powered Grand Jockey cabinet is designed with wooden automata and punch wheel disks. No electricity, no LED's no computers, all mechanical.
>It has one lever for jumping, which mechanically switches CAM wheels to change the horses animation from galloping to jumping. Gates are set on a looping belt and the game is lost if the jump is not timed correctly.
>Owners can interchange punch wheel disks (ala a ployphone) to change the order of the gates.

>> No.9606149

>>9603717
I drop development of the Atari 7800, ST, XEGS, and all other hardware projects at Atari.
Everything is put into the development of a new unified Atari console: the Atari CD.

The Atari CD is a 16-bit console with a rough power level equivalent to the PC Engine CD.
But there is no cartridge base system.
It is CD-based from the beginning.
The familiar Atari controller is redesigned to use a d-pad plus six buttons + start/select. Games are becoming more complex and commonly arcades use three buttons so double it just to be sure and future proof.
The CD drive is used primarily for
1. music
2. extra game data storage
3. cheapness of manufacturer

A 1x drive will be sufficient but let's try for 2x.
Top loader design. Off-the-shelf components if possible to allow repair shops to replace worn out CD drives without causing too much headache or cost to the owner.

Major Japanese developers are courted.
Long-form console gaming is the future.
With luck some good action RPGs are released for the Atari CD that catch on and steal the thunder of Zelda. Overall, the focus is on console gaming as a genre to itself, rather than bringing the arcade home.

refutations
>CD would be too expensive
Not quite. It's borderline but I've looked into it and by 1986 or early 87 it was feasible using the same tech used in portable CD players of the time.
>where does the funding come from?
Investors who are willing to take a chance betting on the company that made the VCS.
At this point in history the 5200's flop could be considered a fluke.

>> No.9606176

>>9606149
extra note:
The Atari CD is blue. Not wood grain or black.
It's a nice blue color. Maybe some gray highlights.

>> No.9606205
File: 17 KB, 600x450, DuoRX_set.jpg [View same] [iqdb] [saucenao] [google]
9606205

>>9606176
hmm

>> No.9606242

>>9606149
Thinking it over a little bit more I'm going to go with as off-the-shelf as possible and cheap 16-bit components as I can get. I'm going to do with Nintendo did with the N64 and get a ready-made machine but instead of Japanese going to Americans I'm going to be an American going to Japan and saying give me a 16-bit console we quickly interface a CD-player with. The Yellow Book was out by 1984 and we want to hop on that as quickly as possible.

>> No.9606261

>>9606149
>drop development of the ST
That would be a really dumb thing to do.

Your best bet would be creating a console using largely the same parts as the ST hardware by modifying the bitmap shifter in the ST into a tile controller, reducing the 512K main RAM into a 128KB cache, and replacing the floppy drive with a sony or panasonic CD drive. That would save a lot of money, and it'd be a more powerful system than the PC Engine or even the genesis in some ways. The PC-E has no DMA and is unable to do sophisticated visual effects or complex math operations, it's just a beefed out sega master system. Tramiel could order those CD ROM drives in a bulk and get the best prices, he was good at that, but be ready to make a few enemies in the process.

>> No.9606303

>>9605095
It's better in almost every way.
>larger sprites
>no flickering
>more subdued color palate
>sound chip with programmable wave forms
>vram modification on the fly without any extra chip
>capable of pixel doubling and bitmap

>> No.9606343

>>9606261
Then that's what I'd do, but the ST and the Atari CD would become the same system. There is no more Atari computer division and line-up separated off from the console division. The marketing around the Atari CD would be almost entirely dedicated to presenting it as a video game system. However, during development, if possible without adding expense or extra development time, the ability for the system to interface with add-on floppy drives, printers, and other modules would be included. Support for these would be metered out. I don't want 3rd parties going nuts with it. And I sure don't plan on any 32x style disasters. Think more along silly things like the Gameboy camera and printer. Years down the road.

>> No.9606729

>>9605535
>Yeah you didn't even read my OP posts.
I read them. But it's all nonsensical gibberish because you don't have the slightest clue how any of the stuff you're talking about actually works. I get that this is fantasy console design, but you might as well just say it runs on rainbow unicorn farts
>I didn't. The datasette doesn't read the second track of the tape. A 32-bit CPU could do that.
Jesus. You know this is a 18+ board, right?

>> No.9607062

>>9606729
You talk like an incel.

>> No.9607070

>>9605662
Sega computer business was in about 84 was looking pretty good so they make a computer instead of a console in 1986 using the z8000 which they continue to update until it is finally discontinued in 1995 after being used to make the special effects for free willy and flipper 2.

Another idea, sega gets rejected by motorola, watches this trailer and is convinced the z8000 is the way to go. Master system graphics chip except 4x better in sprites and tiles. 8x16 colour palletes for backgrounds and another set for sprites. Uses the ensoniq sound chip.

https://www.youtube.com/watch?v=FACRFrl_9zE

idea 2
atari lynx but design to run on a tv and at 4 times the resolution instead of the panther

>> No.9607083

>>9603717
>you're designing a console in 1984
Uhm, no I'm not and I really don't appreciate you claiming I did things I in fact had not.

>> No.9607097

>>9606303
The games confirm that it's worse

>> No.9607132

>>9604581
I think the SMS is hideous.
But this actually looks pretty cool. I'd change the colors, though.

>> No.9607139

>>9603717
>Be Sega
>Accept SGI's officer for the reality coprocessor GPU to be uaed in the saturn instead of those gay VDPs
>Increase texture cache size to 16k
>Release the saturn
>Daytona USA as launch title runs at 30fps, with good draw distance and stable 3d

Sega wins 5th gen.

>> No.9607578
File: 40 KB, 680x680, laughing-dd.jpg [View same] [iqdb] [saucenao] [google]
9607578

>>9607062
I'm sure the incels are delighted to hear that you see them as intelligent well educated gentlemen

>> No.9607973
File: 226 KB, 1600x1066, s-l1600.jpg [View same] [iqdb] [saucenao] [google]
9607973

>>9603717
Here is my hindsight-based design:

Hardware choice is up to my designers.
BUT
The hardware and its capabilities must be fully documented in a professional and easy to understand manner.
Said hardware must be considered to be "easy" to work with and I'm not going to take just one or two people's opinions on this, there's going to be a lot of testing and prototyping including sending out dev kits to major third parties and getting their feedback, if this results in corporate espionage I don't care.
The hardware is focused on fast action games with smooth vertical and horizontal scrolling and lots of colors on screen.
The controller will have at least eight buttons including start+select, games are getting more complex and I can think of a lot of scenarios where one or two won't cut it.
The controller will have a great and responsive feel to it that allows for sharp gameplay.
Top loader cart slot.
Power supply board inside the system if possible, I don't like power bricks.
Multi-out for RF/RGB and phono plugs for composite.
System aesthetic is blues/greens/grays, no woodgrain or plain blacks, but it can't be perceived as a girl's toy either, I'll know it when I see it.
Power switch makes a satisfying click when pressed. This sparks joy in the player.
No add-ons of any kind. It's just a games machine.

>> No.9608293

>>9607973
>Power supply board inside the system if possible, I don't like power bricks.
The N64 had the most elegant solution for this imo, easily replaced if it shits the bed and a normal size plug.

>> No.9608656

>>9607139
>Sega wins 5th gen
Probably not, Sega of Japan wasn't exactly generous with their development kit and documentation, and the SGI Reality GPU had some complicated functionalities that could easily be misused without a proper guidance. That's why most N64 games ran like shit, Nintendo wasn't a generous company. Nintendo rejected games using the fast Turbo3D microcode for having "bad graphics" so Factor5 had to write their own microcode while learning the system on their own.

>> No.9608784

>>9608293
But why not just place it inside the system and use a standard stereo power cord like the PS1/2 and Dreamcast?

>> No.9609441
File: 122 KB, 820x654, lol.jpg [View same] [iqdb] [saucenao] [google]
9609441

>>9607973
>The hardware and its capabilities must be fully documented in a professional and easy to understand manner.
So does this mean you're using all custom chips or are you gonna fix all the errors in the vendor supplied datasheets?

>> No.9609448

>>9609441
You're fired.

>> No.9609626

>>9607097
>better platformers
>better shmups
>better racers
>better RPG
>has turbo outrun
NES lost.

>> No.9609654
File: 30 KB, 160x120, 160px-DoomZXSpectrumFS.png [View same] [iqdb] [saucenao] [google]
9609654

>>9603838
>>9605927

I'm only interested when Doom gets ported to it

>> No.9609693

>>9609654
Here's an idea for a mechanical Doom in the 1940s.
>industrial video camera with a radio transmitter fitted into a remote controlled electric wheels as the player character
>2000 square feet mechanical maze that could shift its walls every time a level is won to change the map design
>100 electromagnetic enemies that could randomly pop up, move, and attack the player
>electrical counters and switches for damage calculations and registers
>player sits in a separated room with CRT monitor and a couple of potentiometer paddles to control the camera

>> No.9610327

>>9609693
I think you'd need to be a robber Baron to have enough quarters for that. It would be easier and cheaper for someone like Henry Ford to have a shotgun loaded with low grain shells going through a hedge maze. Italians and Jews hold up "bullet resistant steel" full body shields, cutout and painted like demons. Maybe they get to throw water balloons. Maybe they get deported if they actually score enough hits and he loses.The health power ups are bottles of gin. The score and sound effects are handled by very loud Irish and Chinese folk musicians. They may also be shot and deported if they survive.

>> No.9610375

>>9609693
>2 square feet mechanical maze that shifts as character moves
>10 mechanical enemies that could randomly pop up, move, and attack the player
>mechanical counters and switches for damage calculations and registers
>player stands in front of the machine and views active playing area through a 19" window.
>lines drawn on window to simulate scanlines

>> No.9610504

>>9610375
A Periscope-type device (as in the actual electromechanical game) tied to a Ray-O-Light system for the gun. (It's an on-rails shooter, but if additional complications are in the budget, player choice could matter.) The periscope moves through a concealed rotating drum in front of the player, by the players forward force on the gun ( as they're allowed by their completion of goals). The drum is a series of diorama sliced corridors front to back with metal cast demons inside and an end state on the far side of the machine with a door painting. The player uses their light gun and view through the window (a glass panel with prisms displayed on the machine for everyone to see.) Each hit is registered by the optical sensors. The metal cast figure falls. The score flips higher. The knockers hit an accordion like device for the demon's death wail and a metal clicker for the gun shot. The music plays on a record in a loop. The player advances to the end of the corridor. Another tone plays. they lift the gun up and back freely as the lights go off inside the drum for the transition. Once the player does this correctly, the machine cycles to the next course in the drum.

>> No.9610515

>>9610504
Actually I think my firet instinct of a flat wheel system resetting at the center makes more sense. A drum allows for more area, but the wiring would probably be a bitch.

>> No.9610573
File: 42 KB, 720x405, brawler-64-wireless-controller.jpg [View same] [iqdb] [saucenao] [google]
9610573

>>9603717
N64 but the controller isn't retarded
I don't understand why retrofighters insists on making the Z buttons analog triggers

>> No.9611308

>>9610573
It should've been a potentiometer analog stick on the left and a trackball on the right, right below the A and B buttons. Analog and dpad alternator button would also be quite nice, when the analog stick wears out it would let the player use the dpad as the substitute. That would be great for both platformer games and FPS games while also improving reliability and saving cost.

>> No.9612065
File: 9 KB, 250x188, DWrgil1WAAA06SV.jpg [View same] [iqdb] [saucenao] [google]
9612065

>>9609693
Your idea reminds me a thing Disney Quest had where there were RC in a maze under the floor and you had to control them with arcade cabinets that would show their pov.

>> No.9612314

>>9603717
>1984
>68000 cpu
Too expensive for a home console

>> No.9612325

>>9612314
https://www.nytimes.com/1984/06/29/business/motorola-s-powerful-new-chip.html
>Initially, the chip will be quite expensive. Motorola said the first models will sell for $487 each, close to the price of the 68000 when it was first brought out in 1979. But as with all semiconductor products, the price of the 68000 plummetted as volume production began, and it now sells for about $15.

>> No.9613037
File: 65 KB, 800x456, atari-7800-cuttle-cart-multicart-chad_1_cd81fa757e018a7aac65680019b9b535.jpg [View same] [iqdb] [saucenao] [google]
9613037

>>9604168
The 7800 video chip had a lot of wierd shit about it that made it ass to program for, and sharing video RAM with CPU bus cycles really hurt its power. The NES got one thing very right, and that was to copy the TMS9918 by putting VRAM under VDP control, and even adding a cartridge bus for graphics ROMs.
It could also have used a real sound chip. The primary option of using a chip half the size of the cartridge shell was not a good option.
But yeah, the worst thing was Jack immediately putting it on the shelf, giving N time to tie up most of the vidya IP market.
>>9605768
The US got the stupid joystick with thumb-killing side buttons, which was one of the worst things about the 5200. The 5200 controller design was such a box full of fail.

>> No.9613121

>>9604168
>arcade conversions,
you've doomed it

>> No.9613196

>>9612065
i played with this in like 1998 or something

>> No.9613660

>>9613037
>sharing video RAM with CPU bus cycles really hurt its power.
No it was alright. The CPU would be halted during bus access, but the MARIA chip has a DMA which runs independently from the CPU. The 7800 treats its graphics as a display list rather than object list, it could move a large number of images at a stable framerate. Sure its not as simple to program for, but it performs better. The only problem is scrolling background graphics but there are ways around it.
>The NES got one thing very right, and that was to copy the TMS9918 by putting VRAM under VDP control, and even adding a cartridge bus for graphics ROMs
A separate VRAM would pretty much make the 7800 slower because the CPU would have no direct access to the display RAM and thus no ability to modify the display list instantly. Also the cartridge bus was the NES' weakness in a way, it made the games way more expensive.
Something I'd add to the 7800 is 16K more RAM though. Many games needed it.
>It could also have used a real sound chip
That one is undeniable, along with 16K more RAM. But Atari wanted the 7800 to be cheaper than the NES while retaining BC with 2600 out of the box. I think that wasnt a good idea in 1986, the TIA RIOT and 2600 sound chip should've been a separate addition to the console. Atari was releasing 2600 jr at the same time anyway.