Live data from Hacker News

PC Engine CPU

jsgroth.dev

61–70 of 72 posts

Re: PC Engine CPU

#61
post #44
post #13

I didn't grow up with the PC Engine or TurboGrafx, but I did start getting into it after I got the MiSTer. I find that the unsuccessful [1] consoles are generally pretty bad. The 3DO and the Jaguar and CD-i are mostly pretty crappy, and while it can be fun to play for a novelty and you might even find one or two games that make it worth it, the vast majority of the time there's a reason that people don't seriously re…

Maybe they should have sold the TurboGrafx-16 in the US only with the CD add-on already built in, and one or two CD games included to set off the hardware price somewhat. That would have made them stand out versus SNES/Genesis.

CD drives were still expensive and a bit flakey at that point. It might have worked by packing in extra games.

Sega of America was just really good at understanding the US market.

Sega did a US launch (August 29, 1989) of the Genesis 9 months after the JP launch. They had EA releasing sports games on the console in 1990.

The TG-16 came out in 1987 in JP but they waited 1 year 10 months to do a US release, so it came out after the Genesis. They didn't get any US developers on board.

A 1988 release of the TG-16 combined with some decent sports games probably would have been a success.

Re: PC Engine CPU

#62
post #4

The PC Engine's CPU is probably its strongest aspect, Hudson did a great job here. Going with a really fast 8-bit CPU makes much more sense than Nintendo's choice of going with a slow 16-bit CPU, especially when the screen is 256 pixels wide so most of the calculations a game would be doing are only 8 bits anyway. Even when you have to do 16-bit calculations, the SNES CPU still has an 8-bit data bus so it doesn't hav…

As someone who owns a SNES and a TG-16, I think I disagree. The TG-16 graphics really pop compared to the SNES. The SNES can only render 256 simultaneous colours. The TG-16 could do twice that at 512. Its video processor was also full 16-bit. I’m not sure where you’re getting that the video was the weakness of the TG-16. At the time, that was the Turbografx’s whole claim to fame in that it was superior graphically to…

Its big weakness is that they didn't realize how much multilayered backgrounds made things pop.

The sprites look really good, but the single background layer makes things look flat compared to the SNES / Genesis. Devs started working around that by updating some of the background tiles on each frame or using some of the sprites.

The SNES also could do layer blending effects. So while all of the input data could only be 256 colours, the PPU was spitting out a high colour signal after the effects were applied.

Re: PC Engine CPU

#63
post #43
post #3

Earlier quoted context omitted.

>"haha, it was the TurboGrafx-16 but its CPU was 8-bit" Amusingly, TurboGrafx-16 is a US-specific name, so is the huge shell. In Japan, the console was called PC Engine and was really compact. Later revised as CoreGrafx and CoreGrafx II, both still the same fundamental hardware. I own the later variant. Very solid little box that sips power and produces stable a/v output.

When I was a teenager, I had a hobby of importing Japanese gaming consoles and video games. I had a PC Engine and a Super Famicom (well before the SNES made it to the US!). They both had cosmetic differences but I thought that the Japanese versions of both would be more attractive to US customers. I'm not sure why they shipped different casings like they did.

For the SNES, from what I heard it was partially because with the flat topped NES, Nintendo of America got a lot of repairs from kids spilling soda or whatever on the NES they were using as a table. For the SNES, they deliberately made it harder to that.

Re: PC Engine CPU

#64
post #3

Earlier quoted context omitted.

>"haha, it was the TurboGrafx-16 but its CPU was 8-bit" Amusingly, TurboGrafx-16 is a US-specific name, so is the huge shell. In Japan, the console was called PC Engine and was really compact. Later revised as CoreGrafx and CoreGrafx II, both still the same fundamental hardware. I own the later variant. Very solid little box that sips power and produces stable a/v output.

I've got a TurboExpress. Recapped, it's a great little handheld. Screen is adequate for the era (though I've seen upgrades). My favourite 6502-based handheld is still the Atari Lynx, but this is close.

I have a lynx II, and it is a brick (huge! heavy!).

Re: PC Engine CPU

#65
post #25

Earlier quoted context omitted.

N also took the opportunity to remove the lockout chip, since the system came out so late in the lifecycle and they were largely successful at stamping out unlicensed releases. The Japanese version of that redesign also got compatibility with existing SNES Multi-AV cables (at least the composite ones, the AV Famicom didn't output s-video) while the US version was RF-only (and AFAIK is worse for jailbars than any prev…

They described the 1st NES changes from 1st Famicom.

Oops, I misread and thought they were talking about the re-redesign near the end of the NES' lifetime.

Re: PC Engine CPU

#66

Earlier quoted context omitted.

I think they tried to sell it to Nintendo at some point.

According to Wikipedia, Hudson originally approached Sharp before pitching the idea to NEC. While Sharp was enthusiastic and agreed that it had great commercial potential, the deal ultimately fell through. The deal-breaker was Sharp’s deep relationship with Nintendo at the time. Apparently, developing a console with Hudson’s CPU was seen as something that would have jeopardized their partnership with Nintendo. What S…

The Japanese version of that TV used an internal RGB connection with an RGB PPU, making it as clear and sharp as Nintendo's Famicom-based arcade hardware.

The US version of that TV used composite internally

Re: PC Engine CPU

#67

The PC Engine CPU is highly underrated. People like to go "haha, it was the TurboGrafx-16 but its CPU was 8-bit" like that makes it a joke, but that clock speed boost on top of the 6502 architecture is a big deal. (The S-CPU on the SNES still has an 8-bit data bus too, so the 16-bit advantage isn't as strong as it seems) The Arcade Card add-on was designed specifically around using the transfer instructions to rapidl…

The first time I used an IBM PC I was so disappointed. On every aspect of the interaction my Apple II would run rings about it. Character IO via the BIOS on CGA was glacial to avoid writing to VRAM and getting snow, and an 8088 at 4.77 MHz was not nearly 4.77 times faster than the 6502 at 1 MHz - in fact, it felt slower.

It’s not that the 8088 was a horrible CPU - it was a pretty ok one - it’s just that the 6502 was a beast of a CPU.

Re: PC Engine CPU

#68
post #59

The PC Engine CPU is highly underrated. People like to go "haha, it was the TurboGrafx-16 but its CPU was 8-bit" like that makes it a joke, but that clock speed boost on top of the 6502 architecture is a big deal. (The S-CPU on the SNES still has an 8-bit data bus too, so the 16-bit advantage isn't as strong as it seems) The Arcade Card add-on was designed specifically around using the transfer instructions to rapidl…

The PCE (and by extension, TG16) proved that outside of games that relied on high processing speed (3D games like Elite, or sports games), 8-bit CPUs could give every bit as compelling an experience as 16-bit chips. Wonder what a good programmer could do with a modern 6502-based ISA clocked at 20+ MHz but otherwise identical hardware to . Imagine being able to hit I/O registers on every single hardware cycle because…

Dream big. Imagine what we could do with a 5 GHz 6502.

Of course, the memory would need to be on the same die to be able to function at that speed, but my Apple //e had a full megabyte of RAM (in addition to the 64 on the motherboard) and, IIRC, Apple’s bank switching scheme could accommodate up to 16 megs. The chip would be mostly SRAM.

Talking to anything outside the chip would slow things down considerably though, and using one in place of a real 6502 would be comically weird. It’d feel like a machine that spends 99.999999% of the time waiting for IO.

Which, amusingly, feels the opposite of mainframes, where the machine appears to never have to wait for IO.

Re: PC Engine CPU

#69
post #68
post #59

Earlier quoted context omitted.

The PCE (and by extension, TG16) proved that outside of games that relied on high processing speed (3D games like Elite, or sports games), 8-bit CPUs could give every bit as compelling an experience as 16-bit chips. Wonder what a good programmer could do with a modern 6502-based ISA clocked at 20+ MHz but otherwise identical hardware to . Imagine being able to hit I/O registers on every single hardware cycle because…

Dream big. Imagine what we could do with a 5 GHz 6502. Of course, the memory would need to be on the same die to be able to function at that speed, but my Apple //e had a full megabyte of RAM (in addition to the 64 on the motherboard) and, IIRC, Apple’s bank switching scheme could accommodate up to 16 megs. The chip would be mostly SRAM. Talking to anything outside the chip would slow things down considerably though,…

I think that would be approaching diminishing returns long before getting to 5GHz. If the only real requirement is "you can write a new value to any register on every cycle" then you need nowhere near that level of overshooting. 20MHz might not be enough (I only mentioned that value because there is an actual commercial product, the SuperCPU, that brought 20MHz 65816 to the C64/128), but 48 or 50MHz might fully cover that. Maybe 60MHz if you want to do other processing on lines where you have to slow down to communicate with the rest of the hardware (which requires slowing down to bus speed - even the base-level C128 could not use 2MHz mode with the VIC-IIe display enabled, as the extra 2MHz cycles stomped on the bus, making the VIC-II display what was essentially open bus).

Re: PC Engine CPU

#70
post #69
post #68

Earlier quoted context omitted.

Dream big. Imagine what we could do with a 5 GHz 6502. Of course, the memory would need to be on the same die to be able to function at that speed, but my Apple //e had a full megabyte of RAM (in addition to the 64 on the motherboard) and, IIRC, Apple’s bank switching scheme could accommodate up to 16 megs. The chip would be mostly SRAM. Talking to anything outside the chip would slow things down considerably though,…

I think that would be approaching diminishing returns long before getting to 5GHz. If the only real requirement is "you can write a new value to any register on every cycle" then you need nowhere near that level of overshooting. 20MHz might not be enough (I only mentioned that value because there is an actual commercial product, the SuperCPU, that brought 20MHz 65816 to the C64/128), but 48 or 50MHz might fully cover…

Mine was never an exercise in practicality - it would be ridiculous to implement, and complete overkill.

OTOH, I wonder if someone would build something like this - a 6502/65816 with lots of SRAM and system-bus compatible timings - using the cheapest commercially available foundry, how much could it cost.

Post reply on HN