Portable Nintendo 64
07-19-2011, 05:32 PM
#21
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
Are you referring to the work of Benjamin J. Heckendorn (aka Ben Heck), who built all of the portable consoles I posted earlier?
Reply
0
0
07-19-2011, 05:59 PM
#22
Are you referring to the work of Benjamin J. Heckendorn (aka Ben Heck)
Here are some more options/designs. The first one is done so well it could be sold as a commercial product.
Not the same, but it's cool idea.
Reply
0
0
07-19-2011, 07:36 PM
#23
You're quite right. I never owned a Saturn (they were after my time) but I'd thought that it only supported bitmap graphics. Did a little research and found out that its graphics engine supported both bitmapped sprites and shaded polygons.
Rather interestingly, the background renderer was its own discrete engine, so this seems to have been sort of a crossover design, where polygons were used, but were conceptually treated as though they were sprites, in that they were separate from the playfield itself.
But it has a 3D rendering engine, so it falls into the Modern Era. (It did not, however, have a gerbil-***** controller as standard equipment- that was optional.)
Post corrected.
Rather interestingly, the background renderer was its own discrete engine, so this seems to have been sort of a crossover design, where polygons were used, but were conceptually treated as though they were sprites, in that they were separate from the playfield itself.
But it has a 3D rendering engine, so it falls into the Modern Era. (It did not, however, have a gerbil-***** controller as standard equipment- that was optional.)
Post corrected.
From what I've read it died out as it was harder to write for then the PS1, though in some respects it was superior (you definitely see FAR more beautiful 2D games on the saturn).
Reply
0
0
07-19-2011, 08:31 PM
#24
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
There have been some real oddball CPU and GPU designs over the years.
A neighbor of mine was, until recently, a lead developer for Rockstar Games. So I hear some interesting stories.
For instance, that the original developer's platform for the XBOX 360, provided to them by Microsoft, was a Mac? Yup. They needed something with a PowerPC processor in it, and the 360 hardware was nowhere close to being ready for the developers, so they bought a bunch of PowerMacs, had ATI spin a modified graphics card for them, wrote some custom firmware, and shipped 'em to the developers.
The poor thing doesn't have a fixed-to-float operand, either. Programmers will understand what a bitch that is.
And coding for the PS3 is apparently just utter hell. The problem comes from having to manage shared resources amongst a seven-core processor. Obviously the opportunities for memory conflicts, stalls, race conditions and whatnot abound. On the plus side, the GPU is apparently so underutilized that they offload most of the game physics onto it.
Of course, the original VCS (Atari 2600) was the grandaddy of weird hardware. I've spent a lot of time studying that machine, as it's quite fascinating. In particular, the book is an excellent volume, though if you're into that sort of thing, I recommend that you start by simply downloading the schematics and looking over them. They're available here:
http://www.atariage.com/2600/archive..._2600_Low.html
The schematics for the actual TIA chip itself are laughably simple by modern standards. You could build one out of discrete parts: http://www.atariage.com/2600/archive...tia/index.html
There's also a good design history here: http://www.atariage.com/2600/archive...?SystemID=2600
Did you know that the 2600 had no framebuffer, and for that matter, no video memory of any kind? Today, we take this sort of thing for granted. Just write some data into some location in RAM, and the video hardware will take care of putting it on the screen for you. Not the VCS. Only 128 bytes (not k, but bytes) of RAM, and that was all for the game logic. The CPU itself actually had to draw the screen in real time as the beam moved.
That's why those huge borders are there all around the active display- they provide the CPU with some extra time in which to do all of the actual game logic (fetching input, doing collision detection, updating the sprite table, generating sound, keeping score, reading and writing to memory, etc.) It's also why, if you dig back in your memory, some games occasionally had little black, horizontal lines which encroached into the left edge of the playfield from time to time- lazy programmers put those there as needed to give the CPU just a few extra cycles to finish whatever it was doing:
(You'll also notice that no Activision game ever had "the lines." The programmers there were absolutely fanatical about that.)
Since the timing of the horizontal and vertical intervals is an absolute, dictated by the NTSC television standard, there's just no getting around it. The timing of the deflection coils is fixed in stone, and they dictated everything else in the system. When it came time for the beam to turn on and actually start drawing a line on the screen, the CPU had to be done with everything else and ready for it come hell or high water. Hence the term "Racing the Beam" as used in the title of the book I mentioned earlier.
A neighbor of mine was, until recently, a lead developer for Rockstar Games. So I hear some interesting stories.
For instance, that the original developer's platform for the XBOX 360, provided to them by Microsoft, was a Mac? Yup. They needed something with a PowerPC processor in it, and the 360 hardware was nowhere close to being ready for the developers, so they bought a bunch of PowerMacs, had ATI spin a modified graphics card for them, wrote some custom firmware, and shipped 'em to the developers.
The poor thing doesn't have a fixed-to-float operand, either. Programmers will understand what a bitch that is.
And coding for the PS3 is apparently just utter hell. The problem comes from having to manage shared resources amongst a seven-core processor. Obviously the opportunities for memory conflicts, stalls, race conditions and whatnot abound. On the plus side, the GPU is apparently so underutilized that they offload most of the game physics onto it.
Of course, the original VCS (Atari 2600) was the grandaddy of weird hardware. I've spent a lot of time studying that machine, as it's quite fascinating. In particular, the book is an excellent volume, though if you're into that sort of thing, I recommend that you start by simply downloading the schematics and looking over them. They're available here:
http://www.atariage.com/2600/archive..._2600_Low.html
The schematics for the actual TIA chip itself are laughably simple by modern standards. You could build one out of discrete parts: http://www.atariage.com/2600/archive...tia/index.html
There's also a good design history here: http://www.atariage.com/2600/archive...?SystemID=2600
Did you know that the 2600 had no framebuffer, and for that matter, no video memory of any kind? Today, we take this sort of thing for granted. Just write some data into some location in RAM, and the video hardware will take care of putting it on the screen for you. Not the VCS. Only 128 bytes (not k, but bytes) of RAM, and that was all for the game logic. The CPU itself actually had to draw the screen in real time as the beam moved.
That's why those huge borders are there all around the active display- they provide the CPU with some extra time in which to do all of the actual game logic (fetching input, doing collision detection, updating the sprite table, generating sound, keeping score, reading and writing to memory, etc.) It's also why, if you dig back in your memory, some games occasionally had little black, horizontal lines which encroached into the left edge of the playfield from time to time- lazy programmers put those there as needed to give the CPU just a few extra cycles to finish whatever it was doing:
(You'll also notice that no Activision game ever had "the lines." The programmers there were absolutely fanatical about that.)
Since the timing of the horizontal and vertical intervals is an absolute, dictated by the NTSC television standard, there's just no getting around it. The timing of the deflection coils is fixed in stone, and they dictated everything else in the system. When it came time for the beam to turn on and actually start drawing a line on the screen, the CPU had to be done with everything else and ready for it come hell or high water. Hence the term "Racing the Beam" as used in the title of the book I mentioned earlier.
Last edited by Joe Perez; 07-19-2011 at 10:21 PM. Reason: schpelling
Reply
0
0
07-20-2011, 10:19 AM
#25
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
I wonder if you portable console enviers are familiar with the GP32, and its derivative, the GP2X?
These are a rather interesting family of open-source handheld videogame systems. And while there are some games that have been coded directly for them, and numerous popular game engines have been ported to them, their most popular applications are emulators. With all of the different EMUs which are available for them, you can run just about any classic videogame ever written. MAME is available, for starters, as is just about every console and home computer ever created up through the mid 90s.
You can emulate the Atari 2600, the C64/128, the Amiga, the Genesis, the NES, the Apple II, the original Playstation, a PC running DOS, and dozens more. Here's a list taken from the DeveloperWiki:
Acorn
(Did you catch the second-to-last one in the list? This ****** can emulate the EDSAC! The very first stored-program, general-purpose computer ever greated! Read about it here.)
The company that originally made them is sort of bankrupt-ish, however the hardware still seems to be available, as it appears that another company has taken over production:
http://www.thinkgeek.com/electronics/retro-gaming/bfc7/
http://www.thinkgeek.com/electronics/retro-gaming/e5ef/
These are a rather interesting family of open-source handheld videogame systems. And while there are some games that have been coded directly for them, and numerous popular game engines have been ported to them, their most popular applications are emulators. With all of the different EMUs which are available for them, you can run just about any classic videogame ever written. MAME is available, for starters, as is just about every console and home computer ever created up through the mid 90s.
You can emulate the Atari 2600, the C64/128, the Amiga, the Genesis, the NES, the Apple II, the original Playstation, a PC running DOS, and dozens more. Here's a list taken from the DeveloperWiki:
Acorn
- Archimedes
- BBC Micro
- CPC
- Apple ][
- Macintosh
- CPS2
- MAME
- MC68000/Z80
- 130XE
- 800/800XL
- 2600
- 5200
- 7800
- Jaguar
- Lynx
- ST
- Wonderswan
- Adam
- ColecoVision
- Amiga
- Plus/4
- C64
- C128
- CBM-II
- PET
- VIC-20
- Vectrex
- PC
- Odyssey 2
- Intellivision
- MGT/SAM/WCC
- SAM Coupé
- PC-98
- PC Engine
- GameBoy (and GameBoy Color)
- GameBoy Advance
- NES
- SNES
- ZX Spectrum
- Game Gear
- Master System
- Mega CD
- Mega Drive
- Neo Geo
- Neo Geo CD
- Neo Geo Pocket
- MSX
- PlayStation
- Color Computer (aka. Radio Shack TRS-80)
- 99/4A
- TI-92
- TO7-70
- Supervision
- Chip8
- EDSAC
- J2ME
(Did you catch the second-to-last one in the list? This ****** can emulate the EDSAC! The very first stored-program, general-purpose computer ever greated! Read about it here.)
The company that originally made them is sort of bankrupt-ish, however the hardware still seems to be available, as it appears that another company has taken over production:
http://www.thinkgeek.com/electronics/retro-gaming/bfc7/
http://www.thinkgeek.com/electronics/retro-gaming/e5ef/
Last edited by Joe Perez; 07-20-2011 at 02:02 PM. Reason: fixed link
Reply
0
0
07-20-2011, 11:13 AM
#27
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
Touchscreen (or tiny keyboard, or crackberry-style trackball / touchpad) on smartphone + videogame designed for joystick input = hellafail.
I've tried it. Even Super Mario Brothers is utterly unplayable. I don't even know why the guy bothered to port it. Shoving shards of broken glass up his ******* would have been more productive.
I've tried it. Even Super Mario Brothers is utterly unplayable. I don't even know why the guy bothered to port it. Shoving shards of broken glass up his ******* would have been more productive.
Reply
0
0
07-20-2011, 02:53 PM
#31
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
This is mine:
From what I have seen, I have a better keyboard than about 90% of smartphone users. And for gaming, it's not even one-fourtieth as user-friendly as an actual D-pad. (Or even a gerbil-*****, for that matter.)
Realistically speaking, the majority of non-hackberry smartphones (including what is considered by many to be "The" smartphone) do not have keyboards at all.
Kind of defeats the whole "portability" thing, too, if I need two hands to hold and operate the joystick, and a third hand to hold the phone. Granted, you and I have never met in person, so your anatomy may differ from mine.
Reply
0
0
07-20-2011, 06:25 PM
#34
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
This is getting interestinger and interestinger....
I have no interest in lugging around a PS3 joystick so that I can run emulators that don't exist on my phone with crappy battery life.
On the other hand, the GP2x "Cannoo" (the latest version, built by a company that actually exists) seems to garner high praise:
And then I stumbled across the Pandora:
Now, on the one hand, it's slightly too large to be called a handheld game.
On the other hand, it's an actual computer.
I have no interest in lugging around a PS3 joystick so that I can run emulators that don't exist on my phone with crappy battery life.
On the other hand, the GP2x "Cannoo" (the latest version, built by a company that actually exists) seems to garner high praise:
And then I stumbled across the Pandora:
Now, on the one hand, it's slightly too large to be called a handheld game.
On the other hand, it's an actual computer.
Reply
0
0
