In my previous post on Sleeping Arrangements, I was fairly negative about Roof Top Tents (RTT), citing their detrimental effect on vehicle driving dynamics, vehicle aerodynamics, and also the potential danger of sleeping over 2 metres above the ground at the end of a flimsy ladder.
However, for certain reasons, I’ve now decided to mount a RTT to the top of my Stockman Pod Extreme. Mounting the RTT on the trailer removes all of the above mentioned disadvantages, but keeps all the RTT advantages.
The mounting height is about 1.5 metres above the ground and is barely 40 cm above the top of the trailer load platform. Whilst the 60 kg of the RTT will affect the trailer dynamics, in the case where the trailer cannot follow along, it can be left behind at camp leaving the vehicle dynamics unaffected. The highest point of the RTT is lower than the vehicle roof line, and the selected RTT is quite streamlined, so the overall aerodynamics should not be significantly worse than they already are (considering both vehicle and trailer are pretty much brick shaped anyway).
The most important benefit of fitting the RTT to the trailer is that at just 1.5 metres off the ground a fall is substantially less dangerous. To further reduce the danger of falling, I’ve decided to fit my RTT so that the entry will be from the rear using a set of well formed, large and stable steps. This rear entry concept does have an impact on the method I’ve chosen to fit my RTT to the trailer.
I’ve chosen to use a James Baroud Evasion M Evo, based on good reviews and inspecting the options available at retailers around Melbourne. I purchased my RTT from Outback HQ, and I’m very happy with their customer service.
Following delivery of my Stockman Pod Extreme, the large cardboard box was placed on top and secured for the drive home.
Fortunately there was no further excitement until I was able to crane off the RTT and get to work mounting it.
Firstly the Stockman Pod Extreme RTT Upgrade gas struts needed to be attached to their mounting points in the lid of the trailer. If they weren’t added before the RTT was fitted then the smaller standard struts (which remain) wouldn’t be able to lift the lid with the tent. Adding the heavy duty struts costs some access to the trailer, by reducing the angle of the lid, but it is not significant.
However, with the heavy duty gas struts in place, the lid needed quite some encouragement to close. I needed to juggle ratchet straps to close it down.
Rear Entry Reinforcing
Usually Outback HQ recommends that the James Baroud M sized tents need just two bars, but they should be widely separated. Larger sized RTTs need to have three bars to support them properly.
With the Stockman Pod the Rhino Aero bars are just 1.5 metres apart, which is quite close but not an issue normally. However, as I was planning to use the rear entry of the James Baroud Evasion RTT there would be quite a lot of load over the end of the tent, out beyond the internal aluminium rails integrated into the tent under-shell. This could lead to cracking the outer shell in the worst case.
To provide an additional layer of strengthening to both front and rear of the RTT, I have added full length aluminium beams under the existing integrated rails but extending to the end of the tent shell at both front and rear. This provides full support for sitting on the rear ledge of the tent (when entering or leaving), and also provides additional strengthening for the entire mounting system.
I chose to use 100mm x 50mm x 3mm thick aluminium channel. This is the largest channel shape that can fit between the top of the Stockman Pod Big Top Lid and the top of the Rhino Aero bar on which the RTT would be mounted. As the Aero bar is only 40mm thick, this left 10mm of material on both sides of both channels to provide the end-to-end strength that I desired to achieve.
Overall, this mounting method adds significant strength and security to the whole build. The RTT cannot “lift off” the bars, as the Aero bars are inserted through the channel rails which are tied at multiple points to the RTT chassis rails.
Now the trailer lid can be comfortably opened and closed with the RTT fitted, either stowed or open. With the RTT stowed or even opened, the front tool box can be opened too.
Building Rear Step
My Stockman Pod Extreme is fitted with the plywood storage shelf and two aluminium storage bins, as well as the standard fold down tail-gate. These conveniently provide two large and stable steps up to the RTT. In addition only a low stool or step is needed for the first step up to the tail-gate.
So all that was needed was to turn the top of the storage bin into a large step. This was done with a sheet of 2mm thick aluminium non-slip tread plate, carefully cut, and folded for strength, and fitted across the top of the storage bin. As a side benefit, the aluminium step can be stored in-situ on the storage bin so it takes no space to transport.
Obviously, the wooden school chair photographed is not a permanent solution. I will get a work step or stool that can be used to provide one or two steps up to the tail gate. The tail gate makes a safe stoep to leave boots and mud before stepping up into the RTT via the storage bin step.
To exit the RTT it is just a matter of sitting on the edge of the tent shell and your feet naturally find the top of the storage bin step, and you can stand up (preferably holding onto one of the tent roof struts for stability), before stepping down to the tailgate. It is even possible to sit on the storage bin lid when putting boots.
I would also point out that the aluminium storage bins are 2 metres long, and are contained within a structural case. The storage bins are designed to hold well over 100 kg of items. The step could be used with the storage bin extended by over a 1 metre (rather than just the depth of the tail gate, about 40 cm). So, the step is quite strong and overall using this rear entrance to the RTT is much safer than the standard folding aluminum ladder.
As discussed in the Curb Weight post, I decided to purchase a custom built Stockman Pod Extreme for Going Bush. I took delivery of following a short delay because I asked to add Rhino Rack Aero bars and upgrade the lid to support a roof top tent.
This is a short note to cover the adjustments that I made to the standard Stockman Pod Extreme product, that do not appear on their options list.
To use the drawbar to carry light weight items such firewood or rubbish, added 4 D-ring tie-down points welded to the inside of the bar. This will enable the load to be secured on the top of the drawbar, and therefore not need to pass under the bar where the tie-down strap could be cut or scraped on a rock. The tie-down points are also set up enough to allow a PVC or steel pipe to pass through them, potentially allowing a hammock style carrier to be created for smaller items.
I added a gusset between the frame and drawbar. Stockman have never seen a case where separation was a problem but, since it was easy to do and it made me happy, it was done.
Water Tank Bash Plate
The Stockman water tank is 6mm thick poly roto-moulded plastic and it is very tough, well able to withstand blunt trauma from rocks and other material. It is also located much higher than the tow vehicle ground clearance. So there is little that can go wrong.
But to prevent damage due to sharp objects, such as branches and sticks, I’ve added an aluminium bash plate to the underside of the water tank. This is not to prevent normal impacts from being absorbed by the poly plastic tank, but rather to prevent a sharp object from penetrating the plastic. The concept is like lightweight medieval chain-mail used to prevent cutting and stabbing, rather than full plate armour.
Suspension Reinforcement Bracing
Triangulation gussets between the suspension hangers and the spring mounts was added as per the CruiseMaster installation recommendation. Prior to my build this was not being done but now it has become standard practice for Stockman to add the triangulation reinforcement bracing.
Hayman Reece Recovery Points
And finally, the standard D-ring recovery points were replaced with Hayman Reece 2″ hitch points. This allows recovery straps to be connected to the hitch point with standard hitch pins, rather than using a shackle. Also each Hayman Reece hitch can support other accessories, such as a vise mount for example. Using two hitch points allows recovery forces to be shared onto both side of the frame, and allows the trailer to be guided more accurately for a reverse recovery.
ReGIS graphics can be used to build high quality vector graphical output for embedded (Serial) devices, for example Arduino devices or retro-computers such as the RC2014 running CP/M, with the graphics output being displayed on a Windows 10 desktop. This method uses WSL Ubuntu with XTerm to support graphical output for Serial connected embedded devices, and a Windows based X Server to host the display.
ReGIS is useful to display information that can be more easily interpreted as a diagram or a graph, such as plotting planet motion. It can also be used for vector graphics such as the GLX Gears program.
Today, where DEC VT series terminals are impractical to obtain, the easiest method to display ReGIS vector graphics is to use the XTerm terminal emulator. The XTerm fully supports ReGIS, but this capability is not enabled in general release versions. We’ll need to compile our own version with ReGIS enabled.
XTerm was developed for the X Windows System running on versions of Unix or Linux. So to use it on a Linux desktop machine running (e.g. Ubuntu) is quite straightforward. But if we want to use it on a Windows 10 desktop we will need to jump through some additional hoops and that is the point of this story.
The X window system (X) is a client / server windowing system developed in the mid 1980’s to support remote windowing. Unlike most earlier display protocols, X was specifically designed to be used over network connections rather than on an integral or attached display device. X features network transparency, which means an X client program running on a computer somewhere on a network can display its user interface (window) on an X Server running on some other computer on the network. The X Server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X Server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user’s computer to request the rendering of graphics content and receive events from input devices including keyboards and mice.
To get XTerm to connect to a Serial interface, provided by an Arduino device or by a retro-computer such as a RC2014 CP/M machine, it is necessary to use a dumb terminal emulator to pipe the Serial bit-stream originating on the Serial-USB (FTDI) interface connection to XTerm without tampering with the non-displayable ESC code sequences that ReGIS uses for signalling. The best option is to use picocom for this role. Most other terminals “cook” the Serial to remove those ascii control characters that can’t be displayed, rather than passing them transparently.
We now have a complete solution to display ReGIS graphics originated on an Arduino or RC2014 on Unix / Linux machines. XTerm, configured with ReGIS enabled, together with picocom to pipe the Serial bit-stream is all that is required to display vector graphics on a Linux desktop.
To use Windows 10 as the desktop we will need to host a Unix / Linux machine running XTerm and picocom somewhere connected to the embedded device, and provide an X Server on the Windows 10 machine to display the window generated by XTerm. This can be done with a completely separate Linux machine, such as a Raspberry Pi or similar, but it is more convenient to do it using a Virtual Machine inside the Windows 10 platform provided by Windows Subsystem for Linux.
Microsoft provides two versions of the WSL. The first version WSL1 uses specific services and drivers to give Linux applications access to the Windows 10 kernel and file system. WSL1 supports access to Serial interfaces and the host file system. The use of the specific services and drivers between the Windows 10 kernel and Linux causes a performance penalty for most Linux applications, so WSL2 was introduced with a lightweight virtual machine, based on Hyper-V, to optimise Linux application performance. However WSL2 does not allow access to Serial interfaces or direct access to the Windows 10 file system. For most applications WSL2 is a better choice, but as we need to access the Serial interfaces directly we need to use WSL1.
From our Windows 10 desktop machine we need to provide an X Server to enable XTerm to display its window on our desktop. There are several options available to do this. Xming (not free) and VcXsrv (open source) are two that are commonly recommended.
Another option to provide a Windows 10 X Server is MobaXterm. MobaXterm is proprietary, but is available for free for home users. It provides both an X Server (based on X.org) and secure shell (SSH) capability. SSH is particularly required where we need to connect to XTerm and picocom (the X client) running on separate Raspberry Pi hardware, but it is also useful for Windows 10 WSL. However, we can access WSL Ubuntu directly through its own terminal to initialize the XTerminal session, so for WSL Ubuntu the SSH capability is just a very convenient “nice-to-have”.
Lets go through the steps required to get this all working…
Windows Subsystem for Linux & Ubuntu
The Windows Subsystem for Linux (WSL) allows Linux / Unix distributions to use the Windows host computer. This instruction is based on Ubuntu 22.04 LTS, but other distributions will be similar.
Once WSL is installed then go to the Microsoft store and install Ubuntu 22.04 LTS. There are options for both Windows 10 and Windows 11, so choose the suitable alternative.
Confirm that you have both WSL1 and Ubuntu 22.04 LTS installed using. > wsl -l -v
And then set the default distribution to Ubuntu-22.04. > wsl -s Ubuntu-22.04
Then launch the Ubuntu 22.04 LTS subsystem using the Windows Start menu command, to configure the new distribution. Update and upgrade the packages using apt, and make any other adjustments you need. Set up directories that you will use to build XTerm and (optionally) build z88dk. Building z88dk will ensure that you have the prerequisites to prepare .COM files for later uploading to your RC2014 CP/M.
At this stage DO NOT install XTerm or picocom from the Ubuntu repositories.
Launch the installer. It will automatically recognise your installed WSL and Ubuntu 22.04 LTS instances and will automatically configure SSH (local) terminal access for them. It will also allow you to connect directly to your Serial attached Arduino or RC2014 retro-computer if you configure a serial connection.
Use MobaXterm to connect to your Ubuntu 22.04 installation. The advantage of doing this is that the DISPLAY environment variable is automatically set, so that later XTerm can find the Windows 10 screen with no further setting needed. However, the direct Ubuntu 22.04 terminal can alternatively be used later for other purposes with no problem.
Preparing XTerm to support ReGIS
XTerm is the only known software solution supporting ReGIS. But it doesn’t support ReGIS in the default build. You’ll need to enable ReGIS support yourself by building and installing a customised version.
From your WSL Ubuntu command line use the below recipe. If you have not built any prior code on your WSL Ubuntu installation you may need to add additional packages, as signalled by the configuration step. Use apt to install them as needed.
> sudo apt install -y build-essential libxaw7-dev libncurses-dev libxft-dev
> wget https://invisible-island.net/datafiles/release/xterm.tar.gz
> tar xf xterm.tar.gz
> cd xterm-373
> ./configure --enable-regis-graphics
> sudo make install
Install picocom for Ubuntu 18.04 LTS
From Release Version 3.0 picocom implemented advanced terminal control system calls, which are unsupported by the Windows 10 WSL1 implementation. This means that the Ubuntu 22.04 LTS supported release for picocom can’t be used with WSL1.
To initialise XTerm for VT340 emulation, connecting to Windows 10 Serial device COMx, from the MobaXterm terminal use this command string. This command assumes we’re using 115200 baud 8n2 with RTS flow control, and we’re going to use XMODEM protocol to send binaries to our RC2014 or other device. Check the picocom manual to adjust the serial interface configuration to your own needs.
At this point a new XTerm window should appear on the Windows 10 desktop, supported by the MobaXterm X Server.
Assuming that you have a program which can generate ReGIS graphics already installed on your RC2014 (or Arduino), such as the demo program provided here, then it is time to start the program from the CP/M command prompt. Otherwise, it makes sense to use XTerm (with picocom) to access your RC2014 and upload the provided ReGIS demo program, or other any other program, using XMODEM protocol and the XM.COM or XMODEM.COM program on your CP/M installation, and then launch the program from the CP/M command prompt.
The resulting XTerm window (example image shown is planet-motion) should look similar to the image below.
And that is then all that needs to be done to enjoy high resolution vector graphics generated by a Serial connected embedded device such as an RC2014 running CP/M or an Arduino device.
The ReGIS library for z88dk has been developed to support ReGIS on the RC2014 and other Z80 CP/M machines. Therefore programs can easily generate the required Serial codes using the C functions provided.
The ReGIS library for Arduino is hardware agnostic, and supports all Arduino architectures. It can be installed from the Arduino Library Manager.
I’ve pitched a camp to test that I’ve got all the required things. The lists are great, but they don’t necessarily match completely with reality.
It is still a few months before my vehicle and pod trailer are going to be available, so my old station wagon is serving as the test mule. I loaded everything in and transported it to the camp. It took two trips as I’m minding an extra dog, and have to allow space to transport dogs rather than equipment.
Of course the weather doesn’t play nice, and it is raining continuously as I try to set up the camp. And, since I’ve pitched camp about 80m from the closest approach, everything has to be carried in through the rain.
The first job is to work out where the table, and cooker work best. I’ve decided to put the table into the middle of the gazebo space, and then use one side for cooking, and later the other side for sitting / reading / writing. Putting the kitchen in the far corner allows me to empty water, coffee dregs, etc onto the grass, and keeps the inescapable ants away from the tent.
Very happy with the old Primus stove. I’ve inherited many pieces of my kit, including the tent, cooker, and quite a few tools and whatnot. So it is the first time that the 1970’s stove has been used in a long while.
Similarly, my Terka Tent from Czechoslovakia also looks to be performing well. It hasn’t been out of the bag since the early 1980s. Yet, after standing in the rain all day, it still looks to be fine inside. But time will tell.
As I’m minding an extra dog I had to build a bivouac for her. Using a cheap tarp found in the local supermarket pegged out with 1/3 under and 2/3 over, a piece of 10mm insulation board to get her off the ground, and her own blankets from home, I was able to make her a dry and warm place to sleep.
I’d forgotten how slow it is to get things done. In a house there’s hot water on tap, and boiling water from an electric kettle, and food straight out of the refrigerator. Living in the outdoors, things are not so time efficient. To make a coffee requires preparation, and cleaning up. A choice has to be made as to whether to clean up first, and have cold coffee, or to enjoy the coffee, but then have the chore of cleaning up after the relaxation of consuming the coffee. Similarly, preparing toast, making tea, or any other process around the kitchen needs extra steps that either add time, or reduce the “enjoyment” value of the activity.
Over the weekend the weather got better and better, and once things had dried out the ease of doing everything increases. Fortunately, as it wasn’t too windy, the gazebo provides 9m2 of living space protected from the rain. So, it seems that at least in still weather the gazebo is a valid alternative to a vehicle awning.
Proving to myself that there is no real benefit to a vehicle awning is a big thing. Vehicle awnings are expensive, are heavy high on the vehicle, and they increase fuel consumption because they rely on having a roof rack to mount them. They also force you to limpet yourself to the side of your muddy or dusty vehicle and they need to be closed before the vehicle can be moved.
I used some extra guy ropes looped through the gazebo frame and anchored to the ground, to hold it very stable. The gazebo roof is only held onto the frame with Velcro. Should a strong wind gust take the nylon roof off, the frame will remain tied down. A piece of nylon material floating or flapping about won’t do any damage, and will probably come back down to earth quickly as it has no form holding the wind. Alternatively, attempting to hold a 9m2 “sail” to the ground in the face of a strong wind gust is a pointless endeavour.
I am pretty happy with the kitchen set up. The stove, and substitute Engel refrigerator are easy to use, and effective. I purchased some wicker (plastic) boxes, which I used to store 1. Food, 2. Crockery, 3. Pans and Utensils, and 4. Cleaning and Utility products. These are much easier to use than plastic shopping bags (which would have been the temporary alternative), yet they’re not perfect. The issue is juggling them from the ground (in the rain), to the 5’ Lifetime Table or the top of the Engel. If I build a kitchen storage in the back of the Rubicon, then that may solve the juggling of containers, but it may create an issue where things are hard to access. Another alternative is to organise the boxes by process or task or by frequency of access, rather than by topic as I’ve done now.
For the sleeping arrangements, I’ve got it generally right, but I’m still not totally happy. The combination of the stretcher and mattress makes for a very warm and comfortable bed. However, the way I’ve organised the YHA Bedsheet together with antique woollen blankets is uncomfortable. They slip around on the mattress, and become tangled quite easily. One very pleasing accident with the YHA Bedsheet is that the pillow slip serves to hold the pillow from slipping off the end of the bed. As the stretcher has no “head” this can happen easily, so it is very useful that the pillow is retained by the sheets.
As I’ve prepared the bedding into a rolled swag, with an 6’x8’ tarpaulin outside the self-inflating mattress, sheets, and blankets, the idea of storing everything together has worked well. The plan is that having all the bedding rolled together will allow the bed to be dropped anywhere and used, and stay dry until unrolled even if it is carried in the rain.
Because the Engel refrigerator is very heavy, as an exception I used a handcart to move it from the vehicle to the camp site. And, because I had it with me I was also able to use it to move the 12V battery, 20l water containers, and other heavy items. A handcart is not something that I’d previously considered taking along, but now I think if there’s space then it will come with me. It will be useful for moving water, firewood, and many other backbreaking tasks.
I didn’t bring a broom. I should have. A hand brush is useful to sweep standing water, meat ants, and leaves off the ground tarpaulin, and to clean the tent and generally around the site. But I think that a broom would work better and be much easier on the back.
I’ve taken some pictures of the things that worked, to remind me what comes with me.
Stadium Seats for chairs are very comfortable, and weigh nothing. They can be used anywhere. The handcart is a very useful addition. Not sure about collapsing water containers. Sure they’re easy to store and keep handy, but they’re not easy to use when half full. So, it is best to transfer their contents into a “working” container. The kettle was used more often than any other utensil. Hot water is essential.
And finally, the Australian bush just loves to come home with you. This “little” guy was hitching a ride in the cutlery container. He joined with the meat ants roaming around the campsite, and mosquitos swarming everywhere, making this camp a 3 of 6 wildlife expedition. Fortunately no scorpions, or snakes. And no centipedes.
From the previous discussion on Curb Weights I’ve selected a method to transport sufficient water, fuel, supplies, and equipment to travel in the bush. But, I also need to examine how best to sleep given the impact of common environmental influences in the bush.
There are a number of sleeping systems provided by the vehicle and system for going bush. The below images try to indicate these in context.
I’ve found many options are possible. Six major options are indicated above, related to the previous discussion on curb weights, and they are discussed following some basic environmental considerations.
Roof Top Tent
The environment of Australia plays the major role in determining the best sleeping system. Let’s talk about the environmental aspects of sleeping.
There are no bears, lions, or other large predatory mammals in Australia. The wildlife is much smaller, more intimate, and loves nothing more than a warm bed to snuggle into during the cold desert nights.
Keeping the local wildlife away out of your bed, and out of your boots, is an important consideration for where your bed should be.
The Dry Creek
When selecting a flat smooth camp site it is easy to believe that a dry creek bed is a good place to spend the night. Unfortunately bush creeks are subject to flash flooding, and the storm which causes the flood may be a great distance away. It may not even rain where you are.
While the flood waters will not be as extreme as shown here (Todd River, Alice Springs, Northern Territory), it is very possible that a creek bed campsite can become subject to anything from a trickle of water to an active flowing creek during the night.
The Gibber Plain
The term “gibber plain” is used to describe desert pavement in Australia. It is a desert surface covered with closely packed, interlocking angular or rounded rock fragments of pebble and cobble size. Desert varnish can collect on the exposed surface rocks over time.
Gibber is located across of much of central Australia, and in the desert you’ve a choice of sand dunes, bull dust, or Gibber plains on which to make a camp site. So, remember to take a rake.
Ok, now we’ve got some of the environmental preamble out of the way, let’s look at the options for sleeping comfortably.
The swag or bed-roll is the traditional method of rough camping in the Australian bush. It is basically a canvas tarpaulin with a mattress inside. They’re quite warm and they’re also waterproof. It zips all the way up so it covers your head, and you have the canvas for a rain cover. The swag is useful for any of the options for carrying the equipment, and can be used in good conditions even when other alternatives are available.
The swag is the choice of bedding for a swagman. A swagman was a transient labourer who travelled by foot from farm to farm carrying his belongings in a swag. The term originated in Australia in the 19th century and was later used in New Zealand.
Swagmen were particularly common in Australia during times of economic uncertainty, such as the 1890s and the Great Depression of the 1930s. Many unemployed men travelled the rural areas of Australia on foot, their few meagre possessions rolled up and carried in their swag. Their swag was frequently referred to as “Matilda”, hence the song Waltzing Matilda, based on Banjo Paterson’s poem, refers to walking with their swag. Typically, swagmen would seek work in farms and towns they travelled through, and in many cases the farmers, if no permanent work was available, would provide food and shelter in return for some menial task.
A swag is quite the romantic holiday experience for backpackers, but it is not going to protect the quality of your sleep from gibber plain cobbles, local wildlife, or flash flooding. So its use case is limited to good conditions, and it shouldn’t be relied upon in bad conditions (if you want quality sleep). Score here is 0 from 3 environmental points.
Tents are the next option to discuss. They can protect you from local wildlife, provided they are always properly closed up and are in good condition. They will protect you from bad weather and some water flow. But inside the ground will still be rocky and uneven if camped on gibber cobbles or other rock formations. So let’s say the tent scores 1.5 from 3 environmental points.
Roof Top Tent
The Roof Top Tent would seem to address all of the failings of a normal tent. Placing the tent up high, with a flat bed and mattress, removes all of the environmental issues and scores maximum 3 points.
However, the RTT has a fatal flaw. Every time you go up to bed, or get out of bed, you have to climb a 2m high ladder. This is not an issue 99 times from 100 times, but if you’re sleeping in it for a year the chances are you’re going to slip at least 3 or 4 times, and one of those times (in compliance with Murphy’s Law), you’ll break your leg, and that fall will occur in the middle of the Simpson Desert.
From that safety issue alone the Roof Top Tent has a complete veto, in my opinion.
The stretcher bed, cot, or camp bed is an option to uplift quality of sleep in a tent, under a swag, or anywhere there is no full mattress available. The stretcher bed adds environmental points to the tent and also to the swag by lifting you above gibber and minor water, and protecting against most of the wildlife issues (except mosquitos).
The Experts agree that if there’s space available they would never go bush without a stretcher bed. The combination of tent and stretcher bed scores the full 3 environmental points.
While the trailer, and specifically the pod trailer, is not designed for sleeping, it can be used as an alternative sleeping platform in the case of bad weather, when the gibber or bull dust is too thick to sleep on the ground, or when there is no need to set up a tent.
Pod trailers can be optioned up to become a full soft-floor camper, but that is not the intention of this discussion. The goal is simply to point out that, as an alternative, the bed of a pod or box trailer can be used as a base for a swag or bed roll, instead of using a stretcher bed, and it scores 3 environmental points for this purpose.
Perhaps, the best option is to fit a RTT to the top of a Pod Trailer? This would avoid the fatal safety issue incumbent in vehicle mounting, and score the maximum points.
Sleeping indoors, while in the great outdoors, is the epitome of comfort. Having a clean, dust proof, wildlife proof haven at the end of the day will provide the best possible sleep quality. But, of course this does come at some expense, and the issues covered in the Curb Weight discussion apply. Scores 3 environmental points.
Going into the Australian Bush requires the intrepid traveller to carry substantial supplies of water and fuel, as well as the normal requirements for living off-grid for extended periods. This is quite different to the norm in international overlanding where fuel and water is usually available in small towns, and is due to the very (incredibly) low population density of the Australian Bush. The population density of the Australia’s Northern Territory is 0.16 people/km2, about 1/100th of the density of Argentina with 17 people/km2, or 1/25th of Botswana with 4 people/km2, for example. So the purpose of my lists is to estimate the weight required to travel with some comfort across long desolate desert tracks, before the required fuel and water supplies are added.
Whilst my lists remain incomplete they are a useful tool to establish the the total equipment and supplies budget, and then contemplate the best method to carry everything. My current calculation shows that the normal total mass estimate is around of 575kg, including fuel and water. A rough breakdown of the categories is below.
Recovery Equipment – 50kg
Vehicle Spares / Consumables – 20kg
Tools – 30kg
Camping Equipment / Tents / Tarps – 90kg
Battery & Electrical – 50kg
Refrigerator / Slide – 45kg
Cooking Utensils – 20kg
Computers / IT / Camera – 20kg
Clothes / Blankets / Linen – 30kg
Food – 30kg
Unclassified / Toys – 20kg
Adding to the items above, is necessary to carry water sufficient for 20 days. And fuel to bridge the longer distances between services.
Now that might look like I’ve budgeted to carry a lot of stuff, but the idea is not to load up to 100% capacity before departure. But rather the calculation is intended to to allow room for growth as over time, as stuff tends to accumulate, and trophies and memorabilia will take up their share of space too. Nobody likes to climb into a vehicle and have their stuff fall out on the road because everything is packed to the roof.
So, I’m going to estimate that a total payload budget of 600kg will be sufficient. How can that payload be effectively carried across sand and rock over thousands of kilometers?
Carrying the Payload
As a starting point, the Jeep Wrangler JL Rubicon 2 door is the chosen vehicle for going bush.
From the 2020 Wrangler Specification, the Rubicon can carry a maximum payload of 1322lbs, or 600kg, in the 4 door version. The 2 door version has similar mechanical specifications but weighs about 100kg less, but I will assume that it can’t carry a greater payload than the larger 4 door version. Maximum braked towing capacity for the 2 door version is 1497kg. Let’s have a look at some of the options for carrying 600kg with a 2 door Rubicon.
In the above images I’ve considered some alternative solutions for carrying 600kg payload (in green), and the maximum usable axle load (in red) for the vehicle. My alternatives include:
Bare Vehicle – everything inside the vehicle
Roof Rack – 450kg in vehicle, 150kg on roof (and outside)
Roof Top Tent – 500kg in vehicle, 100kg of RTT (and outside)
Box Trailer – 200kg in vehicle, 400kg in trailer
Pod Trailer – 200kg in vehicle, 400kg in trailer
Teardrop Camper – 200kg in vehicle, 400kg in camper
The Wrangler 2 door is a very small vehicle and, although it is probably the most capable 4WD available “off the showroom floor”, loading it up to the maximum payload will make a very uncomfortable origami that would need to be unfolded at each camp and then intricately repacked each morning. Additionally, as the maximum rear axle payload is about 1000lbs, or 450kg, the available payload would be limited to less than the maximum vehicle payload, as there would be no way to share the weight to the front axle.
In my opinion only way to carry 600kg on a Rubicon is to distribute the weight onto both axles by using a Roof Rack.
By adding a roof rack, and possibly also side racks for fuel and a rear rack for tools and fuel, it is possible to distribute the weight onto both axles, and also increase the load volume of the Rubicon sufficiently to reasonably store the maximum vehicle payload.
The cost for roof rack system consists of a base rack of around A$1,000, guard rails at around A$500, and then vehicle specific mounting kits from around A$400. Accessories to mount shovels, high lift jacks, jerry cans, or gas bottles can be added for around A$200 per item.
Adding a roof rack will increase the loading on the front axle and especially the rear axle up to the maximum design rating of 3100lbs, or 1400kg, and will increase the tire load affecting both sand driving ability and the tire wear characteristics. Axles, wheels, and tires will be running at maximum load constantly. Adding a lift-kit to balance out the spring compression will not resolve this loading issue, and it is likely that the vehicle may end up being over-weight from a legal (insurance) perspective.
Using a roof rack will also significantly impact the dynamics of the vehicle. Adding up to 100kg onto the roof and 50kg to the outside of the vehicle will increase the overall pitch and roll as the track pushes the vehicle around. It will be very uncomfortable, and may actually become unsafe as the maximum approach and departure angles are reached.
On road, which will be the majority of the kilometres travelled, fuel economy can suffer by 10% and up to 25% according to some reports. Where tens of thousands of kilometres are at stake, and fuel is both in limited supply and expensive, it is best not to use a roof rack if there are better alternatives.
Roof Top Tent
The roof top tent suffers from the same dynamics and fuel economy issues as the roof rack, and it is also of very limited application being purely a place to sleep. If a roof top tent is fitted then the top of the vehicle can no longer be used for storing equipment.
A roof top tent costs around A$,5000, but considerably more can be spent if desired.
With the issues associated with roof top tents being the same as with roof racks and offering no other advantages, it is better to seek alternatives.
Many people have realised the benefits of an additional load carrying axle when travelling around Australia. The typical steel box trailer in the standard 6’x4′ or 7’x5′ single axle configurations lives in most suburban back yards, and has been making the journey to the summer camping holiday since forever. It has become more common recently to add off-road suspension and hitch components to make the box trailer capable of serious expeditions.
The typical suburban box trailer costs around A$1,500, but the vehicle must have a trailer hitch which can cost up to A$2,000 to install, depending on the vehicle. An off-road trailer with uprated suspension and chassis typically starts around A$5,000, but specialist camper trailers can be substantially more. Some fully fitted off-road box trailers cost upwards of A$60,000.
The design and registration of box trailers typically focusses on a gross vehicle mass (GVM) of 750kg and their Tare is typically 250kg, in the best case, leaving a payload capability of 500kg. If our total load can be distributed between vehicle and trailer then we can load the trailer with 400kg, leaving a margin of 20% remaining, and reduce the vehicle load to 200kg.
The load in a trailer is carried with a low centre of mass, so that the dynamics of the tow vehicle are not affected, and having the additional loaded trailer axle reduces the wear on the vehicle axles, wheels and tires.
However, towing a box trailer does not come for free. There is an increase in fuel consumption to be expected from towing. Depending on the size of the load carried and the amount of wind drag created by the trailer, the increase in fuel consumption may be up to 10%. This is significant, but it is much less than if a similar load were on a roof rack. And, as we now have a greater free load capacity it is possible to carry up to 100l of extra fuel as needed.
An important advantage to using a trailer is that it can be disconnected from the vehicle and left behind at a camp site, or trail head, when its contents are not needed. Through this method most of the payload associated with living does not need to accompany the vehicle on a difficult 4WD trail. This minimises the chances of breakage or damage to the payload.
The box trailer has several disadvantages. Firstly, the load is carried open and unsecured, and secondly, the payload is subject to dust and sand from both the vehicle rear wheels and the environment generally. Whilst Australia is generally safe, for piece of mind, it is best to keep valuables and equipment hidden out of sight when the trailer is left behind. So box trailer loads are usually covered by a tarpaulin or load cover. This adds to the soft security of the load, and helps to prevent dust and sand ingress, but it is time consuming to wrap and tie down the load each morning.
There are many advantages to using a simple box trailer to carry the payload, but it would be more ideal if the box trailer load could be covered by a solid lockable lid to secure the load and mitigate dust and dirt ingress.
Recently advances in plastics technology have enabled the creation of large roto-molded polyethylene structures, and companies have started to produce off-road “pod” trailers using polyethylene tubs and lids jointed like a clam shell and sealed with a gasket to produce an effective dust seal.
Typically these pod trailers incorporate all of the advantages of the box trailer, adding in the tare weight saving of a dust resistant plastic tub and sealed lid, and the aerodynamic efficiency of a smooth load top.
Many pod trailers can carry a payload of 750kg to 810kg, with their GVM being 1250kg with trailer brakes. An extreme off-road pod trailer can cost from A$13,000, and customisation and options can be added to increase the suitability for long distance expeditions.
With an appropriate off-road independent suspension, hitch, and trailer brakes, a pod trailer can follow behind a vehicle on all but the most difficult 4WD tracks. And where necessary the secure lockable pod can be left behind at a camp site or trail head.
Moving up from the box trailer or pod trailer solution, it is possible to consider a teardrop or square drop camper. The key advantage of the camper is that the question of sleeping arrangements is answered by a permanently made bed. At the end of a day, or when weather is bad there is a lot to be said for a ready-made bed.
A teardrop camper is usually a significant Tare approaching 900kg, and they can usually carry at least 400kg and up to 800kg in payload. They can easily accommodate the 400kg we need to carry. However the camper GVM will certainly be approaching 1,900kg when fully loaded. This is about 1 Tonne more than a box or pod trailer.
Teardrop campers range in price from A$50,000 and up to around A$100,000, making them potentially more expensive than the tow vehicle.
Besides the large GVM of the teardrop camper, there is a cost to transport the volume for a bed and “sleeping space” around the country. The cost comes in increased the form of increased drag and increased fuel consumption from the larger box, and in reduced space to store camping equipment, unless the potentially dirty equipment is transported on top of the clean made bed.
Conclusion and Decision
Following on from the discussion above, I have decided to go with the pod trailer solution. Although using a trailer will close off some of the more extreme trails and options, such as parts of the CSR, the flexibility to leave the pod and equipment safely behind at the campsite, and have the small tow vehicle remain relatively unmodified (no heavy duty springs, or body lifts, etc), together with the other points discussed above, make the pod trailer the best value for money.
Really, I should be doing better than this. With a background in Agile Methodologies and Waterfall Project Management, using lists is positively Neanderthal in comparison. Yet, here I am. To get things done, and to remember what needs to be planned and done , I’m writing lists.
About a month ago I asked a good friend whether he’d be interested to join me in the bush for a while, since it had become obvious the only other interested co-traveller was our family dog. His response was, “Would I like to have a copy of a mutual friend’s 23 camping lists?” To which I just laughed. I mean 23 lists… come on. How many lists to you need to leave the house for a few weeks?
I didn’t think about lists for a while. But then after consuming another 20 hours of YouTube suggestions and recommendations for overlanding or international expeditions, I could no longer hold all of the thoughts and ideas in my head. And then I realised that this mutual friend has the right idea. Put it on a list and then it is managed. Putting it on a list doesn’t get it done, but it does get it reviewed every time the list is examined.
One month into this, I’ve established 11 lists for going bush. At this stage I’ve written no lists of destinations or activities, but rather focussed entirely on what I’ll need to make sure that being out bush won’t be life threating, and will be mainly enjoyable.
So here’s my “TOP 11” List of Lists for going bush.
Vehicle – accessories and upgrades
Recovery – how to recover from vehicular stupidity
Tools – fixing things that fail
Spares – consumable items for vehicles
Camp Equipment – portable lifestyle
Cooking Utensils – to eat healthily
Camp Consumables- not quite food, but related
IT / Photography – toys related to bush activities
Planning during the past two years has been impossible. Worldwide, for everyone, so many things have changed.
I had plans, but I guess they’ve changed too. I no longer possess a licence for free movement, so leaving the country has become impossible. In the interim I’ve decided to go bush, at least until the restrictions on free movement are relaxed, and probably longer.
The Australian term “to go bush” has various definitions, including “to abandon amenity, and live rough” or “to live a simpler or more rural lifestyle”. Alternatively it can be seen as “going into hiding, to avoid authorities”.
So these will be my notes on going bush. Since I’m not photogenic, vlogs are out and the written word will have to suffice. I hope to cover my motivation for decisions on timing, routes, and gear. And when the adventure finally begins, and I am truly “gone bush”, updates on activities should come regularly wherever the Internet exists.
Just over 4 years ago, on 18th March 2018, I committed the first CP/M-IDE files into the RC2014 repository. Now that some time has passed and it has developed into a stable solution for CP/M I think it is time to fill in some details about why it was written, how it differs from other CP/M implementations, and how to reproduce images to match those in the CP/M-IDE repository.
There are several implementations of CP/M available for the RC2014. Initially, the CP/M on breadboard implemented by Grant Searle became the default implementation for the Z80 RC2014. Slightly later Wayne Warthen added support for the RC2014 to the Z80/Z180 RomWBW System. RomWBW is a very extensive and advanced set of system software, supporting many different RetroBrew machines, and in general it requires 512kB ROM and 512kB RAM to reach its full potential.
Each of these implementations has its own focus. The 9 Chip CP/M is based on simplicity, and being able to be built on a breadboard with the minimum of complexity, but it uses an occasionally unreliable 8-bit CF Card interface and has a substantially smaller TPA. Alternatively, RomWBW supports a variety of hardware including Z180 CPUs, and provides an underlying generalised architecture support which provides paged memory and many facilities but this imposes a processing overhead on I/O, and requires substantially more RAM than a typical CP/M system.
Faced with both these options, and being very interested to build my own solution, and to use my growing experiences supporting the z88dk community, I decided to build CP/M-IDE to fulfil a specific niche.
The CP/M-IDE is designed to provide support for CP/M on Z80 while using a normal FATFS formatted PATA or IDE drive. And further, to do so with the minimum of cards, complexity, and expense. Most recently, it has also become the CP/M which supports the 8085 CPU Module. Also recently, support for the standard RC2014 Pro with CF Module has been added.
Initially I chose the IDE Hard Drive Module specifically because I could use it to attach any old hard drives, aka “spinning rust”, to my RC2014, and this led to support for everything from these old 3 1/2″ hard drives, through to modern SSD or DOM solid state drives. It also supports both old and modern Compact Flash Cards in their native 16-bit mode, so readily available modern 1 and 2 GigaByte Compact Flash cards are OK. It is also possible to use SD Card to CF Card adapters with the IDE Hard Drive Module, allowing direct support of modern pluggable storage.
CP/M is a very compact Operating System and, in the most common version 2.2, it supports only serial interfaces and disk interfaces. For the RC2014 there are two standard serial Modules, being the ACIA Module and the more advanced and expensive SIO/2 Module.
As I’m quite interested in building real-time and event driven systems, in contrast to other CP/M implementations, CP/M-IDE therefore includes drivers supporting both transmit and receive interrupt based solutions, sourced from my z88dk RC2014 support package for the ACIA serial interface and the SIO/2 serial interface.
8085 CPU Module
More recently I have built a 8085 CPU Module for the RC2014 System. This is the first time that an 8085 CPU has been integrated into the RC2014 System, and it is able to work with the Z80 bus signalling required to drive the standard RC2014 Modules.
The concept remains to use the minimum of additional hardware over the entry level RC2014 Pro model. In fact just the IDE Hard Drive Module is desirable. But, the standard CF Module (and derivatives) can also be used, subject to the limited support of modern CF Cards.
IDE Hard Drive Interface
The IDE Hard Drive Module is based on the 8255 PPI device. This device was designed to work with the 8085 CPU and 8086 CPU. It is perfectly suited to supporting a 16-bit parallel IDE interface as it provides latching of signals on 3 separate 8-bit ports.
Initially I was concerned that the selection of control signal pins for the IDE interface limited the possibility for use of the 82C55 device for generalised I/O. I still think that this is an issue but, since no one has implemented further generalised solutions, the point is moot.
The IDE Hard Drive Module supports PATA hard drives of all types (including SSD IDE and DOM storage) and Compact Flash Cards and SD Card Adapters in native 16-bit PATA mode with buffered I/O being provided by the 82C55 device.
The IDE interface (or also termed diskio) is optimised for performance and can achieve over 110kB/s throughput using the FatFS library in C. It does this by minimising error management and streamlining read and write routines. The assumption is that modern IDE drives have their own error management and if there are errors from the IDE interface, then there are bigger issues at stake.
The CF Module interface can achieve over 200kB/s throughput at FATFS level, and seems to provide best performance using SD Cards in SD to CF Card Adapters. The default RC2014 CF Module is often unstable with modern CF Cards or with SD to CF Card Adapters. However there are options for third party CF Modules that have become quite reliable. If you experience problems, then seek out these alternative implementations.
For both IDE interfaces, within CP/M performance is approximately half the FATFS performance because the CP/M deblocking algorithm implements a double buffer copy process where 512 Byte physical sectors found on IDE disks are converted into the 128 Byte logical disk blocks that CP/M expects.
In the ACIA builds, the receive interface has a 255 byte software buffer, together with an optimised buffer management supporting the 68C50 ACIA receive double buffer. The choice of memory size for the receive buffer is based on optimisations available by having the buffer a full “page”. Also text can be “pasted” in fairly large chunks into the CP/M command line without losing bytes.
Hardware (RTS) flow control of the ACIA is provided. The ACIA transmit interface is also buffered, with direct cut-through when the 31 byte software buffer is empty, to ensure that the CPU is not held in wait state during serial transmission. The size of the transmit interface buffer is based on free memory within the CP/M BIOS. As BIOS memory is typically reserved to start on the 256 Byte page boundary, if an update needed to consume more RAM, I would reduce the size of the transmit buffer to avoid the need to consume an additional page of BIOS memory.
In the SIO/2 build, both ports are enabled. Both ports have a 127 byte software receive buffer supporting the SIO/2 receive quad hardware buffer, and a 15 byte software transmit buffer. The transmit function has direct cut-through when the software buffer is empty. Hardware (RTS) flow control of the SIO/2 is provided. Full IM2 interrupt vector steering is implemented.
As both ACIA and SIO/2 devices have a hardware buffer for received bytes, it is important for the receiving interrupt handler to drain these buffers completely before returning execution to the program. If this is not done there is a danger that received bytes could be overrun and lost.
For the CP/M-IDE 8085 build the Serial Output (SOD) FTDI interface found on the 8085 CPU Module is enabled as the CP/M LPT: interface. This is activated by using ^p as per normal practice.
Whilst there is no support for additional hardware within CP/M itself (as there are no BDOS calls standardised), it is possible to use additional hardware in CP/M applications. Typical hardware options include the APU Module, various Sound Modules, and digital I/O Module.
There are many descriptions of Digital Research CP/M, so I won’t go into detail. It is important to know that CP/M v2.2 was in its day the most widely deployed Operating System for small computers based on the 8080, 8085, and Z80 CPUs. Later versions of CP/M supported the 8086, and 68000 CPUs, as well as providing many more system functions than the CP/M v2.2.
Whilst there have been later versions of CP/M produced, to my knowledge, there were no widely available user applications produced which could not be run on CP/M v2.2. This broad compatibility is why CP/M v2.2 is important.
CP/M v2.2 is essentially just 4 pieces of code. The BIOS (Basic Input Output System) is provided to abstract the hardware devices from the operating system. Essentially there is a limited set of BIOS commands that the BDOS can call on. These BIOS commands are implemented specifically for the characteristics each machine, and in the early days of computing it was essential that a user knew how to write their own BIOS.
The second piece of code is the Page 0 of memory, which is written by the BIOS cold boot command on initialisation. The role of this Page 0 is to provide important addresses (for both BIOS and BDOS) and to set important status registers like the I/O Byte. The Page 0 is also used to manage the 8080, 8085, and Z80 CPU interrupt vectors, and to store the command line entered by the user when an application is initialised.
The CP/M BDOS is the middle layer of the Operating System. Application programs rely on BDOS system calls to support their requirements. Here the drives (A:, B:, through to maximally P:) are opened and closed, and disk sectors are written. The BDOS does its work by calling BIOS commands on behalf of the application that is currently loaded.
Often the BDOS is combined with the CCP (Console Command Processor) into one assembly language file because both of these components are constant and they are independent of the hardware. These two components are essentially the distribution of Digital Research CP/M which was sold to the user.
The CCP is the user interface for CP/M. It provides a very small number of integrated commands, like “directory list”, “erase”, “rename”, “type” or “exit”, but its main role is to load additional commands or applications called “Transient Programs” into RAM and execute them. Often, an application loaded into the Transient Program Area (TPA) RAM will overwrite the CCP in memory as it is normal for the CCP (and BDOS) to be reloaded once an application quits.
There are third-party alternatives available for both the CCP and BDOS, and as these are loaded each time the computer is restarted it is possible to replace the default versions by alternatives if desired. Specifically for CP/M-IDE, the DRI CCP can be replaced by Microshell SH (here), or both CCP and BDOS can be replaced by NZCOM without impacting the installed system.
CP/M was developed before there was a standard implemented for computer disk drives, and every system had its own peculiarities. In order to cope with this situation each BIOS had to be written to cover the possibilities, by completing a Disk Parameter Block. Each disk type needs its own DPB, which takes space in BIOS RAM, so it made sense for CP/M-IDE to be implemented with only one type of disk supported. Additionally each drive attached by the BIOS requires a substantial Allocation Vector RAM reservation. It needs to be said that providing for unused drives in CP/M substantially increases the BIOS size, and commensurately reduces the TPA RAM for user applications and in turn their working RAM. For comparison, CP/M-IDE has 3kB more TPA RAM available for user applications than the default RC2014 CP/M implementation.
A subtle but important advantage to using only one disk type is that every disk is orthogonal, and it can be located anywhere on the underlying physical disk (ie. starting at any LBA). Also, it does not matter into which CP/M drive A:, B:, C:, or D: a disk is mounted when booting. The CP/M “system disk” looks exactly like any other disk, and every CP/M disk file can be located anywhere on the FATFS parent drive.
Further, the CP/M-IDE CCP/BDOS/BIOS operating system binaries are loaded from ROM. This is not typical, as most CP/M BIOS implementations will load the CCP/BDOS/BIOS from the first sectors (or tracks) of the first attached physical drive, and will require the system disk to be located in specific sectors of the physical drive, and they also rely on a specific allocation of LBA addressed sectors (or slices) for all additional drives.
The CP/M-IDE system supports a maximum of 4 active drives of nominally 8 MByte each. The maximum possible size of a CP/M disk is 8 MByte, due to overflow of a 16-bit calculation within the BDOS. Further each CP/M disk can support up to 2048 files as a maximum. By setting the standard CP/M-IDE disk type to be maximised both in terms of size and number of supported files there is no question of the disk storage being too small. The only limitation introduced is that up to a maximum of 4 CP/M drives can be active at any one time, which leaves us with the maximum free TPA RAM. The choice of 4 drives for CP/M-IDE was based on nominally having 1 drive for CP/M system utilities, 1 drive for application files, 1 drive for user data or source files, and 1 drive for temporary files. In practice I’ve found that working with 2 or 3 drives is the most common scenario, and often it makes sense to copy the few needed system utilities onto a working drive and work off that one drive.
CP/M-IDE is like having a 4 “floppy” drive machine (with 8MB floppy disks), and a library of up to thousands of floppy disks to choose from. Just insert the floppy disks you want to use when you want to use them. This interchangeable disk strategy is different to other RC2014 CP/M implementations that put everything into a maximum of 16 “hard” drives, at fixed LBA locations or slices, and leave them attached permanently.
As CP/M-IDE uses LBA addressing there can be as many CP/M disks stored on the IDE FAT32 (or FAT16) formatted disk as desired, and CP/M-IDE can be started with any 4 of them in any drive. Note that CP/M does not know about or care about the FAT file system. On launch CP/M-IDE is provided with an initialisation LBA for each of its 4 drives by the shell, and all future sector references to the disk (file) are calculated from these initial LBAs provided for each drive.
As the FAT32 format supports over 65,000 files in the root directory, and a similar number of files in each sub-directory, collections of hundreds or even thousands of CP/M disk files can be stored in any number of sub-directories on the FAT32 parent disk. Knock yourself out by storing every conceivable CP/M application on thousands of disks on a single 120 GByte drive. As the CP/M Operating System doesn’t store state (the CCP/BDOS is reloaded each time an application terminates), changing or reordering drives is as simple as typing exit, and then restarting with the new drives desired using following shell command: cpm filefor.A filefor.B filefor.C filefor.D.
As we can store literally thousands of CP/M disks on one FAT32 parent disk, let’s think about how to create CP/M disks, and how to store information on them. There are two main methods for building CP/M disks, being from within CP/M using native tools such as the yash shell, and alternatively from a Linux or Windows PC host with the physical FAT32 disk temporarily attached to the host. For creating and building many CP/M disks the second host based method may be faster and more convenient.
Building CP/M disks from a PC host relies on the use of the CP/M Tools software utilities package. cpmtools utilities can be used to copy executable CP/M files from your host PC, where you have downloaded them, into the CP/M disk found on your FAT32 disk.
As CP/M-IDE uses a “non-retro-standard” disk definition, cpmtools lacks the required definition in the standard distribution. The disk definition for 8MByte CP/M-IDE disks is provided below. In Linux based systems this disk definition should be appended to the host’s /etc/cpmtools/diskdefs file.
On Windows PCs, as of cpmtools 2.20, creation of a new disk does not fully extend the CP/M disk out to the full 8388608 Bytes of a fully sized CP/M disk. This means that as files are added to the CP/M disk it is possible that the host PC operating system may potentially fragment the disk as it grows it. This would be bad, as offsets are calculated from the initial file LBA and therefor the CP/M-IDE system has no way to recognise fragmented CP/M disks. Therefore, for safety, a template CP/M disk file has been provided which can be stored onto the parent disk and then copied and renamed as often as desired.
Typical usage to check the status of a CP/M disk a.cpm, list the contents, and then copy a file (e.g. bbcbasic.com) from the host to the CP/M disk, is shown below.
Building a CP/M System disk is a personal choice. There are multiple utilities and applications available, and not all of them will be relevant to your own needs. However, to get started, the contents of the RunCPM system disk can be used. An extended version can be found here.
Also, the NGS Microshell can be very useful, so it has been added to the example system disk too. There is no need to replace the default DRI CCP with Microshell. In fact, replacing it permanently would remove the special EXIT function, added to the CP/M-IDE version of the DRI CCP, used to return to the shell.
Of these applications above, the Hi-Tech C v3.09 suite continues to be updated and maintained by Tony Nicholson. Therefore it is useful to update the HITECHC.CPM.zip CP/M disk with the current release files.
When commencing a new project it can be convenient to start with a new clean working drive. Either the yash shell can be used from within CP/M to create a new drive file. The yash shell will properly extend the created file to ensure that it is contiguous on creation. Or the system drive can be temporarily attached to a PC and normal file management can be used to copy the template drive file provided, and rename the newly created drive file appropriately for the project.
Alternatively when working with a CP/M compiler, or editor, making a copy of the compiler drive file and working from that copy (rather than the original) can be quite useful.
On first boot into CP/M, mount the sys.cpm system drive and the new working drive. It can then be useful to copy some CP/M commands onto the working drive using PIP.COM, then the sys.cpm system drive does not need to be mounted on further boots. Generally XMODEM.COM is all that is necessary, as the CP/M CCP has DIR, REN, ERA, TYPE, and EXIT commands built in.
Then, on each subsequent boot-up of CP/M only the working drive in drive A: is necessary. After compiling a new project with z88dk, the work-in-progress application .COMor .bin can be uploaded to the RC2014 using XMODEM.COM and then tested. If the work-in-progress crashes CP/M or needs further work, then repeat the process as needed without danger of trashing files in any other drives.
Of course other development workflows are possible, as is simply mounting the ZORK games drive and playing an adventure game or two.
Building CP/M Software from Source
CP/M-IDE is quite unusual in that it is built with a unix like shell as the system loader. From the shell the CP/M system is started, but it is also possible to use the shell to read the FAT file system and provide directory listings, to print memory and disk sector contents, and to provide status for the attached drive. Other versions of CP/M for Z180 have file system write capability included, but due to the limited capacity (32kB) of the RC2014 ROM these additional file management functions had to be omitted from the CP/M-IDE ROM, though they are available from the yash shell application.
The chicken or the egg? In this case the z88dk is both the starting point CP/M-IDE and the finishing point for developing CP/M-IDE applications.
By default the z88dk ACIA drivers are set up to use a 15 Byte transmit buffer. This needs to be changed to a 31 Byte transmit buffer, by changing this configuration to 0x20.
Also, if you wish to enable the shadow RAM setting where the Memory Module or SC108 Module is used then this setting needs to be changed to 0x01. This will enable the RAM copy stub and shadow RAM write and read functions. This is not relevant for the 8085 CPU build (which doesn’t support relocatable jump instructions), and is disabled by default for the Z80 builds (to support the 64k RAM Module).
And finally, the ide driver is selected by using either CF (8-bit) or PPIDE (16-bit) interfaces. To use the PPIDE interface the CF Module configuration needs to be set to 0x00.
With these settings adjusted to suit the targeted hardware, the RC2014 libraries need to be rebuilt. The sure way to do this is by a full rebuild of z88dk, as both 8085 and Z80 libraries will be touched. it is done with the ./build.sh -c command from the root directory of z88dk. There are other alternatives, such as deleting the libraries that will have to be changed and executing the ./build.sh command.
As well as two compilers, a macro assembler, and a large variety of useful tools, the z88dk is in essence a library of Z80 assembly language code covering all of the standard C requirements, and providing multiple options for implementing these libraries.
However, the z88dk doesn’t have C code libraries included. These are excluded because they can take too long to compile, and z88dk already takes quite a while to build as is. However the use of external libraries, and mainly C libraries is supported through the use of the z88dk-lib tool, which can import a compiled library and allow the linker to find it when a final binary application is being prepared.
For CP/M-IDE we need to have a high quality, reliable, fully functional FAT file system implementation. The most commonly used implementation is the ChaN FatFS. This code has been modified to work effectively with the Z80, and is provided in my z88dk-libraries.
For CP/M-IDE I have elected to use the SDCC compiler with the IY version of the libraries. For the CP/M-IDE 8085 the only option is to use the SCCZ80 compiler as it supports 8085 (and 8080) compilation.
As noted above, there is insufficient ROM available in the 32kB to support the full set of FAT file system functions, so we have to build a special version that is “read only”. There is a configuration that should be set to 1 to enable RC2014 read only in the file here. Then the library can be rebuilt with the following command lines.
The FAT file system libraries are now available for z88dk so we can move on to compiling CP/M-IDE
The source code available in the RC2014 Github repository for CP/M-IDE is kept up to date. There are four versions, each tuned to suit their minimum hardware characteristics. There is no “auto identification” of additional hardware. This implementation of the CP/M operating system supports only IDE attached FAT formatted disks and 1 or 2 serial ports, so that is all that is necessary. Any optional additional hardware available is supported by drivers built into the relevant application.
From the source directory of each version the command line identified here can be issued. The resulting .ihx file (renamed as .hex) can be compared with the provided HEX file. For interest it is worth compiling with the --list option, and studying the resultant assembly listings. This gives a good overview of the quality of code produced by the two compilers, and also the amount of space required to assemble the CP/M CCP/BDOS and BIOS components.
Now we have a functioning CP/M-IDE Intel HEX file, which can be written to EEPROM and tested.
New applications can be built using either the zcc +rc2014 -subtype=cpm or zcc +cpm for Z80 targets, or for the CP/M-IDE 8085 use zcc +cpm -clib=8085 to build applications. There are example applications to test with in the z88dk examples directory including, for example, players for 8-bit sound.
Of particular interest is the yash shell, which runs on CP/M and allows full access to the underlying FAT File System. It provides all of the standard file management tools which are missing (due to space constraints) from the CP/M-IDE ROM shell. This can be found in the z88dk-ext/os-related/CPM directory, together with the instructions to compile it. It is also provided in the CP/M-IDE “system disk”.
How does it work?
This is a description of CP/M-IDE 8085 specifically. The versions for the Z80 are quite similar, and so this can also be used as a reference for their operation. However as the RC2014 8085 support is unique in z88dk it is worth noting the specifics here.
The CP/M-IDE 8085 build is based on the rc2014 target and acia85 subtype within z88dk. The 8085 CPU starts execution at address 0x0000 from /RESET, therefore the target must write an effective Page 0 including a jump to the start of code, and interrupt and trap vectors, before the main() program for the CP/M-IDE shell can be started. z88dk uses the m4 macro preprocessor tool to expand included assembly code, and the configuration files for the acia85 subtype are found in config_8085.m4.
The overall initialisation process for the acia85 subtype is found in CRT 2 startup code for the RC2014. Each target in z88dk has multiple subtypes, and each of these subtypes has its own CRT startup code specification. These startup specifications are fully expanded and can be read most efficiently by using the --list option when compiling the system.
Before diving into the startup process it is worth considering how and where drivers for the rc2014 acia85 build are obtained. As the acia85 subtype is hybrid across newlib and classic libraries within z88dk it is worth noting that most of the drivers for acia85 are obtained from the device and driver directories within the rc2014 target. However, stdio drivers for acia85 and basic85 subtypes are found in the classic library in the rc2014/stdio directory.
Further, using the characteristics of linker preferences, if we chose to override the library drivers with our own versions found within the CP/M-IDE BIOS then the library versions will be ignored. And that is the case, where we provide the ACIA, 82C55, and IDE drivers. This also means that before the main() function is started we need to copy these drivers to their correct location in RAM. This process is done by placing code in the code_crt_init section, as this code will be loaded and run prior to main() according to the memory model allocation.
Now we have our interrupt vectors completed, and the interrupt code placed with buffers initialised and ready to go. Our diskio and IDE drivers have been placed and now we can start our main shell user interface. Now we are parsing the command line using a shell system inspired by the example code by Stephen Brennan. Each of the commands implemented are self explanatory, and are mainly invoking one of the ChaN FAT file system functions. However the cpm command requires further description as this is the transition point from z88dk into DRI CP/M.
The cpm function is called with up to 4 arbitrary file names, representing the 4 CP/M disks. These file names are tested and, if all the files provided are found to exist, the base LBA of each file will be written to a specific location in cpm_dsk0_base, and processing will be handed over to the cpm_boot() function.
The _cpm_boot function is the CP/M cold boot mechanism. The CP/M cold boot will firstly toggle-out the lower 32kB of ROM to reveal a “clean” 32kB of RAM. At this point the 8085 interrupt and trap vector addresses must be written into Page 0 RAM, together with other important CP/M locations such as the I/O byte. Then control is passed to the rboot function to continue with the cold boot.
In the cboot process we should remember that the contents of the CCP/BDOS and the BIOS RAM have already been written to upper 32kB of RAM by the preamble code, so this process does not need to be repeated. This is different in the warm boot wboot process where we have to assume that the CP/M application or transient program will have overwritten the CCP and possibly also the BDOS, so we have to repeat the initialisation found in the preamble called by pboot.
As part of the cboot and wboot process, we check which CP/M disk is going to be used for our A: drive, by reading the LBA base, and then launching CP/M CCP shell by returning to the to the preamble code and falling through to _main.
This covers creation of software support for the 8085 CPU within the framework of the z88dk and also with MS BASIC 4.7. Specifically, the 8085 undocumented instructions will be covered, and some usage possibilities provided.
Future work is to build a re-entrant IEEE floating point library specifically using the stack relative instructions found in the 8085 undocumented instructions.
8085 Microsoft BASIC 4.7
The Microsoft BASIC 4.7 source code is available from the NASCOM machine. Although the NASCOM machine was a Z80 machine there were only minor changes to the original Microsoft BASIC 8080 code. Therefore it is an ideal source to use to build a 8085 based system.
Also a rc2014 target ROM subtype acia85 has been provided to allow on-the-metal embedded applications to be written. The full 32kB of ROM and 32kB RAM is then available, with the option to toggle out the ROM if needed for CP/M or similar systems.
The z88dk sccz80 C compiler is used for 8080, 8085 and Gameboy Z80 CPUs. This compiler is supported by the z88dk classic library. Over a few weeks, I reworked all of the sccz80 compiler support primitives (called l_ functions) to make them reentrant, and to optimise them for the respective CPU.
I’ve also reworked all of the z88dk string functions to support callee for the 8085 CPU. The callee calling mechanism is substantially faster than the standard calling convention. Also I’ve changed the loop mechanism for 8080 / 8085 / GBZ80 to use a faster mechanism. This consumes 5 bytes more for each function used, but reduces the loop overhead from 24 cycles per iteration to 14 cycles per iteration. Quite a substantial saving for extensively used functions like memcpy() and memset(), for example.
8085 Undocumented Instructions
Over the years since launch several very useful undocumented instructions designed into the 8085 have been found. These instructions are particularly useful for building stack relative code, such as required for high level languages or reentrant functions. However, perhaps because of corporate politics, these useful instructions were never announced, and thus were never widely implemented.
The z88dk-z80asm assembler provides synthetic instructions to simplify code for the different variants (it has also recently become a macro assembler) to simplify programming. These instructions are usually a useful sequence of normal instructions that can be issued with no side effects (eg. setting flags) that may streamline combined 8085 / z80 programming.
Discussion on the Instructions
Some things to think about (and then do).
Use the Underflow Indicator (K or UI) flag with 16 bit decrement and JP K, JP NK instructions to manage loops, like LDIR emulation, more cleanly. 16 bit decrement overflow flag K is set on -1, not on 0, so pre-decrement loop counter.
Use the LD DE,SP+n instruction with LD HL,(DE) to grab from and LD (DE),HL to store parameters on the stack. Can use this with a math library to make it reentrant, for example, and also relieves pressure on the small number of registers.
Use the LD DE,SP+n instruction with LD SP,HL to quickly set up the stack frame. For example LD HL,SP+n, DEC H, LD SP,HL to establish 256-n stack frame.
Use RL DE together with EX DE,HL to rotate 32 bit fields.
Use RL DE together with ADD HL,HL to shift 32 bit fields.
Use RL DE as ADD DE,DE to offset into tables and structures.
Use SUB HL,BC for 16 bit subtraction.
Remember EX (SP),HL provides another “16-bit register”, if SP+2 is the location of the return, and SP+4 is the location of first variable.
Learn how signed arithmetic can be improved using the K flag.
Since we know that the 8085 undocumented opcodes are available in every 8085 device they can be relied upon for any 8085 system. The challenge will be to take existing 8080 programs, such as Microsoft Basic and CP/M, and implement improvements using these 8085 specific instructions.
In reworking the z88dk sccz80 l_ primitives to make them reentrant and to optimise them for the 8085 CPU, I have found the LD DE,SP+n instruction very important. Using this instruction it is possible to use the stack as effectively as static variable storage locations. The alternative available on the 8080 (and Z80) LD HL,N , ADD HL,SP takes 21 cycles, and clears the Carry flag. With the few registers available on the 8080 losing the Carry flag to provide state causes further cycle expense, spared with the 8085 alternative.
To load a single stack byte using LD DE,SP+n , LD A,(DE) is only 4 cycles slower than loading a static byte using LD A,(**). Also, loading a stack word using LD DE,SP+n , LD HL,(DE) is only 4 cycles slower than loading a static word using LD HL,(**). Given that variables can be used in-situ from the stack or pushed onto the stack from registers rather than requiring the overhead of the value being previously loaded into the static location, this small overhead translates into about 3 stack accesses for free compared to static variables.
One small design oversight in the Program Status Word of the 8085 is however quite annoying. The flags register contains a single bit that always reads as 0. A $FFFF pushed to AF is read back as $FF7F. This means that unlike in the Z80, it is not possible to use a POP AF , PUSH AF pair as a temporary stack store, which invalidates AF as one of the only 3 additional 16-bit registers as an option, making things even tighter when juggling the stack. I’d call it annoying AF.
The RL DE and SUB HL,BC instructions are very useful to build 16-bit multiply and divide routines effectively. They have contributed to useful optimisations of these primitives. The saving in bytes over equivalent 8080 implementations has allowed for partial loop unrolling, which also speeds up the routines by reducing loop overhead. Initially, I was concerned that the SUB HL,BC function didn’t include the Carry flag. But in hindsight it is not possible to effectively carry into the registers, and using the 8 bit SUB A,C , SBC A,B instructions via the A register is the way to manage long arithmetic.
Recently the LD DE,SP+n and LD HL,(DE) or LD A,(DE) instructions were used to replace the sccz80 z80 stack access routine LD HL,n, and ADD HL,SP followed by CALL l_gint or CALL l_gchar. Also the stack store routine CALL l_pint was replaced by LD (DE),HL. These small changes to the optimisation process have substantially improved the 8085 benchmarks, in both code size and performance, and they are now often better than similar z80 benchmarks.
The next challenge was to build a CP/M-IDE version for the 8085 CPU. The ingredients are ACIA serial drivers adapted for 8085, IDE and diskio drivers for 8085, and the ChaN FatFs library compiled for 8085, plus a 8085 adapted BIOS.
When looking at the IDE drivers written previously for Z80 it was obvious that I’d gone out of my way to use Z80 instructions, which were actually slower than using 8080 instructions. So, I took the opportunity to rewrite an integrated solution for both Z80 and 8080/8085, for future maintenance.
The new CP/M-IDE 8085 code is very similar to the existing ACIA and SIO serial Z80 code, by design. I’ve tried to minimise the differences where ever possible. The remaining differences are mainly in the BIOS code, and relate to initialisation of the 8085 interrupts and the different CRT code used between Z80 and 8085 systems.