The code is ready (I think). I’ve made it available in the following locations:
github: https://github.com/urbancamo/vaxlander28g
wickensonline.co.uk: http://wickensonline.co.uk/static/files/rc202004/vaxlander28g.zip
The zip file contains a VAX/VMS executable that will run on a SIMH OpenVMS 7.3 instance without needing to install BASIC to compile.
Enjoy!
So I have been working hard over the last couple of days to convert my BBC lander program to VAX Basic. This has not been a trivial task! I decided that I would try and make use of the structured programming facilities available. This requires that sub modules are in separate source files, so I have had to split the single BASIC source file up into lots of files.
This evening I got to the point where the program would run and I’ve started ironing out the bugs. There are a few more to go, but it is looking quite like the original now.
So, just a quick update, I haven’t forgotten about RetroChallenge! I remembered that the VAX version of BASIC includes graphics support via the GKS library and thought I might be able to make use of that to code up a graphical version of my BBC BASIC Lander.
VAX BASIC is quite different from BBC BASIC, and I have been keen to make the most of the structured elements of the language. As it stands I currently have a single source file that needs splitting into separate source files, each one containing a sub-routine. I have encapsulated the global variables into two records: GameState and LanderState. I’m just trying to figure out how to share the RECORD definition between sub-modules.
Please bear with!
I’ve been paying more attention to vintage computing since my portable amateur radio activities have been curtailed due to COVID-19. I recently found an excellent youtube video:
Bob Supnik being a key figure from DEC’s history and also implementer of the VAX emulation in SIMH.
There was also a very interesting post on the HECNET mailing list that provided a link to an archive containing the DIGITAL version of Smalltalk-80:
See below for a link to a g-drive file containing a ZIP archive of the DEC research group implementation of Smalltalk for the VAX.
If someone has a VT125 to try it on I would appreciate seeing an image of the screen with Smalltalk running.
Begin forwarded message:
From: Nigel Williams <nw@retroComputingTasmania.com>
Date: 7 April 2020 at 10:33:55 pm AEST
To: John Ames <commodorejohn@gmail.com>
Subject: Re: VAX/Smalltalk-80?On 2 Apr 2020, at 10:08 am, John Ames via cctech <cctech@classiccmp.org> wrote:
I know from the book “Smalltalk-80: Bits of History, Words of Advice”
Thanks for the reminder about the VMS version, as you likely know
their paper about VAX Smalltalk was in an early DEC Technical Journal
too.
…while the second ran under VMS and was actually developed within DEC. This version – VAX/Smalltalk-80 – was headed up by Stoney Ballard and Stephen Shirron; anybody know if there’s a surviving copy out there, if it was ever available outside DEC to begin with?I contacted Stephen and he kindly provided a ZIP
https://drive.google.com/open?id=1NvO-ULropJ9xyT-WFqalXY79FBt6tdfB
I had a quick look and it will need an early VMS I suspect, around
version 4.x (might work on a later version).
cheers,
nigel.
I found this really interesting for two reasons: firstly I know nothing about Smalltalk other than it came out of Xerox PARC is a message-passing, object-oriented language with its’ own environment. Secondly, upon inspection the majority of the code is written in VAX Macro-32 Assembly language, with only one C source file used to interface to VWS. To have an application coded up in VAX Macro is quite unusual – normally it is used for targeted performance optimization, not a whole application.
VWS or VMS Workstation Sofware was the pre-cursor to the DEC X-Window System providing a graphical user-interface to VAX/VMS and was available on a number of devices including VT200 terminals and early VAXstations:
VMS Workstation Software (VWS) is a VMS layered
product that provides windowing and graphics support
for the VAXstation II, VAXstation II/GPX, VAXstation
2000, VAXstation 3100 Models 30/40/38/48 with GPX
graphics and VAXstation 3200/3500.VWS supports VAXstations with windowing, VT200 se-
VWS 4.3 Software Product Description
ries terminal emulation with technical character set,
TEK4014® and TEK4125® terminal emulation, a simple
mouse-based human interface for window manipulation,
a graphics programming interface, Hard Copy (HCUIS)
for applications requiring hardcopy output, VWS/SIGHT,
an easy-to-use tool that enables the user to create
graphics, and a Migration Tools kit to assist users in
migrating UIS applications to the DECwindows platform.
There isn’t a great deal on the web about VWS, although I did find an interesting Masters Thesis that provides some insight in using it as a graphics library:
Application of VAX/VMS graphics for solving preliminary ship design problems
Publication date 1989-12
Publisher Monterey, California : Naval Postgraduate School
Collection navalpostgraduateschoollibrary; fedlink
Language EnglishThe VAX/VMS UIS graphics library routines were used in the creation of a menu driven, interactive program which solves basic preliminary ship design problems. The program uses a menu with active mouse and keyboard to select options, enter data, and control program execution. At present, the program solves transverse and longitudinal static stability problems and predicts the effects of shifting weight in three planes. It also calculates the hydrodynamic derivatives for maneuvering performance and predicts the turning circle characteristics of the ship. Provisions for a hardcopy, detailed report are also included. Space has been allocated to include future program modules or user supplied programs.
by McGowan, Gerald K.
A year or so ago I used Matt’s excellent update to SIMH for VAXstation graphics adapters to create a virtual VAXstation 3000 Model 38. I had it up and running using VAX/VMS 5.5-2H4 and felt sure that I could get VWS running on this hardware emulation. This proved very straightforward.
Building the VAX/Smalltalk software was also very straightforward, with help from Keith Halewood who fixed the file formats for the source code and virtual machine image. I had to tweak the limits for the user account in order for it to have enough breathing room to start up (I copied the values from the SYSTEM account)
This software is in two parts: the VAX Smalltalk-80 virtual machine emulator, and the virtual machine image of the Smalltalk-80 environment provided by Xerox.
There is thankfully lots of information on the internet about Smalltalk-80, and it is a fascinating story. One of the best sources of ‘drop-in’ information is BYTE magazine’s August 1981 special Smalltalk-80 edition. There are a number of Smalltalk books available free online.
A fascinating article in BYTE called The Smalltalk Environment by Larry Tesler of Apple describes his crusade for mode-less computer applications. It includes a detailed description of how to select text in Smalltalk. What really struck me is how this contrasted to the general state of computing evident in the numerous adverts for text-only PCs and terminals.
The official user-guide is Smalltalk-80 – The Interactive Programming Environment.
So lots to think about! Just bringing this all back on point for the Retrochallenge I am thinking in true Wickens style I will have an initial detour into Smalltalk and see if I can’t implement my Lunar Lander program in the Smalltalk environment for VAX. We can get to the COBOL implementation, all in good time.
Hopefully not another false start, this is a last minute entry into the RC2020/04 competition, put on unofficially by Mark Sherman, to his credit.
I got in touch with John Linville and Dale Goodfellow who used to run the competition with me to see what had become of it, and thankfully it looks like between all of us we can resurrect it this year, with Mark at the helm and us other folk providing a hand where required.
So, to my entry. Back in the Summer of 2010 (10 years ago!) I wrote a Lunar Lander simulator in BBC Basic which I ran on a Z88 portable. My interest in COBOL has been piqued recently – with the call for COBOL programmers due to COVID-19 in New Jersey being in the news recently. It is a language I have never used in my working life, and with what looks like an excellent implementation for VAX/VMS I thought I might try rewriting my Lunar Lander application in VAX COBOL. It seems suitably esoteric to be a typical Wickens Retrochallenge Entry.
I’m going to give Retrochallenge another go this year with a programming project to emulate the iconic 1980’s handheld electronic game Grandstand’s Astro Wars. I was bought this game as a Christmas present around 1981 and played the thing to death.
So, what to do this time round? Well, I haven’t made my mind up yet, but that’s OK! What I want to do this time is to have fun and not set myself some grandiose goal that will just act like a pair of concrete boots.
Some thoughts:
At the moment I’m attempting to downsize so it may be that I use one or more systems that I’m planning on eBay’ing soon.
Best of luck to all those who are joining the fun this October!
An update is well overdue. I’ve managed to lose another post as well, but it was pretty much a ‘I’m still on with it’ post. I had a hard lock up whilst running the TERMINAL program and couldn’t clear it with the RESET button, so I had to pull the batteries and switch off the backup battery thus clearing the memory of all files.
I was waiting for a dsub-25 male connector to arrive in the post up until a couple of days ago as I couldn’t get a cable made up with the various connectors I have lying around. As you can see from the photos attached to this post I decided to use a piece of breadboard to try and determine the correct connections for the RS/232 cable. Initially I tried a full hardware handshake cable, but I think I’m missing the mark of what I need.
I have got comms working between the ESP8266 module and the Tandy 200, but it’s far from perfect. Even at 300 baud I’m getting characters dropped. Having looked at various version of null-modem cables I’ve come to the conclusion that I’m going to have to implement software flow control within my ESP8266 lua program. For some reason I was missing the obvious issue that the MAX232 module I’m using is only connected to the ESP8266 module with TX/RX lines, so there is no way in which this end could implement hardware flow control.
The issues I’ve had with the Tandy 200 talking I think are down to the fact that the Tandy does require hardware flow control to be implemented even if it’s a case of looping back signals to satisfy Clear to Send/Ready to Send.
Next steps then are to look a bit more in to hardware versus software flow control and implement XON/XOFF in my telnet client on the ESP8266.
Last night I started looking more seriously, as promised, into implementing a telnet client in LUA for the ESP8266 Wifi Module. I have been using an excellent development environment called ESPlorer – this runs on linux, Windows & OS/X. I tried reading the RTC for the telnet protocol but that was, predictably, dry, so I for the most part resorted to an example of a simple telnet client written in C for embedded systems and, later, the source for linux telnet located in the GNU inetutils package.
Telnet is a fairly simple, somewhat extensible protocol. The initial conversation before data transfer starts involves a two and frowing between client and server side to determine who supports what and to what extent. The basic options are taken care of with either statements or responses:
* Please do use
* Please don’t use
* I will support
* I won’t support
These conversation commands all start with byte 0xff and in their simple form are three bytes:
IAC – 0xff ‘Interpret as command’
DO 0xfd/DONT 0xfe/WILL 0xfb/WONT 0xfc
FEATURE BYTE (eg. LOCAL ECHO is 0x01
In the simplest scenario the client can listen to the ‘please do/don’t’ requests coming from the server and respond ‘I won’t to all. This can be done trivially by replacing the second byte in the request and sending it back.
Eventually the server gets bored and starts sending data, typically the welcome message and login prompt.
For command with parameters the structure is a little more complex and can include arbitrary data, for example the terminal type or the X-Display environment variable setting.
It would be useful for my client to set the window size automatically. Future enhancement.
After some several hours of development early yesterday morning and no so early I have a telnet client implemented with following features:
* display a list of WiFi access points in range
* connect to an access point with supplied password
* telnet to an ip address
* show ip, gateway and netmask
I have code to do DNS resolution but that isn’t working correctly, I anticipate it is something stupid.
Later on today I transferred the programmed module on to the end of a franken- rs232 cable and was able to communicate but there were clearly issues. I think I was going through two null modem adaptors and there were clearly issues with this – I kept getting repeated DC1 characters I wasn’t seeing when plugged into Linux.
No amount of searching found a suitable donor cable so I’m going to have to order some DB25/DB9 connectors and make a custom cable. This is all a little moot as eventually I plan to install the module directly in a Tandy portable, but for development purposes I can’t live without it.
Somewhat exhausted now I am encouraged that I managed to cobble together enough lua knowledge to get this far. There’s nothing like a practical problem to get coding and learning.
In the post there are some uber-rechargable batteries on the way. Thinking about how to power the wifi module (lipos, micro chargers, etc) I came to the conclusion that buying higher capacity AA batteries was bar far the simplest solution. If the WiFi module is powered at the same time as the Tandy portable the drain won’t be constant and I believe there are facilities to power down the WiFi part when not required.
Normal life resumes tomorrow so progress will now slow somewhat. It’s been an educational journey so far however!
This is now the second time I’ve written this blog post. I found an unfortunate consequence in choosing Download rather than Upload in the Tandy 200’s TERMINAL program is that if you give the name of the existing file it is immediately overwritten with a blank document!
More care required in future!
I’ve spent most of the day helping my youngest daughter with a homework project on The Mayans. What a lovely Christmas present from her school! Chances are I’ll be on it for some of tommorrow although now my wife has finished putting away the Christmas decorations I may be a reprive.
More on topic I have created a Multiplan spreadsheet on the Tandy 200 (Multiplan is built in to the ROM and comes with a handy-sized manual) to track my food intake, exercise and body stats (weight, body fat, hydration etc.) Since I started looking after myself around 18 months ago I haven’t attempted to corrolate between calories in and out and the effect on the body. Everytime I’ve had a theory it’s been proven incorrect based on limited data, so this may well help.
I also dug out the ESP8266 WiFi module and printed out the TELNET PROTOCOL SPECIFICATION for a read-up on what is required to implement a telnet client that will be accessible via serial on the Tandy portables. The examples provided in lua for the NodeMCU firmware all concentrate on implementing a telnet server. This may take a while as I am a lua noob and so far my good intentions to learn the language have amounted to naught!
Right, lets try and get this posted for the second time!
You must be logged in to post a comment.