The N64 was a pretty badly designed machine, unfortunately. Both it's GPU and CPU were quite performant, but was limited to 4 KB of texture memory total, which is not a lot. To make things worse, the memory architecture overall was just flat out bad and hamstrung the console's performance. Similar to the game consoles we have today, the N64 has a unified memory architecture where there is only one pool of memory that is shared by the CPU and GPU. This is generally a good thing for game programming, but the n64 is a special kind of beast; unlike more straightforward designs, the CPU isn't actually able to access memory directly. The GPU controls all memory access and data has to be loaded into the CPU via the GPU, and while the memory in the n64 was fairly fast, the link between the gpu and the cpu was slow as molasses.
This design has just never made any sense to me. The GPU isn't fully programmable like the GPUs we have today, it has to be loaded up with work by the CPU, but the CPU is constantly getting stalled because it can't get to memory fast enough. To make things worse, the CPU was pretty deeply pipelined and suffered knock-on performance degradation any time it was stalled due to being memory starved.
While it was true that the CPU didn't directly connect to the RAM that's not actually insane and mostly a function of their chosen CPU (MIPS R4000 series) not using the same bus interface as their chosen RAM (early version of RAMBUS) so the GPU acted as bus master, instead of fabbing two custom chips and in any case this is actually faster than most multi-master setups would be at the time. The GPU needs faster access anyway because it simply exchanges more data, they did correctly recognize that (also you absolutely cannot miss pixel scanout on a CRT). Modern GPUs have an order of magnitude more bandwidth to RAM than their CPUs do.
Their CPU additionally had a (for the time) fairly generous 24 kB cache which means they (hopefully) only needed to burst lines. This + the pipeline was pretty much the only reason it worked as well as it did.
Additionally it was actually quite a capable little GPU, a fully programmable frontend coupled to a somewhat programmable backend writing to a full Z-buffered framebuffer
For reference the block diagram of the N64 looks something like
CPU <-> GPU MUX <-> RDRAM
|
RSP<->RDP
There were significant flaws though
- Not enough RSP memory. The RSP handled audio and vertex transform, acting as the graphics frontend. It had 4k of instruction and another 4k of data memory. Tasks had to be constantly reloaded because 4k was just not enough code memory to do all the things and each time there needed to be a synchronization step
- Tiny texture memory. 4k is just flat not enough. This forces games to either have terrible textures or use more bandwidth loading textures constantly. It also forces synchronization whenever you have to upload new textures
- GPU / CPU cache problems. The CPU had a cache, but it had to be cleaned before the GPU could access its buffers. This is still true today of course (though Intel remains committed to their fully cache-coherent memory model) but it was worse back then because of
- Memory latency. RDRAM was not a great choice, there's a reason it didn't win after all. RDRAM had significantly higher latencies than SDRAM and while it could then do a decent burst, the CPU cache lines were only 32 bytes instruction or 16 bytes data whereas RDRAM could burst up to 256 thereby leaving a bunch of theoretical bandwidth on the table. This is further exacerbated by
- MIPS being MIPS. MIPS is weird. The CPU chosen was actually a full 64-bit CPU with a full 64-bit address space... because reasons. Additionally it operated with a TLB and a virtual memory system. MIPS being MIPS though they used a software managed TLB, though I'm almost 100% sure they always used the address range that bypassed all of this crap. It was still a RISC instruction set though which means comparatively big instructions in a time when the compiler wasn't so great at using lots of registers that well. Plus RISC instruction sets tend to generate larger code footprints and all the 64-bit stuff was mostly a trap
- SGI designed the GPU and they wrote the initial GPU microcode. SGI being graphics people wrote things to be accurate, not fast. A few studios eventually did custom microcode but most couldn't
- Linear framebuffers, simple GPU hardware, framebuffer in common RAM means lots and lots of wasted bandwidth. A thin vertical triangle is a nightmare for this system to draw efficiently
Ultimately though the killer was this. They connected their RAM chips in serial instead of parallel. There was a 9-bit data bus (the GPU used the 9th bit) @ 250 MHZ. While it was DDR this still caps at 500 MB/s, and the GPU eats most of it. It doesn't even matter what the effective bandwidth to the CPU is, whether you starve your CPU or GPU you're not completing your frame on time. If they instead did parallel access it probably wouldn't even have cost that much more but GPU transfers would finish in half the time giving CPU transfers lower latency and everything would have worked much better
The N64 was a pretty badly designed machine, unfortunately. Both it's GPU and CPU were quite performant, but was limited to 4 KB of texture memory total, which is not a lot. To make things worse, the memory architecture overall was just flat out bad and hamstrung the console's performance. Similar to the game consoles we have today, the N64 has a unified memory architecture where there is only one pool of memory that is shared by the CPU and GPU. This is generally a good thing for game programming, but the n64 is a special kind of beast; unlike more straightforward designs, the CPU isn't actually able to access memory directly. The GPU controls all memory access and data has to be loaded into the CPU via the GPU, and while the memory in the n64 was fairly fast, the link between the gpu and the cpu was slow as molasses.
This design has just never made any sense to me. The GPU isn't fully programmable like the GPUs we have today, it has to be loaded up with work by the CPU, but the CPU is constantly getting stalled because it can't get to memory fast enough. To make things worse, the CPU was pretty deeply pipelined and suffered knock-on performance degradation any time it was stalled due to being memory starved.
While it was true that the CPU didn't directly connect to the RAM that's not actually insane and mostly a function of their chosen CPU (MIPS R4000 series) not using the same bus interface as their chosen RAM (early version of RAMBUS) so the GPU acted as bus master, instead of fabbing two custom chips and in any case this is actually faster than most multi-master setups would be at the time. The GPU needs faster access anyway because it simply exchanges more data, they did correctly recognize that (also you absolutely cannot miss pixel scanout on a CRT). Modern GPUs have an order of magnitude more bandwidth to RAM than their CPUs do.
Their CPU additionally had a (for the time) fairly generous 24 kB cache which means they (hopefully) only needed to burst lines. This + the pipeline was pretty much the only reason it worked as well as it did.
Additionally it was actually quite a capable little GPU, a fully programmable frontend coupled to a somewhat programmable backend writing to a full Z-buffered framebuffer
For reference the block diagram of the N64 looks something like
CPU <-> GPU MUX <-> RDRAM
|
RSP<->RDP
There were significant flaws though
- Not enough RSP memory. The RSP handled audio and vertex transform, acting as the graphics frontend. It had 4k of instruction and another 4k of data memory. Tasks had to be constantly reloaded because 4k was just not enough code memory to do all the things and each time there needed to be a synchronization step
- Tiny texture memory. 4k is just flat not enough. This forces games to either have terrible textures or use more bandwidth loading textures constantly. It also forces synchronization whenever you have to upload new textures
- GPU / CPU cache problems. The CPU had a cache, but it had to be cleaned before the GPU could access its buffers. This is still true today of course (though Intel remains committed to their fully cache-coherent memory model) but it was worse back then because of
- Memory latency. RDRAM was not a great choice, there's a reason it didn't win after all. RDRAM had significantly higher latencies than SDRAM and while it could then do a decent burst, the CPU cache lines were only 32 bytes instruction or 16 bytes data whereas RDRAM could burst up to 256 thereby leaving a bunch of theoretical bandwidth on the table. This is further exacerbated by
- MIPS being MIPS. MIPS is weird. The CPU chosen was actually a full 64-bit CPU with a full 64-bit address space... because reasons. Additionally it operated with a TLB and a virtual memory system. MIPS being MIPS though they used a software managed TLB, though I'm almost 100% sure they always used the address range that bypassed all of this crap. It was still a RISC instruction set though which means comparatively big instructions in a time when the compiler wasn't so great at using lots of registers that well. Plus RISC instruction sets tend to generate larger code footprints and all the 64-bit stuff was mostly a trap
- SGI designed the GPU and they wrote the initial GPU microcode. SGI being graphics people wrote things to be accurate, not fast. A few studios eventually did custom microcode but most couldn't
- Linear framebuffers, simple GPU hardware, framebuffer in common RAM means lots and lots of wasted bandwidth. A thin vertical triangle is a nightmare for this system to draw efficiently
Ultimately though the killer was this. They connected their RAM chips in serial instead of parallel. There was a 9-bit data bus (the GPU used the 9th bit) @ 250 MHZ. While it was DDR this still caps at 500 MB/s, and the GPU eats most of it. It doesn't even matter what the effective bandwidth to the CPU is, whether you starve your CPU or GPU you're not completing your frame on time. If they instead did parallel access it probably wouldn't even have cost that much more but GPU transfers would finish in half the time giving CPU transfers lower latency and everything would have worked much better
It was designed to be chained sure, but you can run two in parallel if you want to. Either completely separated with the CPU being able to access only one and the GPU being able to either do one exclusively or share the other, or with a little controller to synchronize them into a 16-bit bus. It's just a matter of stalling until the slower chip finishes
I installed Dragon's Lair 3D in Windows 10 and it did not run. I think it is the DRM. I tried to download a cracked version of the exe, but it is getting detected as a virus.
So, I guess I will try installing it in my WinXP VM.
Don't trust the cracked exe if is showing up as a virus.
So I know it's only one generation back, but I got an early Father's Day gift today. We were shopping at a local game/music chain and this had just been traded in. My son knew I had been thinking about rebuying something in the 3ds family, so this came home with us.
We even had enough frequent shopper points to get it half off - so instead of $60 we paid $30! I called Nintendo and filled out the form to get my old NNID assigned to it and magically have over 100 games to redownload! I really love the color too.
What was the online performance like on the Dreamcast? How did people play Phantasy Star smoothly with a 56K modem?
Seganet was very fast for a dialup ISP, it was designed to prioritize latency over throughput so it felt faster compared to using your own dialup ISP (which was supported). It also helped that games were designed around dialup modem speeds.
Since they were limited to four players Phantasy Star Online played very smoothly, and Quake 3 was decent but if you were in a server with an LPB they would have a significant advantage (basically a BBA owner or a PC player). Unreal Tournament was a lot less stable, but it had 8 player servers. I heard 4x4 Evo ran well in multiplayer, and Alien Front Online ran well enough to support rudimentary voice chat.
Your average 56k dialup connection was nowhere near actual 56k speeds, so DC games were designed to run well on extremely slow connections. I'm not sure if they ever found a way around it, but setting up a DreamPI connection (using a RPI to fake a dialup network to connect a Dreamcast to your home broadband internet connection) used to max out at a consistent 33.6k on a DC's 56k modem due to hardware quirks, and most games ran perfectly fine with it.
The way the Sega Saturn Netlink handled online play over a 28.8k dialup connection (or a measly 14.4k connection using the XBand modem in Japan) was to avoid using the internet altogether. Instead, if you want to play against someone else in a multiplayer game, your Netlink would literally make a direct phonecall to the other player's Netlink, which would answer the call and then the connection was made. This made connection speeds very fast, but limited games to only two players. In fact, setting up a VOIP to play Netlink games today will generally have a faster/more stable connection by running at 14.4k (either by using the Japanese versions or patching the US versions of games to connect at the lower speed) as opposed to 28.8k, and performance is decent enough that you can play something like the Japanese version of Virtua Fighter Remix without having a ton of lag.
I thought the only reason to take your Dreamcast online was to chat with your friends on IRC using the web browser disc and the keyboard you got for Typing of the Dead.
I thought the only reason to take your Dreamcast online was to chat with your friends on IRC using the web browser disc and the keyboard you got for Typing of the Dead.
Phantasy Star Online was the real hotness, I gathered. Or demos, maybe.
Whoa. Lots of hate for the latest release of Duke 3D. Partially because they took down Megaton.
Really, that last release sounded interesting.
There is a way to get all the old expansions, but I am not telling.
I bet they killed the Multiplayer for Megaton too.
I thought the only reason to take your Dreamcast online was to chat with your friends on IRC using the web browser disc and the keyboard you got for Typing of the Dead.
Phantasy Star Online was the real hotness, I gathered. Or demos, maybe.
I played a stupid amount of PSO. It was Diablo with more of a direct control thing. Definitely doesn't hold up today, but it was fantastic.
They are doing this annoying thing when they port old games. They clip the title screen off and replace it with fancy menu. They did that with Zombie Ate my Neighbors and Ghoul Patrol.
Limited Run is reprinting carts of those. Hopefully, they kept the original title screens and menus.
It has been almost a whole year and still they have not delivered those cartridges.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
It has been almost a whole year and still they have not delivered those cartridges.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
It has been almost a whole year and still they have not delivered those cartridges.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
Just stop supporting LRG, problem solved.
They have cool stuff, but it gets ridiculous. There is no way it takes that long. They just program an assembly line and churn this stuff out.
0
Options
cj iwakuraThe Rhythm RegentBears The Name FreedomRegistered Userregular
It has been almost a whole year and still they have not delivered those cartridges.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
Just stop supporting LRG, problem solved.
They have cool stuff, but it gets ridiculous. There is no way it takes that long. They just program an assembly line and churn this stuff out.
I wouldn't say it's that easy, since they almost assuredly outsource everything. I will say the quality and the cost of what they include has become largely a lot of junk.
I like artbooks and OSTs. I don't care about fancy cases mimicking things.
+1
Options
Handsome CostanzaAsk me about 8bitdoRIP Iwata-sanRegistered Userregular
It has been almost a whole year and still they have not delivered those cartridges.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
Just stop supporting LRG, problem solved.
They have cool stuff, but it gets ridiculous. There is no way it takes that long. They just program an assembly line and churn this stuff out.
Lol what? No it's not even remotely close to that easy. But I'm sure they're purposefully delaying releases for no reason just so people can get mad at them on the internet, that's a solid theory right there.
It has been almost a whole year and still they have not delivered those cartridges.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
Just stop supporting LRG, problem solved.
They have cool stuff, but it gets ridiculous. There is no way it takes that long. They just program an assembly line and churn this stuff out.
I wouldn't say it's that easy, since they almost assuredly outsource everything. I will say the quality and the cost of what they include has become largely a lot of junk.
I like artbooks and OSTs. I don't care about fancy cases mimicking things.
I've ordered once from Limited Run Games. Took 8 months for the physical version of Axiom Verge 2 to arrive (Oct 2021 to this month, June 2022). They do say that after close of sale, it takes a release 4-5 months to make it out (which I did not know until after I did the preorder), but it definitely took a bit longer than that. So, it comes down to if you're willing to wait or not. Apparently they are frequently late, from blurbs online.
Posts
https://en.wikipedia.org/wiki/Legends_of_Valour
While it was true that the CPU didn't directly connect to the RAM that's not actually insane and mostly a function of their chosen CPU (MIPS R4000 series) not using the same bus interface as their chosen RAM (early version of RAMBUS) so the GPU acted as bus master, instead of fabbing two custom chips and in any case this is actually faster than most multi-master setups would be at the time. The GPU needs faster access anyway because it simply exchanges more data, they did correctly recognize that (also you absolutely cannot miss pixel scanout on a CRT). Modern GPUs have an order of magnitude more bandwidth to RAM than their CPUs do.
Their CPU additionally had a (for the time) fairly generous 24 kB cache which means they (hopefully) only needed to burst lines. This + the pipeline was pretty much the only reason it worked as well as it did.
Additionally it was actually quite a capable little GPU, a fully programmable frontend coupled to a somewhat programmable backend writing to a full Z-buffered framebuffer
For reference the block diagram of the N64 looks something like
CPU <-> GPU MUX <-> RDRAM | RSP<->RDPThere were significant flaws though
- Not enough RSP memory. The RSP handled audio and vertex transform, acting as the graphics frontend. It had 4k of instruction and another 4k of data memory. Tasks had to be constantly reloaded because 4k was just not enough code memory to do all the things and each time there needed to be a synchronization step
- Tiny texture memory. 4k is just flat not enough. This forces games to either have terrible textures or use more bandwidth loading textures constantly. It also forces synchronization whenever you have to upload new textures
- GPU / CPU cache problems. The CPU had a cache, but it had to be cleaned before the GPU could access its buffers. This is still true today of course (though Intel remains committed to their fully cache-coherent memory model) but it was worse back then because of
- Memory latency. RDRAM was not a great choice, there's a reason it didn't win after all. RDRAM had significantly higher latencies than SDRAM and while it could then do a decent burst, the CPU cache lines were only 32 bytes instruction or 16 bytes data whereas RDRAM could burst up to 256 thereby leaving a bunch of theoretical bandwidth on the table. This is further exacerbated by
- MIPS being MIPS. MIPS is weird. The CPU chosen was actually a full 64-bit CPU with a full 64-bit address space... because reasons. Additionally it operated with a TLB and a virtual memory system. MIPS being MIPS though they used a software managed TLB, though I'm almost 100% sure they always used the address range that bypassed all of this crap. It was still a RISC instruction set though which means comparatively big instructions in a time when the compiler wasn't so great at using lots of registers that well. Plus RISC instruction sets tend to generate larger code footprints and all the 64-bit stuff was mostly a trap
- SGI designed the GPU and they wrote the initial GPU microcode. SGI being graphics people wrote things to be accurate, not fast. A few studios eventually did custom microcode but most couldn't
- Linear framebuffers, simple GPU hardware, framebuffer in common RAM means lots and lots of wasted bandwidth. A thin vertical triangle is a nightmare for this system to draw efficiently
Ultimately though the killer was this. They connected their RAM chips in serial instead of parallel. There was a 9-bit data bus (the GPU used the 9th bit) @ 250 MHZ. While it was DDR this still caps at 500 MB/s, and the GPU eats most of it. It doesn't even matter what the effective bandwidth to the CPU is, whether you starve your CPU or GPU you're not completing your frame on time. If they instead did parallel access it probably wouldn't even have cost that much more but GPU transfers would finish in half the time giving CPU transfers lower latency and everything would have worked much better
Here is Dragon's Lair 3D. The version that is actually a real game.
Well this one wasn't that bad.
I think RDRAM was serial only.
https://en.wikipedia.org/wiki/Acclaim_Studios_Austin
Remember when games had limited draw distance and fog?
Looks at Morrowind.
So, I guess I will try installing it in my WinXP VM.
Don't trust the cracked exe if is showing up as a virus.
We even had enough frequent shopper points to get it half off - so instead of $60 we paid $30! I called Nintendo and filled out the form to get my old NNID assigned to it and magically have over 100 games to redownload! I really love the color too.
What was the online performance like on the Dreamcast? How did people play Phantasy Star smoothly with a 56K modem?
Seganet was very fast for a dialup ISP, it was designed to prioritize latency over throughput so it felt faster compared to using your own dialup ISP (which was supported). It also helped that games were designed around dialup modem speeds.
Since they were limited to four players Phantasy Star Online played very smoothly, and Quake 3 was decent but if you were in a server with an LPB they would have a significant advantage (basically a BBA owner or a PC player). Unreal Tournament was a lot less stable, but it had 8 player servers. I heard 4x4 Evo ran well in multiplayer, and Alien Front Online ran well enough to support rudimentary voice chat.
Your average 56k dialup connection was nowhere near actual 56k speeds, so DC games were designed to run well on extremely slow connections. I'm not sure if they ever found a way around it, but setting up a DreamPI connection (using a RPI to fake a dialup network to connect a Dreamcast to your home broadband internet connection) used to max out at a consistent 33.6k on a DC's 56k modem due to hardware quirks, and most games ran perfectly fine with it.
The way the Sega Saturn Netlink handled online play over a 28.8k dialup connection (or a measly 14.4k connection using the XBand modem in Japan) was to avoid using the internet altogether. Instead, if you want to play against someone else in a multiplayer game, your Netlink would literally make a direct phonecall to the other player's Netlink, which would answer the call and then the connection was made. This made connection speeds very fast, but limited games to only two players. In fact, setting up a VOIP to play Netlink games today will generally have a faster/more stable connection by running at 14.4k (either by using the Japanese versions or patching the US versions of games to connect at the lower speed) as opposed to 28.8k, and performance is decent enough that you can play something like the Japanese version of Virtua Fighter Remix without having a ton of lag.
Phantasy Star Online was the real hotness, I gathered. Or demos, maybe.
Really, that last release sounded interesting.
There is a way to get all the old expansions, but I am not telling.
I bet they killed the Multiplayer for Megaton too.
Witty signature comment goes here...
wra
He is such a silly over the top character. They pretty much brought him as far as they could take him.
That kind of happened in Forever.
I played a stupid amount of PSO. It was Diablo with more of a direct control thing. Definitely doesn't hold up today, but it was fantastic.
I think she ends up wearing the same damn outfit in Inquisition.
https://www.pcgamer.com/xbox-bethesda-showcase-2022-time/
Steam | XBL
It was $55. There was a recent port and remake of them, but they clipped off the title screens. These are untouched.
Steam | XBL
Limited Run is reprinting carts of those. Hopefully, they kept the original title screens and menus.
They make whole seasons of tv shows in less than a year.
It is absurd. They cannot convince me it takes that long to make cartridges. They have a pipeline setup for that.
Just stop supporting LRG, problem solved.
They have cool stuff, but it gets ridiculous. There is no way it takes that long. They just program an assembly line and churn this stuff out.
I wouldn't say it's that easy, since they almost assuredly outsource everything. I will say the quality and the cost of what they include has become largely a lot of junk.
I like artbooks and OSTs. I don't care about fancy cases mimicking things.
Lol what? No it's not even remotely close to that easy. But I'm sure they're purposefully delaying releases for no reason just so people can get mad at them on the internet, that's a solid theory right there.
Resident 8bitdo expert.
Resident hybrid/flap cover expert.
Not one to advocate piracy, but these weird PS1 games are absurdly expensive now.
There's only a handful there I'm familiar with, but yeah, some of the awesome and relatively obscure games for the PS1 really are crazy money now.
Steam | XBL
I've ordered once from Limited Run Games. Took 8 months for the physical version of Axiom Verge 2 to arrive (Oct 2021 to this month, June 2022). They do say that after close of sale, it takes a release 4-5 months to make it out (which I did not know until after I did the preorder), but it definitely took a bit longer than that. So, it comes down to if you're willing to wait or not. Apparently they are frequently late, from blurbs online.