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.
Play and document an indie game a day on the ZX Spectrum.
Write some BASIC for the ZX81.
Do something with comms and a Raspberry PI with the Tandy TRS80 102/200s.
Run a VAXstation 4000 again for a month.
Use my DEC 3000/600 for something purposeful.
Outdoor computing from as many different scenarios/systems as I can muster.
Document the setup of an emulator for an unusual system – OpenGenera springs to mind!
Some complete last-minute curve ball – the most likely.
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!
So, unlike Mr. Spooner who was downing his first pint before midday I’ve made it to after 3pm before the first of a couple of cheeky glasses of port. Before starting on my RC fun I had setup the slow cooker for pulled pork, baked two lots of scones and cooked off some chicken and sausages. After the late night we’d had on New Year’s eve there was no stirring apart from myself in the household before 11.30!
I’ve not had any retrochallenge successes today. I have learnt some things however.
I started the day attempting to make a replacement direct-connection modem cable for the Tandy Model 102. Previously I’d bought some 8-pin DIN connectors. What I hadn’t realised is that the PHONE socket on the 102/200 is slightly different to the CASSETTE socket. They are both 8-pin DIN, but the PHONE socket pins are spaced closer to the casing. Obviously I found this out after spending an hour making a new cable. It makes perfect sense that you should be prevented from plugging cables in incorrectly given their proximity on the back of the computer, however it takes some close inspection to tell the difference!
I also found that the pin numbering of the PHONE connector in the Tandy 102 Users Guide is different to the numbering on the DIN connector. A lesson learnt (I made the classis mistake initially of forgetting to put the housing on the cable for the connector before soldering otherwise I might not have noticed this difference)!
I did get a modem cable with the 102 but it’s not in good condition. Having initially thought it was wired up wrong (due to the different numbering conventions) I then double checked and found it was wired up correctly. So I tried that cable but couldn’t get anywhere dialing up @retrocosm Nostromo BBS. I suspect it has something to do with the way in which I have the phone and modem connected to the phone line. I couldn’t get a connection established.
Having spoken to folks on the club100 mailing list I’ve also found that UK Model 100/102/200’s have different ROMS with the dialing facility removed. The PROHIBITED sticker on the bottom also indicates a difference.
The Model 100 I recently acquired (which has suffered from battery leakage corrosion) doesn’t even have a PHONE connector – there is a blanking plate and no DIN-8 socket on the motherboard.
I then resorted to the acoustic coupler that I had bought NOS from the USA a couple of months ago (in a whim, on my phone, waiting for the Windermere ferry whilst out on my bike).
In anticipation I had also bought one of these ‘retro’ bluetooth handset for use with a mobile phone with the correct profile for insertion in the coupler’s cups.
I tried this setup with various communication settings (7/8 bit, even/odd/none parity, 1/2 stop bits) and did at times get an occassional intelligible response but nothing remotely reliable.
The mobile phone signal here is very poor and I won’t write off this approach without having tried a connection near the local mobile phone mast (which is next to Booth’s supermarket – Model 200 in their Cafe I anticipate).
I am still to find a convenient method of attaching images to these posts. This time round I’m including a link to a google photo album. You’d think they would make it easy to embed an album on the page, but an internet search suggests otherwise. Like Star Trek the search continues…
Since I entered RC2016/01 I’ve had a few more ideas about what I might get up to this time around.
The primary objective is to make blogging from a Tandy Model 100/102/200 as easy as possible. I intend to write all my blog posts on a Model M. To start with the process is as follows:
* Write a blog article on the Model 200.
* Connect the Model M to a Linux PC via a null modem DB25->DB9->Serial USB cable.
* Linux PC is running a console on the said serial port.
* I run the Terminal software on the Model M, and log in to the Linux box. * I use a $ cat >blogpost.txt command and use the upload facility of the terminal software on the Model M to upload the content of the blog post to a file on the Linux box.
* I run a custom bash function that takes the resulting text file and uses the email to wordpress facility on my blog site to upload the blog to my wordpress site.
There are a number of issues with this process which I will attempt to address. The first is images. I’m attempting to get my Android phone to upload photos automatically to my wickensonline.co.uk site in a specified folder. Doing this will allow me to reference the pictures as I write the blog post. This all needs sorting out. I am using Photo Resizer HD to resize the images before upload and using the Auto Uploader application to push the file via SFTP. However, this isn’t working – I’ve emailed the developer.
Another goal is to convert Model M specific characters (other than straight ASCII) into their Unicode equivalent. I’ve done the ground work for this so it should be fairly straightforward to include as an additional step before upload.
Then I want to try and make this process as easy as possible. One goal is to remove the need for a hardwire. I would like to attempt a WIFI link up via a ESP8266 module. I then want to see how I could make blogging remotely with an upload possible.
Before Christmas I bought an acoustic coupler. It would be great to provide the ability to post blogs via a modem dial-up connection.
Happy New Year to all my fellow Retrochallengers – let the games commence!
I’m not setting any fixed goals this time round as that appears to be the kiss of death. I’m hoping to use the Tandy 102 or 200 as one of my blogging devices. I hope to blog a little, frequently. I may attempt to acoustically couple. Maybe blog from random places. That kind of thing. Entertaining with no focus…
I’ve been completely enamoured with my Tandy 102 Portable Computer since receiving it about a month ago. I can’t believe I’ve gone for so long without picking one up.
The machine itself is great – a nice readable display, excellent keyboard, great battery life, comprehensive BASIC implementation, accurate emulator ( VirtualT) and enthusiastic following. There are a number of after-market solutions for data transfer and storage, and documentation covers all aspects of the machine.
In preparation for my Retrochallenge entry I’ve ordered several books on both the Tandy model and 8085 machine language programming. The 8085 was Intel’s solution to provide a low-power and more tightly integrated version of the 8080. At around the same time the Z80 was released separately by Zilog, so both the 8085 and Z80 share a common ancestor and instruction set in the 8080, but Z80 programs won’t run on the 8085 unless they are written to only use the 8080 instruction set.
As a text editor (and I’m writing this on the Tandy 102 now) I can’t fault the hardware/software combination. It is responsive to both text entry and editing and unlike other comparable tools (such as the Cambridge Z88) the interface and keyboard shortcuts are very intuitive. For example you can use Shift-Left and Shift-Right to move backwards and forwards a word at a time, and Shift-Down and Shift-Up move you a page of text at a time.
As it is summer here one of the truly wonderful benefits is being able to ‘compute’ outside without the problems of screen visibility. I know I’ve harped on about that before with the Z88 and the HX20, but it’s worth re-iterating – the technology used in these early laptops often means they are the only viable outdoor computing options, regardless of age.
Tandy 200 converted to a Rasperry Pi or other Linux based PC. LiPo based power, Teensy 2++ keyboard to USB converter, custom graphic to LCD driver (possibly).
VT420 terminal with a Raspberry Pi built in, LiPo powered with DC->DC converter, keyboard shelf, possibly WiFi connectivity.
Bluetooth serial module for the Tandy 102.
Arduino built into Tandy 102 with Wifi shield for connectivity? Is this possible?
Introduction to the Model 102
Typed on the Tandy 102 itself…
Tandy 102, Supercade, Programming Books, Fruit Tea and Space Invader’s notepad! Oh, outside, in the Sun!
This is the Tandy 102 Portable Computer. There were three variants of the Tandy Portable computer. The original model 100, the 102 (slightly thinner) and the 200 which had a flip up screen displaying more lines of thext. In order to print from the Tandy 102 you need a cable that has a 26 pin ribbon connector and a standard centronics connector. The cable I am using is for a BBC Micro and is compatible.
The operating system for the 102 was written by Microsoft and is well integrated with the excellent BASIC software. Portions of the code were written by Bill Gates and this software is credited with being the last piece of software that Bill had direct hands on involvement with.
The Model 102 comes with a 32K ROM and 24K RAM as standard. An access panel on the bottom of the machine allows the installation of a custom 32K ROM and an additional 8K of RAM.
This particular example was purchased off eBay recently for #26. My Retrochallenge entry this year features the 102 – I plan on writing several pieces of software, hopefully culminating in a machine code program burnt to an EPROM.
The text has been reformatted from the original 40 columns as was transferred to my laptop via the Linux minicom program.
OK, so I’ve not got off to the best of starts here. My first week, where technology has been involved, has mostly been either repairing self-inflicted damage, fixing other people’s stuff or failing at retrochallenge.
I’ll spare you the details of my dd raid drive saga, or the restoration of my wife’s ageing windows install but will concentrate on what I’ve been trying to achieve.
When I received my Tandy Model 102 recently I was curious about burning an EPROM for it. There are quite a few images available and I like to keep it old school if possible. I had an eraser, burner and EPROMS of the right size 27C256 and felt confident once I’d order the adapter PCB that life would be sweet. I failed to get my existing EPROM burner working, or at least talking to, one of my laptops. In a act of despair I ordered a WILLEM programmer on the basis that the software was more likely to be compatible with more recent machines – certainly it couldn’t be any worse than the poorly translated Chinese software that came with my original burner. All this was around two weeks before RC2015/07 and I had the new programmer and the PCB adapter boards in plenty of time.
Freshly burnt Model 100 Option EPROMS
In order to construct the adapter PCB I had to find some pins that were long enough to reach into the weird PLCC like but DIP shaped receptacle that is the option ROM socket in the bottom of the Model 102. I found that IDC pins worked just fine, so soldered a load of those into the PCB and then an EPROM.
First two pins of four in each corner to make fitting the rest as easy as dropping them in and soldering them!
Item on the right goes into item on the left
Swiss army knife with one more trick up its’ sleeve!
Strip of pins. In two rows. Would have been better in one row. Ho hum.
Adapter PCB will all pins fitted
Another shot before the EPROM was soldered in
I have no idea what these images are doing BTW – you spend so much time using these WYSIWIG editors (didn’t that mean something once) only to find when you publish that everything has moved around.
Anyway, long story short all this was for night. I should have read the documentation more carefully, but responses to my post on the Tandy Club 100 Mailing List indicated that I was wrong to try this and that it wouldn’t work. The PCB is primarily for replacing the main ROM in a Model 100 (which is deeper) than the option ROM in a Model 102. When I inserted the adapter into the PCB I could no longer close the trapdoor – I am guessing that the model 100’s deeper housing doesn’t suffer from this failing. And so I moved on…
One of my thoughts was to write a game for the Tandy 102 in assembler. I’d toyed with the idea of targeting a C-compiler, but the more I looked into the Tandy’s ROM and RAM map the more I decided that it was probably going to be a hard thing to achieve. I’d done this previously with my Motorola 68000 SBC, but clearly that is more capable than the rather limited 8085.
Brooke with some Ghostbusters
My attempt at a Samuel Jackson selfie!
At the time I was thinking ‘game’ I both went to the North East Retrogamer (think room full of arcade cabs, pinball tables and consoles/old computers) and also rediscovered my book Supercade. Whilst perusing the book I came across a maze game for a system I’d never heard of, the Channel F. Looked like the right sort of complexity for a first stab.
Here’s the blurb (courtesy of Supercade):
Channel F Fairchild Camera and Instrument
The Channel F Video Entertainment System (VES) was introduced just following the debut of the Coleco Telstar in August 1976. Released by Fairchild and designed by Jerry Lawson, it ws the first home videogame system to use a “Videocat” game cartridge (a plug-in programmable ROM cartridge) in order to play additional
games on the system.
Prior to the release of the Channel F, videogames were selected by a series of switches or dials to toggle between various built-in games. Although the original Magnavox Odyssey did include plug-in cards, they functioned in a similar manner to the switches in that they acted as a circuit “key” to switch between pre-programmed games and didn’t contain any actual game programming. But the Channel F Videocart, with its bright yellow plastic outer casing and bold game label graphics, actually contained program ROM and is now considered the first videogame cartridge.
Supercade on the ‘Channel F’
Transcribing into the Model 100 from the book
Designed around the Fairchild F8 8-bit microchip and four RAM chips, the architecture of the Channel F system was revolutionary in that it was the first home videogame system to use a programmable microprocessor with a screen bitmap – basically a scaled down implementation of the technology now being used in coin-op arcade videogames.
The Channel F shipped with the main system console, two game controllers, AC adaptor, and RF box. Two “console” games – Hockey and Tennis – were pre-programmed into the system. The console itself contained a slot for inserting the optional spring-loaded cartridges ( about the size of an 8-track tape), a compartment to store the game controls, and numerous control switches including an innovative “Hold” button for freezing the action on-screen.
The Channel F was also the first home system to include a directional joystick. Videogame controllers – even the control boxes of the Odyssey – usually consisted of knobs to control the horizontal/vertical direction of active objects on-screen, or a light gun attachment for target games. However, the Channel F’s plunger style game controls – hard-wired to the console – contained a knob on top that could be moved in eight directions: forward, backward, left, right, twisted left or right, pulled up, or pushed down. With this configuration it was now possible to control any number of on-screen actions.
The Channel F was incredibly popular following its release in 1976, and by 1977 the system was on back-order for nearly six months. Fairchild released a total of 21 games for the Videocart library throughout the life of the system including Space War, Memory Match, Quadradoodle, Math Quiz, Shooting Gallery, Tic-Tac-Toe, Blackjack, Pinball Challenge and more. Zircon International (the makers of the handy “StudSensor” pocket tool) purchased the videogame division from Fairchild in 1979 and released the Channel F System 2 along with five additional game cartridges.
Unfortunately the revolutionary Channel F was swiftly eclipsed following the release of the technologically superior Atari VCS – and was discontinued in 1980.
It’s in the Game!
So I printed out a screenshot of the maze shown in the youtube video with a view to encoding it as a bit pattern:
Hand coding the maze into eight-bit bytes
I then wrote a quick BASIC programming to check the data was correct (there were a couple of mistakes) before moving into the murky world of 8085 assembler!
Testing the maze generation data
and the resulting display on the Model 102:
The maze generated via simple BASIC program, scaled to 3x original size
Tandy Model 200
I also received a Tandy Model 200 recently, with half an idea to try and replace the internals with something modern whilst keeping the same keyboard and case. Unfortunately there are three keys that don’t work on the keyboard. I originally assumed that this might be down to a connection issue and they were on the same scan row, but I discovered following disassembly that it is the individual key switches themselves that are faulty. Somewhat disappointing! So I’m going to have to look out for a donor machine.
Model 200 PCB after the keyboard and screen are removed
Screen and top housing
The key caps take some force to remove – I highly recommend a key puller for this job.
Key switches after all key caps have been removed. Notice the smaller function key switches.
Always good to take a reference image of the keyboard before removing caps in anger!
Next up… programming the Virtual Model T in assembler!
So I have been tinkering today with the simulated VMS set up on the server and also started making a stab at bringing up a VAX 11/780 simulator configured to run BSD Unix.
The DL380 has a backup battery attached to the internal HP Smart Array P400 controller. In this server there were two intelligent batteries – there are slots for two, presumably for if you have two controller installed (which may be a reality now that I have bought an external MSA50 drive enclosure). This system came with two batteries but alas the second battery was dead as a parrot.
There is a guide on line I’ve just found to replace the cells with an external AA four cell pack, but I went the whole hog and ordered the actual cells.
The battery compartment has a thin plastic bottom that can be sliced off revealing the four Vartar V500HT. These are available from CPC for £3.44 each. Each cell is 1.2 volt giving a total of 4.8 volts although when I measured the four new cells I got exactly 5 volts – presumably because there was no load. Anyway, the replacement process involves prizing off the crimped on connectors and repackaging the new batteries in the same order. I soldered each sandwich of batteries together at one edge. Once reinstalled I had to be careful to ensure the battery terminals were oriented correctly so the PCB pressed down on the terminals correctly.