GRG16: Mega-Drive-a-like
I was musing about the possibility of getting students to write console homebrew software. I suspect students would find the prospect of running their own games on emulators (or perhaps even an actual software-hacked console) really inspiring and enjoyable.
However, the technological difference between making homebrew software and downloading and running copyrighted ROMs is incredibly small. So I suspect students' parents might be a bit suspicious or potentially even outright hostile to such a club.
So I started to dig down to what the educational benefit of such a thing would be. Potental benefits might include: understanding/using indexed-colour images, managing RAM and VRAM by hand, writing programs in assembler (or a subset of C), understanding specific technical limitations. In short: lots of great scope for computational thinking and exposing technical systems as not-actually-magic.
Pico-8 is amazing and YOU SHOULD BUY IT. I love it and it is very close to what I want for students, but I think it's just arcane enough to hide the low-level without giving enough power for games that would interest sceptical students. When I've tried it out with high-attaining students, they have enjoyed it, but not really known where to go with it (which, to be fair, might say more about my shoddily-written learning resources than pico-8 itself).
After rolling these ideas around in my brain, I came up with a crazy project idea! Why don't I make a Mega-Drive-style hardware-level emulator? That would mean I could write activities to help the students explore how that era of hardware actually worked. It would also mean more advanced students could explore the machine-code level and perhaps even implement a toolchain of their own.
So where would be the happy-medium starting point? So far, I have implemented the very basics of a display processor in C++ and it can display a background 'layer' via libSDL2. I'm now working on a C-subset parser/compiler to allow at least simple programs to be written in a higher-level language than assembler.
Maybe I should focus smaller to begin with and just write an assembler tool, but we'll have to wait and see where my fickle whims guide me.
Some kind of ROM-builder program would also be good to handle the processing/packing of code, graphics and sound so the students can get stuff running without too much difficulty. I want to keep the toolchain as simply-implemented and clunky-to-use as possible though. That way, students can understand more easily what it does and see potential ways of improving it.
Only time will tell whether or not this project will see its way through to some kind of completion, but I'm certainly enjoying playing about with the idea.
However, the technological difference between making homebrew software and downloading and running copyrighted ROMs is incredibly small. So I suspect students' parents might be a bit suspicious or potentially even outright hostile to such a club.
So I started to dig down to what the educational benefit of such a thing would be. Potental benefits might include: understanding/using indexed-colour images, managing RAM and VRAM by hand, writing programs in assembler (or a subset of C), understanding specific technical limitations. In short: lots of great scope for computational thinking and exposing technical systems as not-actually-magic.
Pico-8 is amazing and YOU SHOULD BUY IT. I love it and it is very close to what I want for students, but I think it's just arcane enough to hide the low-level without giving enough power for games that would interest sceptical students. When I've tried it out with high-attaining students, they have enjoyed it, but not really known where to go with it (which, to be fair, might say more about my shoddily-written learning resources than pico-8 itself).
After rolling these ideas around in my brain, I came up with a crazy project idea! Why don't I make a Mega-Drive-style hardware-level emulator? That would mean I could write activities to help the students explore how that era of hardware actually worked. It would also mean more advanced students could explore the machine-code level and perhaps even implement a toolchain of their own.
So where would be the happy-medium starting point? So far, I have implemented the very basics of a display processor in C++ and it can display a background 'layer' via libSDL2. I'm now working on a C-subset parser/compiler to allow at least simple programs to be written in a higher-level language than assembler.
Maybe I should focus smaller to begin with and just write an assembler tool, but we'll have to wait and see where my fickle whims guide me.
Some kind of ROM-builder program would also be good to handle the processing/packing of code, graphics and sound so the students can get stuff running without too much difficulty. I want to keep the toolchain as simply-implemented and clunky-to-use as possible though. That way, students can understand more easily what it does and see potential ways of improving it.
Only time will tell whether or not this project will see its way through to some kind of completion, but I'm certainly enjoying playing about with the idea.
Comments
Post a Comment