EBCDIC gaming? IBM 3033?

My first experience with computing was dumb terminal batch computing on an IBM 3033. For me, it was a mostly non-interactive experience, only slightly removed from punch card computing (I saw punch cards and punch card equipment in the terminal room, but never personally used them).

If anyone was playing games on this system, I didn’t notice it. But could there have been, or even could I have programmed it myself, had I known what I was doing?

The system definitely had Fortran, Pascal, BASIC, and COBOL, but I don’t know if it was possible to run any of them in an interactive way on the dumb terminals.

Anyone familiar with gaming (or lack thereof) on old school IBM mainframes?

1 Like

I found a Star Trek game in BASIC for a IBM 1130 for half a hour or so.
It ran on the console terminal. Ben,

2 Likes

I’ll be honest - I am really unfamiliar with what sort of “operating systems” or compatibility/incompatibility there was with IBM mainframes. Like, I don’t even know if there was multi-user multi-tasking as I’d become familiar with it on *nix systems.

So in particular, would an interactive Star Trek BASIC game only be available to a single “operator” user, or would any of the “normal” dumb terminal users also be able to run an interactive program? I don’t know. My memories are fuzzy, and I did not comprehend most of what I was doing.

The IBM 1130 was single user/ batch. I wish there was more information on the older systems
operating systems for things like MAG TAPE or punched cards. All I can say for sure,one had tiny
tiny memory to run stuff on. I consider the IBM-1130 the first personal computer in that you you had dual floppies , printer and console and even a modem.

2 Likes

To give you some idea of the interactivity I had … the dumb terminals could respond interactively to moving the cursor left/right on the bottom line, with the ability to use insert or delete to move a simple character rocket ship … either >==-- or --==< that I typed in. That was as close to a “game” I had.

Beyond that, we edited programs line by line with a line editor; edited JCL submission files line by line with the same line editor, submitted the jobs … waited for the job to complete, and then either viewed the output on screen or sent to printer (which had high resolution output capability).

It certainly felt like a true multi-user system to me … whenever entering a command to enter/edit a line, it seemed to respond quickly, rather than me sitting their waiting “my turn” or something. But the wait time between submitting a compile/run job and getting the results could be many minutes.

So I don’t really know what the deal was. It certainly didn’t feel like *nix systems I’d use later on, which felt truly interactive … where the computer would immediately start “doing stuff” when told to compile or run a program.

I never got to use a real timesharing system. If you where not in the computer science
course, no access at all. When they had the IBM 1130 and the batch system, any one
could use it , if it was free.

1 Like

I’d guess, there must have been at least some (simple) dice games. Not that I would know, but whenever I looked into any vintage computers in the context of games, and be it one-of-a-kind machines, these programs popped up about everywhere. All you really need for this is some sort of an input command. (I guess, it’s not only for these programs being games, but that it’s about the easiest way to enter into a dialog with the computer and get a genuine experience out of this. You are essentially sharing a world – the world of the game as proposed by the random number generator – with the machine. There may be a stronger urge behind this than even human taste for games and play, which is already quite strong. Moreover, games have always been great demonstration programs that allowed “even” innocent visitors to connect to what was going on and grasp what the machine was enabling.)

1 Like

Early IBM mainframe computing.

Computer gaming on early IBM mainframes was indeed possible and was common if the installation allowed it.

In the early 1970s I worked for a major airline, and we had redundant IBM 360s and then 370s. Memory was initially 256 KB and then 512 KB. One machine was the online reservations machine and the other was used for backup and testing.

As a computer operator working shifts, the lucky ones assigned the graveyard shift had access to the test machine almost all night. We would play around with the machine, learning IBM assembly language programming or Fortran.

The input/output device used by the control operator in those early days was an IBM 1052 console, essentially an IBM Selectric typewriter, which the O/S received commands from and typed to. We had IBM 1403 printers for bulk job output.

Programs and the associated control “wrapper” JCL (Job Control Language) were 80-column cards, produced on a card punch machine. Tape storage was 2400 series magnetic tape. Disk storage was 2314 disk storage units, each disk holding only about 30 MB of data. By the early 1970s, paper tape was on its way out.

The two most common games were Star Trek and Hammurabi. Each, if I remember correctly, was written in Fortran. They were text-based.

Star Trek was the familiar 10x10 dot grid, ten of them in which each was a sector of the galaxy. Picture a 10x10x10 cube. You would navigate through the sectors killing or avoiding Klingons.

Hammurabi is best described by Wikipedia. “Hammurabi is a text-based strategy video game centered on resource management in which the player, identified in the text as the ancient Babylonian King Hammurabi, enters numbers in response to questions posed by the game. The resources that the player must manage are people, acres of land, and bushels of grain.” The game unfolds year by year as you manage your kingdom.

The game, on 80-column cards, would be read into the machine through the IBM 2540 card reader. Once running, it would interface directly with the 1052 operator console. Commands could be entered via the 1052. It also received text output from the games. Towards 1975, CRTs became more commonly used on the mainframes, and they could be used to play these two games as well.

By the latter part of the 1970s, for a number of years we had Perkin-Elmer time share terminals. They came with their own BASIC interpreters where one could write and run BASIC code right from the terminal itself.

Early on in the 1970s, I wrote a tic-tac-toe game which ran on the mainframe. My plan was to make it a self-learning game, in which the human operator would play the computer. The computer would initially make random moves and if it lost, it would save the losing game board pattern to tape at the point just before it made the losing move. So each time you ran the game, it would read in the tape of losing moves, and never repeat that move again. After about 400 games, the machine never lost, and the best you could do against it was a draw, depending on who had the first move.

In the later 1970s vector graphic CRTs were purchased, which were used by the computer operator in place of the IBM 1052 system console typewriter. A friend of mine, actually a brilliant IBM engineer, wrote a space shooter game, where two ships flew around the CRT monitor and, using the keyboard, you could shoot at one another. This was only in use for a short time, as management then decided to kill all game playing on the company mainframes.

So there you have it.

4 Likes

Excellent story - thanks, and a belated welcome!

Thank you so much! Your explanations answer all my questions.

Also - if I understand your Tic-Tac-Toe algorithm, there would be about a 1/8 chance of winning if you went first. You place your first X on a corner, and then there’s a 1/8 chance the computer will place its first O in the center. If so, you wll win.

You place your second X in the opposite corner, and then your 3rd X in the corner that gives you two winning moves (the one further away from the computer’s second O).

It’s been a lot of years. However, after 400 test games, the computer would know to never respond with a center move if you started in a corner. So it would eventually be a draw.

I always wanted to try this idea on chess or even checkers, but soon realized there were too many possibilities.

1 Like

Well big advances in AI machine learning have been made, I wonder when they will
try with that, a good chess program. Real neurons here, don’t try this at home. :slight_smile: