Looking to expand the device capability I stumbled across a really interesting little project that is still in the early stages of development but, is functional and worth trying out.
The TC²-BBS Meshtastic Version is a simple BBS system that runs on a RaspberryPi, Linux PC or virtual machine (VM) and can connect to a Meshtastic device via either serial, USB or TCP/IP. Having my M0AWS-1 Meshtastic node at home connected to Wifi I decided to use a TCP/IP connection to the device from a Linux VM running the Python based TC²-BBS Meshtastic BBS.
Following the instructions on how to deploy the BBS is pretty straight forward and it was up and running in no time at all. With a little editing of the code I soon had the Python based BBS software M0AWS branded and connected to my Meshtastic node-1.
M0AWS Meshtastic BBS Main Menu accessible on M0AWS-1 node.
The BBS system is very reminiscent of the old packet BBS systems of a bygone era but, it is ideal for the Meshtastic world as the simple menus and user interface are easily transmitted in seconds via the Mesh using minimal bandwidth.
The BBS is accessible by opening a Direct Message session with the M0AWS-1 node. Sending the letter H to the node will get you the initial help screen showing the menu above and then from there onwards it’s just a matter of selecting the menu item and following the BBS prompts to use the BBS.
The BBS also works across MQTT. I tested it with Dave, G4PPN and it worked perfectly via the Meshtastic MQTT server.
This simple but, effective BBS for the Meshtastic network will add a new message store/forward capability to the Mesh and could prove to be very important to the development of the Meshtastic mesh in the UK and the rest of the world.
The loading of the Meshtastic firmware on the Heltec ESP32 v3 devices is really simple if done via a Linux PC/RaspberryPi. There are of course other ways to load the firmware using a web browser that supports USB/Serial devices and this method is preferred by many however, being a Linux command line junkie I far prefer the simplicity of using the Linux command line to do the job.
So, how much experience with the Linux command line do you need?
In all honesty none at all. If you know how to use copy and paste then all you have to do is follow the simple steps I’ve detailed below. In reality it will only take a few minutes to do so, don’t be put off by the long article, I’ve just tried to cover everything and provide screen shots along the way.
To get started fire up your Linux PC/RaspberryPi and get yourself to the desktop. Next you will need to open a Linux command line terminal. This is often just called “Terminal” on most Linux desktop installations.
The first thing you need to do is check to see if you have python3 installed. This is done using the following command:
python3 --version
Running the above command you should see a result something like what is shown below.
Python3 command showing installed version
Next we need to check if pip3 is installed using the following command:
pip3 --version
If pip3 is installed then you should get a result similar to that shown below.
Pip3 command showing installed version
If your computer doesn’t have Python3 or Pip3 installed they can be easily installed from the command line. To install Python3 enter the following command into your terminal:
sudo apt install python3
You will be asked to enter your login password and then the installation will begin. You should see output in your terminal similar to that shown below.
Installing python3
To install Pip3 enter the following command into your terminal:
sudo apt-get install python3-pip
This will detail a long list of packages that will be installed on your computer, Enter Y to answer Yes and let the packages install.
M0AWS – Installing Pip3
You will see many messages scroll up the terminal screen such as getting, selecting, preparing, unpacking and setting up, this is all normal.
Once Pip3 is installed you should be dropped back at the command line with a terminal screen that looks something like the one below.
M0AWS – Pip3 install complete
At this point you will now have Python3 and Pip3 available on your computer.
You are now ready to install the tool we are going to use to check your Meshtastic device is connected to your PC and install the firmware to it. (Do not connect your Meshtastic device to your PC just yet!)
Run the following command in your terminal to install the ESP Tool:
pip3 install --upgrade esptool
You will see an output from the installation process similar to that shown below.
M0AWS – Installing the ESP Tool
Now that we have the ESP tool installed plug your Meshtastic device into your USB port on your computer and then run the following command to interrogate the device to find out what kind of device it is.
esptool chip_id
You should see the information about your device that looks similar to that shown below. This information should confirm the device type (ESP32) and which USB port it is connected on (/dev/tty/USB0).
M0AWS – Expected output from the ESPTool command showing device information
Once you have this information you will need to download the firmware for your device from Github using the following URL:
https://github.com/meshtastic/firmware/releases
At the time of writing this I downloaded and used the v2.2.22.404d firmware which I have found to be extremely reliable.
In your terminal you now need to change directory (cd) into the Downloads directory where your downloaded firmware should be. (If you downloaded your firmware into another directory then you will need to cd into that directory). Use the following command to change directory into the Downloads directory.
cd ~/Downloads
Now we need to find the filename of the firmware we have just downloaded, we can use the list directory contents command to find the file using the simple command below.
ls -la firm*.zip
M0AWS – List firmware file name from the Linux command line
In the screenshot above we can see that the filename is called firmware-2.2.22.404d0dd.zip. We now need to unzip the file using the unzip command.
unzip firmware-2.2.22.404d0dd.zip
You’ll see lots of output from the unzip command about inflating files etc, this is normal.
Once the file has been unzipped you are ready to load the firmware onto your Heltec device. First you need to find the .bin file for your Heltec device. Use the following ls command to list the files available.
ls -la firmware-heltec*
This will list out all the firmware file options for the Heltec device as shown below.
M0AWS – List of Heltec firmware files
The file you need to use for a new firmware installation on a Heltec v3 device is firmware-heltec-v3-2.2.22.404d0dd.bin. (If you downloaded a different version then the version number in the file will be different).
Using the filename you found above enter the following command into your terminal.
This will now clear down your Heltec device and will load the Meshtastic firmware. This will take a little time especially on slower computers like the RaspberryPi so, just let it run until it finishes. Do not interrupt the process whilst it is running.
Installing the Meshtastic firmware onto my Heltec ESP32 v3 using the Python command line tool
Once the firmware is loaded the Heltec device will reboot and you will see the Meshtastic banner on the OLED screen. Your device is now ready for configuration.
Now that you have Python3 and Pip3 installed you can load the firmware onto other devices just by downloading the firmware and then running the device-install.sh script file, you won’t need to install Python3 or Pip3 again.
If you want to update your device in the future to a newer version of the firmware then just use the update script and update binary file as shown below.
The bare board that held the HB 6809 V1 circuitry. Waiting for the next SS-50 project.
In computings early days, advancements happened quickly. Which mean purchases went out of date quickly. I built my SWTPc 6800 Computer System in November of 1977. In 1978, Motorola introduced the MC6809 processor, and by March 1979, SWTPc had the MP-09 CPU board available.
MC6809
For those who programmed the MC6800, the MC6809 fixed many problems. It sports 16-bit arithmetic operations, more index registers, many additional addressing modes and a very orthogonal instruction set. It was a powerhouse of an 8-bit processor. Early chips were costly, and the marketplace moved quickly beyond 8-bit chips to 16-bit ones. The MC6809 never became popular enough to dominate the market. For that brief time in the late 70s, it was the most powerful 8-bit processor. I wanted one.
Georgia Tech Symposium
In early 1983, Georgia Tech hosted a symposium where Terry Ritter, one of the designers of the MC6809 spoke. I attended, and the room was packed. Ritter talked about the design decisions that went into the architecture of the MC6809, about the importance of reusable software and position-independent code. Their design lead to the creation of BASIC09 and OS-9.
At the time, I wasn't much interested in any variety of BASIC, so I didn't pay much attention to OS-9. I should have.
The last of Ritter's talk was about an unannounced product, termed the General Motors Custom Microprocessor (GMCM). It built on the foundations of the MC6800. At that time, GM was using the MC6802 in their vehicles. The GMCM added some features to the MC6800, such as 16-bit arithmetic, an extra index register and both multiply and divide instructions. (Divide was something that the MC6809 did not have) But the GMCM lacked all the complex, orthogonal addressing modes of the MC6809. The next year, Motorola introduced the MC68HC11.
MP-09
SWTPc offered the MC6809 with the MP-09 board. The MP-09 draws from the design of the MC6800-based MP-A2 board. Both have four 2716-compatable sockets that can hold 2 KB ROM, PROM or EPROMs. While the primary difference is the CPU, there are other differences:
SS-50 bus changes for the 6809 processor
NMI and RESET switch connections relocated to a CPU board connector, which frees up two bus lines for BUSY and M.RDY, respectively
ROM socket at address F800
ROM/RAM sockets at address E000, E800, and F000
No on-board RAM. (the MP-A and MP-A2 had 128 bytes of RAM)
16 bytes of writable memory at address FFFx that translate the top 4 bits of address
This last feature is known as the Dynamic Address Translator or DAT. The DAT uses a fast 16x4 bit RAM - the 74LS189 chip. It sits between the top 4 address lines A12-A15 of the CPU and the physical bus. Thus it translates address values in 4KB blocks. It is the reason the MP-09 has no on-board RAM. The ROM monitor SBUG-E, on reset, scans addresses to determine which 4 KB blocks have RAM. It then writes the DAT to position those 4 KB blocks as desired. The first block is relocated at D000-DFFF, and the second block at C000-CFFF. These two blocks are used for the stack, and any operating system such as Flex09. The rest of the memory blocks are arranged from address 0000 upward.
The board has a socket for an additional 74LS189 chip for the DAT, which adds the four higher-order bits to the DAT RAM. This extends the address bus with four more lines (S0-S3) allowing the MC6809 to address 1 MB of memory. The S0-S3 lines take the place of the bit rate signals on the SS-50 bus, so these signals have to be supplied elsewhere for the SS-30 bus. SWTPc did this with their MP-MB motherboards, a component of the SWTPc S/09 systems.
The MP-09 board runs on the original MP-B/B2 motherboards with modifications. More on these later.
During my years in college, I eagerly wanted to upgrade my computer to the MC6809. I obtained a copy of the SBUG-E source code and studied it. By April of 1981, I modified SBUG-E, removing code for features I didn't need and adding some features of my own. I called my monitor BBUG. I used a cross-assembler on the Pr1me minicomputers to build my code. But I could not run BBUG without hardware.
MC6809E V1
My last months at Georgia Tech, I took a required course that involved building a working microprocessor system. It had to have ROM, RAM and I/O. Many of my colleagues used the computing laboratory that provided prototyping plugboards and components for their circuits.
This was a challenging course for many computer science majors. It was their first experience with digital logic. And the prototyping plugboards had been used and re-used so many times that their connections were not always reliable. This made it difficult to determine if problems were programming bugs, wiring errors, or just flakiness in the hardware.
I didn't relish dealing with flaky prototyping boards. I had fulfilled many of the requirements of this class when I built the SWTPc 6800 system in 1977! This seemed an opportunity to create my own MC6809 processor board.
I had read articles about the MP-09, and had copies of the schematics, which I studied in-depth. There were electronic parts stores and friends around Atlanta where I could obtain components. It seemed right.
MC6809 V1 Design
April 1983, I drew up schematics. My design borrowed from the MP-09, and included the DAT, but there were several differences.
I did not include an MC14411 bit rate generator or crystal. I intend to use extended physical memory right away. I moved the bit rate generator and crystal to a card plugged into the SS-30 bus. There were no bit rates on my SS-50 bus, only S0-S3 address lines.
Instead of the MC6809 chip, I opted to use the MC6809E. The MC6809 has a built-in clock oscillator and bus control logic. The MC6809E requires an external oscillator as well as a few chips to handle bus control for things like DMA. In trade, it has an LIC (Last Instruction Cycle) and AVMA (Advance VMA) pins. I made use of AVMA in my design.
Instead of four 2716-compatible 2KB sockets, I only had two. A ROM at Address F800, and ROM or RAM at address F000. Having ROM or RAM at E800 or E800 didn't make sense to me, since those addresses conflicted with the I/O ports used by SBUG-E. (In October 1986, I would revise this board to use a single 2732-compatible 4KB chip, covering F000-FFFF)
The memory map for this design was pretty straightforward:
0000-EFFF - accessing off the CPU board to the SS-50 bus
F000-F7FF - ROM/RAM socket #1
F800-FFFF reads - ROM socket #2
FFF0-FFFF writes - DAT RAM
I had no option switches or jumpers in this design. It was exactly how I wanted.
Dynamic RAM Design
The same month, I drew diagrams for dynamic RAM boards. One was a 64 KB board using 4116 chips. Another design provided 256 KB memory using 4164 chips. I intended to add one of these boards to my project. The 4116 design was complicated, with multiple voltages involved. The 4164 design was simpler, but the chips were more expensive. I never build either design.
MC6809E V1 Building
Although I had made some simple PC boards, creating one for the MC6809 design was outside my skill set. Plus, it would have been expensive for my student budget. I had constructed a seven-chip CMOS keyer in 1979 using point-to-point wiring. That was difficult. I built a duplicate keyer for my brother in 1980 using wire-wrap construction. Wire-wrap was a heck of a lot easier. Plus, I already had the tools. A friend supplied wire-wrap wire and sockets and I was in business.
Wiring a design this complex directly from the schematic worried me. Wiring mistakes were easy to make, and hard to track down. Then a classmate asked to join my project. Denise Messerschmidt worked with me in the Users Assistance office at the Computer Center, and she didn't want to have to fuss with the flaky prototype boards either. She asked if she could help, and I figured should could do the wiring of the hardware. This required good instructions.
I solved that problem with a bit of software. I used the LL(1) parser generator written by fellow student Roy Mongiovi and defined a 28 production computer "language" that described the chips and devices and the wiring between them. Given a well-described design, my program produced three lists as output.
The device list showed each device and all of the signals connected to each pin. A device was either a chip or a plug. Chips listed two pins to a line, just as it would appear on a DIP device. Plugs listed one pin to a line. The device list made it easy to verify the design was correctly programmed in the language.
A cross-reference list related the signals connected to each device. Another cross-reference list showed the signals by each device and pin. One would follow this final list to do the wiring. The Wire Wrap parser was about 2500 lines of Pascal code, and it worked beautifully.
The board used 0.1" perf-board, cut to 8 1/2" by 5" -- a little smaller than standard SWTPc boards. Molex connectors epoxied on the edge connected to the SS-50 bus. I installed the wire wrap sockets, and wired up the voltage regulator and the SS-50 pins, plus a handful of discrete components. That took care of everything that required soldering. After training Denise in wire-wrap technique, I gave her the board, wire, tools and the wiring list.
About two weeks later, she came back with the finished product. Every wire had to be manually stripped and wrapped. Denise had done an excellent job - better than I would have.
MP-B Modifications
The MP-B motherboard required modification to work with my 6809 CPU board. The I/O ports on the MP-B decode as eight, four byte ports starting at address 8000. The SBUG-E (and hence BBUG) monitor expects eight, sixteen byte ports starting at address E000.
The modifications aren't difficult:
Connect SS-50 A2 and A3 to SS-30 UD3 and UD4, respectively
Move the ABC inputs in U3 from SS-50 A2, A3 and A4 to A4, A5 and A6, respectively
Cut the trace on U3 pin 5 (Enable*) and connect to SS-50 A9
U5 has an unused NOR gate, connect the inputs to SS-50 A10 and A11, and the output to U3 pin 6 (Enable)
Move the U6 pin 4 (Enable*) from SS-50 bus A6 to A12
Move the U6 decode output on pin 4 (4*) to pin 7 (7*) this signal goes to U3 pin 3 (Enable*) and U5 pin 13 (Enable* for data bus drivers)
Modifications on underside of MP-B. The brown wires on the right go to the 74LS21.
To support extended addressing using S0-S3, the traces between the SS-50 bus to the SS30 bus for the bit rate lines 110, 150, 300, 600 and 1200 must be cut.
I added extended address decoding for the I/O ports. I mounted a 74LS21 4-input AND gate on a daughter board, and connected the inputs to S0-S3, the output goes to U6 pin 6 (Enable).
With these modifications in place, the I/O ports show up in memory as eight, sixteen byte ports, from physical address FE000 to FE1FF. The ports show up in memory four times in sequence, because address lines A7 and A8 are not decoded.
Bit Rate Generator
Bit Rate Generator Board
Since I used the extended addressing lines S0-S3 on the SS-50 bus, the bit rate signals must be provided on the SS-30 bus.
For this, I built a simple card that had just four components: MC14411, LM341-5 regulator, 1.8432 MHz crystal and a capacitor. You can see them lined up on the left side of the board. The MC14411 is the original device from the MP-A CPU board with a date code of 7718 - the 18th week of 1977.
Later, I added the MC6840 timer chip and the SN74LS04. At some point, this board also held an Intel 8250 UART, which is the reason for the molex connector in the upper right. But those parts have been removed. There's certainly room for an MC6850 ACIA or other I/O device on this board.
Bit rates are configured as follows:
110 = 38400 baud
150 = 2400 baud
300 = 300 baud
600 = 9600 baud
1200 = 1200 baud
This represents a good collection of rates across a wide range. As configured other rates are available on the MC14411 from 300 to 115200 baud.
MC6809E V1 Debugging
The beautifully wrapped board Denise wired didn't work.
When I built the SWTPc 6800 Computer System, it didn't work the first time, either. I borrowed an oscilloscope and figured out the issues. For the SWTPc 6800 boards, the problem was nearly all solder bridges. But those boards started with a working design. Mine was untested.
I had access to test equipment on campus, but I couldn't take any of it with me. I had to bring the whole computer and terminal into one of the computer center labs in the evenings, when the labs weren't in use. An oscilloscope wasn't enough. I was introduced to a new device, an HP logic analyzer -- although it took me a while to figure it out. Those evening sessions in the lab were very productive.
Dragging my computer and terminal in and out of he lab each day, I isolated six different wiring errors on the board. Had Denise let me down? No, the wiring errors were all in the original wiring listing! Denise had done her job to perfection -- she wired it exactly as specified.
Once the wiring errors were fixed, the debugging process went smoother. I also had to correct some defects in BBUG. At one point, I had all 24 channels of the HP logic analyzer engaged. 16 pins went to the address bus, and the other 8 to the data bus. This way, I could watch each memory cycle of the MC6809 and determine what was happening.
Eventually, I fixed the issues and had the system running. I received an "A" for the course. Denise, because of her limited involvement, received a "B", but we were both happy.
End of an Era
In 1988, I built another MC6809 CPU board. It replaced the V1 board, and once working, I stripped the V1 board down for parts. All that is left is a board with edge connectors and a voltage regulator, which you see at the beginning of the article.
The GE TDM-114 Data Set. The big toggle switch is my modification so I could turn it off.
GE TDM-114 Data Set
In the fall of 1979, I headed off to Georgia Tech and brought my computer with me to the dorms. My roommate that first quarter wasn't impressed. Nevertheless, I continued to work with the computer and learn new things.
In those days, Georgia Tech used a CDC Cyber 74 system for instruction, and one could dial into the system with a modem. I managed to locate a GE surplus modem for about $40. It was an acoustic coupler modem -- you would dial the phone manually, then jam the handset into the unit. Speakers and microphones would pick up the sounds from the phone line through the handset.
Rear View of TDM-114.
In my second quarter, I ordered a unit. When I got it, it did not work. Fortunately, it came with a manual with a schematic and troubleshooting and adjustment guide. I didn't have any test equipment other than a Volt-Ohm Meter (VOM). I don't remember how I fixed it. With youthful curiosity and dogged persistence, I managed to find a diode that didn't appear to be working, replaced it, et voila! It worked.
Manual with unit.
This was a BELL 103 modem, which meant it supported speeds from 110-300 bps. Back in 1980, that wasn't as slow as it seems. Who am I kidding? It was really slow. It was what we had.
Schematic
Initially, I hooked the modem directly to my CT-64 Terminal system. It was fun being able to dial the Cyber 74 and work on programs from my dorm room. But, it was a pain to swap the cables around between the computer and the modem. It would be nice to leave the CT-64 plugged into the computer all the time, and plug the modem into another serial port. I needed more serial ports.
MP-S
I purchased two MP-S serial ports in early 1980. These boards use the MC6850 Asynchronous Serial Adapter (ACIA). The advantage of the ACIA is it could transmit and receive individual characters without any CPU attention. The big-banging serial port used by the MP-C required the CPU to actively perform all sending and receiving.
The MP-S is really simple, especially after removing the current-loop circuitry, as I've done. I liked this about the design of the SWTPc 6800 Computer Sytem - I/O devices could be added very inexpensively.
One board replaced the MP-C (since I was using SWTBUG by then) and communicated with the CT-64 at 1200 bps. The other used a different slot and was wired for 300 bps. Making them talk to each other was a small matter of software.
The Terminal Program
My initial attempt was a mad polling program in 6800 assembly language. It consisted of a crazy loop that looked for received characters from one port and transmitted them on another, and then did the same thing going the other direction. It even had buffering in each direction. It probably wasn't even 100 bytes long. It worked well.
In the fall of 1980, it occurred to me this could be an interrupt-driven program. This took a bit of doing. You had to configure the proper interrupts and then have an interrupt service routine to determine the cause of the interrupt and service it. Get something wrong, and nothing would happen. This made it much more difficult to debug.
I rose to the challenge and got it to run. I included even larger buffering than in the first program. I had hoped to use the MC6800's WAI (Wait for Interrupt) instruction, but ended up using the idle time to perform buffer housekeeping.
The buffering came in handy. For a while, I had a switch on the CT-64 that would pause reception from the computer. I could run a long listing at 300 bps, flip the switch and read a screenful while the next screen slowly buffered in my computer. flipping the switch again and it would spool on the screen at 1200 bps -- the top speed of the CT-64.
This experience laid the groundwork for my first job -- at Hayes Microcomputer Products, Inc after I graduated from Georgia Tech. I spent nearly twelve years writing much more sophisticated terminal programs.
Login
