
Emulating a PlayStation 1 (PSX) Entirely with C# and .NET - LyalinDotCom
https://www.hanselman.com/blog/EmulatingAPlayStation1PSXEntirelyWithCAndNET.aspx
======
nineteen999
> We often hear Full Stack in the context of a complete distributed web
> application, but for many the stack goes down to the metal. This emulator
> literally boots up from the real BIOS of a Playstation and emulates the MIPS
> R3000A, a BUS to connect components, the CPU, the CD-ROM, and display.

As I say probably too often, the modern usage of "full stack" basically
equates to "iceberg tip".

~~~
alkonaut
"Full stack developer" is short for "Full stack _web_ developer". Outside of
web development it's rarely used.

For other areas, we usually talk about "Systems programming" or "Application
programming". I suppose the full stack there would be to do both?

~~~
nineteen999
It's just that outside web programming, very few developers/programmers I know
would refer to themselves as being able to program the "full stack",
presumably meaning from the ISA level up to database programming, GUI and
network programming etc etc. although there are plenty of people who can do
all these.

Even the omission of the word "web" as you have pointed out, seems to have the
smell of arrogance, as if web programming is all there is worth working on
these days. But the web programming world, IMHO, is full of this kind of CV
inflating jargon, lingo and buzzwords, whether it's "full stack", "Agile",
"devops" etc.

Obviously, there is an element of old man "get off my lawn" that I am
invoking. I am almost certainly projecting here, but it still grinds me the
wrong way.

------
userbinator
_Of course, that 's silly. Good C# can run at near-native speed given all the
work happening in the runtime/JITter, etc._

The keyword being "near". It's like all the "Java is fast" articles out there
--- in theory, you can write microbenchmarks that show your language is fast,
but in practice, everyone knows what it's really like.

Of course if you have a powerful enough CPU and enough RAM you could emulate
any system at a decent speed with any language[1], but I'm willing to bet that
if you ran this C# emulator on the best hardware from ~2000 (which is roughly
when the first PSX emulators appeared), and compared it to the (native) ones
that were around at that time, you'll see a _huge_ difference in performance.
I remember a 1GHz Pentium III with 256MB of RAM would've been sufficient for
those.

[1] The same "fast enough" justification being used to praise writing
applications in JavaScript and bundling them with an entire web browser:
[https://en.wikipedia.org/wiki/Wirth%27s_law](https://en.wikipedia.org/wiki/Wirth%27s_law)

~~~
alkonaut
So long as you write fast C#, C# is pretty fast. But you need to make C# that
effectively compiles (JIT's) to the same assembly as a C or C++ program would.
It's simply staying with a subset of C# that looks a lot like C.

It's really hard to do because you can't easily see when you pay for an
abstraction (is this foreach slower than a for loop? does it allocate an
enumerator? can it unroll? will this call allocate a heap array for its
params? Will this call be devirtualized?)

The "Burst compiler" in Unity takes it a step further: it restricts the
language to those things that are actually always fast.
[https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual...](https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual/index.html#burst-
user-guide)

I really wish the C# team could do something similar: add a fast AOT subset to
C#.

~~~
cm2187
I would have thought the problem with using C# for a game wouldn’t be so much
the execution speed (which should be pretty close to native) than the freezes
required for garbage collection.

~~~
alkonaut
Yes, that's one of the problems. So you want to have zero garbage collection.
That means you want zero garbage creation. That in turn means not allocating
on the heap in the game loop, and that's rather easy to avoid doing explicitly
(just don't use "new" for class types, for example!, use pooling and structs).
But C# makes it tricky because a lot of the BCL types allocate under the hood.
Some times even the compiler inserts allocatoins from syntax sugar (parameter
arrays for varargs). These are pitfalls that the Burst subset tries to solve.

------
tracker1
Hoping SH up-streamed a PR for the shift to .Net Core ... Looks like it's
using Winforms... Would be interesting to see the .Net core port, and then
shift from winforms to eto forms or something else cross platform.

~~~
yodon
Wow thanks for the pointer to Eto.Forms - cross platform Windows Forms
including Linux, OSX, and iOS (but not yet Android) is pretty awesome to hear
about

~~~
jsingleton
See also [https://avaloniaui.net/](https://avaloniaui.net/)

------
Hydraulix989
Maybe this should be a link to the actual project rather than someone else's
article telling us that this project exists (even though I really do enjoy
reading Handelman's blog)?

~~~
tiernano
It was posted last week already:
[https://news.ycombinator.com/item?id=20917742](https://news.ycombinator.com/item?id=20917742)

~~~
Hydraulix989
Okay, then this post really feels like a dupe then since it isn't a link to
the original authors' work.

