December Days 06: LOAD"*",8,1
Dec. 6th, 2019 10:56 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradept[This is part of a series on video games, their tropes, stories of playing games, and other related topics. If you have suggestions about where to take the series, please do say so in the comments. We have a lot of spaces to fill for this month.]
I learned how to use a command line so I could play games.
Which, I suppose, dates me ever so slightly, in that the first exposure to computers that I had was before the idea of the GUI (Graphical User Interface) had really taken off in the forms of Windows 3.0 and Apple's macOS System 8 (although it would be System 9 that became the mainstay of Mac OS's perception until they jumped up to OSX). This isn't to say that GUIs didn't exist, or that they weren't popular (AmigaOS has had GUI since the beginning), just that this is before I have them as a regular part of my (and almost everyone else's) computing experience.
A program that Dad had found, somewhere, someway, was called Automenu. It turns out, that, thanks to the Internet Archive, rather than just describing the program and having you nod and smile as I ramble away, Automenu was given away in a shareware form (oh, goodness, we'll have to talk about that eventually, too, won't we? Because shareware was definitely a thing for its own time and place.) in a few different places, but the Internet Archive has happily told me they have The Big Blue Disk, volume 10, ©1987 available for people to download and browse. You'll need DOSBox to mount and run it properly, but it works as advertised, and you, too, can poke around and see this program that was on the family gaming computer and organized the programs and games that were on the machine to make it easier for the kids to find the programs they wanted to run. We could go to the appropriate menu entry, hit Enter, and then the program we wanted would appear on the screen. Since there wasn't a whole lot of software installed on the machine at any given time, this worked out pretty well.
I would eventually go on to learn a little bit about using Automenu's built-in menu editor for my own purposes on a DOS-based machine, so I suppose wanting to play gaes also taught me a little bit about learning how to program and how to write scripts, even though the Automenu program didn't do anything that would be translatable to anything else. Like a lot of things, it ended up doing more to teach me about how the form of things go, and what sort of things might be useful to include in your own work so that you can remember what you were aiming for previously, or you can give yourself reminders of how you accomplished some pretty neat things. I've been able to do a lot of modifying scripts others have written in little ways to get them to point at what I want them to point at and other such things as that from these exercises. So it helped build some confidence for me in being willing to poke into files that look like they can be poked into and have their parameters changed to see if they can suit my purposes.
Most importantly, however, in this Automenu-enabled world is that we were still dealing with small amounts of RAM sizes. An oft-attributed, but ultimately un-cited, and therefore not actually attributable, statement says Bill Gates declared that 640K of RAM would be more than sufficient for everyone, and despite the lack of veracity, at this point, RAM isn't being sold in gigabyte options, nor are hard disk drives, and so while 640k might not be enough for everyone, it's a barrier that has to be contended with, because 640K is an upper limit for conventional memory for 8086 and 8088-based systems, and still becomes an issue for games and software even in several generations after the 8086/8088 because of the need to maintain a certain amount of backward compatibility with such important things as the operating system. So, memory management becomes an increasingly sophisticated operation, but there's still the 640K barrier to overcome, and each program that gets added, either as a part of DOS or that is run on top of it, shaves off another part of that 640K for itself while it's running (or, in the case of the Terminate and Stay Resident (TSR) things, that memory bit is just eaten, unless DOS or a memory manager tosses it into a different part of memory entirely so as to preserve as much of that 640K as possible).
Enter a game called Sharkey's 3D Pool, which, yes, you can play on the Internet Archive through emulation (or use DOSBox that you downloaded to look at the Big Blue Disk and play locally), but at that moment was full-screen gaming awesome. (Also, there's probably something to be said that Sharkey himself is a black cigar-smoking pool-hall hustler with sunglasses. He's not the only black character, however! Slashin' Sally also exists, so that means two of the seven computer opponent characters are black. So, I suppose that's good in terms of representation, maybe?) As a fully three-dimensional billiards simulator, however, and with fabulous EGA graphics and either synthesized or digitized sound, it took a pretty significant chunk of memory by itself. As did more than a few games, like Scrabble. It wasn't possible to run both Automenu and all the games that I wanted to play, as some of the other games would complain about an out-of-memory error and then exit back to Automenu.
This is probably the point where I should introduce Pops and mention that he is a fine engineer who has worked on many projects that he can discuss with his children, and more than a few, I suspect, that he will not ever be able to talk about in any sort of detail, unless one of the children obtains proper governmental security clearance. (That's unlikely, although I admit I am tempted to know what are in the classified annexes of various presidential libraries and archives.) For the purpose of this story, however, Pops does what is now considered a hallmark of good instruction, and engages his curious child by asking questions about what the child wants to do, and indicating whether there is a method for the child to be able to achieve those ends. Considering I'm probably all of six-seven at this point, I think (it's a fuzzy memory, which suggests it's somewhere in the Kindergarten-1st grade space, and I know full well that as I progress through schooling, my grasp on how to run DOS gets better and more familiar), I'm pretty sure it started with trying to figure out how to get to a game that wasn't specifically in Automenu. Which involved taking a peek behind the hood at the way Automenu was configured, and seeing if I could piece together how to make it work.
I suspect Pops supplied me with a key piece of information, specifically, the directory on the hard disk where Sharkey's resided, and possibly also the name of the executable file. Things that I would have had to learn about the command line and directory structure first to discern on my own. And I'm pretty sure my first attempts were almost right, and then I hit on the right combination of copy and paste that allowed me to get to the game. I felt pretty proud of myself for figuring it out - until Sharkey's hit me with an out-of-memory error! So I was stymied at that point, because out-of-memory at this point is an outside-context problem. I'd done everything I needed to get to the program and to have it run from Automenu correctly, but it wasn't working. Having demonstrated the edge of my abilities and understanding at that point, Pops explained to me one more important thing - how Automenu really worked. Which is to say, it was a nice wrapper on top of DOS itself, giving graphical menu options to run programs, rather than having someone have to do all of the commands themselves, or generate batch files to do those commands in sequence. The things that we had put into Automenu to get it to work would work perfectly fine from the DOS prompt itself, and, as it turned out, by exiting Automenu completely, we freed up crucial memory resources that allowed Sharkey's and other games to run.
As games progressed and the 640K memory limitation became more and more of a pain in the ass to deal with, this familiarity and okay-ness with the command line would progress into the manufacture of boot disks. These were bootable disks, yes, but they had a specific purpose - to load just enough of DOS so that all the things a game needed to run would be available, but nothing more than that, because as much of the available remaining memory as possible would need to be taken up by the game itself for it to properly run. This problem would persist through several of my computers, even the ones that were running Windows 95 and 98. (Windows 2000, NT, and XP made the jump to running a specific Windows kernel, rather than running on top of DOS, and ever since, DOS was more emulated than native, which broke compatibility with MS-DOS based games and software something fierce. That's why DOSBox is important, as it emulates a proper DOS environment for that software to work in.) So that meant learning how to put together batch files and config.sys files and other such things so as to set up the correct environment to run a game in. It's not quite learning how to hack, because that suggests I was trying to do things that the system never intended, but I learned a lot more than I would have otherwise about how the environment did things, even if I never fully formally learned what everything did and how I was "supposed" to set it up, and instead tweaked already-created things until they worked properly for what I wanted.
This might also be a contributing factor to why Linux's occasional command line requirements are not super-intimidating to me, because I'm mostly looking at them and going "Huh, so that's what that does, and that's the syntax? Okay." in the same way that I was learning how to change directories, copy files, set environment variables, and other useful things that needed to be done so I could play my games. It's a different set of commands to learn, and occasionally I still slip and try to use one set of commands in the other environment, and it blinks at me and says "Bad command or file name." or something similar.
Lots of educators and pedagogical researchers are (repeatedly) coming to the conclusion that games are pretty useful motivators to get people to learn things. I can honestly say that's true, although in many cases it's not that the games themselves were educational (although many of them were, like Math Blaster, the Doctor Brain series, or Pepper's Adventures in Time), but that I learned a ton of things so that I could play games that were entirely entertaining and otherwise not educational at all. (Or so I thought. I have a feeling that I learned a lot of things unintentionally by playing games that were ostensibly about a space janitor or a student taking a correspondence course from the Famous Adventurer.)
That's the software side of stuff I learned so I could play games. There's a hardware component, too, but we'll get to that tomorrow.
(And if you're curious, the title of the post is the most common way to load software from a disk on a Commodore 64 computer, which was also a familiar computer that I worked with to play games, whether at a friend's house, libraries, or school.)
I learned how to use a command line so I could play games.
Which, I suppose, dates me ever so slightly, in that the first exposure to computers that I had was before the idea of the GUI (Graphical User Interface) had really taken off in the forms of Windows 3.0 and Apple's macOS System 8 (although it would be System 9 that became the mainstay of Mac OS's perception until they jumped up to OSX). This isn't to say that GUIs didn't exist, or that they weren't popular (AmigaOS has had GUI since the beginning), just that this is before I have them as a regular part of my (and almost everyone else's) computing experience.
A program that Dad had found, somewhere, someway, was called Automenu. It turns out, that, thanks to the Internet Archive, rather than just describing the program and having you nod and smile as I ramble away, Automenu was given away in a shareware form (oh, goodness, we'll have to talk about that eventually, too, won't we? Because shareware was definitely a thing for its own time and place.) in a few different places, but the Internet Archive has happily told me they have The Big Blue Disk, volume 10, ©1987 available for people to download and browse. You'll need DOSBox to mount and run it properly, but it works as advertised, and you, too, can poke around and see this program that was on the family gaming computer and organized the programs and games that were on the machine to make it easier for the kids to find the programs they wanted to run. We could go to the appropriate menu entry, hit Enter, and then the program we wanted would appear on the screen. Since there wasn't a whole lot of software installed on the machine at any given time, this worked out pretty well.
I would eventually go on to learn a little bit about using Automenu's built-in menu editor for my own purposes on a DOS-based machine, so I suppose wanting to play gaes also taught me a little bit about learning how to program and how to write scripts, even though the Automenu program didn't do anything that would be translatable to anything else. Like a lot of things, it ended up doing more to teach me about how the form of things go, and what sort of things might be useful to include in your own work so that you can remember what you were aiming for previously, or you can give yourself reminders of how you accomplished some pretty neat things. I've been able to do a lot of modifying scripts others have written in little ways to get them to point at what I want them to point at and other such things as that from these exercises. So it helped build some confidence for me in being willing to poke into files that look like they can be poked into and have their parameters changed to see if they can suit my purposes.
Most importantly, however, in this Automenu-enabled world is that we were still dealing with small amounts of RAM sizes. An oft-attributed, but ultimately un-cited, and therefore not actually attributable, statement says Bill Gates declared that 640K of RAM would be more than sufficient for everyone, and despite the lack of veracity, at this point, RAM isn't being sold in gigabyte options, nor are hard disk drives, and so while 640k might not be enough for everyone, it's a barrier that has to be contended with, because 640K is an upper limit for conventional memory for 8086 and 8088-based systems, and still becomes an issue for games and software even in several generations after the 8086/8088 because of the need to maintain a certain amount of backward compatibility with such important things as the operating system. So, memory management becomes an increasingly sophisticated operation, but there's still the 640K barrier to overcome, and each program that gets added, either as a part of DOS or that is run on top of it, shaves off another part of that 640K for itself while it's running (or, in the case of the Terminate and Stay Resident (TSR) things, that memory bit is just eaten, unless DOS or a memory manager tosses it into a different part of memory entirely so as to preserve as much of that 640K as possible).
Enter a game called Sharkey's 3D Pool, which, yes, you can play on the Internet Archive through emulation (or use DOSBox that you downloaded to look at the Big Blue Disk and play locally), but at that moment was full-screen gaming awesome. (Also, there's probably something to be said that Sharkey himself is a black cigar-smoking pool-hall hustler with sunglasses. He's not the only black character, however! Slashin' Sally also exists, so that means two of the seven computer opponent characters are black. So, I suppose that's good in terms of representation, maybe?) As a fully three-dimensional billiards simulator, however, and with fabulous EGA graphics and either synthesized or digitized sound, it took a pretty significant chunk of memory by itself. As did more than a few games, like Scrabble. It wasn't possible to run both Automenu and all the games that I wanted to play, as some of the other games would complain about an out-of-memory error and then exit back to Automenu.
This is probably the point where I should introduce Pops and mention that he is a fine engineer who has worked on many projects that he can discuss with his children, and more than a few, I suspect, that he will not ever be able to talk about in any sort of detail, unless one of the children obtains proper governmental security clearance. (That's unlikely, although I admit I am tempted to know what are in the classified annexes of various presidential libraries and archives.) For the purpose of this story, however, Pops does what is now considered a hallmark of good instruction, and engages his curious child by asking questions about what the child wants to do, and indicating whether there is a method for the child to be able to achieve those ends. Considering I'm probably all of six-seven at this point, I think (it's a fuzzy memory, which suggests it's somewhere in the Kindergarten-1st grade space, and I know full well that as I progress through schooling, my grasp on how to run DOS gets better and more familiar), I'm pretty sure it started with trying to figure out how to get to a game that wasn't specifically in Automenu. Which involved taking a peek behind the hood at the way Automenu was configured, and seeing if I could piece together how to make it work.
I suspect Pops supplied me with a key piece of information, specifically, the directory on the hard disk where Sharkey's resided, and possibly also the name of the executable file. Things that I would have had to learn about the command line and directory structure first to discern on my own. And I'm pretty sure my first attempts were almost right, and then I hit on the right combination of copy and paste that allowed me to get to the game. I felt pretty proud of myself for figuring it out - until Sharkey's hit me with an out-of-memory error! So I was stymied at that point, because out-of-memory at this point is an outside-context problem. I'd done everything I needed to get to the program and to have it run from Automenu correctly, but it wasn't working. Having demonstrated the edge of my abilities and understanding at that point, Pops explained to me one more important thing - how Automenu really worked. Which is to say, it was a nice wrapper on top of DOS itself, giving graphical menu options to run programs, rather than having someone have to do all of the commands themselves, or generate batch files to do those commands in sequence. The things that we had put into Automenu to get it to work would work perfectly fine from the DOS prompt itself, and, as it turned out, by exiting Automenu completely, we freed up crucial memory resources that allowed Sharkey's and other games to run.
As games progressed and the 640K memory limitation became more and more of a pain in the ass to deal with, this familiarity and okay-ness with the command line would progress into the manufacture of boot disks. These were bootable disks, yes, but they had a specific purpose - to load just enough of DOS so that all the things a game needed to run would be available, but nothing more than that, because as much of the available remaining memory as possible would need to be taken up by the game itself for it to properly run. This problem would persist through several of my computers, even the ones that were running Windows 95 and 98. (Windows 2000, NT, and XP made the jump to running a specific Windows kernel, rather than running on top of DOS, and ever since, DOS was more emulated than native, which broke compatibility with MS-DOS based games and software something fierce. That's why DOSBox is important, as it emulates a proper DOS environment for that software to work in.) So that meant learning how to put together batch files and config.sys files and other such things so as to set up the correct environment to run a game in. It's not quite learning how to hack, because that suggests I was trying to do things that the system never intended, but I learned a lot more than I would have otherwise about how the environment did things, even if I never fully formally learned what everything did and how I was "supposed" to set it up, and instead tweaked already-created things until they worked properly for what I wanted.
This might also be a contributing factor to why Linux's occasional command line requirements are not super-intimidating to me, because I'm mostly looking at them and going "Huh, so that's what that does, and that's the syntax? Okay." in the same way that I was learning how to change directories, copy files, set environment variables, and other useful things that needed to be done so I could play my games. It's a different set of commands to learn, and occasionally I still slip and try to use one set of commands in the other environment, and it blinks at me and says "Bad command or file name." or something similar.
Lots of educators and pedagogical researchers are (repeatedly) coming to the conclusion that games are pretty useful motivators to get people to learn things. I can honestly say that's true, although in many cases it's not that the games themselves were educational (although many of them were, like Math Blaster, the Doctor Brain series, or Pepper's Adventures in Time), but that I learned a ton of things so that I could play games that were entirely entertaining and otherwise not educational at all. (Or so I thought. I have a feeling that I learned a lot of things unintentionally by playing games that were ostensibly about a space janitor or a student taking a correspondence course from the Famous Adventurer.)
That's the software side of stuff I learned so I could play games. There's a hardware component, too, but we'll get to that tomorrow.
(And if you're curious, the title of the post is the most common way to load software from a disk on a Commodore 64 computer, which was also a familiar computer that I worked with to play games, whether at a friend's house, libraries, or school.)
no subject
Date: 2019-12-07 07:24 am (UTC)no subject
Date: 2019-12-07 07:35 am (UTC)no subject
Date: 2019-12-07 07:38 pm (UTC)(not point 😛)
no subject
Date: 2019-12-07 07:57 pm (UTC)no subject
Date: 2019-12-07 03:59 pm (UTC)Once, Xiao Ji "helped" me by turning on Bold by perching on the keyboard, which led me into many future adventures in markup.
no subject
Date: 2019-12-07 04:04 pm (UTC)no subject
Date: 2019-12-07 07:39 pm (UTC)no subject
Date: 2019-12-07 05:39 pm (UTC)I learned to READ so I could play games, on a TRS-80 which was quickly (from my point of view) replaced by a Tandy 1000. Sierra On-Line adventure games taught me important concepts like "look at everything, then try to pick it up" and "Save your game" and such.
no subject
Date: 2019-12-07 08:04 pm (UTC)