LisaList2

Hooked up a cable tap with a saleae on it
Here are the traces doing a boot, and blu ID and spindown
http://bitsavers.org/projects/datatower/d7-d0_a2-a0_wr_rd_rst_req

I'm trying to test Alex's priam interface board.
So far, no joy. Trying on a couple of different drives and controllers I can't get the drive to spin up.
In BLU, ID returns error 8000E5CB and spin down returns 9A40E5CB but I have no idea what those status
bytes correspond to looking at the DS101 document

Congrats!

FWIW, I made a repo of some source files that were compiled on Uniplus a few years ago, including a prehistoric version of Kermit.

https://github.com/arcanebyte/uniplus

Oh snap! I am absolutely going to go through these; getting a working Kermit client on UniPlus would be amazing (and save so much time for future projects I have in mind). I see an xmodem client in there as well and... is that a BBS server? What the heck, lol?

Also, as promised, the GitHub repo for UniPlus Zork. Altogether, the brunt of the work was getting some stuff in supp.c cleaned up; there were some extremely minor formatting issues that needed to be corrected here and there, but this thing by and large cooperated where it needed to. I ultimately managed to enable the 24-row pause function where, if it runs up 23 rows of text on your VT100-compatible terminal, it will prompt you to hit enter to continue. There aren't a ton of places where this is required, but it's absolutely game-breaking if you don't have it enabled and vital text runs right off the screen. The repo has the source files, a compiled binary, and three DC42 disk images: source_files and additional_data are for compiling from source and bin_install just has a compiled version of the game (and its data file) that running the installer script on the disk will copy into the right places. If you're going to be at VCF Southwest this coming weekend (in the Davidson-Gundy Alumni Center at the University of Texas at Dallas - 6/14-16), stop on by and have a play. Alex and I are planning on having five Lisas running every major OS they support - LOS, MacOS, GEM, UniPlus, and Xenix - along with a bunch of other Apple hardware to interact with!

I also need to update my uuencode/decode repo; I went back and retooled it to work similarly to how the actual binaries are supposed to work and not just a hack-job thing I slapped together to get files moving.

Congrats!

FWIW, I made a repo of some source files that were compiled on Uniplus a few years ago, including a prehistoric version of Kermit.

https://github.com/arcanebyte/uniplus

Thank you, all. I think we have a solution at hand. More to come.

If you have a Lisa 1, you should be able to archive them with Basic Lisa Utility!

-J

Once again, congratulations on getting this running! Everyone at VCF is definitely going to enjoy messing with this and as you said, it's really awesome that the first piece of software to be compiled on Lisa Unix in years is something as significant as Zork. Great work, Will!

So, VCF Southwest is next weekend and I've been working off and on for several weeks on something special to let folks play with on one of my Lisas. The original Zork (eventually renamed to Dungeon and then back to Zork) was written in MDL on the PDP-10, then ported to FORTRAN77 for the PDP-11 by Bob Supnik in 1978, and subsequently released to the public sometime in 1980 (as F77 source code). It would eventually get converted to C (not ported, per se) by way of the FORTRAN to C converter (appropriately named "f2c"). I knew the F77 version was floating around for a long time, but I'd never seen the C version prior to a few months ago. After getting Xenix running on one of my Lisas, I figured "hey, why not try to get it running?" and set out to do just that.

Well, it turns out Xenix is... less than favorable to work with - for me, at least. I do have some experience as a *nix administrator, so I felt like I wouldn't be stepping into a complete void when it came to working with the OS. Xenix, though, just seemed to fight me at every turn. It crashed a lot (though some of that may have been a hardware issue); I could not get floppies to read/write for the life of me; the serial connection was very flakey; and, probably worst of all, the C compiler seemed to have problems with even fairly elementary code despite ensuring that I was writing K&R C that met the syntactical requirements of the - contemporaneous - copy of "The C Programming Language" I have. In defense of the compiler, however, I was initially working with constants and those did not exist in the version of K&R C it expects to work with. After finally throwing in the towel on Xenix, I decided to try out UniPlus if for no other reason than it had an F77 compiler and I could at least fall back on that if needed.

So, I got UniPlus up and running after getting some help in the form of a ProFile image from Alex and decided to take another swing at things. On the whole, UniPlus was much, much easier on they eyes (both figuratively and literally) - I've only had it crash once and that was my fault; it reads and writes floppies with no issue; and serial communication is dead simple to setup. Once I had it up and running, I was consoled in via TeraTerm in minutes: connect to serial port "B" and set the terminal to 9600,7N1 with no flow control and you're in like Flynn. Since UniPlus had an F77 compiler, I decided to start there due to my misadventures with C in Xenix. It was... not a pleasant experience. My experience with FORTRAN is hindered by two things: first, the experience I do have is with much more recent versions (some folks at my work use software written in F90 that we maintain) and, second, it's not my strong suit by any means. After running into a bevy of errors, I decided to take another swing at C on this version of Unix and put FORTRAN away for the moment. This was, ultimately, the right choice...

The C source for Zork has 33 C source files, a handful of headers, and one binary data file. That last one was going to be tricky, as I didn't readily have a way to get binary data across the wire to the Lisa, just text via TeraTerm. We'll come back to that, though. I started going file by file looking for anything glaring that I knew would be an issue. Since by this point I knew CONSTs were out of the question, I started with looking for them and removing them. Much of the C was already K&R formatted, so little needed to be changed in that regard. Much of what would ensue was going through each file and making sure that the appropriate libraries were being referenced (and that they actually existed, lol - neither Xenix nor UniPlus have the stdlib.h library, for instance), that there weren't any obvious syntax issues, and that any ANSI C was replaced with something UniPlus' compiler would be more accepting of. Once that was done, I would fire up ed in append mode in TeraTerm on the Lisa and drop the contents of the file into it, then save and ensure that the file size on the Lisa matched the file size on my desktop. Lather, rinse, and repeat for everything that remained. In order to break things down to be a bit more manageable (since I knew that total compile time would be... lengthy), I started compiling each C file to an object file and watching for errors. As one would expect, there were inevitably some errors that needed fixing but nothing ever got crazy. Except for one file - supp.c. Supp.c is responsible for two things: timekeeping and determining the type of terminal that Zork would be running on. Bob built in a few really creative but simple mechanisms for determining this when compiling; this ultimately meant that Zork could run on just about anything - even a legit teletype, if that was all you had. There isn't a ton of documentation of the types of terminal interfaces C in UniPlus supports (outside of termio.h), so I just hard-coded the "effectively a teletype" option that pays no attention to the terminal's capabilities and just spews out text. If it worked, I figured I could come back and try again with more robust settings. This went fine until it got to the last function in supp.c, at which point I got a "multiply defined symbol" error. The compiler did not say anything about where I was encountering this error in the file; I just figured that out by removing functions one-by-one until it compiled. As it turned out, this function was not technically necessary as I was compiling it with the option to just stream out text and disregard terminal capabilities; if it ran, it would not need the work done by that function to take place at all anyway. Once I had that figured out (and it compiled successfully), I still needed to get the game's database file copied over. No big deal, uuencode existed by the time UniPlus was out, so it should be on here, right? Nope.

So, the next thing I needed was a way to get binary data over the wire to UniPlus, but how? Well, I'm a stubborn person and like figuring things for myself so I threw together a very quick and dirty implementation of uuencode and uudecode for UniPlus, the source for which is available here: UniPlus uuencode/uudecode. It compiled and ran successfully in UniPlus and decoded the game's data file with zero issues after having been encoded on my desktop with the native uuencode function in Linux. I can't imagine there's much need for this but if anyone out there wants to tinker with UniPlus a bit more and needs to get binary data over serial, the option to do so now exists. So, on to the next step.

Once I had the game's database file copied over, I was ready to compile. The Makefile included with the C source is almost directly compatible with the make binary in UniPlus; it won't put things where they need to go once it finishes, so I've still got that to work out, though. Other than that, I was ready to hit the proverbial big red button. I typed in "make" and hit enter and waited... and waited some more... and some more... aaaaaand then I hit an error. I went back and fixed what it was complaining about (I've completely forgotten as it was entirely inconsequential) then ran make again... and waited about 20 minutes. The result?



This was about 11:30-12:00 at night and I shouted so loud I figured I must have woken up our 14 month old (thankfully I did not!) when I typed in "zork" and hit enter and it prompted me with "Welcome to Dungeon / You are standing in an open field west of a big white house with a boarded front door. There is a small mailbox here." I am beyond ecstatic that this just... worked! I'm going to clean up some things I did for testing purposes and fix a couple other non-game-breaking bugs but, other than that, this just runs with no issue. Once I have the last dribs and drabs of things cleaned up, I'll post the source, binaries, and disk images with both on my GitHub and link them here. I should have this done by the end of the week.

All said and done, this was absolutely worth the off and on work (and frustration) over the last several weeks I've put into it. Talking with Alex, he pointed out that this may be the first piece of "new" software compiled for Lisa Unix since maybe the mid-1980s. If that's the case, I'm absolutely thrilled it was Zork; this was a huge piece of my introduction to computers as a whole when I was a little kid and had a major influence over how I've viewed and worked with them ever since. Heck, these games even helped me learn to read better when I was young. Needless to say, I look back very fondly on this entire series (and type of game in general). No DECsystem Lisa should be without one!

Wanted to provide an update (and thanks!) on this. Alex sent me an image that has worked swimmingly on my ArduinoFile and, boy oh boy, UniPlus is an infinitely less sensitive OS than Xenix (and a much more pleasurable experience overall - for a Unix OS, anyway). I need to take a look at the image compu_85 posted as well and compare the two at some point.

I'll be posting another thread about Zork/Dungeon, but working with UniPlus has been a fairly frustration-free endeavor. I can connect over serial without issue and format floppies just fine, unlike Xenix; I plan on imaging some test floppies in the near future and seeing if a modern Linux distro that still has SYSV filesystem support can peer into them. If so, that will make future development tasks a bit easier. One of the issues I did run into (that also appears to be the case with Xenix) is a lack of uuencode/uudecode support. As a result, I ended up writing a quick and dirty implementation of both for UniPlus that have so far worked without issue. I'll post a link in the Zork thread.

Thank you to everyone for your help on this!

Very happy to help, but unless the owner travels to London with some frequency, there are likely to be much more convenient options!