Closed larsbrinkhoff closed 4 years ago
Josh wrote (about Maze War):
It also requires that SSV's font still be resident in memory
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 ☺.
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 @tubanhttps://github.com/tuban's Imlac software libraryhttp://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
@jh95468https://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 GitHubhttps://github.com/PDP-10/its/issues/1330#issuecomment-428447553, or mute the threadhttps://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 https://github.com/PDP-10/its/issues/1330#issuecomment-429414676, 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 https://github.com/PDP-10/its/issues/1330#issuecomment-429414676, 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 GitHubhttps://github.com/PDP-10/its/issues/1330#issuecomment-429429003, or mute the threadhttps://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 https://github.com/PDP-10/its/issues/1330#issuecomment-434201246, 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:
; ALL CHARACTERS SUBROUTINES AND THE DJMS TABLE IS UP IN THE CONSOLE PROGRAM (SSV).
The characters are in the file SSV CHARS, which is .INSRTed into SSV 52. SST does that too.
Inching forward. I have ITS loading programs onto the Imlac emulator, and @tuban's "SSV 22" works ok. However, there's a suspicion the MIT programs expect some undocumented hardware modification. @jdersch and I are looking into this.
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 https://github.com/PDP-10/its/issues/1330#issuecomment-614012726, 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 MIT-DM 1970-1977
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...
On Tue, Apr 21, 2020 at 10:51 AM Lars Brinkhoff notifications@github.com 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 https://github.com/PDP-10/its/issues/1330#issuecomment-617316582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4E7MPFSA7L3KRKKUGQE43RNXMKBANCNFSM4F2SPJKQ .
This is just a shot in the dark... Take a look at what happens when the display processor finishes going through its entire display program. In particular, how does it decide when to start the display program back at the beginning of the display code.
I'm wondering if this behavior reflects a timing issue and coordinating between the 2 processors in the Imlac. I've seen that happen before in modern emulations of ancient (slowwwww) hardware (the recent resurrection of the ARPANET IMP code), where the modern code runs too fast and causes weird behavior.
Great progress though! /Jack
Oh, looked at the emulator console and see a lot of these:
PPM-1 not implemented (instr 035100)
As to whether my PDS-1D was modified or not that is likely was. It was from Purdue EE where they were pretty much in the loop and were not afraid to make mods. It certainly ran the program back in the day, but they did not have a PDP-10, only PDP-11s...
--tom
On 4/21/20 1:00 PM, jdersch wrote:
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 notifications@github.com 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 https://github.com/PDP-10/its/issues/1330#issuecomment-617316582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4E7MPFSA7L3KRKKUGQE43RNXMKBANCNFSM4F2SPJKQ .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-617321314, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEEOCILURGZPJNMQGLETRNXNLFANCNFSM4F2SPJKQ.
Fair enough. At the time that I had MAZE running on sImlac, sImlac did not have the MIT DADR mods implemented (that only came to be last week).
From: Tom Uban notifications@github.com Sent: Tuesday, April 21, 2020 11:49:35 AM To: PDP-10/its Cc: Josh Dersch; Mention Subject: Re: [PDP-10/its] Run Maze War (#1330)
As to whether my PDS-1D was modified or not that is likely was. It was from Purdue EE where they were pretty much in the loop and were not afraid to make mods. It certainly ran the program back in the day, but they did not have a PDP-10, only PDP-11s...
--tom
On 4/21/20 1:00 PM, jdersch wrote:
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 notifications@github.com 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 https://github.com/PDP-10/its/issues/1330#issuecomment-617316582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4E7MPFSA7L3KRKKUGQE43RNXMKBANCNFSM4F2SPJKQ .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-617321314, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEEOCILURGZPJNMQGLETRNXNLFANCNFSM4F2SPJKQ.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/PDP-10/its/issues/1330#issuecomment-617347618, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE44TBY3J27FVLTRTA25RCLRNXTD7ANCNFSM4F2SPJKQ.
Is someone keeping a document of the various mods/additions?
--tom
On 4/21/20 1:54 PM, Living Computers: Museum+Labs wrote:
Fair enough. At the time that I had MAZE running on sImlac, sImlac did not have the MIT DADR mods implemented (that only came to be last week).
- Josh
From: Tom Uban notifications@github.com Sent: Tuesday, April 21, 2020 11:49:35 AM To: PDP-10/its Cc: Josh Dersch; Mention Subject: Re: [PDP-10/its] Run Maze War (#1330)
As to whether my PDS-1D was modified or not that is likely was. It was from Purdue EE where they were pretty much in the loop and were not afraid to make mods. It certainly ran the program back in the day, but they did not have a PDP-10, only PDP-11s...
--tom
On 4/21/20 1:00 PM, jdersch wrote:
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 notifications@github.com 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 https://github.com/PDP-10/its/issues/1330#issuecomment-617316582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4E7MPFSA7L3KRKKUGQE43RNXMKBANCNFSM4F2SPJKQ .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-617321314, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEEOCILURGZPJNMQGLETRNXNLFANCNFSM4F2SPJKQ.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/PDP-10/its/issues/1330#issuecomment-617347618, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE44TBY3J27FVLTRTA25RCLRNXTD7ANCNFSM4F2SPJKQ.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-617350193, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEEO75SRYC6KKTHJXNR3RNXTXXANCNFSM4F2SPJKQ.
@tuban, that raises an interesting question. Where did the Imlac version of MAZE go? I understand it was moved to MIT's Architecture Machine group. You mention Purdue. There are many accounts it was played over Arpanet, but between which sites? @dlebling618 says USC. The Stanford AI lab had a few Imlacs too, but I don't know if the game was played there.
There was another version of Maze in the early 80s timeframe, which ran on Xerox hardware (Altos, IIRC). People may be confusing Imlac Maze and Alto Maze. I don't know if Alto Maze was developed independently or somehow "ported" from Imlac but IIRC it looked very similar to the players.
The latest problem with MAZE has been located. A subroutine is using direct addressing to read from an array called WALLS, but the array is not in the same 2K region as the subroutine. This doesn't work with the Imlac address calculation. Strangely, this is commented on in the source code, but indirect addressing isn't used. WALLS ends up at 14011. So actually some of the constants are in peril too.
; constants go here at end of this 2k !!!!! any refs to or from
; succeeding 2k must be indirect-address! bleah!!!!!! (klh)
;
CONSTANTS
^L
;loc 14000 ;happens about here anyway, just needs precision.
;
; distances to walls table
;
WALLS: 511. ; distances to walls
CC'ing Mr. Harrenstien on this :) He likely also has memories of other interesting details...
On 4/23/20 2:12 PM, Lars Brinkhoff wrote:
The latest problem with MAZE has been located. A subroutine is using direct addressing to read from an array called WALLS, but the array is not in the same 2K region as the subroutine. This doesn't work with the Imlac address calculation. Strangely, this is commented on in the source code, but indirect addressing isn't used. WALLS ends up at 14011. So actually some of the constants are in peril too.
|; constants go here at end of this 2k !!!!! any refs to or from ; succeeding 2k must be indirect-address! bleah!!!!!! (klh) ; CONSTANTS ^L ;loc 14000 ;happens about here anyway, just needs precision. ; ; distances to walls table ; WALLS: 511. ; distances to walls |
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-618602672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEENIDZJU6FKLY4D4MITROCHJ3ANCNFSM4F2SPJKQ.
One thing that stood out in my copy of the Imlac MAZE code was the addition of a particular code block. Removing this, WALLS got back in 2K addressing range and I was rewarded by a good looking 3D view.
Nice! What code block is this?
On Thu, Apr 23, 2020 at 12:41 PM Lars Brinkhoff notifications@github.com wrote:
One thing that stood out in my copy of the Imlac MAZE code was the addition of a particular code block. Removing this, WALLS got back in 2K addressing range and I was rewarded by a good looking 3D view.
[image: works] https://user-images.githubusercontent.com/775050/80142109-eb7d1880-85aa-11ea-8ea4-ab0e57107948.png
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-618621312, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4E7MNL4RYPP6HAWD3PTS3ROCKXTANCNFSM4F2SPJKQ .
It's LOADER: https://github.com/PDP-10/its/blob/31c1ae881c39b341da872083dd28ed9f76a6c909/src/imsrc/maze.3#L284-L300
LOADER is the start address, so after MAZE is loaded, we'll execute this code. It waits for two ^A characters sent from the PDP-10, and then jumps to the bootstrap at 40. Which will then accept the data for the maze.
I believe this may have been put in as a shortcut. Other versions lack the LOADER subroutine and have 101 as the starting address. Since MAZE loads to 10000, SSV remains intact in the lower 4K. 101 is SSV's reinitialization entry point. ^A^A is the SSV command to make it jump to the bootstrap.
I wrote about the loading process here: https://github.com/PDP-10/its/issues/1330#issuecomment-617303828
If this is related to some sort of Imlac emulator, you also have to emulate the so-called "8K mod", which was a hardware thing.
--Ken
On Thu, Apr 23, 2020 at 12:16 PM Tom Uban tom@figureeightbrewing.com wrote:
CC'ing Mr. Harrenstien on this :) He likely also has memories of other interesting details...
On 4/23/20 2:12 PM, Lars Brinkhoff wrote:
The latest problem with MAZE has been located. A subroutine is using direct addressing to read from an array called WALLS, but the array is not in the same 2K region as the subroutine. This doesn't work with the Imlac address calculation. Strangely, this is commented on in the source code, but indirect addressing isn't used. WALLS ends up at 14011. So actually some of the constants are in peril too.
; constants go here at end of this 2k !!!!! any refs to or from ; succeeding 2k must be indirect-address! bleah!!!!!! (klh) ;
CONSTANTS
^L ;loc 14000 ;happens about here anyway, just needs precision.
; ; distances to walls table ; WALLS: 511. ; distances to walls
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1330#issuecomment-618602672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEENIDZJU6FKLY4D4MITROCHJ3ANCNFSM4F2SPJKQ .
@tuban:
No, no one is documenting the modifications. Good idea though. Would a new issue here on GitHub be ok? Makes it easy to participate.
If you CC Harrenstien the GitHub email, I'm not sure his reply will make it back here.
@jdersch and I have the 8K mod figured out (well mostly...) and implemented.
I see @WardCunningham was also at Purdue programming Imlacs. I wonder if he played MAZE?
Video of MAZE on real PDS-1D. https://www.youtube.com/watch?v=CF9XKRWnsTY
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 #167, for example. Is the MAZE author here? Or anyone familiar with the creation?
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 https://github.com/PDP-10/its/issues/1330#issuecomment-619034973, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACROEEJ5DGIDVLIBN7QTVA3ROGM4TANCNFSM4F2SPJKQ.
Greg Thompson brought the original maze display code to MIT on paper tape from NASA Ames. Dave Lebling (the person typing this) is here. Greg and I collaborated to create the "game." (I also wrote the Maze builder referred to in another thread.) Tak To wrote the Maze Watcher for the E&S LDS-1 Ken Harrenstein did significant speed and protocol improvements.
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.
@hpalmer, @gregt590 and others wrote MAZE at NASA Ames.
So was it natively an Imlac program? Or clone for Imlac from somewhere else?
Use @livingcomputermuseum's sImlac to run MAZE.