5 ms·

Retro emulators seem to be increasing in popularity lately. I've seen a few articles now covering the "how", but does anyone have pointers to something explaini

by mrec 7y ago

Retro emulators seem to be increasing in popularity lately. I've seen a few articles now covering the "how", but does anyone have pointers to something explaining the "why"? Is it a Zachtronics-style technical challenge? Specific nostalgia for the software that ran on these ancient platforms? More general nostalgia for the days when platform stacks were still thin and comprehensible [1]? Something else? [1] https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...

zeta0134 7y ago
Given how complex a successful emulator project tends to be, I expect the answer will be highly personal. In my case, it's a combination of nostalgia for the games I grew up playing, curiosity and respect for the developers who were working with such unusual constraints (by today's standards), and a strong desire to help preservationist efforts. I want to help ensure that future curious minds have a wide variety of tools available to play older software once the hardware becomes difficult to acquire. Well, that's the philosophical answer anyway; the more practical answer is that I simply enjoy the challenge, and nostalgia is a great spark to motivate the effort.
Lerc 7y ago
A bit of all of that I think. I'm making a fantasy console with an 8 bit instruction set and I'm having quite a bit of fun writing assembly for it myself. A few years ago I added a graphics mode to a DCPU-16 emulator and wrote a game of Pac-Man for it and it felt extremely liberating to write code that just does the job. I think that aspect could be achieved in other environments if you have a extremely thin API, That is, I think, one of the appeals of the PICO-8. While the Lua language is pretty powerful, the interface to the virtual hardware is thin enough that there is very little API wrangling. If you want it, build it. As for the technical challenge side of things, I have long wanted to write a Language like BASIC in 8-bit ASM. They squeezed a lot into 4 to 16 k back in the day, it would be fun to have a go myself.
jdc 7y ago
For me it's the appeal of potentially mastering the _entire_ machine.
ddingus 7y ago
Fully understanding is one reason. Another is to preserve experiences. There is a lot of great retro software out there. Yet another is development. Many older machines enjoy an active development scene. Emulation can help this along. Fun.
byuu 7y ago
For me, the "why" is that I grew up playing RPGs, and around my early teens I discovered the west missed out on dozens of major games (even Dragon Quest 5 and Final Fantasy 5!) I taught myself programming and reverse engineering so that I could fan translate these games. After I finished a few of them, I became disheartened that my work had trouble running on real game consoles due to emulator inaccuracies. The folks writing emulators at the time took many shortcuts to run on the slower computers we had back then, but in spite of PCs getting faster, they didn't want to incur any speed hits or break any other fan translations relying on emulator bugs. So I switched focus and started writing my own emulators instead. I was filling a niche that at the time wasn't covered. These days, I mostly keep at it because it's fun, I like the games on these old systems, and I'd like to preserve the games for future generations as faithfully as possible. (if you're bored and would like a really in-depth answer, see https://byuu.org/about https://byuu.org/about for a full history.)
unoti 7y ago
> Is it a Zachtronics-style technical challenge? Actually, I did a lot of assembly coding on 6809 and 6502 back in the day, and also played a lot of the Zachtronics games. It's not really the same at all! Zachtronics games are all about challenges that are quite a bit more ridiculous than you have in real life with small machines. In a typical Zachtronics assembly programming game, you spend a lot of time trying to figure out how to do pretty trivial things using a ludicrously small amount of resources, like maybe you've got two reigsters to work with. In a real assembly project, you'll have a few kilobytes to work with, or at a bare minimum 512 bytes. The smallest system I worked with had 512 bytes of RAM and 8kb of ROM. The Zachtronics games were fun and challenging, but they were more like puzzles rather than real programming. Puzzling out how to get the assigned task done with ridiculous artificial limitations. Contrast that to an example of a real-life non-trivial assembly thing I did on a 6502. I needed to respond to remote control commands from an infrared remote similar to what you have with a TV. For input, I'd get interrupts connected to an IO-pin that would fluctuate up and down when receiving IR input. The task involved "recording" commands from a remote, then later monitoring the input and seeing if it matched any of the pre-recorded patterns. You'd count the amount of time between successive pulses, using a real-time clock that was connected to some other IO pins. It's not rocket science, but it's fun and challenging figuring out how to get all that going with a limited amount of memory. To me that kind of thing is a lot more fun than figuring out how to do the various challenges in Zachtronics games, which mostly center around taking something that'd be trivial do if you had a couple hundred bytes of memory to work with, but they are forcing you to do it with 2 bytes of memory. So you make little side constructs that act as memory, or other side constructs that somehow use message queues as memory, or whatever. The appeal of retro emulators I think is that it's a system that's small and limited enough that you have more of a chance of understanding it from end to end. There's a feeling of comfort or coolness in knowing that you know exactly what the system is up to on every cycle. With larger computers, the hard drive starts blinking and God only knows what it's doing, or why. There's this feeling on small embedded or emulated systems that you are really in control of what's happening. On larger, more complex systems, the software I write is just one little part of the larger who-knows-what going on inside the machine. For me another aspect of it is how much I'm getting done with so little code. There's something very satisfying about knowing the entire binary package of assembled code I've generated, and being able to point to any byte of that and understand what it is. It's the exact opposite of what's going on in my other terminal, where as I type it's creating a new react app and downloading untold megabytes of who-knows-what with countless dependencies and abstractions. In retro systems, if the system is capable of doing something, it's probably because you personally made it able to do that thing.

by mrec 7y ago

zeta0134 7y ago

Given how complex a successful emulator project tends to be, I expect the answer will be highly personal. In my case, it's a combination of nostalgia for the games I grew up playing, curiosity and respect for the developers who were working with such unusual constraints (by today's standards), and a strong desire to help preservationist efforts. I want to help ensure that future curious minds have a wide variety of tools available to play older software once the hardware becomes difficult to acquire. Well, that's the philosophical answer anyway; the more practical answer is that I simply enjoy the challenge, and nostalgia is a great spark to motivate the effort.

Lerc 7y ago

A bit of all of that I think. I'm making a fantasy console with an 8 bit instruction set and I'm having quite a bit of fun writing assembly for it myself. A few years ago I added a graphics mode to a DCPU-16 emulator and wrote a game of Pac-Man for it and it felt extremely liberating to write code that just does the job. I think that aspect could be achieved in other environments if you have a extremely thin API, That is, I think, one of the appeals of the PICO-8. While the Lua language is pretty powerful, the interface to the virtual hardware is thin enough that there is very little API wrangling. If you want it, build it. As for the technical challenge side of things, I have long wanted to write a Language like BASIC in 8-bit ASM. They squeezed a lot into 4 to 16 k back in the day, it would be fun to have a go myself.

jdc 7y ago

For me it's the appeal of potentially mastering the _entire_ machine.

ddingus 7y ago

Fully understanding is one reason. Another is to preserve experiences. There is a lot of great retro software out there. Yet another is development. Many older machines enjoy an active development scene. Emulation can help this along. Fun.

byuu 7y ago

For me, the "why" is that I grew up playing RPGs, and around my early teens I discovered the west missed out on dozens of major games (even Dragon Quest 5 and Final Fantasy 5!) I taught myself programming and reverse engineering so that I could fan translate these games. After I finished a few of them, I became disheartened that my work had trouble running on real game consoles due to emulator inaccuracies. The folks writing emulators at the time took many shortcuts to run on the slower computers we had back then, but in spite of PCs getting faster, they didn't want to incur any speed hits or break any other fan translations relying on emulator bugs. So I switched focus and started writing my own emulators instead. I was filling a niche that at the time wasn't covered. These days, I mostly keep at it because it's fun, I like the games on these old systems, and I'd like to preserve the games for future generations as faithfully as possible. (if you're bored and would like a really in-depth answer, see https://byuu.org/about https://byuu.org/about for a full history.)

unoti 7y ago

> Is it a Zachtronics-style technical challenge? Actually, I did a lot of assembly coding on 6809 and 6502 back in the day, and also played a lot of the Zachtronics games. It's not really the same at all! Zachtronics games are all about challenges that are quite a bit more ridiculous than you have in real life with small machines. In a typical Zachtronics assembly programming game, you spend a lot of time trying to figure out how to do pretty trivial things using a ludicrously small amount of resources, like maybe you've got two reigsters to work with. In a real assembly project, you'll have a few kilobytes to work with, or at a bare minimum 512 bytes. The smallest system I worked with had 512 bytes of RAM and 8kb of ROM. The Zachtronics games were fun and challenging, but they were more like puzzles rather than real programming. Puzzling out how to get the assigned task done with ridiculous artificial limitations. Contrast that to an example of a real-life non-trivial assembly thing I did on a 6502. I needed to respond to remote control commands from an infrared remote similar to what you have with a TV. For input, I'd get interrupts connected to an IO-pin that would fluctuate up and down when receiving IR input. The task involved "recording" commands from a remote, then later monitoring the input and seeing if it matched any of the pre-recorded patterns. You'd count the amount of time between successive pulses, using a real-time clock that was connected to some other IO pins. It's not rocket science, but it's fun and challenging figuring out how to get all that going with a limited amount of memory. To me that kind of thing is a lot more fun than figuring out how to do the various challenges in Zachtronics games, which mostly center around taking something that'd be trivial do if you had a couple hundred bytes of memory to work with, but they are forcing you to do it with 2 bytes of memory. So you make little side constructs that act as memory, or other side constructs that somehow use message queues as memory, or whatever. The appeal of retro emulators I think is that it's a system that's small and limited enough that you have more of a chance of understanding it from end to end. There's a feeling of comfort or coolness in knowing that you know exactly what the system is up to on every cycle. With larger computers, the hard drive starts blinking and God only knows what it's doing, or why. There's this feeling on small embedded or emulated systems that you are really in control of what's happening. On larger, more complex systems, the software I write is just one little part of the larger who-knows-what going on inside the machine. For me another aspect of it is how much I'm getting done with so little code. There's something very satisfying about knowing the entire binary package of assembled code I've generated, and being able to point to any byte of that and understand what it is. It's the exact opposite of what's going on in my other terminal, where as I type it's creating a new react app and downloading untold megabytes of who-knows-what with countless dependencies and abstractions. In retro systems, if the system is capable of doing something, it's probably because you personally made it able to do that thing.