Run MAZE #1330
Comments
|
Josh wrote (about Maze War):
So I got SSV from @tuban's Imlac software library and tested it. It runs, but I can't seem to do anything through the keyboard.
@jh95468, do you remember anything about SSV? |
|
It’s a terminal emulator, and it’s full duplex – when you type it’s sending characters out the TTY port but since it’s got nothing to talk to, they don’t get echoed back. It would be interesting to know if there are any local controls, etc. through the keyboard. I’ve never seen any documentation for ssv.
I’m working on that “nothing to talk to” part as we speak ☺.
- Josh
From: Lars Brinkhoff <notifications@github.com>
Sent: Tuesday, October 9, 2018 10:58 PM
To: PDP-10/its <its@noreply.github.com>
Cc: Josh Dersch <JoshD@livingcomputers.org>; Mention <mention@noreply.github.com>
Subject: Re: [PDP-10/its] Run Maze War (#1330)
Josh wrote:
It also requires that SSV's font still be resident in memory
So I got SSV from @tuban<https://github.com/tuban>'s Imlac software library<http://www.ubanproductions.com/imlac_sw.html> and tested it. It runs, but I can't seem to do anything through the keyboard.
[ssv]<https://user-images.githubusercontent.com/775050/46715789-cabbcf00-cc61-11e8-9f97-1f825d743a89.png>
@jh95468<https://github.com/jh95468>, do you remember anything about SSV?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1330 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ATnJh0nu8Mro5siCKgDmLCM6e2h50m31ks5ujYx6gaJpZM4XUnpV>.
|
|
Sounds great, Josh! SSV is also described in some places as a monitor, and as part of the Dynamic Modeling editor, IMEDIT. I also believe it could display graphics sent from the host, using an ARDS-like protocol. |
|
We have a binary version of IMEDIT, so we can try that on occasion. Information from PDL is that the Imlac runtime was eventually changed to a VT52 emulator. I don't know if that's a newer version of SSV, or if it's named something else. |
|
I wrote IMEDIT, in PDP-10 assembler. It didn't have any graphics functionality, but was solely intended for editting ascii documents, instead of using TECO. The overriding requirement for IMEDIT was that it fit into a single block of PDP-10 memory (in contrast to TECO which took 6 or 7 IIRC). As we received more Imlacs and hooked them up as ITS terminals, the PDP-10 became overloaded and it was hard to get anything done. There was no 'virtual memory' at that time, so whatever programs you were using consumed real physical memory, which was in very limited supply. Even TECO was a problem with all of the terminals that could be active at one time. IMEDIT allowed us to use all of the Imlacs we had, by designating some (most?) of them as "Imedit-only" terminals, where the only program you were allowed to use was IMEDIT. We were all constrained to use signup sheets, and allowed to reserve only 2 hours maximum at a time, with (IIRC) another 2 hours on an IMEDIT-only terminal. One of the staff (like me) was assigned in shifts to enforce this, although anybody could see the paper signup sheets and do TTY^F to see what programs and more importantly memory you were using - regardless of whether or not the program you started happened to be named IMEDIT. IMEDIT was a simple program that simply passed ascii from a file to an Imlac and back, except for control characters which were used to issue commands like 'open a file'. If you try to run IMEDIT from a normal non-IMLAC TTY you can see what it does by typing control-commands and watching what it sends you. Of course you needed the right software on ths IMLAC side to make it operate as an editor. |
|
Forgot to mention... I don't remember the term 'SSV', or remember what we called the everyday program that ran in all the Imlacs. It might have been 'SSV', but the everyday program was just a terminal emulator, with an extra feature or two. In particular, it responded to the 'Page Xmit' key, and when you pushed that, whatever was on the Imlac screen (even off the top or bottom) was sent to the TTY output. Assuming IMEDIT was running on the PDP-10 at the other end of that TTY line, it would read all the input from the Imlac and just write it to the output file. Typing a command, e.g., ^Y (Yank) would then instruct IMEDIT to read some more characters from the input file, and send them down the TTY connection to the Imlac. So, assuming SSV was that Imlac-side program, and you can somehow push the virtual keyboard's Page-XMIT key, you should be able to use IMEDIT to edit files. I think... |
|
Thanks, Jack. Apparently the Imlac situation is more complicated than I thought.
Anyway, for Maze War I guess the most important thing is that the SSV fonts are resident in core. |
|
SST was the common terminal emulator used at Purdue. I've added George Goble as
he has the memory of an elephant and did system support during the Imlac's time
(and still today). You might re-state any questions you haven't answered yet for him
to think about (e.g. the SVV $5 wire update)...
…--tom
On 10/12/18 1:18 PM, Lars Brinkhoff wrote:
Thanks, Jack. Apparently the Imlac situation is more complicated than I thought.
* I believe SSV worked with IMEDIT.
* Later a VT52 emulator supplanted SSV.
* I don't know anything about SST.
* DECUUO can display vector graphics using the same protocol as GT40. Yet another Imlac program?
Anyway, for Maze War I guess the most important thing is that the SSV fonts are resident in core.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKLiET6_Y_ndpzz3d2cj7HFhj8z_MeALks5ukNzkgaJpZM4XUnpV>.
|
|
Since a VT52, as far as I remember, didn't have a 'Page Xmit' key, an Imlac strictly emulating it wouldn't have ben very useful with IMEDIT. As DM got more memory, paging, swapping, etc., IMEDIT became less necessary, so I can believe they might have been turned into simple VT emulators for everyday use (and the Maze program for the wee hours). In the later part of the 70s, it was common to spend your entire terminal time in Muddle, editting, running, and debugging programs, so IMEDIT and even TECO weren't used as much as earlier in DM history. |
|
One other detail from memory... Each Imlac had an operator's console which sat on its desk and contained the usual array of lights switches and buttons that were common on minicomputers of the day. There must have been some kind of boot loader in a protected memory, because I can still remember flipping those switches and pushing those big square buttons to get the Imlac back into a usable state after it had crashed or left dead by some previous user - pretty common in mornings after a night of Maze... I don't recall that the Imlacs had any disk storage, so if the core memory image was corrupted a new image would have had to come from the ITS machine down the TTY line by working the buttons and switches. Not sure what that boot software was called. |
|
On 10/12/2018 2:27 PM, Tom Uban wrote:
SST was the common terminal emulator used at Purdue. I've added George
Goble as
he has the memory of an elephant and did system support during the
Imlac's time
(and still today). You might re-state any questions you haven't
answered yet for him
to think about (e.g. the SVV $5 wire update)...
--tom
On 10/12/18 1:18 PM, Lars Brinkhoff wrote:
>
> Thanks, Jack. Apparently the Imlac situation is more complicated than
> I thought.
>
> * I believe SSV worked with IMEDIT.
> * Later a VT52 emulator supplanted SSV.
> * I don't know anything about SST.
> * DECUUO can display vector graphics using the same protocol as
> GT40. Yet another Imlac program?
>
> Anyway, for Maze War I guess the most important thing is that the SSV
> fonts are resident in core.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1330 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKLiET6_Y_ndpzz3d2cj7HFhj8z_MeALks5ukNzkgaJpZM4XUnpV>.
>
The Imlac terminal emulator was STS. BC (Bill Croft wrote it).
I remember being up all night when BC got Mazeware to run.. only about
30 hosts then on the original ARPANET.
--ghg
|
|
Most Imlacs had a bootstrap ROM (using a diode matrix) located at 40(8). You could use the panel on the operator’s console to toggle in the starting address and set the machine running. On machines without the console, there was a toggle switch and a button – the toggle switched between address 40(8) and 100(8), and the button caused the machine to jump to the selected address and begin execution, so you could bootstrap the machine without the console.
It would be interesting to know what the bootstrap on MIT’s machines looked like – I assume they sent some kind of request down the line to tell ITS to send the terminal program over, but this is speculation. The Imlac we have here at the museum (which was formerly Tom’s) had a small modification made – if you started it at 71(8) it would send 34(8) over the TTY interface before beginning the normal bootstrap process. I don’t know the provenance of this machine, though – Tom, you have any knowledge of this machine’s history?
From: Jack Haverty <notifications@github.com>
Sent: Friday, October 12, 2018 12:05 PM
To: PDP-10/its <its@noreply.github.com>
Cc: Josh Dersch <JoshD@livingcomputers.org>; Mention <mention@noreply.github.com>
Subject: Re: [PDP-10/its] Run Maze War (#1330)
One other detail from memory... Each Imlac had an operator's console which sat on its desk and contained the usual array of lights switches and buttons that were common on minicomputers of the day. There must have been some kind of boot loader in a protected memory, because I can still remember flipping those switches and pushing those big square buttons to get the Imlac back into a usable state after it had crashed or left dead by some previous user - pretty common in mornings after a night of Maze...
I don't recall that the Imlacs had any disk storage, so if the core memory image was corrupted a new image would have had to come from the ITS machine down the TTY line by working the buttons and switches. Not sure what that boot software was called.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1330 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ATnJhyXnui-j17S0ApZ7ybHl4MiAyxB0ks5ukOfbgaJpZM4XUnpV>.
|
|
Update. I have now run @livingcomputermuseum's Imlac simulator with the added TELNET support. I can load SSV, and then login to ITS and start MAZE. The initial top view of the maze works, but the 3D view from inside the maze doesn't. |
|
Good progress.
…On 10/30/18 2:42 AM, Lars Brinkhoff wrote:
Update.
I have now run @livingcomputermuseum <https://github.com/livingcomputermuseum>'s Imlac simulator
with the added TELNET support. I can load SSV, and then login to ITS and start MAZE. The initial
top view of the maze works, but the 3D view from inside the maze doesn't.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKLiEaPOudIMpDCtD0VbIWx7H1pIG90Bks5uqALrgaJpZM4XUnpV>.
|
|
We now have a newer version of SSV we can try on the Imlac. And something called SST that probably isn't related to the one at Purdue. |
|
I have started both SSV 52 and SST 21 on the sImlac. I have not yet tried them with ITS. Next, check MAZE. Is it happier about SSV 52 than 22 or 24? Will it be OK with SST? |
|
MAZE source code explicitly says: The characters are in the file SSV CHARS, which is .INSRTed into SSV 52. SST does that too. |
|
Excellent news. I recall mention of a hardware mod as well, but do not recall anymore. Looking
through the various schematics might locate a note or change.
…On 4/15/20 7:38 AM, Lars Brinkhoff wrote:
Inching forward. I have ITS loading programs onto the Imlac emulator, and @tuban
<https://github.com/tuban>'s "SSV 22" works ok. However, there's a suspicion the MIT programs
expect some undocumented hardware modification. @jdersch <https://github.com/jdersch> and I are
looking into this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACROEEJFAPFK4JJWBV5JZL3RMWTEJANCNFSM4F2SPJKQ>.
|
|
By the way, the makers of the "From Bedrooms to Billions" series of video game documentaries are making a new episode about big iron games. I have helped them get some footage of PDP-6/10 ITS games, but MAZE is still on their to do list. |
|
IIRC, there were several hardware mods to the DM Imlacs. All of them were very simple, and were accomplished by wirewrapping changes on the backplane, using some unused existing logic gates wherever they could be found to make the change. The one that was done for Maze was motivated by the glitchiness of the display, where lines would occasionally go randomly off the screen. It looked like a loose connection, but everything was tight and the same behavior occurred on different Imlacs. The problem was a lack of synchronization between the Imlac's two processors. The program (Maze etc.) ran in the main CPU, and shared memory with the display processor. So to change the screen image, the program modified the graphics instructions that the display processor was executing. Depending on where the display processor was executing at the time the main processor changed the display list, glitches could occur. I can't recall exactly how we fixed that (even though I'm probably the one who designed the hardware mod). IIRC, it had something to do with adding a way for the display processor to raise an interrupt for the main processor, so that the main processor could make a display program change at a 'safe' time. There was probably a flag bit involved somewhere too. In any case, it was a simple mod, probably just a few additional gates or FFs that were already in the machine somewhere. If you look into the Maze code and find where it changes the Imlac's display code, that's likely the only place where you'll find the hardware mod being used. PDL may remember more - I'm pretty sure he's the one who changed the software to use the mod. The other two mods are probably not of concern to the emulator since they involved the RS232 interface. I remember doing something to push the RS232 speed as far as it could go and be reliable - that was important for Maze to reduce latency - i.e., the "muzzle velocity" of the bullets. The other mod was done while sitting in the ballroom of the Washington Hilton, setting up the ICCC '72 demonstration of the ARPANET. That had something to do with RS232 control signals (CTS, RTS, etc.) to make the Imlac work with the ARPANET TIP. Documented? Of course it was documented. Like all software of the day, the "documentation is in the code". In the case of hardware, that meant handwritten changes on the master copy of the Imlac logic diagrams kept in a rack in the machine room. But I suspect those have been lost long ago. /Jack Haverty |
|
Thank you @jh95468, that is great information! The modification we're puzzling over right now is why the range of the argument to DLXA and DLYA (load X/Y accumulator) was extended from 12 to 13 bits, just like the address argument to DJMP and DJMS. X/Y coordinates are just 10 (or possibly 11?) bits. |
|
Sorry, can't help with that. We didn't do any mods that extensive. Is it possible that the Imlac corporation made changes, e.g., to add memory? We had some of the first Imlacs, and we were always complaining about memory in everything. Engineers from Imlac used to occasionally come to MIT-DM and just hang out to see what we were doing, and that probably influenced changes or additions to their next production runs. Maybe they made a mod in anticipation of more memory in the future. Or perhaps MIDAS was changed to permit use of larger addresses, if anyone ever got around to making the hardware changes to do so? Does the code ever set those new bits to other than 0? I do remember one kind of funny "mod". Lick was very much into office automation, and the first Imlac displays were delivered as landscape mode rather than portrait orientation. Lick really wanted them to look like a standard 8-1/2x11 printed page. So Imlac did a mod whereby the displays became portrait mode. The funny part of this is that the change didn't really matter to the hardware. The displayable address space was square, not rectangular. So all the rotation accomplished was to move the non-displayable part of the screen from the top/bottom to the sides. But that may have led to changes, e.g., adding a bit here or there to make more of the screen usable? I never did any Imlac programming, so I don't know about such mods, but if it involved a hardware mod I'm pretty sure it was not done by DM. PDL or GAT would likely know more. |
|
Some information about what happens when the MAZE game is started on the PDP-10.
|
|
I single stepped this in DDT (sometimes using comlink to get to the otherwise disconnected TTY), and right after the ^A^F I got this!
|
|
The 3D view doesn't work yet. |
|
After a while, I get this intermittently. @jdersch, help! |
|
Very hard to say. I had at one point coerced MAZE to run solo (the version
Tom Uban et al had hacked up for VCF back in the day) and the game ran fine
(but wasn't much fun without other players). It's possible the emulation
has regressed since then but I'm unsure what has changed since then.
Pick up my latest sImlac bits; they correct DADR behavior (it is now a
toggle). Probably won't make a difference, MAZE ran on Tom's unmodified
PDS-1D, so who knows...
- Josh
…On Tue, Apr 21, 2020 at 10:51 AM Lars Brinkhoff ***@***.***> wrote:
After a while, I get this intermittently. @jdersch
<https://github.com/jdersch>, help!
[image: maze3]
<https://user-images.githubusercontent.com/775050/79897016-67d7f600-8409-11ea-95b3-fde5b1e8fd72.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG4E7MPFSA7L3KRKKUGQE43RNXMKBANCNFSM4F2SPJKQ>
.
|
|
Was going to send this, but Dave posted his message seconds before me. I'll still send it, even though some information is duplicated. Several MAZE people are inolved. I'm not entirely familiar with the history, but something like this:
|
|
I wrote the Guncher. It was a very simple program, given that ITS had no security. It just looked for certain specific bits of code that were at known addresses in MAZE and killed any program containing them. It was mandated to exist by certain powers-that-were, and it was moderately fun to write, but also trivially easy for anyone who wanted to play to kill the daemon that ran it, or to reassemble MAZE with slightly different locations or contents for the code the Guncher was looking for. A very primitive precursor of anti-virus programs. |
|
Ward -- is this your Maze program?
http://yahozna.dyndns.org/scratch/imlac/maze.png
Seems to match your description, except you hold down "D" to solve, rather
than S...
- Josh
…On Fri, Apr 24, 2020 at 7:12 AM Ward Cunningham ***@***.***> wrote:
Yes, I played with MAZE. With only one machine it took some imagination to
appreciate the work. I also wrote a program that generated and solved large
mazes where each cell was represented by a display call into one of eight
custom characters positioned in memory such that three bits (side wall,
bottom wall and mouse dropping) were easily accessed by the cpu.
http://code.fed.wiki.org/maze.html
Thank you for including me in this discussion. i have a casual interest in
restoring old programs, not so much to be played, but to appreciate the
work from the programmer's perspective, Crowther writing Adventure, for
example. Is the MAZE author here? Or anyone familiar with the creation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG4E7MLTBGAMMGA4MBDE7G3ROGM4TANCNFSM4F2SPJKQ>
.
|
|
@jdersch Wow, it could have been. The solver left bright little dots in the middle of each cell. It would animate both the construction and solution of the maze. This might not be obvious if a simulator were too fast. I would love to be reunited with this source code. |
|
This is Steve Colley's recollections of how he created the 3D maze program: http://www.digibarn.com/history/04-VCF7-MazeWar/stories/colley.html So yes, it was an Imlac program from the very beginning. |
|
On 4/24/20 2:12 PM, Ward Cunningham wrote:
@hpalmer <https://github.com/hpalmer>, @gregt590 <https://github.com/gregt590> and others
wrote MAZE at NASA Ames.
So was it natively an Imlac program? Or clone for Imlac from somewhere else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACROEEIPOQVUSVLOKSBHPNTROHQCXANCNFSM4F2SPJKQ>.
Howard is the one to answer that question.
…--tom
|
|
On 4/24/20 2:17 PM, Lars Brinkhoff wrote:
This is Steve Colley's recollections of how he created the 3D maze program:
http://www.digibarn.com/history/04-VCF7-MazeWar/stories/colley.html
So yes, it was an Imlac program from the very beginning.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACROEEMDALWSIN55HFLBGATROHQVHANCNFSM4F2SPJKQ>.
I was at Purdue late in the Imlac scene. There were two machines, a PDS-1D and a PDS-1 in the EE
building where I hung out. They were both connected via serial port to the "A machine", a PDP-11/70
running BSD Unix. I spent many an hour playing games on them and as I ended up working for the EE
Engineering Computer Network (ECN) as a student, I also had the opportunity to take the two machines
home when they were scrapped. There was also a PDS-1D and a PDS-4 in the Mechanical Engineering
building, neither of which worked, but I was also able to keep the boards from that 1D as spares.
I've always wondered what improvements the PDS-4 had over the 1D. I see in the pictures at the
bottom of the digibarn page that the PDS-4 had a slightly different style of console, in a wood
framed box, with a rotary knob. I purchased a console like that on eBay in 2017 and didn't know it
was from a 4.
…--tom
|
|
Yes, it started on the Imlacs at NASA Ames. We had it running on a
custom local network there. Greg took it to MIT, where it ended up on
the ARPAnet.
The original Ames source code has been lost. For the 30-Year
Retrospective
<http://www.digibarn.com/history/04-VCF7-MazeWar/index.html>, Tom and I
revived an MIT version on his Imlac. That version and the tools I
created to build it are in my github Imlac
<https://github.com/hpalmer/imlac> repo.
Howard
…On 4/24/2020 12:19 PM, Tom Uban wrote:
On 4/24/20 2:12 PM, Ward Cunningham wrote:
>
> @hpalmer <https://github.com/hpalmer>, @gregt590
> <https://github.com/gregt590> and others wrote MAZE at NASA Ames.
>
> So was it natively an Imlac program? Or clone for Imlac from
> somewhere else?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1330 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACROEEIPOQVUSVLOKSBHPNTROHQCXANCNFSM4F2SPJKQ>.
>
Howard is the one to answer that question.
--tom
|
|
Unfortunately I do not have the source, only the binary. I can provide a
machine-disassembly of it if you'd like something to start with.
- Josh
…On Fri, Apr 24, 2020 at 12:15 PM Ward Cunningham ***@***.***> wrote:
@jdersch <https://github.com/jdersch> Wow, it could have been. The solver
left bright little dots in the middle of each cell.
I would love to be reunited with this source code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG4E7MIQH2C7RFTK6QBTQU3ROHQMVANCNFSM4F2SPJKQ>
.
|
|
On Fri, Apr 24, 2020 at 12:31 PM Tom Uban ***@***.***> wrote:
On 4/24/20 2:17 PM, Lars Brinkhoff wrote:
>
> This is Steve Colley's recollections of how he created the 3D maze
program:
> http://www.digibarn.com/history/04-VCF7-MazeWar/stories/colley.html
>
> So yes, it was an Imlac program from the very beginning.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1330 (comment)>, or
unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ACROEEMDALWSIN55HFLBGATROHQVHANCNFSM4F2SPJKQ
>.
>
I was at Purdue late in the Imlac scene. There were two machines, a PDS-1D
and a PDS-1 in the EE
building where I hung out. They were both connected via serial port to the
"A machine", a PDP-11/70
running BSD Unix. I spent many an hour playing games on them and as I
ended up working for the EE
Engineering Computer Network (ECN) as a student, I also had the
opportunity to take the two machines
home when they were scrapped. There was also a PDS-1D and a PDS-4 in the
Mechanical Engineering
building, neither of which worked, but I was also able to keep the boards
from that 1D as spares.
I've always wondered what improvements the PDS-4 had over the 1D. I see in
the pictures at the
bottom of the digibarn page that the PDS-4 had a slightly different style
of console, in a wood
framed box, with a rotary knob. I purchased a console like that on eBay in
2017 and didn't know it
was from a 4.
It increased the directly-accessible resolution to 2048x2048 (a full
11-bits) and increased the drawing and processor speed. It also
incorporated many of the optional enhancements to the PDS-1 (Suppressed
Grid, Variable Intensity, Scissor bits, long vectors etc.) while adding a
few new drawing modes to allow more efficient storage of display lists.
The main processor got a bunch of new instructions and two stack pointers.
It's mostly backwards compatible with the PDS-1D software, one IOT got a
different encoding, and the format for long vectors is completely
different.
The console was updated as you noted, but they shipped versions of the
PDS-1D with those as well (I have one of these, sadly missing the display.)
- Josh
…
--tom
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG4E7MOD3STRRZVFR2RKXG3ROHSJHANCNFSM4F2SPJKQ>
.
|
|
@jdersch Yes, please. I would love to browse a decompiled version. I'd also like to have a running version so that I can impress my friends (or not). |
|
Mostly modifier on the PDP-10 side, some dabbling on the Imlac,
and a modest claim to be the most dangerous player within
my circle of hacker friends.
The wikipedia article <https://en.wikipedia.org/wiki/Maze_War> lists the
initial authors and is accurate as
far as I know, although it necessarily leaves out a lot of details.
I was one of the 3 people at Oracle NPD who re-created Maze (the
article calls it the SQL*Net version) for one of the Oracle conferences
to demonstrate the ability of our network layer to work on any sort of
pipes, as well as the ability of the Oracle Toolkit to work on any platform.
I did all the server side work and some of the client-side maze rendering
algorithms. Amusing fact: I worked from the PDP-10 server source when
re-creating it in the Oracle C environment. That was before the ITS
archives were available, so I used my XGP paper copy.
…--Ken
On Fri, Apr 24, 2020 at 7:55 AM Tom Uban ***@***.***> wrote:
I believe Ken was involved with it, whether that was creator or modifier,
I do not recall...
--tom
On 4/24/20 9:12 AM, Ward Cunningham wrote:
Yes, I played with MAZE. With only one machine it took some imagination to
appreciate the work. I also wrote a program that generated and solved large
mazes where each cell was represented by a display call into one of eight
custom characters positioned in memory such that three bits (side wall,
bottom wall and mouse dropping) were easily accessed by the cpu.
http://code.fed.wiki.org/maze.html
Thank you for including me in this discussion. i have a casual interest in
restoring old programs, not so much to be played, but to appreciate the
work from the programmer's perspective, Crowther writing Adventure, for
example. Is the MAZE author here? Or anyone familiar with the creation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACROEEJ5DGIDVLIBN7QTVA3ROGM4TANCNFSM4F2SPJKQ>
.
|
|
Ward:
The original Maze Wars program, and others that led to it like Steve Colley’s hidden line cube rotation program, were original native Imlac programs (for PDS-1 <https://en.wikipedia.org/wiki/Imlac_PDS-1>, PDS-1D or PDS-4 <http://www.megalextoria.com/wordpress/index.php/2018/06/19/imlac-pds-4/>) written in Imlac Assembly language by Steve Colley, Howard Palmer and myself (Greg Thompson) using a cross-assembler written by Howard and running on IBM TSS/67 <https://en.wikipedia.org/wiki/TSS_(operating_system)>. The Imlac programs were then uploaded from TSS over an IBM channel <https://en.wikipedia.org/wiki/IBM_System/360> connection to an IBM 1800 <https://en.wikipedia.org/wiki/IBM_1800_Data_Acquisition_and_Control_System> Data Acquisition and Control System running an operating and file system we developed on top of the batch-based IBM Multi Programming eXecutive <https://ethw.org/w/images/d/d3/MPXIntroduction.pdf> (MPX) and stored in our file system on 1 platter IBM 2310 <https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives#IBM_2310> and 6 platter 2311 <https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives#IBM_2311> disk drives. (Each removable drive platter held about 1MB - boy have storage densities improved since then). Then Imlac programs via our Imlac bootstrap code/kernel were downloaded over high speed serial communication lines from the IBM 1800 <https://ethw.org/IBM_1800> hosted file system into Imlacs residing throughout NASA/Ames.
When I went to MIT, I took the game and other Imlac utilities and code to J.C.R Licklider <https://en.wikipedia.org/wiki/J._C._R._Licklider>'s MIT Project MAC <https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artificial_Intelligence_Laboratory#Project_MAC> where Maze Wars <https://en.wikipedia.org/wiki/Maze_War> was brought up on the MIT-DMS PDP-10 ITS <https://en.wikipedia.org/wiki/Incompatible_Timesharing_System> system and made available to be download into Imlacs at MIT-DMS. Communication between Imlacs occurred via its serial communication port which was then extended across the Arpanet via programs that PDP-10 ITS programmers Dave Lebling and Jack Haverty wrote. A great book on t
Much of its history is further described in pages found off the Maze War wikipedia site <https://en.wikipedia.org/wiki/Maze_War>. Its Imlac assembly source code <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Mazewar-Imlac-asm.txt> and listing <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Mazewar-Imlac-listing.txt> can be found posted there as well. We got the original Imlac game running on Tom Uban <https://www.youtube.com/watch?v=RbZTzs6te7Q>’s Imlac PDS-1D <http://ubanproductions.com/imlac.html> again for the 30th anniversary VCF event <http://www.digibarn.com/collections/games/xerox-maze-war/> held at the Computer History Museum <http://www.digibarn.com/history/04-VCF7-MazeWar/> held Nov 7, 2004.
- Greg
…-------------------------------
Greg Thompson
Director of Information Systems
Quest Science Center <http://www.quest-science.org/>
i-GATE Innovation Hub <http://www.igateihub.org/> & BRIIA Mentor <https://briia.io/mentors>
Livermore, CA 94550-4333
Personal Email: gregt@alum.mit.edu <mailto:gregt@alum.mit.edu>
LinkedIn: www.linkedin.com/in/grthomps <http://www.linkedin.com/in/grthomps>
In response to:
On Apr 24, 2020, at 12:12 PM, Ward Cunningham <notifications@github.com> wrote:
@hpalmer <https://github.com/hpalmer>, @gregt590 <https://github.com/gregt590> and others wrote MAZE at NASA Ames.
So was it natively an Imlac program? Or clone for Imlac from somewhere else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2S3NSAH3EOBRL3UMISTDTROHQCXANCNFSM4F2SPJKQ>.
|
|
@gregt590 Thank you for this summary. I wonder if you recall aspects of the initial development which we might now call software engineering? For example, were you generally familiar with the who program when you worked on it or did you find a leveraged place and insert your code there? How did you come to understand what had been done before? Was there psudo-code? Did you write psudo-code or flow charts or state-transition tables? There seem to be some thoughtful comments explaining the approach at a high level. Were those always there? Did they evolve substantially before the program stabilized? I remember there were many two or three instruction idioms that were used all the time. I went looking for things I might recognize. This sequence caught my eye: This must be exploiting some carry propagation to some end. The browser's search showed the many places that WPTR2 was used and the highlights in the scroll bar offered insight into how references were distributed: once at the top, once at the bottom, and lots in the middle. I once set out to "preserve" the programming experience for an assembly language program. My experiment in website design included pop-ups for register allocations and common idioms. I'm not sure I could see all that in the program as it exists today but maybe you do and would be interested in such a restoration? Here, for the interested, is one of my restorations: |
|
Ward:
Not sure what you are referring to by “the who program”? However the code was original and wasn’t inserted anywhere at the time, existing only on TSS/360 at NASA/Ames, in our IBM 1800 file system accessed by the Imlac screen-oriented editor we developed for the Imlacs, on listings as printed by the TSS/360 1403 printers, as well as FTPed to MIT-DMS later.
There wasn’t any research as to what was done before. Our primary goals were not to create a game but to investigate the capabilities of the Imlac system which eventually evolved into Maze War and other games. We actually developed a number of Imlac programs including a screen-oriented editor, an interactive debugger, emulations of other graphics terminals (like the Tektronix 4010/4014), download utilities/monitors, other games, etc.
There was no formal pseudo code or flow charts I remember, although I am sure we sketched out on paper various aspects of program design at times as we shared and discussed between Steve, Howard and myself.
The Imlac ISZ instruction (Octal 030 qqq) stood for Increment a location and Skip if Zero. It took two cycles and incremented the specified memory location, skipping the next instruction if the result was zero. The sequence of ISZ instructions effectively implemented its own “carry” between two halves (WPTR and WPTR2) of the pointer. Check out the Imlac PDS-1D Programming Guide <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/PDS-1D_ProgrammingGuide.pdf> and PDS-4 Programming card <http://www.digibarn.com/collections/instructon-set-guides/imlac-card-bw/index.html> for further information.
Note that WPTR is located at offset 105 (everything for Imlac is shown and listed in octal) but the 16-bit code for the ISZ instruction (“030000”) in the posted listing does not include the qqq displacement to the WPTR variable stored in the bottom 9 bits. I forget where we found the listing posted, but I am sure the Imlac code listings from the cross assembler Howard developed on TSS/360 did show the currect displacement values. I think this listing was from the MIDAS assembler running on ITS that could generate Imlac code through using lots of instruction macros with displacement values patched in prior to finishing or downloading the program binary.
Also be careful in that there are a number of auto-increment memory locations at locations 10 to 17 (octal) in each 2K block of memory. That was an unusual feature of the Imlac instructions set.
I wrote most of the comments you will find in the code. Steve didn’t tend to add comments if I remember right. However I always found them helpful, not only to document the code and design for others but also to help me remember the function & purpose of different parts of the code.
- Greg
In response to:
On Apr 25, 2020, at 7:14 PM, Ward Cunningham <notifications@github.com> wrote:
@gregt590 <https://github.com/gregt590> Thank you for this summary.
I wonder if you recall aspects of the initial development which we might now call software engineering? For example, were you generally familiar with the who program when you worked on it or did you find a leveraged place and insert your code there? How did you come to understand what had been done before? Was there psudo-code? Did you write psudo-code or flow charts or state-transition tables? There seem to be some thoughtful comments explaining the approach at a high level. Were those always there? Did they evolve substantially before the program stabilized?
I remember there were many two or three instruction idioms that were used all the time. I went looking for things I might recognize. This sequence caught my eye:
02030 030000 ISZ WPTR
02031 030000 ISZ WPTR2
02032 030000 ISZ CNT
02033 010000 JMP PRNT1
This must be exploiting some carry propagation to some end. The browser's search showed the many places that WPTR2 was used and the highlights in the scroll bar offered insight into how references were distributed: once at the top, once at the bottom, and lots in the middle.
I once set out to "preserve" the programming experience for an assembly language program. My experiment in website design included pop-ups for register allocations and common idioms. I'm not sure I could see all that in the program as it exists today but maybe you do and would be interested in such a restoration?
Here, for the interested, is one of my restorations:
http://c2.com/ward/pdp8sim/ <http://c2.com/ward/pdp8sim/>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2S3NX7YMS73RJP4MFW4SDROOKJDANCNFSM4F2SPJKQ>.
|
|
If you're interested in assembly-language "experience", this might be interesting: https://inwap.com/pdp10/hbaker/hakmem/hacks.html See items 145 onward. I've wondered for 50 years how some of these "hacks" were discovered (software engineered?). There was a class of die-hard assembly language programmers that we called "bit-twiddlers". That was a compliment. It meant that they could wring the last bit of memory and cpu power out of the machines of the era by "clever hacks", i.e., programming constructs that were somewhat outlandish but worked. /Jack Haverty |
|
I can testify that debugging those clever hacks now is a dual delight/headache. Happy to report that all outstanding issues with Maze have been solved. (For now.) @jdersch's latest version of the @livingcomputermuseum sImlac emulator does run SSV 22 and MAZE. |
|
Here's a video: |
|
Is that a PDS-1 or PDS-1D? Doesn't maze require long vectors?
…--tom
On 4/30/20 1:27 PM, Lars Brinkhoff wrote:
Here's a video:
https://youtu.be/jYRFDLYPeTU
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACROEEIGBC6AJVQCD4NGWS3RPG7KXANCNFSM4F2SPJKQ>.
|
|
That is @jdersch's PDS-1D emulator: |
|
Very nice! It sure looks exactly as I remember it. Just curious - does anyone remember a 3D version of Maze, or see any evidence of such a beast in the artifacts? I vaguely recall a brainstorming session many decades ago where a bunch of us were trying to solve the problem of certain people having become so proficient with Maze that no one else could survive more than a few seconds with them around. There were several ideas. One was simply to extend the maze size so it would be harder for one player to dominate the whole Maze world. That evolved into the idea of a 3D Maze. In addition to corridors heading left and right, there could be corridors heading up and down. Going forward when you were facing a wall would cause you to climb up that wall, and the maze would rotate so the wall became the new floor. Similarly going forward at the edge of a "cliff" (corridor heading downward) would rotate you 90 degrees onto that corridor as the new floor. IIRC, this actually got programmed at least far enough to try it out by walking around a 3D maze, and the conclusion was that it was so confusing that even the experts (KLH.....!) wouldn't be able to master it. It was really difficult to "get your bearings" after a few quick moves in 3D space. But I can't remember much beyond that, and don't have any memory of ever playing in a 3D multiplayer battle. Maybe that was happening just as I left MIT. Does anybody else remember anything like this? It might be fun to play such a game...anyone planning to port Maze to IOS/Android, or maybe as a Web app? SpaceMaze? /Jack Haverty |
|
I understand it is on the simulator, but because it says PDS-1 (instead of PDS-1D) at the top of the
display, it is confusing as to the machine which is being simulated.
…--tom
On 4/30/20 2:22 PM, Lars Brinkhoff wrote:
That is @jdersch <https://github.com/jdersch>'s PDS-1D emulator:
https://github.com/livingcomputermuseum/sImlac
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACROEEKQWC5DW3QNM57XRK3RPHFXHANCNFSM4F2SPJKQ>.
|
|
The exact definition of these machines is a bit fuzzy and no two machines
were alike :). The LVH-1 (Long Vector) option was available for the PDS-1,
for example, which still didn't make it the equivalent of a PDS-1G (which
had a slightly faster processor and was a redesign/repackaging of the
PDS-1). I believe the 1G included this by default, the 1D might not have.
My PDS-1D has a hand-made wire-wrapped LVH option board in it :).
But yes, I do need to update the titlebar, perhaps...
- Josh
…On Thu, Apr 30, 2020 at 12:55 PM Tom Uban ***@***.***> wrote:
I understand it is on the simulator, but because it says PDS-1 (instead of
PDS-1D) at the top of the
display, it is confusing as to the machine which is being simulated.
--tom
On 4/30/20 2:22 PM, Lars Brinkhoff wrote:
>
> That is @jdersch <https://github.com/jdersch>'s PDS-1D emulator:
> https://github.com/livingcomputermuseum/sImlac
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1330 (comment)>, or
unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ACROEEKQWC5DW3QNM57XRK3RPHFXHANCNFSM4F2SPJKQ
>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1330 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG4E7MNWT6T6FB3N23D75ILRPHJS7ANCNFSM4F2SPJKQ>
.
|
|
Jack:
The hardware version of Maze that Mark Horowitz, George Woltman and I built for the 6.111/6.112 digital design class in 1976 was 3D with up/down vertical shafts in addition to the normal left/right corridors. It used a 16x16x16 maze that you could load or change by loading it (4-bits per ASCII character) via a paper tape reader into the 1024 x 4 bit (512 byte) board memory card (which used four LSI 2102 chips). The demonstration maze we created implemented 4 floors (at Z=0, Z=3, Z=7 and Z=10) with the other levels becoming floors and ceilings. Of course the implementation was symmetric so if you tilted up or down, what was an up/down shaft became a corridor. George's software supported 1 to 4 human players along with a robot implemented in the 256 16-bit instructions plus 512 bytes of scratch and variable memory. Mark designed the display processor and I did the TTL-based main Maze processor design.
The hardware Maze game report <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Hardware_Maze_Game_Report.pdf> with schematics, design notes and code listing, as well as the 6.11/6.112 class TTL boards specifications <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Hardware_Maze_Game_Boards.pdf> can be found posted on the Maze War wikipedia page if you want further information.
This “hardware version" of Maze War at the time showed the game could be implemented at one to two orders-of-magnitude less cost than compared to the general purpose $8,300 PDS-1, $9,970 PDS-1D or $17,300 PDS-4 Imlacs.
- Greg
In response to your question about a 3D version of Maze:
On Apr 30, 2020, at 12:41 PM, Jack Haverty <notifications@github.com> wrote:
Very nice! It sure looks exactly as I remember it.
Just curious - does anyone remember a 3D version of Maze, or see any evidence of such a beast in the artifacts?
I vaguely recall a brainstorming session many decades ago where a bunch of us were trying to solve the problem of certain people having become so proficient with Maze that no one else could survive more than a few seconds with them around.
There were several ideas. One was simply to extend the maze size so it would be harder for one player to dominate the whole Maze world. That evolved into the idea of a 3D Maze. In addition to corridors heading left and right, there could be corridors heading up and down. Going forward when you were facing a wall would cause you to climb up that wall, and the maze would rotate so the wall became the new floor. Similarly going forward at the edge of a "cliff" (corridor heading downward) would rotate you 90 degrees onto that corridor as the new floor.
IIRC, this actually got programmed at least far enough to try it out by walking around a 3D maze, and the conclusion was that it was so confusing that even the experts (KLH.....!) wouldn't be able to master it. It was really difficult to "get your bearings" after a few quick moves in 3D space.
But I can't remember much beyond that, and don't have any memory of ever playing in a 3D multiplayer battle. Maybe that was happening just as I left MIT.
Does anybody else remember anything like this? It might be fun to play such a game...anyone planning to port Maze to IOS/Android, or maybe as a Web app? SpaceMaze?
/Jack Haverty
MIT-DM 1970-1977
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2S3NUEDCGC7IVYPKUHWADRPHH5TANCNFSM4F2SPJKQ>.
|
|
Actually checking the implementation (its been a while) the hardware maze game implemented up to 8 players of which up to 4 could be human players as well as 4 robots. The human player’s displays were Tektronix oscilloscopes using the Z input to turn on/off the beam as needed as it drew each players view.
- Greg
P.S. I also just added the 1977 Auerbach Corp report <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Auerbach_Imlac_1977_report.pdf> on the Imlac PDS Graphic Display Computer to the Maze War page <https://en.wikipedia.org/wiki/Maze_War#Sources> for reference.
Adding to:
On Apr 30, 2020, at 2:14 PM, Greg Thompson <gregt1657@gmail.com> wrote:
Jack:
The hardware version of Maze that Mark Horowitz, George Woltman and I built for the 6.111/6.112 digital design class in 1976 was 3D with up/down vertical shafts in addition to the normal left/right corridors. It used a 16x16x16 maze that you could load or change by loading it (4-bits per ASCII character) via a paper tape reader into the 1024 x 4 bit (512 byte) board memory card (which used four LSI 2102 chips). The demonstration maze we created implemented 4 floors (at Z=0, Z=3, Z=7 and Z=10) with the other levels becoming floors and ceilings. Of course the implementation was symmetric so if you tilted up or down, what was an up/down shaft became a corridor. George's software supported 1 to 4 human players along with a robot implemented in the 256 16-bit instructions plus 512 bytes of scratch and variable memory. Mark designed the display processor and I did the TTL-based main Maze processor design.
The hardware Maze game report <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Hardware_Maze_Game_Report.pdf> with schematics, design notes and code listing, as well as the 6.11/6.112 class TTL boards specifications <https://s3-us-west-2.amazonaws.com/tmmeng/Maze/Hardware_Maze_Game_Boards.pdf> can be found posted on the Maze War wikipedia page if you want further information.
This “hardware version" of Maze War at the time showed the game could be implemented at one to two orders-of-magnitude less cost than compared to the general purpose $8,300 PDS-1, $9,970 PDS-1D or $17,300 PDS-4 Imlacs.
- Greg
In response to your question about a 3D version of Maze:
On Apr 30, 2020, at 12:41 PM, Jack Haverty <notifications@github.com <mailto:notifications@github.com>> wrote:
Very nice! It sure looks exactly as I remember it.
Just curious - does anyone remember a 3D version of Maze, or see any evidence of such a beast in the artifacts?
I vaguely recall a brainstorming session many decades ago where a bunch of us were trying to solve the problem of certain people having become so proficient with Maze that no one else could survive more than a few seconds with them around.
There were several ideas. One was simply to extend the maze size so it would be harder for one player to dominate the whole Maze world. That evolved into the idea of a 3D Maze. In addition to corridors heading left and right, there could be corridors heading up and down. Going forward when you were facing a wall would cause you to climb up that wall, and the maze would rotate so the wall became the new floor. Similarly going forward at the edge of a "cliff" (corridor heading downward) would rotate you 90 degrees onto that corridor as the new floor.
IIRC, this actually got programmed at least far enough to try it out by walking around a 3D maze, and the conclusion was that it was so confusing that even the experts (KLH.....!) wouldn't be able to master it. It was really difficult to "get your bearings" after a few quick moves in 3D space.
But I can't remember much beyond that, and don't have any memory of ever playing in a 3D multiplayer battle. Maybe that was happening just as I left MIT.
Does anybody else remember anything like this? It might be fun to play such a game...anyone planning to port Maze to IOS/Android, or maybe as a Web app? SpaceMaze?
/Jack Haverty
MIT-DM 1970-1977
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2S3NUEDCGC7IVYPKUHWADRPHH5TANCNFSM4F2SPJKQ>.
|
|
Wow, yes, that's probably what I remember. I didn't recall that it was hardware. Must have taken quite a lot of work too. Six or seven years prior to your project, Ken Pogran and I did a digital project lab (6.711 then) which built a word-processor, with a tty/tape reader and a memory that could store a bunch of pages of text, for display and editting on a 4-line CRT (possibly the same Tektronix you guys used...). Kind of a primitive WYSIWYG editor machine a la Emacs. Lots of fun even though it never worked - the memory was an acoustical delay line (only large memory available back then) and it didn't play well with the noise created by the tty activity. We were the first proejct ever to get an A with a project that didn't work after the TAs and Prof concluded that the acoustical memory should never have been made available. I still have my project report; a few years ago it even went in to court as evidence of prior art for a patent fight. Your Maze Machine was cheaper than an Imlac but must have been less powerful. I bet it didn't even have a way to burn out an amp in the display. Maze was very popular; I remember when we brought it to Interop in 1992, the lines to play were always long. Curious that it never made it to the modern gaming world; I bet it would still be popular. /Jack |
Use @livingcomputermuseum's sImlac to run MAZE.
The text was updated successfully, but these errors were encountered: