Beating the limitations of the TurboGrafx-16/PC Engine | White_Pointer Gaming
ฝัง
- เผยแพร่เมื่อ 26 มิ.ย. 2024
- The TurboGrafx-16 or PC Engine was a limited console in many ways, but developers pulled off some really neat tricks on it to really push it to its limit and compete with Sega and Nintendo. This video explores some techniques that were used to do so!
0:00 Intro
0:20 History
2:24 Comparisons with Sega and Nintendo
3:47 Faking background layers and parallax
7:05 Swapping memory locations on the background
11:08 Conclusion and Outro
Purchase my book "Secrets of Video Game Consoles" directly from the publisher here: www.pen-and-sword.co.uk/Secre...
Also available as an ebook!
Some other links:
www.barnesandnoble.com/w/secr...
www.booksamillion.com/p/Secre...
www.angusrobertson.com.au/boo...
www.booktopia.com.au/secrets-...
www.chapters.indigo.ca/en-ca/...
www.amazon.com/Secrets-Video-...
Or check out your favourite book store, hopefully they have it in stock! - เกม
PC-Engine will always be my favorite childhood console ^__^ It had a style and ecosystem entirely unique that will always be special.
I have to admit I always just assumed the PC Engine HAD multiple background layers, so this was an eye opener for sure! Thanks a lot for this video!
I loved the Turbo Graphics 16. I had it for like a week when I was younger, but my brother stole it and sold it for drugs.
Oh dang, sorry to hear that.
Dude I'm so sorry to hear that. In like 90 he did? Dang I somehow lost mine over the years before I got back into games (and had turbo CD and an express 😢). Hope your life is good these days brother.
What ever happened to your brother if you don’t mind me asking
@@Fry09294 He ended up doing a 3 year stint in prison and completely changed his life when he got out. He now has a wife, 2 kids, motorcycle, nice car, nice house with a pool, and is a journeymen plumber that only has to take the test to become a master. He makes very good money. We weren't close during childhood, he was pretty abusive, but after prison, completely different person. The system was technically his as well so I can't be too mad, but damn was I excited when he brought that home. I let him play my SNES and Genesis and I thought he was returning the favor.
Having drawn tile graphics on a couple of Homebrew releases a d designed graphics for a couple of unfinished titles, the way these guys worked around the limitations is just amazing
I've done some hobby work programming for the Sega Master System and Game Boy in assembly. Getting those parallax effects or a HUD that doesn't scroll vertically OR horizontally is a really fun and interesting challenge, with many different ways to go about handling it. These are some really fascinating examples! I always wondered how the TG-16 got away with some of its more impressive effects with just one layer, thanks for sharing!
Did you achieve that in the Master System?
@@kwkfortythree39 I've got one video on my channel of a little parallax scrolling demo I made for the SMS, and I've taken a look behind the code as to how the SMS version of Y's has its static HUD while the screen scrolls 4 ways. I plan on making a video about it actually, and have a script written, but it stil needs a lot of work to convey the complexities of assembly programming in a way that anyone can understand
The Game Boy at least had a window layer, similar to the Mega Drive's window plane, which allowed it to create stuff like static HUDs and text boxes without much trouble. Of course, you would know this, I'm just saying this for the benefit of others that might read this :)
@@WhitePointerGaming Yeah! Thanks for pointing it out! The window box is also used in some really clever out-of-the-box ways, such as many bosses in Operation C, and Prehistorik Man.
I LOVE this stuff! This is what fascinates me about the PCE's hardware! (Well, that and its awesome soundchip)
I also actually really like the GBC in particular for very similar reasons!
10:00 this is insane, the trick to getting the healthbar there is extremely clever-if you pause on a frame where Ken goes above the healthbar (10:49), you can see that the healthbar creates some sort of wormhole that makes Ken taller because it doesn't actually overlap with the background! If you weren't pausing to look though, you'd never notice, so this technique is truly brilliant.
Luv the PCE, luv this video. Subbed!
There's some coding voodoo going on there for sure lol.
Awesome explanation of a rather complex topic! I still don't fully understand it, but I definitely understand it better than I did before watching this video! 🙂
Game devs were so clever during this time period. Limited hardware really made them have to think and come up with crazy solutions.
What game was that at the very end flying around and shooting dragons and such?
The game at the end is Lords of Thunder. Awesome shoot 'em up that also takes advantage of the CD format for a rocking soundtrack.
Really love these techy videos that explain console dev tricks. Reminds me of GameHut! I am thanking the TH-cam algorithm that I found your channel. Wish you a lot of success in the future.
Thanks for the kind words, I'll do my best :)
I always love videos like this and wish for more. I'd like to see a long play of games that us a lot of trick broken down.
very educational, thanks.
Great video
Very interesting, thanks for the video. PCE is my main system but for sure a number of games do look quite flat where these techniques aren't used.
Love this kind of content! Keep it up!
Remember my cousin getting one of these and a important copy of Rondo Of Blood. The guy who had it imported spent alot of $$ getting it to the US.
As primarily a SNES fan who's interested in development there, I like seeing how stuff like this was done on both PC Engine and Genesis too, as the methods employed are almost always available to be used on SNES as standard as well.
And, doubly interestingly in particular here imo, is that because the PC Engine's particular sprites per scanline limit and sprite pixels per scanline limit both fall a bit below SNES (16 and 256 on PC Engine vs 32 and 272 on SNES), you can actually do basically everything with sprites on SNES similar to how you see it being done with sprites on PC Engine (and even more in some cases), just with the potential for a little more flicker in some specific use cases if you were to similarly do it all just with sprites on SNES due to how priorities work on each system, which of course usually wouldn't be necessary on SNES anyway as you have up to four times as many background layers to work with there.
What it means for SNES is that you can combine these methods you see for faking background layers and elements and such on both PC Engine and Genesis alongside the capabilities that are unique to SNES for some really cool results. Imagine using all of these tricks seen above on top of the four fully-overlapping full-screen background layers available in Mode 0 on SNES alongside the standard transparency effects and such there too for example. . . .
Good stuff going into the various details and explaining how much of it works. It's very useful for people to understand this kind of thing imo, both the capabilities and the limitations, especially for potential developers on any of these beloved fourth generation consoles.
PS. One little detail with the colours on-screen there: You've listed both the Genesis and SNES numbers including the transparent colours in each palette but the PC Engine minus the transparent colours in each palette. So, keeping them all the same, I think it should read 512 on-screen colours for PC Engine, 64 for Genesis and 256 for SNES, or I think 480 [+1 backdrop colour and 1 border colour] for PC Engine, 60 [+1 backdrop colour] for Genesis and 255 [+1 backdrop colour] for SNES. I'd probably just go with the full numbers including transparent palette colours for each for simplicity.
PPS. I just subscribed. :)
Glad you liked it, thanks for the subscription and the comment :) I'm actually not entirely sure whether the SNES could handle all of those things you speak about all at once, that would tax it quite a bit and would likely cause a lot of slowdown I imagine.
@@WhitePointerGaming A game like Donkey Kong Country 2 running on the stock SNES actually shows a bunch of the effects going on at the same time, so I think it definitely could, but only if the programmer had/has the skills to pull it off:
th-cam.com/video/RVzjFr6gprg/w-d-xo.html
There's full screen, full colour, three overlapping background layers, row/line scrolling for faux perspective and even pseudo 3D on both the water surface and separate floor levels in the background, tile priority switching, transparency effects, dynamic sprite tile loading in/out on the players and enemies, etc, all going on at once there while maintaining 60fps.
I'm pretty sure some dynamic background tile animations to fake extra parallax and using some sprites as background elements could be added into the mix there too. Again though, only if the programmer has a good grasp of the system and knows how to optimize things fully.
Edit: I should also mentioned that quite a few of the examples on my own TH-cam channel use lots of these effects and tricks at the same time too. And a couple of those have been coded up [by some helpful SNES programmers] and run just fine on SNES.
Yeah but even DKC2 struggles with slowdown at times, and DKC3 is even worse, there's actually quite a bit of slowdown in that game.
@@WhitePointerGaming I don't personally see any noticeable slowdown there in that scene in DK2 that I linked. So, I guess that's a matter of how we each interpret the meaning of "a lot of slowdown".
Is it what you are seeing with your eyes or viewing it via some kind of technical frame measuring tool or something?
Either way, I personally think it's entirely possible to do something with many of the effects combined at a solid frame rate on SNES. That was just one example with lots of cool effects going on at once that immediately came to mind.
But, if you're interested in some other examples, I'd say the likes of Super Aleste and Rendering Ranger R2, which both run at solid frame rates even while stuck in SlowROM at 70% of the SNES' full CPU speed, are great showcases for the potential there:
th-cam.com/video/DM9B36ZvH7M/w-d-xo.htmlsi=kJCHXEmTkvc9YjWU&t=223
There's three full-screen fully-overlapping background layers, proper transparency effects, full line-scrolling, loads of sprites on-screen, sprites faking background elements, solid frame rate, etc, there.
th-cam.com/video/Tl7D25I6yDc/w-d-xo.htmlsi=AagAt3hDuk-461lV&t=783
th-cam.com/video/Tl7D25I6yDc/w-d-xo.htmlsi=DEl0jJjwZ1254VoF&t=1180
th-cam.com/video/Tl7D25I6yDc/w-d-xo.htmlsi=VNpoyVSvrFj_wUeS&t=1372
th-cam.com/video/Tl7D25I6yDc/w-d-xo.htmlsi=5-S5_3chkp4XcFyZ&t=2833
There's often three fully-overlapping full-screen background layers, sprites faking additional background elements, row/line scrolling, transparency effects, loads of sprites on-screen, solid frame rate, etc, there.
And, just to emphasize again, these games are both running in SlowROM. So, even if there are a couple of frames of slowdown during the most busy/hectic moments there, they could certainly be removed simply by switching to FastROM and, if necessary, also optimizing the code even further as well.
And, if you want another in-progress example, you can check out the upcoming Rex Nobilis too:
th-cam.com/video/1AGMEZvU14g/w-d-xo.htmlsi=upei2C538M2Eg3Gn&t=1535
That game has levels running in the SNES' 512x448i mode with two full-screen fully-overlapping background layers, an additional third semi-transparent background layer using the colour windows plus HDMA, loads of sprites on-screen, all at a solid frame rate, etc
So, yeah, I still think the SNES is capable of doing basically all the aforementioned more traditional tricks alongside the stuff that's more specific to it at the same time, if the programmer knows what they are doing.
I'm not saying there was slowdown in that specific scene, just that the game does have slowdown in places.
Mesen 2 pce emulator is your friend. The status bar in SF2, while yes is a scroll reposition for the bar (background).. it also turns off sprites for that section and then turns them back on at the bottom of it. This forces the sprites to "appear" underneath bar. The PCE can turn on/off the background and/or sprites on a scanline basis. It can change a lot of video register values on a scanline basis.
Thank you for explaining all the tricks they use to make games for the PC Engine(TurboGrafx16). I wonder what Sega games could NEC made for the system. Could there been a Sonic the hedgehog for the PC engine. I wish they have made more fighting games for the TurboGrafx16; but somebody thought Americans was tired of fighting games. 😂😂😂
There were actually some Sega games on the PC Engine, oddly enough, such as Outrun.
@@WhitePointerGaming What would Enternal Champions look like on the PC Engine. Probably have more colors on screen and brighter.
Would love to hear you talk about the Neo geo MVS or AES hardware techniques.
Definitely considering it!
Your wish has been granted :) th-cam.com/video/Lh77KKss4Hk/w-d-xo.html
Good video thanks. I remember the pc engines had many arcade ports. A great machine.
Back in the day when frame buffer doesn’t exist. Impressed how creative developers can be especially when they did a pseudo-3D games using a sprite only to create a 3D illusion like racing games or flight games.
Amiga1000 was available in 1985, and Amiga 500 was affordable in 1987. But the blitter could only draw wireframes or letters. Is still useful for wide flat shaded polygons.
Great stuff, thnx!
3:35 worth keeping in mind that while the SNES had 256 color registers it also had color math (add, subtract or average two layers), so the potential number of on screen colors would still be way higher,
Technically, the colour maths was applied between the main screen and the sub screen, not between two layers. I cover how the transparency effects worked in this video: th-cam.com/video/K1DSUHFDmkA/w-d-xo.html
@@WhitePointerGaming correct, still it allowed for many more colors than the normally stated 256.
@@Phredreeke but it was never used as direct color. That's the point. Because direct color (sub palettes) is how art and details are derived.
@@TurboXrayI think we have different understandings as to what "direct color" means. The way it is used in regard to the SNES is a mode that bypasses looking up the palette in the color registers and instead mapping bytes directly to RGB values. I don't know of any game actually using it though
@@Phredreeke Ohh.. I was talking about the direct "use of color" as in number of colors available impact art - not the 3:3:2 "direct color" mode on the snes. That mode is completely useless IMO because its basically a fixed 256 color palette rather than 256 colors out of 32000 colors (which is a better mode). Act Raiser does use "direct color" mode paired with mode 7 though. All other games that use mode 7 (which is 8bit color) use the indirect 8bit palette mode.
But yeah, SNES is already starved for VRAM (and sprites very much so too), and it makes both "8bit" color modes mostly impractical (both vram and rom space).
You talked about some of the systems specs in comparison to the Genesis and Snes but that isn't the entire picture. The TG-16 held its own for the same reason the Genesis did.... both machines were far more than their VDP/GPU's. For example, both consoles ran with a multiprocessor setup and are faster than an Snes. Sega just flat setup their 16-bit machine like an arcade cab with as little bottlenecks as possible. This gave Sega the ability to punch well above what they should have been doing. For example 99.9% of all Genesis games run in a higher resolution than the Snes. You sure wouldn't have guessed that just looking at their video output specs but it happened. Now, look at what indy developers are doing with the Genesis today. We are finally seeing what one is truly capable of, and it's amazing. I believe if indy developers decided to go crazy with the TG-16, we would see similar results.
A lot of cross console ports almost always resulted in the SNES version being cropped compared to the Genesis!
@@AltimaNEO
Very true!
I talk about this kind of stuff in my Mega Drive/Genesis video here: th-cam.com/video/RwdgaBnd9U0/w-d-xo.html
Nice video! Have to watch it again soon to understand everything better, too much noise around here now.
With three of the main 16-bit consoles covered, there's only one left. Some consider it more of an arcade machine, but it was competing with the others in the magazines back then, with ads and reviews. Any plans for covering that one?
Thanks for the comment! As for the Neo Geo... maybe!
You might like my latest video! th-cam.com/video/Lh77KKss4Hk/w-d-xo.html
Sounds very similar to how the Neo Geo did a lot of it's effects. It doesn't have a lot of fancy capabilities, just a lot of sprites and brute force,
Definitely considering taking a look at the Neo Geo sometime in the future.
@@WhitePointerGaming From another video I watched on the subject, it can handle a TON of sprites and like one background layer or something like that. The backgrounds in most games are nothing but sprites. Its insane.
That might be similar to what's happening here in @TurboXrays Bonk parallax demo. It goes over my head but I believe it's all using sprites for the foreground layer
th-cam.com/video/1iq8nQ2Bd80/w-d-xo.htmlsi=lEUpfJj_wS4PN3Jy
New video on the Neo Geo! th-cam.com/video/Lh77KKss4Hk/w-d-xo.html
The TG16, which was created to challenge the NES, was a magical piece of hardware that unfortunately was overlooked by most North Americans.
Nintendo of America's stranglehold on the 80s & 90s video games industry made it almost impossible for competitors (such as Sega & NEC) to achieve success.
I miss my tg 16. My brother took mine to college without asking. Had around 20 games. It magically vanished probably for beer money.
Dang, someone else here in another comment said their brother took theirs as well. That sucks, man.
No-one in my capital city carried any TG-16 games and I was stuck with Kieth Courage until emulation creeped into my life...e-m-u-l-a-t-i-o-n...aaaaaagggghh...
The snes was also not a true 16-bit console, could you make a video about that?
didnt sf2ce on pc-engine have an enhancement chip by way of it being a memory-mapper-chip on the bulker rom-card
Yeah I think it did, but that was due to it using a non-standard size for the Hucard - 20 megabits, or 2.5 megabytes. It needed the memory mapper because the console only had 2 megabytes of address space. Most other games capped out at 8 megabits, or 1 megabyte in size.
Doesnt the Super CD card add additional RAM as well?
Yes it does and the Arcade card adds even more making neo geo ports quite good
Pc engine was officialy distributed in France by Sodipeng man....
NEC didn't technically officially release it in France and Sodipeng never had an official arrangement with them. What Sodipeng actually did was grey import Japanese PC Engine models and distribute them with French instructions and appropriate AV cables to play on French TVs. The only European countries the console was officially released in were the UK, Spain and Portugal.
It's so funny. The PCE had a 7.16Mhz 6502 based cpu, designed by Hudson. Which is extremely fast for a 6502 style cpu. The SNES has the same 6502 base, but only 2.56Mhz. It has a 16bit ALU! But limited 16bit instructions, maybe 4, for multiplying, moving a decimal point, stuff like that. All completely pointless because the bus was 8bits. They pulled the same trick with the N64. The bus is memory speed and running games needs lots of it and for it to be fast.
SNES usually ran at 3.58MHz, but could slow down to 2.68MHz. There are other differences in the architecture, too, even though it's based on similar tech.
@@WhitePointerGaming opposite.
@@WhitePointerGaming I'm working on a complete knowledge of the system. I would be the only person with this knowledge.
@@WhitePointerGaming if it makes you feel better alot of the potential of the snes library was affected by politics, affecting quality.
"But limited 16bit instructions, maybe 4, for multiplying, moving a decimal point, stuff like that. All completely pointless because the bus was 8bits."
I swear, where do people come up with this stuff. That is 100% not correct at all. And the N64 has nothing in common with the SNES.
Would not be the Master System or Mark III the first console to have the scanline counter?
It would. It does have a built-in scanline interrupt system.. but you can't change the Y scroll on the master system.. which makes it more limiting. Even the NES, with external interrupts (and without) could change the Y scroll position. The SMS also struggles with handling lots of scanline IRQs, where as the PCE high clock speed is pretty much made for that sort of thing (even more efficient than 68k doing scanline interrupts.. which is why Sega opt'd for a VDP scroll memory implementation.. and hDMA for snes).
@@TurboXray can you please elaborate that last part of MD's and SNES' approaches? Thanks!
Yes, I say that the TG-16 was ONE of the first ;) I acknowledge the SMS to be the first one in this video: th-cam.com/video/PpdreiX_UFM/w-d-xo.html
@@kwkfortythree39 Mostly that lots of interrupts means lot of overhead for context switching in a frame. This is very true for the 68k cpu, because the call takes longer than most processors and more registers need to be saved, etc. So it makes more sense to put things into tables which the device (VDP) can just read out and apply on whatever basis (scanline, 8 pixel block, etc).
The SNES cpu is a fast context switching design for interrupts, unlike the 68k, but the lower clock speed means it's relatively more taxing. Plus, the SNES has a lot more registers it needs to update per scanline for effects compred to either the MD or PCE, so the hDMA is a really fast way to get data to those registers quickly (timing matters too).
Don't get me wrong, the MD and SNES have the option to do scanline interrupts too - it's just rarely used because there are much faster/better methods (VDP tables or hDMA tables).
On the MD, a couple of things can only be done via scanline interrupts (color changes, or changing the v scroll table mid screen, etc).
On the SNES, it's sometimes faster to use scanline interrupts than hDMA if you're not using that many - but this rare. And like the MD, there are a few super rare effects that can only be done via scanline interrupts (but these are for demoscene type FX).
But in general, both the MD and SNES were designed with a newer approach/design-philosophy than simply using scanline interrupts via the cpu.
Nice overview of the game tricks!
The PCE was a lot more powerful than first thought- it can chuck around sprites more similar to a NeoGeo, so it's possible to create an entire background layer with large sprites on top:
th-cam.com/video/kU7myUxemZg/w-d-xo.html
Interestingly, the soundchip can be better than the Megadrive and Snes in that it has cleaner pcm playback.
Another sprite capability is rotation and some scaling:
th-cam.com/video/APmUEbIE04A/w-d-xo.html
Colour is the main strength of the VDP though:
th-cam.com/video/JMIDJEvTH8Q/w-d-xo.html
The cpu is actually quite powerful though, and could do comparable 3D:
th-cam.com/video/Sp_r369-9_4/w-d-xo.html
The TG-16/PCE could not do sprite rotation and scaling, not even the stock SNES could do that. That video you linked to is running on the SuperGrafx, an attempted upgraded follow-up to the PCE that was backwards compatible, but was its own thing (with only around 6 games ever made specifically for it). Despite that it's still not a proper hardware rotation, they have just been animated to rotate, similar to how Sonic 1's bonus stages were done.
Same story with the 3D demo you show, that's once again running on the SuperGrafx. So don't confuse the SuperGrafx with the original PCE/TG-16.
@@WhitePointerGaming I didn't say hardware rotation and scaling. It's likely that this technique is similar to the Sonic1 bonus stages, so the fact that's It's shown on the supergrafx doesn't mean it can't be done on the PC engine. Similarly for polygons which are typically cpu bound- the supergrafx has the same cpu so polygons should perform identically?
The supergrafx can do some clever effects with the two vdps that the pc engine can't, like transparency
th-cam.com/video/75IdGO1I1o4/w-d-xo.htmlsi=bqhwt1F8Rex32-LL
Im simple. Someone posts Turbo content i click sub.
Thanks for the sub! :)
The snes was also not true 16-bit, you should make a video about that.
Hey some huge spoilers for you because you don't seem to know... basically the TRUE reason why the NEC Turbo GraFX 16 failed in North America is because Hudson Soft and NEC headquarters in Japan entrusted the subsidiary branch (a subsidiary branch is NOT the headquarters of a company and can never be... this is harsh lesson to Sega Genesis fanboys) to launch the NEC PC-Engine in North America by 1988 however the subsidiary branch management decided that the name "PC-Engine" needed to be changed and that the plastic shell design also needed to be changed which by all accounts required an entire YEAR wasted doing that... then what sealed the doom of the NEC Turbo GraFX 16 was the fact and ONLY fact that will make sense in that again the subsidiary branch were apparently looking at the sales numbers they could potentially estimate for the U.S.A. (btw there is a problem of subsidiary branches back then minus Nintendo of America of completely ignoring Mexico and barely making a presence in Canada and French Quebec so when you take those two regions where middle class wealthy people existed and were technology literate and if the marketing and distribution was very subpar then that will translate to major problems later) which means the fifty states of the Union and could also use the additional territories but back then being that NEC Turbo GraFX 16 was new and that NEC America had to overcome themselves instead of doing proper research, apparently they felt too confident that they could reach a particular sales number of units sold in a year's time frame and they just decided to order something like 700,000 TG16s for the launch in 1989 which apparently makes it clear that the NEC America management staff were convinced that they were actually going to sell that many units at $200 dollars a pop.. eh ... just because?
Therefore a clueless American public and quite possibly snubbed Canada and Mexico... nevermind that even in 1989 it was not easy for all fifty states and towns within to have retail stores to buy a Nintendo NES even though Nintendo had the advantage of building distribution relations earlier on. Therefore we can look back and confirm that many of the shipped TG16 units simply sat in stores while some indeed sold but the proportion of units sold to the 700k number was disproportionate during the first couple of months which means that when these TG16s were just sitting there in store shelves during 1990 year that they were becoming a loss to the retail shops who were convinced to order them so when new shipments were available for more units to order, most of those retail stores opted not to order more TG16s.
Then combine that with the then rising EGM magazine article with data that was alleged to have been supplied by then Sega of America's management staff who later made a special contract deal with the EGM publisher to make an additional official Sega quarterly publication (Sega Force) and the then rising hardcore gamers who were teenagers rising into young adult gamers and the remaining arcade and Atari gamers who had been gaming since the early 1980s and were still amazed by and interested in arcade and the newer tech from Sega and NEC and Nintendo and as such an image that somehow the TG16 marketing was lying became a thing... however that is a minor issue.. the real problem was the NEC America management being too over confident in how many units to order and ship which is also the SAME problem faced by Michael Katz who was the new manager hired by Sega headquarters in Japan to be the main manager of Sega of America (a subsidiary branch) and according to some old numbers it was said that Michael Katz's marketing team were confident that they could sell between probably 700k and one million Sega Genesis systems and note that the big Sega Genesis package in 1989 included two gamepads, Altered Beast ROM Cartridge and the Sega Genesis system (the Sega MegaDrive because again Sega of America's management had some weird ideas even though they failed to market the Sega Master System and decided they did not like the MegaDrive name so they went through several name changes until they settled on Genesis and most likely also WASTED almost an entire year where a North American MegaDrive launch could have happened by December 1988 to even say February 1989... but more important is that back then the Japanese 1988 launch MegaDrive shipped with one gamepad and no game for roughly $210 USD equivalent in 1988 and by 1989 SoA was selling the Sega Genesis with an additional gamepad and a free game for $190 USD which tells us that they were losing money giving a free game and gamepad so if a certain number of units were not reached then they could not expect a percentage of one million buyers to buy additional game software which is a huge problem with the truest reasons why Sega of America's management led Sega as a brand and company down to bankrupcy.
Another problem that multiple people close to the situation(namely, people I knew at TTI, TZD, Icom, & WD) all said the same thing, that trying to get games from Japan was basically like pulling teeth. NEC of Japan shut down tons of games NEC of America wanted and then later Hudson Soft of Japan shot down TTI's game list.
Whatever truth there is in the whole Mortal Kombat for TurboGrafx-CD debacle is some evidence of that, the Japanese branch shooting down the idea of Americans wanting fighting games.
Plus, Electronic Arts giving NEC America the finger I think didn't help because I think sports games at least in North America were big time. Very few sports games came out for the tg16, and none other than maybe Champions forever boxing and Andre Panza kickboxing had real people in them. It was always made up teams and players of the few games that did come out. Supposedly when presenting the TG to various companies, a representative of Electronic Arts got upset when a representative of NEC said something along the lines of "Are you up to the challenge" if making games for the TG. Very bizarre, I can't imagine any sea was trying to be a jerk, but EA allegedly took it as such.
However I did recently uncover that EA did have a deal to release tons of games in Japan for the PCE in a joint venture with Victor Musical Industries.
However, only one game(Ferrari Formula One) was named specifically and it was pushed back and eventually canceled. I haven't yet figured out what happened between that joint venture. In one of the articles I found, it mentioned some ridiculous number of games they wanted to port over mainly from the Amiga, something like 150 games. Which obviously never happened.
John Madden did eventually come out but that was a completely separate thing done by Hudson Soft, not Victor Musical. Possibly one game that does have a connection is Shadow of the Beast which was released for some consoles by Electronic Arts but then the PCE version in Japan was released by Victor Musical. But I can only speculate.
Actually it was an 8bit machine as you said. But SNES is 8bit too. The databus is 8bit. With that in mind, if snes is a 16bit machine cause its cpu is 16bit internally, then the megadrive is 32bit...
68k has a 24 bit address bus. I think it is shocking that Motorola did not offer a 68EC10 by 1984. So does the 68k need two cycles to put a register on the address bus? Or do the 8 address registers actually sit on a 24bit bus? Also MUL is so bad on 68k. At least after the first 3d games on AtariSt, Motorola should have improved fixed.point math .
@@ArneChristianRosenfeldt 24bit address is correct, but it is for the amount of RAM that the system can see. Actually is 23bit with the last bit acting as even/odd but yes, 16MB of RAM. As for the EC version, I think it is pointless as the MMU unit on the 010 was external. 2 cycles indeed.
@@104d_3rr0r_vincea special case would be to write a single byte. Then somehow the 24 bits need to be routed out of the address register to to the (25) pins. Even N64 games and Quake on PC ignored the MMU.
I just think it is so weird how Intel included so many queues in their 8086 and 8088, but 68k has fixed timing like 8-bits or RISC. Patents? Queues are needed to really saturate memory and ALU.
The data bus has nothing to do with it. If any of these machines had a super hi-speed 1bit data bus.. it wouldn't make them 1bit systems. That's ridiculous. What makes the PCE "8bit" is that the CPU registers are.. 8bit. The SNES is 16bit because the processor registers ARE 16bit. And yes, the 68k feels NO different than if the ALU was 32bit.. because all the registers are 32bit and support full 32bit operations!
I have no idea why people keep focusing on the data bus. Clearly don't have an understanding of what actually matters.
@@TurboXray So can it send 16bit chunks at a time? If it just sends 2x8 then this is the definition of bottleneck. The exact thing happens to the 68000. If you are doing 32bit calculations, you need 12 cycles instead of 4.
Boycott of 50 Hz flicker is the only right way. PcEngine can output RGB on the expansion port without modifications inside. So no need to call that NTSC .
The RGB output is NTSC spec though. It has no option for 50hz frame timings.
@@TurboXray and this okay as I have learned that many TV in PAL land accept 60Hz RGB ( RGB only , no composite ). Vertical deflection is controlled by software
I loved, no LOVE Splatterhouse and Jacky Chan on the PC-Engine. Really remarkable games as well.
wow I always thought tg and genesis were like neck and neck hardware wise
Instead of it being a weak "16bit" machine,
I've always thought of the TG16 as the beefiest 8bit game console ever!