Any Colour You Like

Targeted repairs for missing rows and columns on the Sharp EL-9900's LCD

Wed, 02 Sep 2026 13:09:08 +0100

Sharp don't seem to have the best reputation when it comes to graphing calculators however I do have a bit of a soft spot for them as they do have some interesting features. The EL-9300 lets you connect a printer and cassette interface to print out screenshots, program listings or formulae as well and save data to (and load data back from) tape cassette. The EL-9600 has a touch screen which does rather speed up menu navigation. The EL-9900 loses the touch screen but has a reversible keyboard with a "basic" side and an "advanced" side, which changes available menu options and defaults as well as the keyboard layout.

Unfortunately, the EL-9900 seems to suffer from the flex cable that connects the main PCB to the LCD coming unstuck, resulting in an increasing number of missing rows and columns as it ages. Fortunately, there is direct access to the flex cable on the EL-9900 calculator, which means it can be reattached by reheating it.

I have four EL-9900 calculators now and all had this issue. The first one I repaired by gingerly poking around with a soldering iron (set to around 250°C) until all the rows and columns came back. The next one I repaired in a video for YouTube and I dealt with that one by working my way along the whole flex cable from left to right until everything was working. Not exactly a scientific approach, but with so many missing columns I figured the cable needed some serious attention anyway and that calculator is still fully working 20 months later.

The first calculator I tried to repair didn't fare so well, unfortunately. After the initial success it started losing rows and columns again and so I'd try re-heating the flex cable. That would work for a week or so until yet another row or column disappeared. Eventually I had reheated the cable so many times it started to look very crusty and the repairs became less effective, until I ended up melting a hole straight through a section of it, destroying it completely.

I recently acquired another pair of EL-9900 calculators, both with only two or three missing rows and columns on them. I thought it would be a good opportunity to try a more targeted approach, as reheating the whole flex cable when there were only a small number of faults seems unnecessarily risky. There are two issues here: identifying which rows and columns are faulty, and then identifying where the corresponding point on the flex cable is to heat with the soldering iron. To this end, I developed this printable guide (LibreOffice Draw file) that has three rulers on it.

The first two rulers can be used to measure the column or row number of the missing pixels. You could just count these, but that can quickly get very tedious! The third ruler can then be used to find where to heat up the flex cable:

Note that the "Lower Rows" are – I think – incorrectly ordered in this photo.

The flex cable can be broken down into three areas. The large central area corresponds to the columns, though as we are working on the back of the LCD the column numbers are reversed (and so run from right to left, rather than left to right). The left hand side of the flex cable corresponds to the top half of the display and the right hand side corresponds to the bottom half. I worked this out by removing the LCD from the calculator I'd previously destroyed and holding it up to a bright light to see where the traces in the glass went. Fortunately for me but unfortunately for testing purposes the LCDs in the calculators I've repaired have only had faulty rows in the upper half of the display, which means that I initially got the order of the "lower rows" reversed – having sketched it out on some paper I think the middle row (32) will be connected on the outside of the flex cable and the bottom row (63) will be on the inside, nearest the "columns" section, as otherwise the traces would have to cross over each other. I have updated the PDF and ODG, but that explains the error in the above photo, and until I find a calculator with a fault in the lower half I won't be able to double check.

All the rows and columns are back, but sadly I can't do much about the LCD "bruise" below the C in CONTRST.

I was able to use the guides to successfully repair the two recently-acquired calculators by only heating the affected parts of the flex cable. I also used a lower temperature on the soldering iron than before (220°C) and that seemed to be enough to stick the cable back down – I'd only hold it against the flex cable for a short amount of time, lightly running it down the cable in the direction of the traces and then holding the flex against the PCB firmly with a finger as it cooled.

In case you found this post because you also have a faulty EL-9900 calculator and are looking for some repair tips, here's what springs to mind:

The calculator has five main screws on the back as well as one smaller one inside the battery compartment under the third cell from the left. You do not need to remove the screw on the memory battery backup door.
The case has four clips on the sides holding the two halves together. I find it easiest to unclip the first two from the top (the guide for the hard case widens at the top, giving you plenty of room to insert your fingers to pull, with the two clips being towards the bottom of the LCD). Squeezing the white front half of the calculator whilst continuing to pull will release the lower two clips. Do not fully separate the two halves yet, you just want to release the clips.
There are four very thin wires between the rear half of the case (containing the battery compartment) and the front half of the case (containing the main PCB). The two halves of the case can be opened like a book with the opening on the right hand side when looking at the front of the calculator.
As the battery compartment is connected with wires (rather than, say, spring contacts to the main PCB) the calculator can be operated when open. However, a switch on the main PCB (normally pressed by a stud on the battery compartment door) prevents this from happening – a piece of tape will hold this down and let you switch the calculator on.
The connections for the thin wires between the battery compartment and main PCB are extremely fragile, so if you keep opening and closing the calculator when working on it these will likely break and need to be resoldered. To avoid this, I recommend only opening the calculator up once, then using some tape to join the two halves of the calculator together at the "hinge" and using two pieces of cardboard and an elastic band to hold everything together as this will let you flip the calculator over between working on the flex cable and checking the LCD without stressing those thin wires. The keyboard should also be popped out to prevent the cardboard from holding down the keys (the fixed keys above the removable keyboard are more than sufficient to test the calculator when working on it).

Only poke the soldering iron near the part of the flex cable that's stuck to the board. The soldering iron will very easily melt a hole in the flex cable if you touch it in the unsupported gap between the PCB and the LCD glass.
Once you've repaired any known faulty rows or columns, test the calculator over a period of a few hours before closing it back up in case the fixes don't hold or any new faults appear after disturbing the flex cable. Keep a list of rows or columns you've repaired to see whether the issue is one you've repaired before or whether it really is a new fault.
When closing the calculator back up, it's much easier to do this without the keyboard installed due to the sprung pin that normally tries to push the keyboard out. I also find it easier to put the spring and pin in the back half of the calculator and to lower the front half on top of it (threading the pin through the small hole in the front) rather than balancing the pin with the spring on top of it in the front half and lowering the back half on top of that.

Here again is the link to the printable repair guide (LibreOffice Draw file), and maybe it'll help you if you have a faulty EL-9900. It's certainly helped me – good luck!

Various calculator-related updates: BBC BASIC, Vinegar, Telnet 83, Brass and Latenite

Sun, 14 Jun 2026 18:51:39 +0100

My original TI-83 Plus feels like it's on its last legs. I suspect there's some issue with the flash memory, and I've already had to wipe its certificate page using the BootExec utility that exploits a buffer overflow in the link routines to get an operating system back on it. Even though it's working for now, I'm somewhat wary of installing flash applications on it.

Recently, however, someone contacted me to let me know that there was a bug in the TI-83 Plus version of Richard Russell's BBC BASIC that I'd put together a few years ago. It turns out that on more recently-manufactured TI-84 Plus calculators uses a new LCD driver which modifies the data pointer when reading back the status register. The BBC BASIC host interface I'd put together polls the busy flag in this status register, and so the display was corrupting on these new calculators as writes to the LCD memory were not going to the correct address.

It was a reasonably easy fix (replacing my own LCD busy test with a call to the one provided by the calculator's operating system), but not one I could test myself as I don't own a TI-84 Plus. I also wanted to check that there weren't any regressions with the fix, but I didn't want to risk damaging my TI-83 Plus further by reinstalling the flash application on it.

I did find the above TI-83 Plus Silver Edition calculator on eBay, though, for a good price – and it's the ViewScreen model! This has a special socket on the back of the calculator that lets you plug in a large external LCD (it came with two of them) which is designed to be used on an overhead projector so a teacher can demonstrate using the calculator to their students. I'd previously experimented with a project that displays the calculator's screen on a TV, but that captures a screenshot over the calculator's link port so is slow, requires a button to be pressed to update the image and only works in situations where the OS is idly waiting for a keypress. The ViewScreen taps into a buffered copy of the signals sent to the calculator's LCD driver, so will automatically and immediately show a copy of what's on the calculator's own screen.

Now that I had a TI-83 Plus Silver Edition I installed BBC BASIC on it, saw that the LCD fix had worked and not broken anything else, but also encountered a few other bugs that I'd not noticed before which I've also fixed:

Pressing non-printable keys (e.g. cursor keys) in INKEY no longer slows CPU down to 6MHz until the app is restarted.
Pressing Clear in INPUT statements now clears the whole input line instead of inserting a CHR$27 into the line.
The On key only triggers escape when pressed. On the Silver Edition it was triggering when released as well.

These updates have been uploaded to the project page on this site, the GitHub page and ticalc.org.

Now that I had a shiny new calculator, I thought I'd try installing some other old programs on it to see how well they worked. One of these was Vinegar, a CHIP-8 and SCHIP 'emulator'/interpreter. I soon found that this also had an LCD bug on the TI-83 Plus Silver Edition, as enabling the "96x64 SCHIP mode" (which scales the 128×64 native resolution of SCHIP games down to the calculator's 96×64 display instead of cropping it) would erroneously switch the LCD driver into "6 bits per column" mode after a few seconds of play instead of the intended "8 bits per column" mode, corrupting the display.

How the options menu should appear (left) versus how it appears on the Silver Edition (right) due to a bug.

This project had some very old code and had never been checked into source control so I set it up on GitHub, combined the copy of the source code I had on my local machine with the source code that was publicly available for download and fixed the LCD bug. I also found and fixed a memory leak bug that occurred if no CHIP-8/SCHIP programs ("ROMs") were installed on the calculator and added a couple of keyboard shortcuts to control the display. These changes are available in release 1.2 on the main project page, the GitHub page and ticalc.org.

The next bug I spotted was in Telnet 83. I didn't originally write this particular program, but it is included as part of the TIWiFiModem project where I've already made some bug fixes and improvements. When trying to use it to set up my TIWiFiModem with my new wireless access point I discovered that I couldn't type in the password as some of the keys were not being mapped correctly. I'd previously corrected other key mapping bugs in this program but must have missed a couple, so these are now fixed. There isn't an official release for this project but the compiled .8xp is checked directly into the repository so can be downloaded from there.

I use my old Brass assembler to build the Telnet 83 project. Some other people do still use this from time to time and so I decided it would be best for the community if the source code was available, no matter how embarassingly poorly-written it was. To this end I set up a GitHub repository a few years ago, but as the code had never been checked into source control before then there was no accompanying history. I did have a few old backups and so imported them into the repository in date order, but as these backups were taken around 20 years ago with no notes as to what I was thinking at the time it's all a bit of a mess!

As this is not intended to be an actively-developed project I don't plan to make too many changes to it, but I have fixed a couple of bugs along the way. Notably, operator precedence is handled more correctly now (operators with the same precedence, such as * and /, are now evaluated from left to right whereas previously * had higher precedence than /). When working on Telnet 83 I also found that if data overlaps in the output binary the reported address range was incorrect and also poorly-formatted, and this has now been fixed too:

Brass Z80 Assembler 1.0.5.4 - Ben Ryves 2005-2023
-------------------------------------------------
Assembling...
Pass 1 complete. (310ms).
Pass 2 complete. (84ms).
Writing output file...
Warning: Data overlap between $14930-$14930. ← Now shows the correct value '$AB9D'
Errors: 0, Warnings: 1.
Done!

String literals were also handled very oddly, and I've slightly improved this and added extremely rudimentary expression parsing on string, so #include "page" + pagenum + ".asm" now works as you might expect. I've filled in some of the missing gaps in the documentation, too; updates can be downloaded from the Brass page on this site or the GitHub repository.

An even more ancient development tool that I put together was Latenite, an IDE designed to be used for Z80 development. I hadn't used this myself in years (preferring to use Visual Studio Code as an editor and the Brass 3 Project Builder to build the code and launch a debugger) but Vinegar was set up to use this (including a project file, build scripts and debug scripts) so I thought I'd give it a go. Unfortunately, it really didn't work – the files I had on my local development copy didn't match what was in the publicly released zip files, and neither worked with what Vinegar was expecting.

Again, I set up a GitHub repository for the project and tried to piece together a working code base using the files I had locally, the files that had been publicly released and what I could remember of what had gone on twenty years before.

The solution contained a series of projects for tools (an 8xp "linker", a TASM error processor and a WLA-DX error processor) that aren't included in later releases of the software. I suspect these are remnants of the project from before Brass became the bundled assembler. I have added the Brass repository as a submodule to the project so that it can be built alongside Latenite, and that will hopefully help keep things in sync.

A notable sticking point was a conflict in the PindurTI-based debugging system. There appear to be two different versions, with different debug scripts and executable names. The older "PTIDebugger" was a project in the Latenite solution I had locally, and is what the Vinegar project was looking for, however the bundled project template for TI-83 (Plus) development uses a new executable called "PindurTI Debugger" and set of debug scripts with incompatible file names and I had no record of its source code anywhere.

Fortunately, the old Latenite interface for this debugger is still present in the PindurTI is an emulator developed by the legendary Patai "cobb" Gergely, not that you'd know it from the lack of attribution in Latenite or my other development tools. Similarly, calculator shells were bundled directly for debugging purposes without mentioning their authors or including their documentation, just a raw binary. For the most part image resources used in the IDE were nicked directly from Windows XP or Visual Studio, too. This is all very naughty! Whilst I don't really intend to pick up development on Latenite again, beyond fixing some of the more obvious bugs, I would at least like to try to remedy this. I've already replaced the image resources with new icons and now provide links to the calculator shell documentation from within the IDE. There's still a way to go before I'm happy with this, though.

A comparison of the old icons (top) compared to the new icons (bottom).

I don't expect anyone to be still using this development tool, but in case there are old projects out there that were assembled using it then in the interest of making sure they can still be built in the future I think it's worth making sure the source code is available.

All of this relates to calculator programming and the place where I used to share all of this was the MaxCoderz forum. This has had very little traffic for the past few years, but if you were one of the few people looking for it you might have noticed that until very recently it was unavailable. This was due to bots very aggressively scraping the content, causing phpBB to insert millions of rows onto the session table on the database – this one site that had virtually zero legitimate traffic ended up slowing down the entire server to a crawl a few times per day, and though I did at first selectively block the bots it ended up being a very tedious game of Wack-a-Mole and so I ended up taking down the whole forum.

Nobody had complained about the site being down, but in the interest of keeping sites online for historical interest I have restored the site and it's now protected with CloudFlare. This is not something I'm too happy about doing, but I'd rather have a site accessible via CloudFlare than not accessible at all.

One thing I have noticed is that this site is very poorly-equipped for distributing information about updates, with so many projects being scattered across different (and poorly-maintained) sections of the site. I am currently working on overhauling this site and shifting it onto a new platform, but one of the key requirements is to not break any of the existing links or content so it'll take a bit more work to get it ready.

Calculating the approximate phase of the moon on a range of devices

Tue, 07 Apr 2026 15:34:53 +0100

Calculating the phase of the moon always struck me as a fun little program for a calculator, and with the current Artemis II mission it seemed like as good a time as any to look at a few example programs for this on a range of different calculators and pocket computers.

Sharp PC-1211

I copied the following program from the book 119 Practical Programs for the TRS-80 Pocket Computer and it forms the basis of most of the subsequent programs:

  100 "MOON"INPUT "DATE M?",M,"D?",D,"Y?",Y: GOSUB "DJ"
  110 M=(J+4.867)/29.53058:M=2*(M-INT M)-1:N=ABS M
  120 USING "##.##": PRINT "MOON LIT ABOUT ";N
  130 Z$="NEW": IF M>0 LET Z$="FULL"
  140 PRINT "HEADED FOR A ";Z$;" MOON.": END
  900 "DJ"J=INT (365.2422Y+30.44*(M-1)+D+1):N=M-2+12*(M<3)
  905 Z=Y-(M<3):E=INT (Z/100):Z=Z-100E
  910 W=INT (2.61N-.2)+D+Z+INT (Z/4)+INT (E/4)-2E
  915 W=W-7*INT (W/7):X=J-7*INT (J/7)
  920 J=J-X+W-7*(X<W)+1721061: RETURN

The program has two parts; the first is to convert a date from its year, month and day components into a Julian day number which it does via the subroutine DJ. It then calculates the phase of the moon by adding an offset (4.867 in this case) and dividing by 29.53058, the length of the synodic month (lunar cycle) in days. The fractional part of the result of this calculation corresponds to the phase of the moon, and by multiplying by two and subtracting one you can get a value roughly corresponding to how illuminated the moon is on a particular date and whether it's waxing (heading for a full moon) or waning (heading for a new moon).

Incidentally, the program listing printed in the book does have a bug: line 130 just checks IF M instead of IF M>0, and so the program will nearly always report a waxing moon (heading for a full moon). This is corrected in the version of the code shown above.

Sharp PC-1500

The next page of the book where I copied the PC-1211 listing from showed a graphical representation of the moon's phase which I thought would be fun to replicate, though as the PC-1211's printer doesn't support graphics it would be a very crude representation indeed. Fortunately, the PC-1500's plotter allows for graphical output, so I added an optional plotting routine to the above program as well as some other niceties like automatically populating the month and day fields with the value from the real-time clock:

   30 T=TIME :Y=2000:M=INT (T/1E4):T=T-M*1E4:D=INT (T/1E2)
   40 L=-50
   50 WAIT 0
   60 CLS : PRINT "Year (";STR$ Y;") ";: INPUT Y
   70 CLS : PRINT "Month (";STR$ M;") ";: INPUT M
   80 CLS : PRINT "Day (";STR$ D;") ";: INPUT D
   90 CLS : WAIT 
  110 J=INT (365.2422*Y+30.44*(M-1)+D+1)
  120 N=M-2+12*(M<3)
  130 Z=Y-(M<3)
  140 E=INT (Z/100)
  150 Z=Z-100*E
  160 W=INT (2.61*N-.2)+D+Z+INT (Z/4)+INT (E/4)-2*E
  170 W=W-7*INT (W/7)
  180 X=J-7*INT (J/7)
  190 J=J-X+W-7*(X<W)+1721061
  210 P=(J+4.867)/29.53058
  220 P=2*(P-INT P)-1
  230 N=ABS P
  240 Q=INT (N*100+.5)
  250 CLS : PRINT "Moon lit about";Q;"%"
  260 Z$="full": IF P<0 LET Z$="new"
  270 CLS : PRINT "Headed for a ";Z$;" moon."
  290 IF PEEK &A000<>&C0 END
  300 WAIT 0:P$="Y": PRINT "Print output (Y/N) ";: INPUT P$
  310 IF P$<>"Y" END
  320 "MPRINT" CLS : PRINT "Latitude (";STR$ L;") ";: INPUT L
  330 IF L<-90 LET L=-90
  340 IF L>90 LET L=90
  360 CLS : PRINT "Printing...": WAIT 
  380 M$=STR$ M: IF M<10 LET M$="0"+M$
  390 D$=STR$ D: IF D<10 LET D$="0"+D$
  400 TEXT : CSIZE 3: LPRINT STR$ Y;"-";M$;"-";D$
  410 GRAPH : GLCURSOR (216/2,-216/2+15): SORGN :R=108: DEGREE 
  420 C=9: FOR A=0 TO 360 STEP 6
  430 LINE -(R*SIN (A),R*COS (A)),C
  440 C=0: NEXT A
  450 V=N*2:C0=9:C1=0
  460 IF P>=0 LET V=2-V:C0=0:C1=9
  470 FOR S=1 TO 2:C=9
  480 FOR I=-R TO R STEP 8
  490 XO=I*COS (-L):YO=I*SIN (-L)
  500 W=√(R*R-I*I)
  510 XN=W*SIN (L):YN=W*COS (L)
  520 X=XO-XN+V*XN:Y=YO-YN+V*YN
  530 IF S=1 LINE -(X,Y),C:C=0
  540 IF S=2 GLCURSOR (XO-XN,YO-YN): LINE -(X,Y),C0: LINE -(XO+XN,YO+YN),C1
  550 NEXT I: NEXT S
  560 GLCURSOR (-216/2,-216/2-25): SORGN 
  710 TEXT : CSIZE 2: LPRINT "Moon is lit about"
  720 LPRINT STR$ Q;"% and headed"
  730 LPRINT "for a ";Z$;" moon."
  740 LF 3: END

The program also prompts for latitude to rotate the drawing appropriately – the moon appears to fill with light from the right to the left in the Northern hemisphere, from top to bottom at the equator and from the left to the right in the Southern hemisphere.

HP-12C

This calculator is really designed for financial applications but it is keystroke programmable and so a phase of moon calculation program would be a good learning project. Fortunately it can already calculate the number of days difference between two dates, so that would save having to write a program to calculate the Julian day number.

Step	Key	Display	Comment
01	ENTER	36	Enter the current on-screen value onto the stack.
02	1	1	Enter "1.012" (1st January 2000).
03	.	48
04	0	0
05	1	1
06	2	2
07	g ΔDYS	43 26	Calculate number of days between 1st January 2000 and the submitted date.
08	CHS	16	Change sign to get the number of days after 1st January 2000.
09	2	2	Enter "20.195" (offset to 21st January 2000, 04:41).
10	0	0
11	.	48
12	1	1
13	9	9
14	5	5
15	-	30	Subtract to get the number of days since the full moon.
16	2	2	Enter "29.53059" (synodic month, lunar cycle duration in days).
17	9	9
18	.	48
19	5	5
20	3	3
21	0	0
22	5	5
23	9	9
24	÷	10	Divide to get lunar phase.
25	g FRAC	43 24	Extract the fractional part.
26	1	1	Add 1.
27	+	40	Add 1.
28	g FRAC	43 24	Extract fractional part again (corrects negative values).
29	2	2	Multiply by 2 (value in range 0 to 2).
30	×	20	Multiply by 2 (value in range 0 to 2).
31	1	1	Subtract one (value in range -1 to +1).
32	-	30	Subtract one (value in range -1 to +1).
33	ENTER	36	Enter result onto the stack (Y).
34	1	1	Enter 1 into X.
35	x⇔y	34	Swap so X=result, Y=1.
36	%T	23	Express X (result) as a percentage of Y (1).
37	g GTO 00	43,33 00	End program.

Dates on the HP-12C are represented as decimal values, either MM.DDYYYY or DD.MMYYYY depending on the current calculator mode. To keep things simple, rather than calculate the correct Julian day number the number of days since the first of January 2000 is used as the reference as this can be represented as 1.012 in either mode.

This change of date meant that the offset from the Julian day number (previously 4.867) could no longer be used. As the range of moon phases (0 to 1) are mapped to being from full to full (-100% to +100%) the 0 reference value also needs to be a full moon. I found a list of moon phases for the year 2000 which put a full moon at 04:41 on 21st January, so the offset was set to 20.195 – 20 days after the 1st January is the 21st, and 04:41 is (4+(41/60))/24=0.195 hours into the day.

One other very minor change from previous programs is the use of 29.53059 as this is a closer approximation than 29.53058, but in the grand scheme of things it doesn't make much difference to the accuracy. The program can be run by typing in the desired date (e.g. 7.042026) and pressing the R/S key.

Casio fx-3800P

This is another keystroke programmable calculator, though life is made a little more difficult for us compared to the HP-12C as it doesn't have a built-in function to compute the number of days between two dates. One complication with adapting date computation algorithms to scientific calculators is that they often lack functions to truncate values to integers, and even if they do have a way to round a number (e.g. by switching to a mode that only shows a certain number of fixed decimal places and using a "modify" key to convert the displayed number to the stored one) they sometimes don't allow mode switches mid-program.

Fortunately, the Casio fx-3800P will store mode changes in its programs. Even better, you can switch between different numerical bases and the value will be truncated (not rounded) without raising an error which is the behaviour we want when handling date calculations, and when in this BASE-n mode calculations are carried out using integer division and multiplication which suits the algorithm perfectly.

The program is split into two parts: PROG I converts a date (stored in constant registers K1=year, K2=month, K3=day) into the Julian day number and stores the result in the memory register M. The second part, PROG II, converts the Julian day number stored in M into the approximate phase of the moon.

PROG I is adapted from Julian Day Numbers by Bill Jefferys, and is as follows:

Keys	Comment
1 Kin - 1	Subtract 1 from year.
12 Kin + 2	Add 12 to month.
15 - Kout 2 =	Check if month is in valid range.
x>0	If not, loop back to start.
1 Kin + 1	Add 1 back to year.
12 Kin - 2	Subtract 12 back from month.
Kout 1 + 4716 = × 365.25 =	Base of Julian day number based on current year.
MODE 1 DEC MODE 0 Min	Truncate to an integer and store in M.
Kout 2 + 1 = × 30.6001 =	Offset Julian day number by value from month number.
MODE 1 M+	Truncate to an integer and add to M.
Kout 1 ÷ 100 = M-	Account for centuries not being leap years.
Kout 1 ÷ 400 = M+	Account for special case century leap years.
Kout 3 M+	Offset Julian day number by the day of the month.
Kout 2 ÷ 13 = Kin + 1	Restore original year if we shifted it back.
Kout 2 ÷ 13 × 12 = Kin - 2	Restore original month if we shifted it forward.
MODE 0	Switch back to COMP for floating point.
MR - 1522.5 = Min	Subtract offset to get Julian day number.

PROG II is somewhat simpler, and follows the same sort of logic as previous programs:

Keys	Comment
MR + 5.867 = ÷ 29.53059 =	Add Julian day offset and divide by synodic month.
Kin 4	Store phase in K4.
MODE 1 + 0 = MODE 0	Truncate phase to an integer.
Kin - 4	Subtract from K4 to get fractional part of phase.
200 × Kout 4 - 100 =	Convert to range -100 to +100.

As mentioned above the programs make fairly heavy use of mode switching to truncate values to integers. Program flow control is very limited on these programmable scientific calculators, usually only permitting a jump back to the start of the program based on a certain condition – hence the slightly clumsy month/year adjustment at the start and end of PROG I.

The Julian day number calculation returns a value that is 0.5 smaller than the value returned by the PC-1211 program that was the basis for most of the other programs (e.g. for 7th April 2026 the Bill Jefferys algorithm returns the correct 2461137.5, the algorithm in the PC-1211 program returns 2461138). To compensate for this the offset used to calculate the current phase of the moon is made 1 larger; not 0.5, as through some experimentation a value of 1 produced results that more closely matched a lunar phase calculator I found elsewhere.

That said, none of the programs above line up particularly well with any other lunar phase calendar, and if you search through days to find when the new moon, full moon and quarters are based on the values closest to 0%, 50% and 100% you'll often find yourself a day off to one side or the other. A more accurate program would be useful, which brings me to the final and most sophisticated program.

Sharp PC-1251

When leafing through old issues of La revue des Sharpentiers, a French publication about all things Sharp from the 1980s, I found an interesting program for the PC-1261:

    1 "A": PRINT =LPRINT : GOTO 5
    2 "Z": PRINT =PRINT : GOTO 5
    3 REM PHASES DE LA LUNE*J.HERY D APRES J.MEEUS* EDI.20/11/85
    5 CLEAR : WAIT 100: DEGREE :U=0: DIM M$(12)*9,L$(7)*2: RESTORE 
    7 FOR I=1 TO 12: READ M$(I): NEXT I
   10 FOR I=1 TO 7: READ L$(I): NEXT I
   20 PRINT "**PHASES DE LA LUNE**"
   25 INPUT "ANNEE ? ";Y: INPUT "NO MOIS OU AN ? ";S$:Z=Y
   30 G=1: IF Y<1583 LET G=0
   35 USING "#####": PRINT "AN:";Y: IF S$<>"AN"PRINT "MOIS: ";M$(VAL S$)
   40 PRINT " PH.   DATE    TU.(H.M)": PRINT ":--:----------:--------:": WAIT 
   45 K=INT ((Y-1900)*12.3685)
   50 T=(Y-1899.5)/100
   60 I=2415020+29K
   65 L=.0001178TT-.000000155TTT
   70 L=L+.75933+.53058868K
   75 L=L+.00033*SIN (166.56+132.87T-.009173TT)
   80 L=L-.000837T-.000335TT
   85 N=.08084821133K
   90 N=360*(N-INT N)+359.2242
   95 N=N-.0000333TT
  100 N=N-.00000347TTT
  105 O=.07171366128K
  110 O=360*(O-INT O)+306.0253
  115 O=O+.0107306TT
  120 O=O+.00001236TTT
  125 V=.08519585128K
  130 V=360*(V-INT V)+21.2964
  135 V=V-.0016528TT-.00000239TTT
  140 K=4*(VAL S$-1): IF S$="AN"LET K=0
  145 FOR K=K TO 53
  150 J=I+7K:F=L+.38264717K
  160 P=N+K/4*29.10535608
  165 Q=O+K/4*385.81691806
  170 W=V+K/4*390.67050646
  180 IF U=0 OR U=1 GOSUB 300
  185 IF U=.5 OR U=1.5 GOSUB 340
  190 F=F+.5/1440
  195 J=J+INT F:F=F-INT F
  197 R=J+F+1.5:R=R-7*INT (R/7)+1
  200 GOSUB 400
  205 IF Y<Z GOTO 260
  210 IF S$="AN" OR M=VAL S$ GOTO 220
  215 GOTO 255
  220 IF U=0 PRINT "":P$=" NL"
  230 IF U=.5 LET P$=" PQ"
  235 IF U=1 LET P$=" PL"
  240 IF U=1.5 LET P$=" DQ"
  245 PRINT P$;"  ";L$(R);USING "###";D;M;USING "#####.##";DMS H
  255 IF M>VAL S$ AND S$<>"AN"GOTO 270
  260 U=U+.5: IF U=2 LET U=0
  265 NEXT K
  270 PRINT "": END 
  300 F=F-.4068*SIN Q
  305 F=F+(.1734-.000393T)*SIN P
  310 F=F+.0161*SIN (2Q)-.0004*SIN (3Q)
  315 F=F+.0104*SIN (2W)+.0004*SIN (2W+P)
  320 F=F-.0074*SIN (P-Q)-.0004*SIN (2W-P)
  325 F=F-.0051*SIN (P+Q)-.0006*SIN (2W+Q)
  330 F=F+.0021*SIN (2P)+.0005*SIN (P+2Q)
  335 F=F+.0010*SIN (2W-Q): RETURN 
  340 F=F+(.1721-.0004T)*SIN P+.0021*SIN (2P)
  345 F=F-.6280*SIN Q+.0089*SIN (2Q)
  350 F=F-.0004*SIN (3Q)+.0079*SIN (2W)
  355 F=F-.0119*SIN (P+Q)-.0047*SIN (P-Q)
  360 F=F+.0003*SIN (2W+P)-.0004*SIN (2W-P)
  365 F=F-.0006*SIN (2W+Q)+.0021*SIN (2W-Q)
  370 F=F+.0003*SIN (P+2Q)+.0004*SIN (P-2Q)-.0003*SIN (2P+Q)
  380 F=F+SGN (1-U)*(.0028-.0004*COS P+.0003*COS Q)
  385 RETURN 
  400 F=F+.5
  405 IF F<1 GOTO 415
  410 F=F-1:J=J+1
  415 IF G=1 GOTO 425
  420 A=J: GOTO 435
  425 B=INT ((J/36524.25)-51.12264)
  430 A=J+1+B-INT (B/4)
  435 B=A+1524
  440 C=INT ((B/365.25)-.3343)
  445 D=INT (365.25C)
  450 E=INT ((B-D)/30.61)
  455 D=B-D-INT (30.61E)+F
  460 M=E-1:Y=C-4716
  465 IF E>13.5 LET M=M-12
  470 IF M<2.5 LET Y=Y+1
  475 H=24*(D-INT D):D=INT D
  480 RETURN 
  500 DATA "JANVIER","FEVRIER","MARS","AVRIL"
  510 DATA "MAI","JUIN","JUILIET","AOUT"
  520 DATA "SEPTEMBRE","OCTOBRE","NOVEMBRE","DECEMBRE"
  530 DATA "DI","LU","MA","ME","JE","VE","SA"

Another optimisation is related to the PC-1251's lack of support for long variable names; it supports implicit multiplication in certain situations, for example 2*A can be written as 2A. Whereas the original program used T2 and T3 to store the values of T² and T³ respectively, I could instead use TT and TTT in their place and save having to use up more previous variable names. I could also replace instances of Q+Q+Q with 3Q or W+W with 2W. After making these changes the program was a few bytes smaller and had enough spare single-character variable names free to use for the remaining two-character names; the end result is somewhat harder to read, but it does run on the PC-1251 and matches the output of the PC-1261 original.

Sharp PC-1245

A very similar computer to the Sharp PC-1251 is the PC-1245. This can drive the same 24-column printer, however its display is only 16 characters wide. A bigger problem, however, is the amount of available RAM: the PC-1245 only has 1486 bytes free for a program and dynamically-named variables, and the PC-1251 program is 2112 bytes in length. Slimming the program down to fit was a considerable challenge, but here are some of the changes that were made:

Dynamically-allocated variables were removed; a month number is shown instead of a name, and weekday names come from indexing into a string instead of storing them in an array.
Where possible, multiple lines of code were condensed into single lines of code separated by colons.
Constant variables with long sequences of zeroes at the start were replaced with scientific notation where it saved space (e.g. .000000155 to 155𝐄-9).
The user-supplied month number is stored in a numeric variable S with a value of 0 to print a year instead of a string with a value of "AN" – this saves a lot of comparisons and use of VAL to convert back to a number where required.
Parentheses around function arguments were removed where not required.
Conditions were simplified or removed if possible, for example G=1: IF Y<1583 LET G=0 becomes G=Y>1582.
Decorative text and comments were condensed or removed entirely.
Support for outputting to the screen was removed; information would be cut off due to the narrower screen, so making it printer-only felt like an acceptable loss.

The resulting code is much harder to read, but the resulting program is not too much of a compromise from the original in my opinion. It comes to exactly 1486 bytes, which means it completely fills the computer's memory.

   25 "A"CLEAR : INPUT "ANNEE?";Y: INPUT "MOIS?";S
   35 Z=Y:G=Y>1582: USING "#####": LPRINT "AN:",Y: IF S LPRINT "MOIS:",S
   40 LPRINT " PH.   DATE    TU.(H.M)": LPRINT ":--:----------:--------:"
   45 K=INT ((Y-1900)*12.3685):T=(Y-1899.5)/100:I=2415020+29K
   65 L=1178€-7TT-155€-9TTT+.75933+.53058868K
   75 L=L+33€-5*SIN (166.56+132.87T-.009173TT)-837€-6T-335€-6TT
   85 N=.08084821133K:N=360*(N-INT N)+359.2242-333€-7TT-347€-8TTT
  105 O=.07171366128K:O=360*(O-INT O)+306.0253+.0107306TT+1236€-8TTT
  125 V=.08519585128K:V=360*(V-INT V)+21.2964-.0016528TT-239€-8TTT
  145 FOR K=(4S-4)*(S>0) TO 53:J=I+7K
  150 F=L+.38264717K:P=N+K/4*29.10535608:Q=O+K/4*385.81691806:W=V+K/4*390.67050646
  180 IF U=INT U GOSUB 300
  185 IF U<>INT U GOSUB 340
  190 F=F+.5/1440:J=J+INT F:F=F-INT F:R=J+F+1.5:R=INT (R-7*INT (R/7)): GOSUB 400
  205 IF Y<Z GOTO 260
  210 IF S*(M<>S) GOTO 255
  220 IF U=0 LPRINT ""
  230 P$=MID$ ("NLPQPLDQ",4U+1,2)+"  "+MID$ ("DILUMAMEJEVESA",2R+1,2)
  245 LPRINT " ";P$;USING "###";D;M;USING "#####.##";DMS H
  255 IF S*(M>S) GOTO 270
  260 U=((2U+1) AND 3)/2: NEXT K
  270 LPRINT "": END 
  300 F=F-.4068*SIN Q+(.1734-393€-6T)*SIN P+.0161*SIN 2Q-4€-4*SIN 3Q
  315 F=F+.0104*SIN 2W+4€-4*SIN (2W+P)-.0074*SIN (P-Q)-4€-4*SIN (2W-P)
  325 F=F-.0051*SIN (P+Q)-6€-4*SIN (2W+Q)+.0021*SIN 2P+5€-4*SIN (P+2Q)
  335 F=F+.0010*SIN (2W-Q): RETURN 
  340 F=F+(.1721-4€-4T)*SIN P+.0021*SIN 2P-.6280*SIN Q+.0089*SIN 2Q
  350 F=F-4€-4*SIN 3Q+.0079*SIN 2W-.0119*SIN (P+Q)-.0047*SIN (P-Q)
  360 F=F+3€-4*SIN (2W+P)-4€-4*SIN (2W-P)-6€-4*SIN (2W+Q)+.0021*SIN (2W-Q)
  370 F=F+3€-4*SIN (P+2Q)+4€-4*SIN (P-2Q)-3€-4*SIN (2P+Q)
  380 F=F+SGN (1-U)*(.0028-4€-4*COS P+3€-4*COS Q): RETURN 
  400 F=F+.5: IF F>=1 LET F=F-1:J=J+1
  420 A=J: IF G LET B=INT ((J/36524.25)-51.12264):A=J+1+B-INT (B/4)
  435 B=A+1524:C=INT ((B/365.25)-.3343):D=INT 365.25C:E=INT ((B-D)/30.61)
  455 D=B-D-INT 30.61E+F:M=E-1:Y=C-4716
  465 IF E>13.5 LET M=M-12
  470 IF M<2.5 LET Y=Y+1
  475 H=24*(D-INT D):D=INT D: RETURN

I had originally hoped to squeeze the program onto the Sharp PC-1246, but that only has 1278 bytes of program memory so I'd need to shave a further 208 bytes from the program which I don't think I'll be able to pull off without some significant reworking. It should be reasonably easy to split the program into two, and have one program perform the initial setup and calculations and then CHAIN the second half that prints the calendar from tape, but for now I think I've got enough calculators calculating phases of the moon to keep me occupied.

Repairing and using a Sharp ZQ-700 organiser as a pocket computer

Sat, 21 Mar 2026 14:07:37 +0000

The Sharp ZQ-700 Electronic Organizer, also sold as the Sharp OZ-700 Wizard, was a pretty interesting device. Its large 239×80 pixel resolution back-lit LCD and QWERTY keyboard made it a comfortable device to use, though the built-in programs are somewhat simplified from Sharp's more sophisticated earlier offerings; there's also no card slot for software expansion and the connectivity is much more limited. Gone are the options to connect a serial modem, send a fax, print to a thermal printer or back up data to cassette tape, but perhaps this was all a sign of the times. The US version of the organiser proudly sports the mywizard.com domain name, and the features I mentioned were all pretty old hat in an era when the Internet was being rapidly embraced. Whilst the organiser could not directly connect to the Internet, the accompanying website allowed users to share and download data files for the organiser and synchronise them with a PC using the supplied data cable.

A programmable organiser: Sierpinski triangle code typed into a memo

Where this becomes particularly interesting the organiser's My Programs button. Previous Sharp organisers could be turned into pocket computers via the addition of a Scientific Computer card which included a powerful BASIC interpreter. The ZQ-700 has a BASIC interpreter built-in, and up to ten BASIC programs can be stored on the organiser and accessed via the My Programs button. Unfortunately, these BASIC programs cannot be edited directly on the organiser itself and there is no interactive BASIC prompt, but Sharp supplied a free SDK which let you edit BASIC programs and convert them into the tokenised form that could be transferred to the organiser. Being able to write your own programs to run on your organiser is an extremely powerful feature.

Even better, the BASIC interpreter does provide PEEK, POKE and CALL keywords even though these are not directly accessible when using Sharp's official SDK. By creating a BASIC program with a stub CALL at the start and appending machine code to the end of it it's possible to run native code on the organiser. The organiser is powered by a Z80 CPU, and so a user-developed alternative SDK (including a C compiler) was released, allowing people to write their own native code for the organiser.

Unfortunately, most of the sites relating to the ZQ-700 and its community are long-gone. The official mywizard.com has been offline since at least 2009, though interestingly Sharp do still host some downloads relating to the organiser on their global website. The mywizard.com site eventually required user registration to download files, so very little of the user-generated content has been preserved by the Internet Archive. However, some of the hobbyist sites about the organiser have been preserved there, so it is possible to scrape together a bit of a software collection that way.

LCD repair

Aside from the link rot there are some more pressing age-related issues with the ZQ-700 relating to its LCD. Or, as the case may be, non-pressing issues as the flat flex cable that provides an electrical connection between the main PCB and the LCD's rows and columns gradually comes unstuck.

The photo above shows the typical state of the organiser's LCD after all these years. The discoloured paintwork around the hinges is somewhat less typical; I bought two organisers recently for cheap due to their non-working condition, and both showed signs of severe alkaline battery leakage. The two organisers were sold as a pair, and both were showed the same owner's name and address when powered on. I always find it interesting if an electronic organiser has any old user data on it, as it gives you an impression of how much the owner appreciated the device; in this particular case these organisers were very heavily used, with around 5,000 records stored on each. This gave me all the more inclination to want to repair them. As well as thousands of contact details and diary entries there were also numerous BASIC programs in the My Programs section, all related to cars and financing, so I thought it would be worth trying to find a way of backing up said programs before erasing all of the personal data from memory.

Getting access to the LCD is reasonably easy; the rear cover simply clips on. I find it easies to start popping it off near the hinge side, unclipping both sides and working up towards the top edge furthest away from the hinge. Some screws hold the PCB in, with each screw hole marked with a white triangle. In my case one screw was missing from the factory! The LCD glass itself is secured to the front of the screen housing with double-sided tape; some gentle pressure on the screen from the inside will unstick it.

The flat flex cables that are stuck to the LCD glass use a heat-activated adhesive. One potential fix for the cables coming unstuck is to heat them with a soldering iron to reactivate the adhesive, though this is a somewhat risky procedure. In this case, however, that is not an option due to the use of two cables at right angles to each other, with the problematic column-driving cable being folded between the LCD and PCB with no easy way to access it with a soldering iron.

A mechanical fix can be an option, however. This involves finding some way to put pressure between the flex cable and the PCB and/or LCD to physically hold the cable against the contacts. Thin rubber sheeting can work well for this, and for the ZQ-700 series I've found cutting a piece that's 3mm wide and about 105mm long from a 2mm thick sheet does a good job.

I also put two layers of Kapton tape on each side of the rubber strip before cutting it out. Aside from a little extra thickness, this gives the otherwise grippy rubber strip a smooth surface that will make it easier to slide into the fold of the flat flex cable between the LCD and its PCB.

There are two pieces of white tape stuck to the back of the PCB and the flat flex cable which pull on the cable slightly and can make it harder to install the rubber strip. Rather than remove these entirely I very carefully peeled them off the PCB and then cut them rather than try to peel them off the fragile flat flex cable and cause further damage.

After installing the rubber strip and screwing the PCB back down, there was a notable improvement but not all of the columns came back. Putting some additional pressure on the back of the board in just the right place resulted in a complete picture. One possible way to apply this pressure is to put something inside the back cover so that when it's clipped back on it simulates what my thumb was doing in the previous set of photos:

Unfortunately in this organiser's case there was still one missing column, and this was with so much rubber stuck inside the back cover that the whole screen was bowing outwards and could no longer be clipped shut. This clearly wasn't the answer, so the rubber pieces inside the back cover were peeled off. Some targeted application of the heat treatment seemed like the next best option.

There is no direct access to the flex cable, however there is nothing too delicate on the opposite side of the PCB which we do have access to – mostly just a thick copper track. A pair of spring clamps were placed on either side of the missing columns, applying firm pressure to the cable courtesy of the rubber strip inside its fold. The soldering iron was set to 350°C and held against the copper track for a few seconds. Everything was left to cool, then the results were checked – all columns were back!

I must stress this is a risky operation, as the flex cable is very delicate and heating it can ruin it. 350°C is far too hot for directly heating the cable and if the soldering iron slips and makes contact with the cable you'll probably melt a hole in it. When directly heating the cable I use an iron at around 240°C, but even then I only lightly swipe it across the cable in the direction of the contacts – no prolonged contact and no firm pressure.

Once I had the OZ-770 working I turned my attention to the ZQ-770, the other organiser from the pair. This one also has faulty columns on its display, however the fault is rather more intermittent – gently flexing the screen brings the missing columns back, and once the organiser has been on for a short while they generally remain visible until the organiser is switched off for a while. It'll probably need repairing in the future, but for now it's working well enough that I don't want to risk accidentally making it worse.

Backing up My Programs from ZQ-700 series organisers

One of the two organisers I'd bought had a number of BASIC programs loaded into the My Programs area. Unlike the personal data, which I had wiped, I thought it would be interesting to preserve these BASIC programs. Connecting the organiser to a PC is easy enough via an RS-232 serial cable; though I don't have an original one, I was able to make my own from a 3.5mm TRRS connector and a DE-9 plug following the wiring diagram on IMSL Software's copy of a page from the OZdev website. IMSL Software also develop the XLink/Win software which can be used to synchronise data between a Windows PC and an organiser, though this won't let you back up the data from My Programs.

A home-made serial cable for the ZQ-770

Sharp supplied a copy of Day-Timer Organizer for similar purposes and though this won't help back up My Programs either there is a handy backup utility on the CD that can dump the entire contents of the organiser to a file. Someone has uploaded a copy of this OZ-700 Software CD-ROM to the Internet Archive, and though it can't seem to restore backups on modern versions of Windows it happily created backup images from my organisers.

I did take a look at the created backup files and though they looked like nonsense at first I think this is because all of the bit values are inverted. After flipping the bits back I could find various program fragments, though they not contiguous so I suspect there's a file system or similar data structure embedded in the backups that make pulling out the data a little more difficult.

Fortunately this is a solved problem: SbkExplorer can open the backup .sbk file and export the programs as individual .wzd files, ready for reinstallation on other organisers.

Extracting files from the My Programs portion of a backup using SbkExplorer.

When these BASIC programs were originally developed using Sharp's SDK they were stored as a .bas containing the source code as a plain text file and a .prj project file that contained some information about the program such as its full name and a text description. The program would be "compiled" into a .obj file (effectively a tokenised BASIC program with the comments stripped out) and then published as a .wzd file which is an XML-like file containing the description from the project file and the compiled object file as raw binary data. Sharp's Sharp Wizard Decompiler can be used to extract a .bas file from the .wzd. Again, this won't be a perfect match for the source material as any comments would have been stripped out by the Sharp SDK, but it's definitely a good starting point to recovering old programs.

Links to OZ-770 resources

Unfortunately, a lot of the old sites that used to host information about this series of Sharp Organisers are long gone. Fortunately, the Internet Archive's Wayback Machine has copies of a lot of them, and I've linked to those archived copies where the original sites are no longer online.

General tools

Sharp's Software Downloads ZQ-700 series page still hosts the Downloader, Data Creation and SDK tools for the organiser as well as some sample installable .wzd files.
IMSL Software show how to make a serial cable for the organiser and sell Day-Time Organizer: Sharp Edition was originally bundled with the organiser on CD-ROM and can be used to back up and restore data from the organiser.
SbkExplorer can be used to extract data from a .sbk backup (created using the Backup Utility on the previous CD-ROM).

File archives and information about the organiser

Software development

OZdev Wizard Development: 2001, 2002. Lots of good information but the archives have some broken links, hence two captures from the two different domains are provided.
Official Sharp SDK to develop programs using BASIC.
Zifnab, an alternative SDK for developing BASIC programs (includes additional keywords like PEEK, POKE and CALL).
Bacon, an organiser add-on that lets you execute BASIC programs created directly on the organiser as memos.
Sharp Wizard Decompiler to decompile .wzd files into BASIC source files.
C SDK with a lot of sample code.

The result of running the Sierpinski triangle code from the earlier memo using Bacon

If you pick up one of these old organisers you can probably have quite a lot of fun with it as a pocket computer containing a Z80 CPU, a large LCD and QWERTY keyboard. It's just a shame about the poor durability of the screen.

Printing graphics from a Cambridge Z88 on a Serial 8056 via the BASIC patch

Sat, 29 Nov 2025 14:27:04 +0000

I've got a number of older computers that can print, but no printer for them. Quite often these computers require a serial printer, and so when a Serial 8056 printer popped up on eBay for around a tenner I picked it up. This is a thermal printer that takes fax paper rolls, so it seemed like a safe bet as far as consumables go (no need to source awkward cartridges, ink ribbons or spark paper) and the listing claimed it was intended for the Sinclair QL.

When it turned up I was a bit surprised by the plug on the end of the cable – two rows of eight pins, similar to a 16-way IDC connector, and not the phone jack style connector the QL needed. Fortunately the data (RD) and CTS pins were marked on the circuit board inside the printer and I was able to trace them out to the plug and bodge together a cable to plug it into my PC. Between articles from Format magazine, about the printer I was able to find the baud rate (1200), a few control codes for formatting and how to output graphics. Still puzzled by the non-QL plug I asked Reddit and that's when it was pointed out that the Serial 8056 is really a rebadged IBM PC Compact Printer originally sold for use with the PCjr. If my particular printer had been intended for use with the Sinclair QL then it would have included the appropriate adaptor in the box.

Knowing this, however, it made it easier to find information about the printer, including a reference manual, confirming the information I'd gleaned from the magazine articles about the Serial 8056.

One of the computers I had planned to use the printer with was my Cambridge Z88. Setting this up as a text printer was easy enough, but I'd been intrigued by a feature of the Z88 BASIC Patch, as described by the notes:

STOP PRESS Version 2.1 includes a graphics dump for Epson-compatible printers. The statement CALL 11011 will dump the graphics window.

The Serial 8056 is not Epson-compatible, and so the printer just outputs nonsense instead of the promised graphics. However, the Z88 Patch has source code available, so I thought it might be possible to modify this to replace the Epson control sequences with Serial 8056 ones.

Unfortunately, the Z88 BASIC Patch source code release appears to be missing the printer code. I turned to Ghidra to disassemble the patch, and found the pertinent routines.

As the routines send a dump of the graphics window (the "map" in Z88 parlance) to the printer, I named the main routine DUMPMAP. One of the first things it does is to reset the printer via a routine I named DUMPRESET. This sends ESC @ to reset the printer (the Epson ESC/P reference may be useful here), then sends two line feeds. It falls through to the routine that is used to send bytes to the printer, which I've named DUMPWRCH:

                    *************************************************************************
                    * Resets the printer to its initial settings and outputs two line feeds *
                    *************************************************************************
                    DUMPRESET
ram:2bb5 3e 1b             LD           A,0x1b       ; ESC
ram:2bb7 cd c6 2b          CALL         DUMPWRCH
ram:2bba 3e 40             LD           A,'@'        ; ESC @ = Initialize printer
ram:2bbc cd c6 2b          CALL         DUMPWRCH
ram:2bbf 3e 0a             LD           A,'\n'       ; Line feed
ram:2bc1 cd c6 2b          CALL         DUMPWRCH
ram:2bc4 3e 0a             LD           A,'\n'       ; Line feed
                    *************************************************************************
                    * Write a byte to the serial port with a 1 second timeout               *
                    *************************************************************************
                    DUMPWRCH
ram:2bc6 f5                PUSH         AF
ram:2bc7 01 64 00          LD           BC,100       ; 100cs timeout
ram:2bca e7                RST          SYS
ram:2bcb 42                db           OS_Pbt       ; Write the byte to the serial port
ram:2bcc f1                POP          AF
ram:2bcd c9                RET

The DUMPRESET routine is also used at the very end of printing to reset the printer and ensure two line feeds appear after the graphics dump. Graphics data are sent as 8 pixel high rows with condensed line spacing, one byte per column. The relevant code that starts this process of each row is as follows: first the line spacing is set to 1/9-inch using ESC 3, a line feed is sent, there's a one second delay to give the mechanism time to advance and then graphics mode is entered with ESC L and a request to send 768 bytes:

ram:2b33 3e 1b             LD           A,0x1b       ; ESC
ram:2b35 cd c6 2b          CALL         DUMPWRCH
ram:2b38 3e 33             LD           A,'3'        ; ESC 3 = Set n/216-inch line spacing 
ram:2b3a cd c6 2b          CALL         DUMPWRCH
ram:2b3d 3e 18             LD           A,24         ; 24/216 = 1/9-inch line spacing
ram:2b3f cd c6 2b          CALL         DUMPWRCH
ram:2b42 3e 0a             LD           A,'\n'       ; Line feed
ram:2b44 cd c6 2b          CALL         DUMPWRCH

ram:2b47 01 64 00          LD           BC,100       ; 100cs
ram:2b4a e7                RST          SYS
ram:2b4b 2d                db           OS_Tin       ; Wait for a key for 100cs

ram:2b4c 3e 1b             LD           A,0x1b       ; ESC
ram:2b4e cd c6 2b          CALL         DUMPWRCH
ram:2b51 3e 4c             LD           A,'L'        ; ESC L = Select 120-dpi graphics
ram:2b53 cd c6 2b          CALL         DUMPWRCH
ram:2b56 3e 00             LD           A,0          ; nL = 0
ram:2b58 cd c6 2b          CALL         DUMPWRCH
ram:2b5b 3e 03             LD           A,3          ; nH = 3: 768 bytes
ram:2b5d cd c6 2b          CALL         DUMPWRCH

The graphics window (map) is only 256 pixels wide, though, so why 768 bytes? Well, the printing code actually scales the image up before printing: it doubles the height and triples the width of each pixel. When outputting a row of graphics data, each column byte is sent three times:

ram:2b7c cd c6 2b          CALL         DUMPWRCH
ram:2b7f cd c6 2b          CALL         DUMPWRCH
ram:2b82 cd c6 2b          CALL         DUMPWRCH

This is all of the Epson-specific printer code, and fortunately it maps pretty well to the Serial 8056:

Action	Epson ESC/P	Serial 8056
Initialise printer	`ESC @`	`CAN`
Set 1/9-inch line spacing	`ESC 3 n=24`	`ESC 1`
Output bitmapped graphics	`ESC L n=768 [768 bytes]`	`ESC K n=512 [512 bytes]`

Ideally, the Epson codes could simply be patched with the equivalent Serial 8056 codes but there is one slight spanner in the works: the Serial 8056 needs a carriage return to be sent after each line and the code doesn't do that and there's no easy way to insert it at the end of the relevant printing routines.

However, it is possible to insert a carriage return at the start of each line, which means that each line will start by ending the preceding one. This does still leave the final line, but fortunately the code calls DUMPRESET after printing the last line and so an additional carriage return can be inserted at the start of that routine to terminate that line.

It's not quite as elegant a patch, as the order of some code needs to be adjusted rather than just patching the Epson codes with the equivalent Serial 8056 codes, but it's not too bad overall. The full list of code changes are as follows:

                    DUMPRESET
ram:2bb5 3e 1b             LD           A,0x1b       ; Change to CR: ?&2BB6=13
ram:2bb7 cd c6 2b          CALL         DUMPWRCH
ram:2bba 3e 40             LD           A,'@'        ; Change to ESC: ?&2BBB=27
ram:2bbc cd c6 2b          CALL         DUMPWRCH
ram:2bbf 3e 0a             LD           A,'\n'       ; Change to '2': ?&2BC0=50
ram:2bc1 cd c6 2b          CALL         DUMPWRCH
ram:2bc4 3e 0a             LD           A,'\n'

The need to insert an extra carriage return at the start of the reset routine means we can only output a single line feed after resetting the printer instead of the original two. You may also be wondering why the printer is "reset" with ESC 2 instead of CAN, as that would save a byte – in my case it doesn't appear that resetting the printer that way resets the line spacing, which means that the printer gets left in the 1/9-inch line spacing mode. ESC 2 explicitly restores the 1/6-inch (default) line spacing mode.

The code that runs at the start of each line of output is a bit more awkward to change, unfortunately. The original code currently works like this:

Send ESC
Send '3'
Send 24
Send LF
Wait 100cs

However, our new code needs to do this instead:

Send CR
Send LF
Wait 200cs*
Send ESC
Send '1'*

Three of the five operations line up, however two of them (sending a byte of data and introducing a delay, marked with an asterisk) are swapped, which means that two code blocks in the code need to be swapped. Very fortunately, the code for each operation is the same size (five bytes) which at least means that the code between them can be left in the same place.

ram:2b33 3e 1b             LD           A,0x1b      ; Change to CR: ?&2B34=13
ram:2b35 cd c6 2b          CALL         DUMPWRCH
ram:2b38 3e 33             LD           A,'3'       ; Change to LF: ?&2B39=10
ram:2b3a cd c6 2b          CALL         DUMPWRCH 

ram:2b3d 3e 18             LD           A,24        ; Change to 200cs delay: ?&2B3D=1 ?&2B3E=200
ram:2b3f cd c6 2b          CALL         DUMPWRCH    ; ?&2B3F=0 ?&2B40=231 ?&2B41=45

ram:2b42 3e 0a             LD           A,'\n'      ; Change to ESC: ?&2B43=27
ram:2b44 cd c6 2b          CALL         DUMPWRCH

ram:2b47 01 64 00          LD           BC,100      ; Change to DUMPWRCH '1':
ram:2b4a e7                RST          SYS         ; ?&2B47=62 ?&2B48=49
ram:2b4b 2d                db           OS_Tin      ; ?&2B49=205 ?&2B4A=198 ?&2B4B=43

The time delay is handled by calling the OS input routine with the timeout delay specified in register BC. The original code used 100cs, i.e. 1 second. When I was testing the code I ran into some issues: the first few lines printed fine, but the last couple of lines ended up failing to print, with the preceding lines showing some junk characters at the end of each line. Extending the delay to 200cs fixed the issue, but I was not sure why the first few lines printed fine and the problem only manifested itself at the end of the print until I looked at the movement of the print head more carefully.

The test image I was using was a row of Sierpinski triangles, and so the rightmost pixels were mostly white in the early rows but increasingly black as the triangles widened towards the bottom of the image. It turns out that if the end of the line is white the print head returns back home early, and so the one second delay was enough when the print head was skipping the end of the line but not quite enough when it had to travel the full distance back to the left edge. Extending the delay to two seconds provides more than enough time for the carriage to return.

When it comes to sending the actual bitmap data to the printer only a simple modification is required:

ram:2b4c 3e 1b             LD           A,0x1b
ram:2b4e cd c6 2b          CALL         DUMPWRCH
ram:2b51 3e 4c             LD           A,'L'        ; Change to 'K': ?&2B52=75
ram:2b53 cd c6 2b          CALL         DUMPWRCH
ram:2b56 3e 00             LD           A,0
ram:2b58 cd c6 2b          CALL         DUMPWRCH    
ram:2b5b 3e 03             LD           A,3          ; Change to 2: ?&2B5C=2
ram:2b5d cd c6 2b          CALL         DUMPWRCH

Instead of ESC L with an argument of 768 bytes (&0300) we need to send ESC K with an argument of 512 bytes (&0200). The code will still try to send 768 bytes by repeating each column of the 256-pixel wide image three times, so instead we need to only send each column twice:

ram:2b7c cd c6 2b          CALL         DUMPWRCH
ram:2b7f cd c6 2b          CALL         DUMPWRCH
ram:2b82 cd c6 2b          CALL         DUMPWRCH     ; Change to CALL <dummy>: ?&2B83=&B4

The final CALL could be replaced by three NOP bytes but rather than do that the address of the target is patched to &2BB4. This address contains a RET instruction as it's the final instruction of a nearby routine so effectively turns the CALL into a NOP.

This completes the patch itself; the only thing needed to do is to wrap it up into a neat installer. Here is the result of that, in BBC BASIC:

   10 REM Serial 8056 Patch for Z88 BASIC
   20 C%=0:FORA%=&2B03TO&2BF6:C%=C%+?A%:NEXT
   30 IFC%=&5BF1PRINT"Patch already applied.":END
   40 IFC%<>&5BB9PRINT"Please load Z88PATCH.BBC first.":END
   50 READA%,V%:REPEATA%?&2B00=V%:READA%,V%:UNTILA%<0
   60 PRINT"Patch applied: use CALL 11011 to print.":END
   70 DATA&B6,13,&BB,27,&C0,50
   80 DATA&34,13,&39,10,&3D,1,&3E,200,&3F,0,&40,231,&41,45
   90 DATA&43,27,&47,62,&48,49,&49,205,&4A,198,&4B,43
  100 DATA&52,75,&5C,2,&83,180,-1,0

Line 20 first calculates a checksum of the area targeted by the patch, which is then checked in lines 30 and 40 for two known states: Serial 8056 patch already applied and Z88PATCH loaded but Serial 8056 patch not applied. Line 50 reads the patch data itself (stored in lines 70 to 100) which is made up of addresses and patch value pairs; as all bytes to patch appear in the &2Bxx address range only the least significant byte of the address is stored.

In summary, if you have a Serial 8056 and a Cambridge Z88 and wish to print graphics from BBC BASIC you may find the Serial 8056 for Z88 patch useful. You will also need the Z88 BASIC Patch as a starting point.

40-column text modes on Sharp organisers with the 16-column IQ-707 BASIC card

Wed, 02 Jul 2025 02:08:07 +0100

Recent posts on here have taken a bit of a detour into Sharp Pocket Computer territory. When hunting down parts or accessories for them on eBay I'll occasionally be recommended other Sharp devices, such as their calculators or organisers, if an exact match for the thing I'm actually hunting for can't be found. Calculators are indeed a useful tool, so I appreciate those recommendations, but mid-1980s electronic organisers are not usually the sort of thing I'd be too interested in.

However, some of Sharp's organisers are definitely worth a look, and these are often considerably cheaper to pick up second-hand than pocket computers or calculators. I suspect this is partially due to difficulty in testing them and perhaps a bit of user error – they often require a large number of CR2032 cells to be installed, usually after removing a screwed-on back cover, and have a series of interlock switches that all need to be set just right before the device will even try to switch on. As a result, I've acquired quite a large collection of them for very little money, mostly sold as faulty or untested but all working just fine.

These particular organisers have a card slot on them, which can be used to expand the device's capabilities via a credit card-sized "IC card". The most common sort that you'll find is a RAM expansion card, which allows you to store more data (notes, calendar appointments, address book entries and the like) in a separate area to the device's built-in memory. More interesting, however, are the application IC cards. Dictionaries, thesauri, spreadsheets and even games were made available.

To me the most appealing is the Scientific Computer Card. The organisers do have a simple calculator built in, but the Scientific Computer Card adds more advanced calculator features such as trigonometric functions, logarithms and a statistics package. This is all handled via a very capable BASIC interpreter built into the card, and you can write your own programs on the organiser. The organisers also have a 4-pin "option" port that can be connected to a printer and cassette interface, and a 15-pin "PC link" serial port, so when you slot the card into your organiser you are in effect turning it into a pocket computer (though with all the accessories attached, you might need pretty large pockets!)

My only real criticism of this arrangement when compared to Sharp's dedicated pocket computers is the IQ-7000's keyboard. It's not too difficult to get used to the non-QWERTY alphabetic characters, but for BASIC programs you often need certain symbols (such as the speech mark, comma, semicolon, colon, less/greater than or ampersand) which are not present on the organiser's keyboard – they're only available via a pop-up menu that appears when you press the SMBL key. This menu only shows 10 options at a time and you need to hunt up and down through it to find the symbol you need; not an ideal experience!

Fortunately, Sharp released later organiser models (such as the IQ-8000) with QWERTY keyboards. Not only are these more comfortable to type on, but most of the symbols are now accessible via a shift key and these organisers retained backwards compatibility with the IC cards from the earlier IQ-7000 organisers.

The screen is also quite a bit larger and clearer, albeit now with non-square pixels which can make applications look a little skinny. Unfortunately, old applications developed with the 96×64 pixel display on the IQ-7000 in mind won't know how to take advantage of the 240×64 pixel display of the IQ-8000 and so are rendered on the left hand side of the display with a separator line. That seems like an awful lot of wasted space!

Application cards that took full advantage of the larger screens (up to 40 columns of text) were sometimes sold separately to the versions that were only designed for the smaller-screen devices (16 columns of text). For example, the above photo shows two cards of the same software – 3 Dimensional Spreadsheet for Electronic Organizer – with different card numbers (IQ-706A v IQ-8B01). The card on the right has 16/40 printed in the top right corner, showing it supports both 16-column and 40-column organisers. The card on the left doesn't, and will work in both, but will only display in the leftmost 16 columns.

As an aside, another difference is that the IQ-8B01 version has an extra "Graph" button on it. When the cards are inserted the front labels are visible through a transparent window. That window is touch-sensitive and allows cards to provide custom key shortcuts to certain functions. The graph function will work on a smaller-screen organiser though it is a little cramped; I'm not sure why it wasn't otherwise provided on the IQ-706A.

There was a 40-column version of the Scientific Computer Card available (card number IQ-8B03), however I have yet to find one come up for sale and so I've been making the most of my IQ-707. However, I did find something interesting when I used it on my IQ-8000: certain primitive drawing operations could access the whole screen, even if the rest of the application was constrained to a smaller window.

The photo on the left shows the results of drawing a line from (0, 0) to (239, 63) – the line ends up being drawn successfully outside of the 96×64 window at the left of the screen. The second photo uses the same coordinates but also appends the X (invert) and BF (box fill) options which should in theory invert the whole screen, but only ends up inverting the leftmost 96×64 pixels.

Certain other drawing operations (such as PSET and GPRINT) will also happily draw to the whole screen, but text cannot be positioned or drawn outside the 16×8 grid. At this point I wasn't sure if it was the BASIC interpreter or the organiser's OS that was to blame, but I wasn't really sure how to pick apart either of them.

One potential clue came in the form of the WIDTH statement. The IQ-7000 effectively has two screen modes, with differently-sized text characters: the default small font in a 16×8 grid and a larger font that reduces the number of displayed characters to 12×4. These modes can be switched by pressing the button marked 4↔8 Lines, or programatically via WIDTH 16,8 or WIDTH 12,4. The IQ-8000 expands these to 40×8 and 30×4, but trying WIDTH 40,8 or WIDTH 30,4 just displayed an error message. However, something, somewhere must know where the rightmost column number is to allow for proper text wrapping.

I mentioned that the BASIC interpreter is very capable, and it does have an undocumented PEEK function which allows you to read a byte from anywhere in the organiser's memory. I wrote a BASIC program that would scan through memory, switching screen modes with WIDTH and seeing if the value at the address in question changed. Once I'd done this I looked at the addresses that had values that changed in meaningful ways (e.g. between 16 and 12 or 8 and 4).

It looks like the current screen width (in characters) is held in BASIC's memory at &3F988 and the height at &3F989. POKEing a larger width into &3F988 does look like it might start working – if you type then the cursor goes off the right of the 96×64 window and can be seen blinking in the screen beyond, however no characters are printed in this area and certain operations (such as listing programs with long lines) misbehaves in strange ways. There must be more to the puzzle.

Unfortunately, without knowing more about the internal operation of the operating system or BASIC I wasn't sure where to look. However, having been able to draw lines on the full screen I contented myself with adapting a very clever program by @bazzargh that renders the Great Wave as a fractal for the device (the BASIC listing can be seen here: GREATWAV.BAS).

The next breakthrough was coming across this GitHub repository when looking for other technical reference documents. It has a scan of the "ESR-L Instruction Manual" which documents the Sharp ESR-L microprocessor. Some hand-written notes on the cover of the scan mention that it's "for the PC-E500, OZ-7000 series [and] IQ-7000 series", so should be useful for the IQ-7000 organiser. Looking up the PC-E500 led me to this repository from the same owner which has a PC-E500 reference. Even if the IQ-7000 is not the same as the PC-E500, the use of the same CPU in products from the same company made me think there may be other similarities to help understand how the IQ-7000 works. Using the PC-E500 as a search term also brought me to a page of resources on Andrew Woods' website and from there and digging around in the links (including a few trips to the Internet Archive's Wayback Machine) I was able to source a cross-assembler and disassembler.

I now felt I was in a good position to start pulling apart the BASIC interpreter and OS to figure out if it was possible to use the full screen on my IQ-8000. Of course, I'd need to have a ROM dump to inspect, and fortunately this was quite easy to pull off; after all, I already had a BASIC interpreter running on the device! A simple loop over the desired address ranges, PEEKing each byte then PRINT#ing it to the organiser's serial port with a program on my PC receiving the data and storing it in a file left me with some hefty binaries to dig into.

The size did indeed present a bit of a problem. I did have a disassembler, but not a particularly sophisticated one and feeding it the 128KB of BASIC interpreter ROM didn't provide particularly useful results. I'd normally use Ghidra for a job like this, but it doesn't know about the Sharp ESR-L CPU.

However, Ghidra is user-extensible and I did now have an instruction manual/reference for the CPU, so I did my best to learn how to describe the CPU to Ghidra. This was no small undertaking, as I didn't really know my way around the CPU yet myself. After a bit of work I put together this terrible first attempt. I do not recommend using it yourself, as I haven't fully checked that every instruction disassembles correctly and a very large number of instructions don't describe what they do (or if they do, they might do it incorrectly). The disassembly should be somewhat usable, but the decompilation is mostly useless at the moment.

I thought the title screen would be a good starting point to disassemble as I could clearly find where the strings for "BASIC Card" and the equals signs that form the border were in the binary, and from there find out where they were referenced and disassemble the instructions around those references until it made some sort of sense.

This is where the PC-E500 reference ended up being surprisingly useful, as it does share a fair amount in common with the IQ-7000. The way that both operating systems provide access to the hardware is via an IOCS routine at address &FFFE8, and the routine numbers and parameter assignments in the CPU's internal memory appear to be the same on both devices. One difference is certain locations in RAM are different (for example, the location of the text flags or the dot pattern used to draw lines) however these differences are fairly easy to identify.

If you look at the Ghidra screenshot above you'll see that the disassembly on the left looks vaguely sensible but the decompilation on the right is a right mess: for reasons I haven't yet figured out it appears to show stack operations during calls as assignments to variables on the stack (uStack000001 etc) and assignments to variables in RAM which are used as parameters to functions (e.g. BX and DX) are shown as both manual assignments and in the function call parameters.

Trusting the disassembly rather than the decompilation, I dug around in the code, trying to find something that was making use of the magic numbers relating to the screen dimensions: anything with 16, 8, 12 and 4 in close proximity would be a good candidate and I eventually found something promising:

The ESR-L is a little-endian CPU so the hex constants 0x810 and 0x40C in the following code correspond to (16, 8) and (12, 4) in memory.

050eb2 0a 10 08          MV           BA,0x810
050eb5 aa 46 fd 03       MV           [DAT_03fd46],BA
050eb9 0a 0c 04          MV           BA,0x40c
050ebc aa 48 fd 03       MV           [DAT_03fd48],BA

They're stored at &3FD46 and &3FD48 in memory, so directly adjacent to each other, and the surrounding code blocks operate on the cursor's X position and textflags, so it all seems highly relevant to what we're looking for. Those values in memory can be changed with POKE:

POKE &3FD46,40,8,30,4

The side-effect of this change is that you can now use WIDTH 40,8 and WIDTH 30,4 and the mode changes accordingly. However, when you type, text is still invisible once the cursor roams outside the leftmost 96×64 region of the screen. Clearly something else needs to change.

Further up in the code the values at &3FD46 and &3FD48 are copied from other values at &1FD9D and &01FD9F:

050e97 8a 9d fd 01       MV           BA,[DAT_01fd9d]
050e9b aa 46 fd 03       MV           [DAT_03fd46],BA
050e9f 8a 9f fd 01       MV           BA,[DAT_01fd9f]
050ea3 aa 48 fd 03       MV           [DAT_03fd48],BA

These source addresses are in the organiser's own memory rather than the memory built into the BASIC card, so it seems likely that these are the system values for width and height of the screen in the small and large fonts respectively and BASIC maintains its own copies of them which are the values we found before. We could POKE our new text resolutions into those memory locations too, which can be done with this program:

10 POKE &1FD9D,40,8,30,4
20 POKE &3FD46,40,8,30,4
30 WIDTH 40,8
40 CLS

After doing this, the whole screen becomes available to our BASIC program! All graphics operations work on the whole screen and text can be placed and displayed anywhere on it successfully:

I doubt this is the "correct" way to do it, and there is likely a proper IOCS call that updates the screen resolution. As a result there may be other system variables that are not properly updated by directly POKEing values into memory, but so far I haven't run into any significant problems. As I continue to work through the system ROM disassembly I may find the appropriate routines, however.

I did try to see if the full screen size was stored somewhere in the ROM image, as it would be useful to use this to know how to properly set the display mode according to the current organiser's capabilities. I did find the byte sequence (16, 8, 12, 4) in the IQ-7000 (&F083C) and IQ-7400 (&F478A) ROM dumps and the byte sequence (40, 8, 30, 4) in the IQ-8000 (&F1412), IQ-8200 (&F1418) and IQ-8300M (&F1423) ROM dumps. I couldn't find any code that was able to meaningfully access these sequences from a user application. There may be some way to properly identify the device you're running on but I'm not currently sure of a reliable way. One potential option is to use POINT(96,0) – this returns the status of a pixel on the display (0 for off, 1 for on), and crucially it returns -1 if the value is outside the screen bounds. On an IQ-7000 it returns -1, but on an IQ-8000 it returns 0 or 1. However, a later organiser model throws a spanner in the works…

This is the Sharp IQ-8920. Its screen is still 240 pixels wide, like the IQ-8000, but it is significantly taller and has square pixels. When I first saw one of these online I was less interested in it as it didn't have the obvious card slot, but when I looked at a closer photo of it I could see that it still had one on the side. I couldn't see how this would work, as it's missing the window to see the card's buttons through, but I ended up picking one up anyway. It turns out it is still backwards-compatible with the cards from the earlier organisers, and this backwards-compatibility is achieved by displaying the card's buttons directly on the resistive touchscreen (I assume there's a database of cards and their button assignments somewhere in the IQ-8920's ROM). The IQ-8920 also corrects one notable oversight of the IQ-8000…

Attempting to draw graphics out-of-bounds on the IQ-8920 results in them being properly clipped, unlike the IQ-8000 which permits some graphics operations to work even when only the leftmost 96×64 region of the screen should be accessible. This means that on the IQ-8920, POINT(96,0) returns -1 by default and so this can't be used to detect a device with a screen that is wider than 96 pixels.

However, the same BASIC POKE program can be used to get the IQ-8920 to use the full width of the display:

I did also try extending the height of the screen, and though this looks a little promising at the start (as you work down the screen, new lines of text start overwriting the on-screen button display) things go very wrong when the screen tries to scroll and the organiser hangs quite often. Some other scrolling operations do misbehave (e.g. when scrolling through a program listing, occasionally a single line of text may appear invisible) and I'm not entirely sure what the cause is yet. The Great Wave does at least now appear on the IQ-8920:

One thing which susprisingly does not misbehave is if you extend the screen resolution on an original IQ-7000 or IQ-7400. Text disappears off the right of the display, but I haven't seen it crash or hang the organiser. POINT(96,0) still returns -1 with the screen extended on this organiser, so one solution may be to just to try to set the screen to the higher resolution, check if POINT(96,0) is out of bounds, and if it is reset back to the lower resolution. The program would then look like this:

10 POKE &1FD9D,40,8,30,4
20 POKE &3FD46,40,8,30,4
30 WIDTH 40,8
40 CLS
50 IF POINT(96,0)=0THEN END
60 POKE &1FD9D,16,8,12,4
70 POKE &3FD46,16,8,12,4
80 WIDTH 16,8
90 CLS

I will continue to dive into the OS ROM disassemblies to see if I can find ways to make this more reliable and whether there's a more correct way to do this. It would be useful to be able to dump the ROMs for the other 16/40 cards I have to see how they manage the mode switch, however as I've been dumping the ROMs from a BASIC program and I don't have an organiser with two card slots I don't currently have a way to do that. The card lock switch (which causes the organiser to switch off and reset when changing cards) appears to be handled in software (rather than being a hardware interlock) so it may be possible to write a ROM dumping program in assembly, copy it to somewhere safe in RAM from a BASIC program and then hot-swap the cards. There's 2KB of clipboard buffer that looks usable for this process, and you can CALL machine code you've POKEd into memory – I have no idea whether that will be technically possible, though, so this is just something at a very early idea stage.

I did discover a test menu in the IQ-7000 and IQ-7400 ROMs, though. Bear in mind that accessing these will reset your organiser's settings and may clear the RAM, so don't do it on an organiser that contains data you care about!

The one in the IQ-7000 isn't particularly enlightening, but can be accessed by holding ON+9 when pressing the reset button. The one on the IQ-7400 is more interesting and can be accessed by holding ON+CALC when resetting. Of particular note here is a memory dump, which allows you to enter an address and shows the data at that address on the screen. This would allow you to dump an IC card, but it only shows 16 bytes at a time and so could be very time consuming to work through! There is also a memory save and load routine in the test menu that looks like it will transmit the data from the organiser, but unfortunately it doesn't appear to let you enter the start address or length and just exports the built-in RAM rather than letting you enter the address of a card in the slot. The IQ-7400 also has a ROM version screen that can be shown by holding ON+A when resetting.

I don't know if this will have persuaded anyone that Sharp's electronics organisers are more interesting than they might first appear, but if you can pick one up along with a Scientific Computer Card I think you'll find they're fun little devices to experiment with!

Highlighting and tape loading PC-1500 BASIC programs on the web

Fri, 09 May 2025 00:25:17 +0100

I don't think I've had a proper dose of "man-flu" since COVID and I haven't missed it at all. This journal entry has been written in a state of sleep deprivation whilst being tanked up on Lucozade and Lemsip (expiry date: March 2020) so hopefully it still makes some degree of sense.

In my current state the most obvious project is to subject myself to the banshee howls of tape loading. I've implemented some degree of tape loading support to my site before by taking tokenised BBC BASIC programs and running them through a web service that converts them to

Unfortunately, whilst PlayUEF is a superb piece of software for loading Acorn software, it is less ideal for the Sharp PC-1500. This isn't a limitation of the UEF format itself, it's just that Sharp PC-1500 programs are stored at a different base frequency (1270Hz instead of 1200Hz), use a 0° phase instead of 180° phase, and repeat the wave patterns for 0 bits and 1 bits four times longer than the BBC Micro format ("300 baud" mode instead of "1200 baud" mode). None of those features were supported by PlayUEF, however it is open source software so I hacked them into my own fork of the project.

Note that I do say "hacked", as PlayUEF does take some shortcuts when generating the resulting waveform that I found a bit awkward to work around. For example, it needs to allocate a buffer to write the wave file to and so needs to know the number of samples in the resulting wave file to do so. It normally does this by multiplying the number of wave cycles in the file by the number of samples per cycle, but that only works if the number of samples per cycle remains constant through the file (which they won't if we're changing the frequency on the fly) and the number of cycles per bit also needs to remain consistent (which it won't if we're outputting four times as many wave cycles for the Sharp PC-1500 when compared to BBC Micro).

In the end I worked around this with a two-pass solution: the first time around a zero-byte buffer is allocated and written to (which appears to work?) and the final length is calculated by adding up the total number of samples. The second time around the buffer is allocated the total number of samples it requires.

Whilst this works and the end result loads fine onto an actual Sharp PC-1500, the code is now a bit of a mess and there are a lot of nifty visualisations and "fast loading" tricks that only make sense to the BBC Micro but are still baked into PlayUEF. For my own use I might make a less sexy alternative to PlayUEF that just converts a UEF to a wave for loading via the web. However, for now it works as-is.

To support all this I also needed way to tokenise (and detokenise) Sharp PC-1500 BASIC programs and convert the resulting binary into a UEF tape image. To do this I've knocked together a couple of PHP classes, sharp_pc1500_basic and sharp_pc1500_tape that do the work and these files can be downloaded in sharp-pc-1500-php.zip.

Here are some examples of how this works (click the "Load file as tape image" to hear the beautiful sounds):

Relocatable Quick-Tape installer for the Sharp PC-1500

Sat, 26 Apr 2025 23:09:37 +0100

After my previous journal post about faster saving and loading of Sharp PC-1500 programs to and from tape I discovered that I was using a somewhat out-of-date version of Sharp Pocket Tools. The later version I upgraded to adds support for the "SuperTape" and "Quick-Tape" formats, and also includes copies of the PC-1500 programs for those formats.

Both formats appear to support file names and verification of the recorded data (a minor gripe I had with the Fast Load was its lack of these features). SuperTape apparently manages even higher speeds, though at the cost of somewhat more RAM than Fast Load (711 bytes, or 761 for the full version with the ability to merge a program with the existing one in memory, instead of Fast Load's 540 bytes). Quick-Tape seems to be about the same speed as Fast Load, but actually consumes less memory overall (only 508 bytes). Quick-Tape also explicitly supports saving machine language programs by specifying a start and end address, something that I cannot see is supported with the SuperTape format, though it looks like it might support loading machine language programs if the correct load address is stored in the file.

Based on my experiences with Fast Load and the documentation that accompanies SuperTape and Quick-Tape I came up with a rough feature comparison table (I can't claim it's completely accurate, as it's based on what I've gleaned from the documentation):

Format	Fast Load	SuperTape	Quick-Tape
Speed	Fast	Fastest	Fast
Filenames	✗	✓	✓
Verification	✗	✓	✓
Machine language	✗	(Maybe?)	✓
Variables	✓	✗	✗
RAM usage (bytes)	540	711–761	508
Relocatable	✓	(Partial)	✗

To get a rough idea of speed I tried converting the Globe application to a wave file. Both Fast Load and Quick-Tape produce a file that's 30 seconds long — a huge improvement over the seven minutes that the native cassette routines take. SuperTape still manages to blow both of these out of the water with a file that's only 13 seconds long! Only Fast Load seems to have the ability to save BASIC's variables to tape, though this is not a feature I personally have any use for.

The ability to relocate the machine language routines that make up the tape routines is a very important one, however! The available range of memory addresses in a PC-1500 computer will depend on which memory expansion module is installed and whether any other machine language routines are also loaded. Fast Load can be relocated to anywhere you want in memory via its BASIC installer program. SuperTape has a few different versions for different starting addresses based on certain memory modules as well as a BASIC installer, however as far as I can see it doesn't seem to allow being loaded at an arbitrary address which would make it trickier for it to coexist alongside other machine language programs on the computer. Quick-Tape doesn't have any relocation support at all, only working if loaded to address &00C5 and used with the CE-161 memory expansion module.

However, Quick-Tape seems like it would otherwise be ideal — it consumes the last RAM, it seems the most feature-complete and though it's not quite as fast as SuperTape it's still a massive improvement over the native cassette routines.

I therefore decided I'd try to make a relocatable version of Quick-Tape. To assist with this I first disassembled it using lhTools. It doesn't load any data nor jump to any absolute addresses within its own memory space, which is a good start — in fact, it only calls three subroutines inside itself: &01BE, &01BF and &01CF. You can spot these easily in the disassembled code as they are assigned named labels by lhTools instead of absolute addresses, for example in this snippet:

lbl_0_159:
	SJP	lbl_0_1be ; labelled address inside our memory
	ADR	Y
	LOP	lbl_0_159
	LDA	YH
	SJP	lbl_0_1bf ; labelled address inside our memory
	LDA	YL
	SJP	lbl_0_1bf ; labelled address inside our memory

...as opposed to:

lbl_0_117:
	SJP	BBD6 ; absolute address outside our memory
	VMJ	0A
	SJP	BBC0 ; another absolute address outside our memory

The version of lhTools I'm using is one I've modified to use the standard LH5801 instruction mnemonics instead of the Z80-inspired ones it normally uses; it also disassembles vectored subroutine calls into standard VMJ instructions instead of the lhTools pseudo-instructions, though as I haven't got it to re-assembled these instructions properly yet this is not something I'm able to share just yet. However, the important thing here is the subroutine called with the SJP instruction.

Now that we know where these subroutine calls are, a BASIC program can be written that patches the loaded machine language program with the correct target addresses for where it's been relocated to. Similarly, the reserve program (which contains BASIC CALL statements to call the entry points in the machine language program) needs to have its addresses patched to point at the relocated machine language program. The resulting installer looks like this:

    10 M=PEEK &7863*256+197:B=PEEK &7865*256+PEEK &7866
    20 IF B-M<508 PRINT "No room": END
    30 L=M: IF B-M>508 WAIT 0: PRINT "Load @";L;" ";: INPUT L
    40 CLS : WAIT : IF (L<M) OR (L+508>B) PRINT "Bad address": GOTO 10
    50 WAIT 0: PRINT "Play QUICK-TAPE...": CLOAD M"QUICK-TAPE";L
    60 FOR I=1 TO 3: READ A,C: FOR J=1 TO C
    70 READ O: POKE O+L,(A+L)/256,(A+L) AND 255
    80 NEXT J: NEXT I
    90 DATA 249,1,149,250,2,157,161,266,3,411,443,452
   100 M=M-197: PRINT "Play QUICK-RESERVE...": CLOAD M"QUICK-RESERVE";M
   110 FOR I=1 TO 6: READ A,O:A$=RIGHT$("00"+STR$ (A+L),5)
   120 FOR J=1 TO 5: POKE M+O+J,ASC MID$(A$,J,1): NEXT J: NEXT I
   130 DATA 4,89,6,101,5,113,2,130,1,153,0,165
   140 CLEAR :Z$="": WAIT : PRINT "QUICK-TAPE installed"

You can download the installer and reserve program as ready-to-go WAV files in Quick-Tape-Install.zip. You'll also need to create a WAV file for Quick-Tape itself, which can be downloaded as part of Pocket Tools. Instructions can be found inside the installer zip archive.

Faster tape loading on the Sharp PC-1500 with Fast Load

Sun, 20 Apr 2025 21:34:53 +0100

After I've typed a program into my Sharp PC-1500, I tend to save it to my PC for long-term storage using the CE-150 cassette interface. I use the same cassette interface to download programs shared by others over the Internet, and have written a previous post about resampling those shared wave files if you're struggling to load them.

Loading a program this way is quicker than typing them in, but not by much! The Globe application is 5697 bytes in length but takes the best part of seven minutes to load from tape. I was therefore very intrigued by the Fast Load application, which "enables fast loading (4000 baud, 13 times the normal speed) of all Basic or machine language programs and variables".

I didn't have the easiest time using this program, so thought I'd put together this post in case it helps anyone else with similar struggles!

Fast Load's component parts

The included documentation is a little confusing. I assume it's been abbreviated from what would have been included with the original tape, but I'm really not sure. It mentions using CLOAD M to load FAST-LOAD, however if this is to be a relocatable module then how should it be relocated once loaded, and after that point how are you to invoke the saving and loading routines?

Included in the zip archive there are actually three different recordings for three different files, and after studying them a little they need to be loaded in the following order:

FAST-RELO: This is a BASIC program that loads the other two files and performs the relocation.
FAST-RESERVE: This is a reserve program that provides the key mappings to call the save/load routines.
FAST-LOAD: This is the machine language program that implements the save/load routines.

Understanding how all three parts operate will require a bit of knowledge of the PC-1500 and how memory is arranged.

PC-1500 memory layout for reserve program, machine language program and BASIC program

A reserve program occupies the first 197 bytes of RAM. This program can redefine the six keys positioned directly under the display to type in a sequence of characters when pressed. Three separate groups of key mappings are provided (the current group is indicated by the presence of an I, II or III icon on the display) which can be cycled through by pressing the select key. A string can also be stored for each group to act as a reminder of which key does what, and this can be displayed by pressing the RCL key. In the case of Fast Load, the reserve program sets up four keys (two in reserve group II, two in reserve group III) to execute the program/variable save/load routines which it does by typing in CALL <address> and pressing the Enter key. The appropriate routine address for each key is patched into the reserve program by the FAST-RELO BASIC program.

The routines themselves need to be loaded somewhere into memory. By default, the current BASIC program starts in memory immediately after the reserve program's fixed 197 bytes at the bottom of memory, however it is possible to move the start of the BASIC program by passing a numeric parameter to NEW. The numeric parameter defines the start of the BASIC program in memory, but it will not allow you to move it below the end of the reserve program and so a good way to reset the BASIC memory to its largest default is with NEW 0 – a command that you are prompted to enter whenever the device has been reset or a memory expansion module has been changed.

By moving the start of the BASIC program to a higher address in memory it leaves a gap between the end of the reserve program area and the BASIC program that is free for us to load persistent machine language programs.

Note that memory does not necessarily start at address 0, either! In its base configuration RAM starts at &4000, with a CE-155 (8KB) RAM expansion module RAM starts at &3800 and with a CE-161 (16KB) RAM expansion module RAM starts at &0000. Fortunately you can read the most significant byte of the RAM start address from address &7863, which makes it a bit easier to calculate sensible values to load to.

Loading Fast Load into memory using its loader

For simplicity, if we assume we're only going to load Fast Load (and don't need to worry about reserving any additional RAM) then the process should be:

Move the start of the BASIC program up to start of RAM + 197 bytes for the reserve program + 540 bytes for Fast Load.
Use CLOAD to load the FAST-RELO BASIC program.
RUN the BASIC program, it should start trying to load the next part.
Play FAST-RESERVE to load the reserve program into memory.
Once this has loaded the computer will beep and prompt @: to ask where to load Fast Load to.
Enter the start of RAM + 197 bytes for the reserve program, then when it starts loading again play FAST-LOAD.

As mentioned before, the most significant byte of the start of memory can be retrieved from &7863, and so the process would look like this on the computer's screen (using values from the readme included with Fast Load):

NEW PEEK &7863*256+736
CLOAD
RUN
@:PEEK &7863*256+197

Unfortunately, this didn't work; attempting to save seemed to do something sensible, but loads didn't work and after that everything seemed to completely haywire – garbled memory, weird crashes and lockups. What's wrong?

Off by one!

I earlier mentioned that the reserve program is 197 bytes and Fast Load is 540 bytes, so we need to set the start of the BASIC program to 197+540 bytes from the start of memory. 197+540 is 737, however the figure given in the readme is 736. This is one byte too short, and as a result the BASIC program ends up overwriting the last byte of the Fast Load routines. This is a RTN instruction and as a result is fairly important, as without it a subroutine will not return and instead end up executing whatever instructions the start of the BASIC program has put there instead. Not good! Fortunately, it's a very simple fix – just move the start of the BASIC program to the correct position (NEW PEEK &7863*256+737).

It's only a phase…

Once everything is loaded in again (and at the correct location) the routines should now work. I loaded the Globe application using a conventional CLOAD and then used Fast Load to save the program back to my PC. This only took around 30 seconds, roughly fourteen times faster than the native routines! Very impressive, but only useful if the programs could then be loaded back onto the computer. Unfortunately, attempting to load the program back didn't work – the recording would finish playing but the computer was still stuck in its "Busy" state. On a hunch, I tried inverting the wave in the recording software, as I know from previous experience that cassette recorders tend to invert the phase between recording and playback. Doing that did the trick, and I could load back a program in 30 seconds that previously took seven minutes. Brilliant!

Unfortunately, Fast Load does seem to be fairly bare-bones. I haven't been able to find a verification routine similar to the native CLOAD ?, which compares the data on tape to the data in memory to allow you to verify that it was saved correctly, for example. Similarly I've only been able to find routines that save/load from the BASIC program area or the variable area, there doesn't seem to be a user-accessible way to save or load an arbitrary block of data based on its start and end addresses which would be required to save or load machine language programs. It doesn't even support filenames or file types to differentiate between programs and variable data! I have dug through a dissassembly of the Fast Load routines but couldn't spot anything, and the routines that are there do seem to go one byte beyond where they should to include a terminator byte as well. It's entirely possible that I missed something, but I'm still very happy about the speed improvements so don't mind the other limitations too much.

Digging into the protocol

Of course, once I'd got this working I wanted to dig into the cassette protocol used by Fast Load. Fortunately, it's very straightforward! There are two bit states, with the phase being 0°:

A "0" (zero) bit is represented by one cycle of a 2500Hz tone.
A "1" (one) bit is represented by two cycles of a 5000Hz tone.

Each byte is sent as follows:

A "0" (zero) start bit.
Eight data bits, least significant bit first.
A "1" (one) stop bit.

There are two "1" bits between each byte, and the transfer starts with 3 seconds of 5000Hz pilot tone. The data format within the transfer is:

Two byte data size (MSB first).
Data bytes (including &FF program terminator).
Three byte checksum (MSB first).

The checksum is calculated by adding up all of the bytes in the data section (including the &FF terminator).

All of this puts the "4000 baud" claim somewhat in question. Each bit takes the same amount of time – two 5000Hz cycles take as much time as one 2500Hz cycle, so the bit rate would appear to be 2500 baud, not 4000. In our "Globe" example, a 5697 byte program is saved in around 30 seconds. 5697 bytes becomes 5703 when we add the two bytes for the size prefix, the one byte terminator and three byte checksum. Each transmitted byte takes up eight bits for the data bits, two bits for the start and stop and two bits between each byte, so that comes to 5703×12=68436 bits in total. Divided by our 2500 baud rate gives us 27.37 seconds, plus the three seconds for the pilot tone comes to 30.37 seconds, matching our recording – so I think it's fair to say the baud rate is 2500.

Buiding some tools to work with recordings

There is a suite of tools called Pocket Tools that allows you to work with recordings of programs in the native PC-1500 format. You can extract binary data from a wave file recorded from the PC-1500, or detokenise a text BASIC program listing from one, or convert binary data or a text BASIC program listing into a wave file that can be played into the PC-1500. I've written a pair of tools, fwav2bin and fbin2wav, that perform a similar function for Fast Tools. These programs only implement saving and loading raw binary data – if you want to convert to or from BASIC program listings you'll need to first convert to or from a binary image (e.g. using Pocket Tools or lhTools).

Overall I've been very impressed with the speed boost you can achieve with Fast Load, once I managed to get it working.

Building your own analogue sensors for the SmartBox

Fri, 29 Nov 2024 13:53:19 +0000

This is an extremely belated followup to a post from November last year, though one of the reasons for the delay was repeatedly being sent the wrong electronic components which ultimately led to the post from December. I'll try to explain as best I can...

Towards the end of last year I bought myself a SmartBox, a computer control system that's based around a 65C02 CPU and that runs programs written in an interpreted BASIC-like programming language, with software uploaded via a computer's serial connection (and once the programs are loaded onto the box, the serial connection can be severed and the program will continue to run). In the previous journal entry I focussed more on the software side, though to get practical use out of the box I had experimented with some of the hardware too and had built some analogue sensors that I was hoping to write up for the benefit of anyone else who'd acquired a SmartBox but none of the sensors to go with it.

Two home-made User Adaptors and two home-made temperature sensors.

The four analogue sensor ports on the side of the SmartBox use 5-pin DIN sockets (180° to differentiate them from the 240° 5-pin DIN socket used for the serial port). Each sensor port can measure an analogue value with an 8-bit resolution (between 0 and 255) with the maximum voltage refererence being set to 2.55V – that is, each unit in the 0–255 range reported by the sensor corresponds to 1/100V (10mV), so if you connected a 1.5V source to the sensor port you'd see a value of 150 returned.

Sensors were made that measured specific physical properties (such as light level, humidity, temperature, or sound level) as well as generic "User Adaptor" boxes that allowed users to connect their own sensors:

The SmartBox "User Adaptor" pictured in a brochure.

One other nice trick that the analogue sensors had was that they could report which type of sensor they were directly to the SmartBox, so when you plugged in a temperature probe (for example) it would know that it was measuring temperature on that sensor port. The way this was implemented is via a "sense signal" output pin from the SmartBox to the sensor. In normal operation it was low, and the voltage read on the analogue sense input pin was used as the sensor's current value. Once a second or so the SmartBox would drive this pin high, and the voltage read on the analogue sense input pin was used to determine the type of sensor.

There are 32 possible sensor IDs. The ADC reading mentioned in the table below is the minimum value that will cause the Smart Move software to identify a particular sensor, for example a humidity sensor can be identified with an ADC reading between 157 and 164:

ADC	Smart Move 1.16	Smart Move 1.18
0	No sensor	No sensor
5	mT
13	mm	Temp
21	No sensor	No sensor
29	No sensor	No sensor
37	Temp	Volts
45	Temp	Temp
53	mA	Volts
61	Sound	Temp
69	Sound	Sound
77	Sound	PH
85	Pulse
93	Position	Position
101
109
117
125	Light	Light
133
141
149
157	Humidity	Humidity
165		Sound
173		Light
181	Pressure	Sound
189
197	PH	Atmos
205		Light
213		User
221	Adaptor	Adaptor
229	Lux	Temp
237	Volts	LGate
245	Wind
253	Temp	Temp

Note that Smart Move 1.16 and Smart Move 1.18 have some different names for some sensors. If a space is left blank in the table then the sensor is treated as present but is labelled "SENSORA" to "SENSORD" instead of being renamed according to the sensor type.

An analogue multiplexer (such as a 4053 IC) can be used as the basis for an analogue sensor for the SmartBox, sending either the voltage to measure or a reference voltage set with a preset potentiometer to identify the sensor type. The "sense signal" output from the SmartBox chooses which of the two voltages to return:

When the adaptor is connected to the SmartBox the potentiometer RV1 can be adjusted to choose the sensor type. As this is only checked once per second it can be a little fiddly to dial in the specific value you want — temporarily bridging A0 and A1 on the 4053 (so that RV1 is used as both sensor type and input value) and watching the reported sensor value can make life easier (making sure any sensor is disconnected from the input socket, of course).

The internal components of the home-made User Adaptor.

Whilst this is a useful circuit for building custom sensors, or making a replica of the generic User Adaptor (my DIY effort pictured above) there is a simpler option that can be used for temperature sensors. The original temperature sensor doesn't seem to have very much circuitry of its own, being just a simple probe with a DIN socket on the end of a wire:

The SmartBox "Temperature Sensor" pictured in a brochure.

The temperature sensor provides a reading in Celsius directly in the software, e.g. a temperature of 25°C is reported with a value of 25. This corresponds to a 10mV/°C sensor, and an example of such a sensor is the LM35. One limitation of the LM35 is that without a negative supply voltage pulling down its output it reports a minimum temperature of 2°C, yet the brochure snippet shown above reports a range of 0°C to 100°C. However, reading the manual for the SmartBox it mentions that the Smart Sense temperature sensor measures temperatures between 2°C and 100°C which seems to further indicate that it is indeed something like the LM35.

We could therefore just connect an LM35 to the User Adaptor circuit shown above and that would work, however there is a simpler circuit. If you consult the table of sensor types at the start of this post you'll notice that the temperature sensor appears at the bottom of the table with the highest sensor value. This means that to be identified as a temperature sensor, the sensor must output at least 2.53V when the "sense" pin goes high. A crude way to implement this is to connect a diode from the sense output pin back to the analogue input pin:

When the sense pin is low the voltage at "input" will be higher than the voltage at "sense" so the diode will not conduct and not influence the output of the temperature sensor. When the sense pin is high, however, the voltage at "sense" will be higher than the voltage at "input" and so the diode will conduct and raise the voltage at "input" to above 2.53V, indicating that the connected sensor is a temperature sensor.

The internal components of the home-made temperature sensor.

According to the documentation for the SmartBox the inputs are protected against overvoltage so I believe this is a safe circuit to use, however as with the User Adaptor all circuits here are based on some rough guesses as to how the devices would have originally worked as I don't have any real sensors to test with myself. In any case, these sensors work for me as I've not been able to source any of the original parts, so maybe if you like me have an old SmartBox knocking around these may help you get some more use out of it.

Resampling Sharp PC-1500 tape recordings

Wed, 16 Oct 2024 02:24:28 +0100

This is a quick post about problems I'd been having loading tape cassette recordings from my PC to a Sharp PC-1500 Pocket Computer along with a potential solution for anyone having similar issues.

Sharp PC-1500 Pocket Computer connected to the CE-150 Printer and Cassette Interface

The Sharp PC-1500 is a small computer from the early 1980s that can run programs primarily written in BASIC. Programs can be saved to and loaded back from cassette tape but to do this requires it to be connected to the CE-150, a cassette interface that also includes a four-colour plotter. It's the plotter that really attracted me to the computer in the first place, but being able to load programs from cassette rather than having to type them in by hand is definitely a very handy feature!

Unfortunately this CE-150 interface contains an internal battery pack of five Ni-Cd cells. A certain amount of battery leakage is a risk in any old piece of electronics hardware, but having said battery pack soldered directly in with no easy way for the user to remove it for long-term storage makes it more of a certainty than a risk. My CE-150 had not escaped, with heavy corrosion visible on the metal plate under the computer…

The inside of the PC-1500 was a bit better and not quite as musty-smelling, but circuit board traces had definitely been eaten away in places and some of the internal metal structure was looking a bit crusty.

I cleaned up the rusty metal using some appliance descaler (and recorded a video of the process, which can be found on YouTube) then got to work with a scalpel and some fine enamelled copper wire to repair the damaged traces.

Thankfully when I put it all back together again I was greeted by the NEW0? :CHECK prompt, so I connected the computer to the CE-150 and confirmed I could save and load back programs using my PC in place of a cassette recorder. Hooray!

When looking to see what other people had managed to achieve with the computer I found the Sharp PC-1500 (TRS-80 PC-2) resource page which hosts several games and applications which can be downloaded in WAV format. I downloaded a few, but when playing them back on my PC the PC-1500 would refuse to load them. It could load from my own recordings, why not these?

The odd thing is that my own recordings started with a few seconds of constant pilot tone followed by the varying pulses of the program data I was trying to load. When playing back the downloaded recordings they'd start with silence and only make sound when they got to the actual data – and that data sounded quite unlike what my own recordings sounded like. What was going on? I opened a recording in Audacity to see what it looked like, and zoomed in:

That looks like the pilot tone, in that it alternates between high and low at a fixed frequency, though it's only one sample high then one sample low so is a square wave rather than the smooth sine wave I was expecting. The cassette format uses frequency-shift keying so I would expect to see data further on in the recording at half the frequency, or twice the period, i.e. two samples high and then two samples low. Scrolling along, I certainly find that:

Why does it look so spiky, though? It would only need to look like that if it had been sampled at an extremely low rate, and indeed that's what I found – these files are recorded at a 5kHz sample rate:

5kHz is a pretty unusual (and very low!) sample rate that I suspected my sound card was not handling particularly gracefully. Typically audio would need to be resampled to 44.1kHz or 48kHz before playing back, so I thought I'd try resampling in Audacity. This produced this weirdness:

Instead of a sine wave that alternates between two frequencies, I ended up with something more akin to an amplitude-modulated signal! The high-frequency pilot also disappears entirely, apart from what looks to be some initial ringing:

Now, this is a complete guess, but I suspect that what is happening is an attempt to reduce unpleasant harmonics in the resampled audio. A square wave (such as the one we're resampling) produces a lot of harmonics at higher frequencies. As the original audio was sampled at 5kHz, the highest frequency that this could represent was 2.5kHz (alternating high and low each sample, as per the pilot tone). A low-pass filter at 2.5kHz could therefore reduce the harmonics, though I'd still expect some of it to get through (rather than it being apparently being attenuated to zero in this case!) In any case, the signal is being destroyed by the resampling process, so it's no wonder the computer can't load the data.

So, what's the solution? A simpler resampling algorithm that just duplicates samples (a sort of "nearest neighbour") should give us an acceptable square wave when processing, however I could not find any way to achieve this natively in Audacity. Fortunately, though, there's a Nyquist Plugin script that can be used to repeat all samples (install via Tools→Nyquish Plugin Installer, then check it's listed in Tools→Plugin Manager – it will appear as Effect→Repeat Samples). As we want to end up around 44.1kHz the plugin can be used to repeat each sample eight times, which would take our 5kHz sample rate to 40kHz:

↓

When played back the pilot tone can finally be heard, but it's at much too low a pitch! This is because the samples have been repeated eight times, but the track's sample rate hasn't been increased to match. This can be done by right-clicking the track and selecting Rate→Other and entering 40kHz:

Now when the clip is played back it sounds as it should. As a further experiment, the sample rate could be changed from its somewhat odd 40kHz to a more conventional 44.1kHz via Tracks→Resample. When this is done, the nice clean square wave loses definition again:

As I mentioned earlier, square waves have a lot of harmonics, and the resampling process makes these harmonics extremely visible riding on top and bottom of each cycle of the square wave. There is one way to clean this up quite nicely, however – as we want to cull high-frequency harmonics, and as the original recording could only represent frequencies up to 2.5kHz we can apply a low-pass filter at 2.5kHz from the Effects menu:

↓

This resulting file sounds much better and loads into the computer as it should. It's a bit of a convoluted process, but it does at least bypass the resampling weirdness that distorts the original files in such a way that they can't be loaded. The only additional step I might recommend is to more neatly balance the signal around zero by normalising it as the first step:

In summary, the steps are as follows:

Normalise the file (Effect→Normalize)
Repeat all samples by 8× (Effect→Repeat Samples)
Set track sample rate to 8× what it was (right-click, Rate→Other, multiply the value by 8)
Resample to 44.1kHz (Tracks→Resample)
Low-pass filter at 2.5kHz (Effect→Low-Pass Filter)

Happy tape loading!

1-Wire interfacing with the Cambridge Z88

Sun, 17 Dec 2023 02:11:33 +0000

I've been having a tricky time buying LM35DZ analogue temperature sensors for a project recently. One pair of probes and a bag of loose components labelled LM35DZ turned out to be regular NPN transistors with a fake label on them, and another pair of probes ended up being DS18B20 digital temperature sensors.

Whilst the DS18B20 temperature sensors were useless for the project I had in mind they were still functioning components. These use the 1-Wire serial bus, a bus named for the way that its single data line can also be used to parasitically power the devices on the bus. Electrically the bus is open drain with a pull-up resistor that idles in the high state which any device can drive low. The master initiates all communication and you can have multiple peripheral devices connected to the bus in an arrangement called a MicroLAN.

A selection of 1-Wire devices and a 1-Wire interface adaptor plugged into a Z88 computer

I'd had some limited experience working with the 1-Wire bus as part of my version of the Superprobe but now that I had a collection of temperature sensors I thought it might be worth revisiting, this time on the Cambridge Z88.

1-Wire adaptor for the Z88 serial port

To connect 1-Wire devices to the Z88 some sort of adaptor is required and one that plugged into the computer's serial port seemed like a sensible enough option. The Z88's serial port hardware normally handles all the communications for you however it is possible to directly control the logic levels of the serial port's output pins and read back the status of the input pins via some hardware registers.

The TXD line can be +5V for a logic 0 and -6V for a logic 1, adhering to the RS-232 standard. When idle TXD is in its logic 1 state, outputting -6V. Bit ITX (3) in the TXC (&E4) register can be used to invert the behaviour of the TXD pin, so by setting this bit we can change the state of the pin from -6V to +5V.

As we need to have an open-drain bus we can use an NPN transistor with the base connected to the TXD line via a current-limiting resistor, the emitter connected to ground and the collector driving the 1-Wire bus. By default the TXD pin will output -6V, the transistor will be switched off and the bus will be pulled high. When the TXD pin state is inverted it will output +5V, the transistor will switch on and drive the line low.

The state of the RXD line can be read directly via bit RXD (4) in the RXE (&E1) register. The lines appear to be weakly held to 0V and read back a 0 bit in this state, flipping to a 1 bit when the voltage rises above around 2V. In this case we can connect the 1-Wire bus directly to the RXD input and be able to read back the current state.

The circuit for the adaptor, including the 4.7K pull-up resistor, appears as follows:

This can be tested in a BASIC program. To determine the input state we can read from the RXE port register (&E1) and check the state of the RXD bit (4):

10 RXE=&E1:M_RXERXD=&10
20 REPEAT
30   PRINT ~(GET(RXE) AND M_RXERXD)
40 UNTIL FALSE

The mask value M_RXERXD is specified as 2⁴=&10 to correspond to the bit four. When run this program displays &10 in hex (showing bit 4 is set and the bus level is therefore high) until the 1-Wire bus line is connected to ground, when the value changes to 0 (showing bit 4 is reset and the bus level is therefore low).

To change the output state we need to write to bit ITX (3) of the TXC register (&E4). However, when writing to the hardware port we only want to change that bit and leave the others alone. The TXC register is a write-only port, so we can't retrieve its previous state by reading from the port. Fortunately the OS maintains a copy of the last value written as a "soft copy" in RAM at address &04E4 and this can be read with the ? indirection operator:

10 TXC=&E4:M_TXCITX=&08
20 SC=&400
30 TXC_OLD=SC?TXC
40 PUT TXC,TXC_OLD OR M_TXCITX
50 IF INKEY(100)
60 PUT TXC,TXC_OLD

The above program reads the old state of the TXC port from the soft copy, ORs it with the mask of the ITX bit (2³=&08) and then outputs that to the TXC port. This has the effect of inverting the TXD line, driving the 1-Wire bus low. The program then waits one second with a dummy keyboard read before restoring the old value of the TXC port to release the 1-Wire bus.

Normally if changing the state of the serial port it would be good manners to update the soft copy of the serial port state however as the program is just going to be sending short low pulses before returning the port to its previous state this step is omitted.

After testing that the circuit worked on a breadboard a more permanent version was assembled in a DE-9 shell as above. As the clips that hold in the DE-9 connector had to cut off to allow it to fit in the Z88's recessed port the circuit ended up being secured with copious amounts of hot glue, which is far from ideal, but nobody will see when it's all screwed back together.

Bit-level protocol

Now that we can electrically control the bus we need to know how to transfer data on it. This is done by timed pulses, where the bus master will hold the bus line low for a certain amount of time, release it, then check to see if any devices on the bus are holding it low in return. This is summarised in the following timing diagram from Microchip's AN1199, 1-Wire Communication with PIC Microcontroller:

The first thing that needs to be done is to reset all devices on the bus. This is done by holding the bus low for 480μs then releasing it for at least 480μs. If any peripheral devices are present on the bus they will drive the line low after the low pulse from the master, so the full reset procedure is as follows:

Master drives bus low
Delay 480μs
Master releases bus high
Delay 70μs
Sample bus state: if high, no peripheral devices present, if low at least one device present.
Delay 410μs

Once reset, data can be transmitted from the master to peripheral devices bit-by-bit in a similar fashion to the reset pulse, albeit with different timing.

To send a 0 bit:

Master drives bus low
Delay 60μs
Master releases bus high
Delay 10μs

To send a 1 bit:

Master drives bus low
Delay 6μs
Master releases bus high
Delay 64μs

Bytes are transferred as eight individual bits, least-significant bit first. The protocol is also tolerant of large delays between individual bits.

Once data has been sent to a peripheral, it may respond with data of its own. The master is still in control of clocking the data out of the peripheral, and the process is as follows:

Master drives bus low
Delay 6μs
Master releases bus high
Delay 9μs
Sample bus state to read data bit from peripheral
Delay 55μs

The overall timing for reading a bit is the same as the timing for sending a 1 bit (an initial 6μs low pulse from the master and a total bit time of 70μs) so in practice only one routine needs to be implemented and the value returned from the bus during read operations can be ignored during write operations.

Software choice for the Z88

I thought it would be nice to be able to interact with 1-Wire devices from a BASIC program. BBC BASIC on the Z88 does provide direct access to the hardware and would make controlling the 1-Wire bus line possible, as demonstrated earlier, however I don't think it would provide the timing accuracy required to produce the appropriate pulses from the master. Fortunately it does include a Z80 assembler and so a mixture of a BASIC program that provides the high-level routines and assembly snippets for the low-level 1-Wire protocol implementation seemed like an appropriate mix of languages.

When you CALL an assembly routine from BASIC the Z80's registers are initialised to the values of the corresponding static variables, for example A is set to A%, H to H%, L to L% etc. You can't return a value directly – for that you'd need USR – however it's a bit easier to just store the return value in memory and retrieve that from BASIC after the CALL returns.

A rough starting point for the 1-Wire program is as follows:

 10 REM 1-WIRE DEMO
 20 PROC_1W_INIT
 30 PRINT FN_1W_RESET
 40 END
 50 :
 60 REM 1-WIRE ROUTINES
 70 END
 80 DEFPROC_1W_INIT
 90 ow_code_size=256:DIM ow_code ow_code_size-1
100 RXE=&E1:M_RXERXD=&10
110 TXC=&E4:M_TXCITX=&08
120 SC=&400
130 FOR opt=0 TO 2 STEP 2
140   P%=ow_code
150   [OPT opt
160   .ow_buf DEFB 0 \ temporary transfer buffer
170   :
180   .ow_reset
190   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:SBC A,A:LD (ow_buf),A:RET NZ \ check bus is idle
200   DI:LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
210   LD B,120:DJNZ P% \ delay
220   AND NOT M_TXCITX:OUT (TXC),A \ release bus
230   LD B,18:DJNZ P% \ delay
240   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:CCF:SBC A,A:LD (ow_buf),A \ sample presence
250   LD B,100:DJNZ P% \ delay
260   EI:RET
270   :
280   ]
290 NEXT
300 ENDPROC
310 :
320 REM Resets bus, retuns TRUE if any devices are present
330 DEFFN_1W_RESET:CALL ow_reset:=?ow_buf=0

The first few lines are going to be where our BASIC program is. This calls the procedure PROC_1W_INIT which will set things up by assembling any required Z80 code. It then calls FN_1W_RESET which is a function that resets the 1-Wire bus and checks to see if any devices assert their presence.

PROC_1W_INIT starts by allocating some memory for the assembled code to live, defines some constants for the IO ports and then runs through the two passes of the assembly process in a loop. Within the assembly block is a variable (ow_buf) which will be used to store data due to be returned by the assembly routines. The ow_reset assembly routine then follows – this first checks to see if the bus is idle (floating high) and if so it disables interrupts, holds the bus low for 480μs, releases the bus and waits 70μs, samples the state of the bus to check for device presence (storing the result in ow_buf), then delays another 410μs.

The delay loops are simple DJNZ loops with B corresponding to the length of the delay and the timings were roughly calculated first based on the number of cycles each loop would take and the Z88's 3.2768MHz CPU clock speed. They were then adjusted slightly using a logic analyser to ensure the timing was as close as could be managed to the 1-Wire protocol's specifications.

The ow_reset routine has been written so that following a successful presence check ow_buf should contain 0, and if there is a problem it will contain a non-zero value. This is used by the FN_1W_RESET wrapper function which just calls ow_reset and returns TRUE if ow_buf is zero afterwards.

If you run the program you should see that the program will display 0 (FALSE) on the screen until a 1-Wire device is connected to the adaptor, at which point it will display -1 (TRUE) instead to indicate the device's presence. This isn't a very useful program, but shows how BASIC and assembly will be mixed to build the rest of the 1-Wire routines.

Sending and receiving bits and bytes

Now that we know a device is present on the bus after a reset we need to be able to send and receive bits and bytes. Sending a 0 bit is a bit simpler than resetting, as we don't need to check for any response – just hold the line low for 60μs then release it back high for 10μs. This can be implemented as follows:

.ow_put_0
DI
LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
LD B,15:DJNZ P% \ delay
AND NOT M_TXCITX:OUT (TXC),A \ release bus
NOP \ delay
EI:RET

Sending a 1 bit has the same overall timing as reading a bit, so instead of writing separate routines to send a 1 bit and read a bit just one routine is required that handles both situations:

.ow_put_1
DI
LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
NOP \ delay
AND NOT M_TXCITX:OUT (TXC),A \ release bus
PUSH HL:POP HL \ delay
IN A,(RXE):AND M_RXERXD:SUB M_RXERXD:CCF \ sample bit
LD A,(ow_buf):RRA:LD (ow_buf),A \ store bit
LD B,7:DJNZ P% \ delay
EI:RET

This holds the bus low for 6μs, releases it and waits 9μs, samples a bit from the bus and rotates it into the ow_buf transfer buffer, then waits 55μs.

These routines could be wrapped up for use in BASIC but it's not too useful to be able to send or receive single bits, normally we'd need to transfer whole 8-bit bytes. The ow_put_1 routine already handles updating the ow_buf with each received bit, so a byte receiving routine can be put together by just calling ow_put_1 eight times in a loop:

.ow_get_byte
LD B,8 \ 8 bits to receive
.ow_get_loop
PUSH BC:CALL ow_put_1:POP BC \ receive single bit
DJNZ ow_get_loop \ loop
LD A,(ow_buf):RET \ store

A send routine can be put together with a similar loop that shifts out the bit to send and then calls either the ow_put_0 or ow_put_1 routine depending on whether it's a 0 or 1 bit that's required. Bits will usually be shifted out into the carry register, so a new ow_put_carry routine that sends the bit stored in the carry flag makes this a bit easier, e.g.

.ow_put_carry
JR C,ow_put_1
JR ow_put_0

...which will be called by the ow_put_byte routine, as follows:

.ow_put_byte
LD C,A:LD B,8 \ value to send in C, send 8 bits
.ow_put_loop
SRL C:PUSH BC:CALL ow_put_carry:POP BC \ shift and send single bit
DJNZ ow_put_loop \ loop
RET

It is also quite useful to be able to send or receive blocks of data at once – for example, sending or receiving the 64-bit device IDs requires sending or receiving 8 bytes of data at a time. To complement ow_get_byte and ow_put_byte we can write ow_get_bytes and ow_put_bytes routines to send or receive the block of data addressed by HL, length BC:

.ow_get_bytes
LD A,B:OR C:RET Z:DEC BC \ have we finished?
PUSH BC:CALL ow_get_byte:POP BC \ get a byte
LD (HL),A:INC HL:JR ow_get_bytes \ store and loop
:
.ow_put_bytes
LD A,B:OR C:RET Z:DEC BC \ have we finished?
LD A,(HL):INC HL \ fetch
PUSH BC:CALL ow_put_byte:POP BC:JR ow_put_bytes \ send and loop

All of these can now be wrapped up as procedures or functions so they can be more easily used from a BASIC program:

REM Transmits a single byte
DEFPROC_1W_PUT(A%)CALL ow_put_byte:ENDPROC
REM Transmits a block of bytes
DEFPROC_1W_PUTS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_put_bytes:ENDPROC
REM Receives a single byte
DEFFN_1W_GET:CALL ow_get_byte:=?ow_buf
REM Receives a block of bytes
DEFPROC_1W_GETS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_get_bytes:ENDPROC

BASIC's integer variables are 32-bit integers so when passing the 16-bit address or length parameters the target register is the least-significant one (L for HL, C for BC) and the most-significant register (H or B) is populated by dividing the value by 256.

This can all be put together in the following demonstration program. It initialises the routines, resets the bus and checks for presence, then sends the "read ROM" command &33 which will make any connected devices respond with their ROM ID. It then reads back the eight bytes corresponding to the device ID then prints them back in hexadecimal.

 10 DIM ID 7:REM Storage for device ID
 20 PROC_1W_INIT
 30 IF FN_1W_RESET=FALSE PRINT "No devices found.":END
 40 PROC_1W_PUT(&33):REM "Read ROM" command
 50 PROC_1W_GETS(ID,8):REM Read eight bytes of device ID
 60 FOR I=7 TO 0 STEP -1:PRINT ~ID?I;:NEXT:PRINT:REM Print device ID bytes
 70 END
 80 :
 90 REM 1-WIRE ROUTINES
100 END
110 DEFPROC_1W_INIT
120 ow_code_size=256:DIM ow_code ow_code_size-1
130 RXE=&E1:M_RXERXD=&10
140 TXC=&E4:M_TXCITX=&08
150 SC=&400
160 FOR opt=0 TO 2 STEP 2
170   P%=ow_code
180   [OPT opt
190   .ow_buf DEFB 0 \ temporary transfer buffer
200   :
210   .ow_reset
220   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:SBC A,A:LD (ow_buf),A:RET NZ \ check bus is idle
230   DI:LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
240   LD B,120:DJNZ P% \ delay
250   AND NOT M_TXCITX:OUT (TXC),A \ release bus
260   LD B,18:DJNZ P% \ delay
270   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:CCF:SBC A,A:LD (ow_buf),A \ sample presence
280   LD B,100:DJNZ P% \ delay
290   EI:RET
300   :
310   .ow_put_carry
320   JR C,ow_put_1 \ fall-through
330   :
340   .ow_put_0
350   DI
360   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
370   LD B,15:DJNZ P% \ delay
380   AND NOT M_TXCITX:OUT (TXC),A \ release bus
390   NOP \ delay
400   EI:RET
410   :
420   .ow_put_1
430   DI
440   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
450   NOP \ delay
460   AND NOT M_TXCITX:OUT (TXC),A \ release bus
470   PUSH HL:POP HL \ delay
480   IN A,(RXE):AND M_RXERXD:SUB M_RXERXD:CCF \ sample bit
490   LD A,(ow_buf):RRA:LD (ow_buf),A \ store bit
500   LD B,7:DJNZ P% \ delay
510   EI:RET
520   :
530   .ow_put_byte
540   LD C,A:LD B,8 \ value to send in C, send 8 bits
550   .ow_put_loop
560   SRL C:PUSH BC:CALL ow_put_carry:POP BC \ shift and send single bit
570   DJNZ ow_put_loop \ loop
580   RET
590   :
600   .ow_put_bytes
610   LD A,B:OR C:RET Z:DEC BC \ have we finished?
620   LD A,(HL):INC HL \ fetch
630   PUSH BC:CALL ow_put_byte:POP BC:JR ow_put_bytes \ send and loop
640   :
650   .ow_get_byte
660   LD B,8 \ 8 bits to receive
670   .ow_get_loop
680   PUSH BC:CALL ow_put_1:POP BC \ receive single bit
690   DJNZ ow_get_loop \ loop
700   LD A,(ow_buf):RET \ store
710   :
720   .ow_get_bytes
730   LD A,B:OR C:RET Z:DEC BC \ have we finished?
740   PUSH BC:CALL ow_get_byte:POP BC \ get a byte
750   LD (HL),A:INC HL:JR ow_get_bytes \ store and loop
760   :
770   ]
780 NEXT
790 IF P%-ow_code>ow_code_size PRINT"Code size: "P%-ow_code:END
800 ENDPROC
810 :
820 REM Resets bus, retuns TRUE if any devices are present
830 DEFFN_1W_RESET:CALL ow_reset:=?ow_buf=0
840 REM Transmits a single byte
850 DEFPROC_1W_PUT(A%)CALL ow_put_byte:ENDPROC
860 REM Transmits a block of bytes
870 DEFPROC_1W_PUTS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_put_bytes:ENDPROC
880 REM Receives a single byte
890 DEFFN_1W_GET:CALL ow_get_byte:=?ow_buf
900 REM Receives a block of bytes
910 DEFPROC_1W_GETS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_get_bytes:ENDPROC

When connected to an iButton fob the program prints

  55   0   0   1  A0  1A  57   1

...which matches the ID printed on it.

An example of a TM1990A iButton fob (middle) along with the probe used to read it (top)

When connected to a DS18B20 temperature sensor the program prints

  B9   0   0   1  D1  97  5D  28

The least significant byte of the 64-bit ID is the family code – &01 for the iButton fob indicates it's a "silicon serial number" type device and &28 for the DS18B20 indicates it's a "programmable resolution digital thermometer".

The 1-Wire bus supports multiple peripheral devices connected to a single master. If we try that we still get something that looks like an ID back:

  11   0   0   1  80  12  55   0

This happens because it's an open-drain bus and any device holding the line low will take priority over any device releasing the line high. In effect the data read back is ANDed together, so the most-significant byte received is &55 AND &B9 which gives us the &11 we see. Fortunately that most-significant byte does give us a good opportunity to detect such invalid data!

Error detection with a CRC

Some data payloads include a CRC value. The most-significant byte of a 64-bit device ID is such a CRC, with the least-significant byte being the family code. The exact details for the CRC calculation can be found in the article Understanding and Using Cyclic Redundancy Checks with Maxim 1-Wire and iButton Products however for our purposes a Z80 implementation can be written as follows:

.ow_crc
LD B,8:LD DE,(ow_buf):LD D,A \ E = accumulated CRC, D = value to add
.ow_crc_loop
LD A,E:XOR D:SRL D:SRL A:JR C,ow_crc_odd \ XOR and shift bits
SRL E:DJNZ ow_crc_loop:LD A,E:LD (ow_buf),A:RET \ even CRC value
.ow_crc_odd:SRL E:LD A,&8C:XOR E:LD E,A:DJNZ ow_crc_loop:LD (ow_buf),A:RET \ odd CRC value
:
.ow_crc_block
XOR A:LD (ow_buf),A \ reset CRC
.ow_crc_block_loop
LD A,B:OR C:LD A,(ow_buf):RET Z:DEC BC \ have we finished?
LD A,(HL):INC HL:PUSH BC:CALL ow_crc:POP BC:JR ow_crc_block_loop \ update CRC

ow_crc updates the current calculated CRC value (stored in ow_buf) with the next data byte from the accumulator. ow_crc_block calculates the CRC for a block of data pointed to by HL, length BC, using the ow_crc routine. A couple of BASIC functions can then be written, one to calculate the CRC of a block of data and another to check that the last byte of the block corresponds to the CRC of the preceding data:

REM Calculates the CRC of a block of data
DEFFN_1W_CRC(L%,C%)LOCAL H%,B%:H%=L% DIV256:B%=C%DIV256:CALL ow_crc_block:=?ow_buf
REM Checks if a CRC at the end of a block of data matches
DEFFN_1W_CRC_CHECK(L%,C%)=FN_1W_CRC(L%,C%)=(L%?C%)

These two can now be used to check that a device ID is valid. The CRC is also appended to other data reports, such as reading the scratchpad memory of a temperature sensor, so it's a useful routine to have. A new program which checks the CRC is as follows:

 10 DIM ID 7
 20 PROC_1W_INIT
 30 REPEAT
 40   REPEAT UNTIL FN_1W_RESET:REM Wait for device to be present
 50   PROC_1W_PUT(&33):REM Read ROM
 60   PROC_1W_GETS(ID,8):REM Fetch ID
 70   IF FN_1W_CRC_CHECK(ID,7) VDU 7:PRINT "Detected ";FN_1W_ID$(ID);" at ";TIME$:REM Print if valid
 80   REPEAT UNTIL FN_1W_RESET=FALSE:REM Wait for device to be disconnected
 90 UNTIL FALSE
100 END
110 :
120 REM 1-WIRE ROUTINES
130 END
140 DEFPROC_1W_INIT
150 ow_code_size=256:DIM ow_code ow_code_size-1
160 RXE=&E1:M_RXERXD=&10
170 TXC=&E4:M_TXCITX=&08
180 SC=&400
190 FOR opt=0 TO 2 STEP 2
200   P%=ow_code
210   [OPT opt
220   .ow_buf DEFB 0 \ temporary transfer buffer
230   .ow_conf DEFB 0 \ stores last bit conflict index
240   :
250   .ow_reset
260   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:SBC A,A:LD (ow_buf),A:RET NZ \ check bus is idle
270   DI:LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
280   LD B,120:DJNZ P% \ delay
290   AND NOT M_TXCITX:OUT (TXC),A \ release bus
300   LD B,18:DJNZ P% \ delay
310   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:CCF:SBC A,A:LD (ow_buf),A \ sample presence
320   LD B,100:DJNZ P% \ delay
330   EI:RET
340   :
350   .ow_put_carry
360   JR C,ow_put_1 \ fall-through
370   :
380   .ow_put_0
390   DI
400   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
410   LD B,15:DJNZ P% \ delay
420   AND NOT M_TXCITX:OUT (TXC),A \ release bus
430   NOP \ delay
440   EI:RET
450   :
460   .ow_put_1
470   DI
480   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
490   NOP \ delay
500   AND NOT M_TXCITX:OUT (TXC),A \ release bus
510   PUSH HL:POP HL \ delay
520   IN A,(RXE):AND M_RXERXD:SUB M_RXERXD:CCF \ sample bit
530   LD A,(ow_buf):RRA:LD (ow_buf),A \ store bit
540   LD B,7:DJNZ P% \ delay
550   EI:RET
560   :
570   .ow_put_byte
580   LD C,A:LD B,8 \ value to send in C, send 8 bits
590   .ow_put_loop
600   SRL C:PUSH BC:CALL ow_put_carry:POP BC \ shift and send single bit
610   DJNZ ow_put_loop \ loop
620   RET
630   :
640   .ow_put_bytes
650   LD A,B:OR C:RET Z:DEC BC \ have we finished?
660   LD A,(HL):INC HL \ fetch
670   PUSH BC:CALL ow_put_byte:POP BC:JR ow_put_bytes \ send and loop
680   :
690   .ow_get_byte
700   LD B,8 \ 8 bits to receive
710   .ow_get_loop
720   PUSH BC:CALL ow_put_1:POP BC \ receive single bit
730   DJNZ ow_get_loop \ loop
740   LD A,(ow_buf):RET \ store
750   :
760   .ow_get_bytes
770   LD A,B:OR C:RET Z:DEC BC \ have we finished?
780   PUSH BC:CALL ow_get_byte:POP BC \ get a byte
790   LD (HL),A:INC HL:JR ow_get_bytes \ store and loop
800   :
810   .ow_crc
820   LD B,8:LD DE,(ow_buf):LD D,A \ E = accumulated CRC, D = value to add
830   .ow_crc_loop
840   LD A,E:XOR D:SRL D:SRL A:JR C,ow_crc_odd \ XOR and shift bits
850   SRL E:DJNZ ow_crc_loop:LD A,E:LD (ow_buf),A:RET \ even CRC value
860   .ow_crc_odd:SRL E:LD A,&8C:XOR E:LD E,A:DJNZ ow_crc_loop:LD (ow_buf),A:RET \ odd CRC value
870   :
880   .ow_crc_block
890   XOR A:LD (ow_buf),A \ reset CRC
900   .ow_crc_block_loop
910   LD A,B:OR C:LD A,(ow_buf):RET Z:DEC BC \ have we finished?
920   LD A,(HL):INC HL:PUSH BC:CALL ow_crc:POP BC:JR ow_crc_block_loop \ update CRC
930   ]
940 NEXT
950 IF P%-ow_code>ow_code_size PRINT"Code size: "P%-ow_code:END
960 ENDPROC
970 :
980 REM Resets bus, retuns TRUE if any devices are present
990 DEFFN_1W_RESET:CALL ow_reset:=?ow_buf=0
1000 REM Transmits a single byte
1010 DEFPROC_1W_PUT(A%)CALL ow_put_byte:ENDPROC
1020 REM Transmits a block of bytes
1030 DEFPROC_1W_PUTS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_put_bytes:ENDPROC
1040 REM Receives a single byte
1050 DEFFN_1W_GET:CALL ow_get_byte:=?ow_buf
1060 REM Receives a block of bytes
1070 DEFPROC_1W_GETS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_get_bytes:ENDPROC
1080 :
1090 REM Converts ID bytes into string
1100 DEFFN_1W_ID$(ID)LOCAL I%:S$="":FOR I%=7 TO 0 STEP -1:IF ID?I%>15:S$=S$+STR$~(ID?I%):NEXT:=S$:ELSE:S$=S$+"0"+STR$~(ID?I%):NEXT:=S$
1110 REM Converts string into ID bytes
1120 DEFPROC_1W_ID$(ID,ID$)LOCAL I%:FOR I%=0 TO 7:ID?I%=EVAL("&"+MID$(ID$,15-I%*2,2)):NEXT:ENDPROC
1130 :
1140 REM Calculates the CRC of a block of data
1150 DEFFN_1W_CRC(L%,C%)LOCAL H%,B%:H%=L% DIV256:B%=C%DIV256:CALL ow_crc_block:=?ow_buf
1160 REM Checks if a CRC at the end of a block of data matches
1170 DEFFN_1W_CRC_CHECK(L%,C%)=FN_1W_CRC(L%,C%)=(L%?C%)

The program waits for a device to be present, reads its ID, then prints it to the screen along with the date and time if its CRC is valid. It then waits for the device to be removed before looping around to check again. This allows you to tap iButtons to a reader and it will display the relevant ID, for example. It also adds a couple of utility routines – a function, FN_1W_ID$(ID), which turns a block of ID data bytes into a string and a procedure, PROC_1W_ID$(ID,ID$), which does the opposite.

Enumerating the 1-Wire bus

It's certainly useful to be able to detect a single device on the 1-Wire bus however it would be more useful to detect multiple devices and be able to address them individually. Checking every single possible 64-bit address for a response would take far too long, but fortunately there is a way to very quickly enumerate every peripheral device on the bus by means of a binary search.

Each socket is wired in parallel to allow multiple 1-Wire devices to be connected to the Z88

To start the search, the master sends either the normal search command &F0 or the alarm/conditional search command &EC. When using the conditional search only devices that are in some sort of alarm state will respond, allowing the master to more quickly identify the devices that need attention. As we're interested in all devices we'll use the normal search command &F0.

After issuing the search command all active devices on the bus will start to report their ID, bit by bit. Each device will send each bit twice, firstly in its normal state and then again in an inverted state. Due to the open-drain nature of the bus, this allows the master to detect conflicting bit values – if all active devices have a 0 in the current bit position then the bus will read 0 then 1, if all active devices have a 1 in the current bit position then the bus will read 1 then 0 but if there is a mixture of zeroes and ones then the bus will read 0 then 0.

After this the master sends a single bit that tells the active peripheral devices which bit it has identified. If this does not match the peripheral's current bit value then the peripheral will go into an idle state and stop responding until the bus is reset again, but if it does match then the device will continue to send bits of its ID. This allows the master to walk down both branches of the binary tree when searching for device IDs when it detects a conflict, by first selecting one bit value in one iteration of the search and then the other bit value in another iteration of the search.

The full procedure for enumerating the bus is more explicitly described in the app note 1-Wire Search Algorithm, and can be implemented with the following Z80 assembly code:

.ow_conf DEFB 0 \ stores last bit conflict index
:
.ow_search
LD DE,(ow_conf):LD D,0:LD C,1:LD B,64
.ow_search_loop
PUSH BC:CALL ow_put_1:CALL ow_put_1:POP BC:RLCA:RLCA \ get bit, !bit
AND 3:JR Z,ow_search_conf \ 00 = conflict
DEC A:JR Z,ow_search_1 \ 01 = 0 bit
DEC A:JR Z,ow_search_0 \ 10 =  1 bit
SCF:RET \ report failure
.ow_search_conf
LD A,B:CP E \ how does bit index compare to last conflict
JR C,ow_search_0_conf \ 0, update current discrepancy
JR Z,ow_search_1 \ 1, no update
LD A,(HL):AND C:JR NZ,ow_search_advance \ old bit = 1, just advance
LD D,B:JR ow_search_advance \ old bit = 0, update current discrepancy
.ow_search_1:LD A,C:OR (HL):LD (HL),A:JR ow_search_advance
.ow_search_0_conf:LD D,B \ fall-through
.ow_search_0:LD A,C:CPL:AND (HL):LD (HL),A \ fall-through
.ow_search_advance
LD A,(HL):AND C:SUB C:CCF:PUSH BC:CALL ow_put_carry:POP BC \ return the ID bit
RLC C:JR NC,P%+3:INC HL \ advance mask
DJNZ ow_search_loop
LD A,D:LD (ow_conf),A
XOR A:LD (ow_buf),A:RET \ report success

A pair of BASIC wrappers can make using this search routine a bit easier:

REM Starts enumerating devices on the bus
DEFPROC_1W_SEARCH_RESET:?ow_conf=TRUE:ENDPROC
REM Searches for next device on bus. Pass search type &F0 for all devices, &EC for alarming devices. Returns TRUE if next device found
DEFFN_1W_SEARCH(A%,ID)IF ?ow_conf=0:=FALSE ELSE IF FN_1W_RESET=0:=FALSE ELSE PROC_1W_PUT(A%):H%=ID DIV256:L%=ID:CALL ow_search:=?ow_buf=0

The "reset" routine just sets the last bit conflict index to -1 (TRUE=-1) and FN_1W_SEARCH will search based on the search type (&F0 for all devices, &EC for alarming devices only), the current ID and last conflict index and will return TRUE if an ID was found or FALSE if no more IDs were found.

A snippet of code that enumerates all devices on the bus and displays their IDs is as follows:

PROC_1W_SEARCH_RESET
REPEAT F%=FN_1W_SEARCH(&F0,ID):IF F% PRINT FN_1W_ID$(ID)
UNTIL F%=FALSE

Reading temperature sensors

So far the examples have been fairly uninteresting, but we now have enough support code to do something useful with devices on a 1-Wire network. The DS18B20 temperature sensors that inspired this whole project are probably the easiest way to show how useful the 1-Wire bus can be.

A DS18B20 temperature sensor in a TO-92 package and another in a cabled probe

The idea here will be to search for all temperature sensors on the network and to display their current temperature reading alongside their ID on the screen. The temperature conversion is initiated by sending the "Convert T" command (&44) to the desired 1-Wire devices and then waiting for at least 750ms with the bus inactive, allowing the parasitically-powered devices enough power to complete the temperature conversion, after which the temperature can be read back from the sensor's scratchpad memory.

Due to the large delay when waiting for the sensors to handle the "Convert T" command it is easiest to send the command to all devices on the network rather than to each one individually. This can be done by first sending the "Skip ROM" command (&CC) which allows the master to skip sending a 64-bit ID to the specific device it's addressing before sending the "Convert T" command (&44). The process to tell all devices to perform a temperature conversion is as follows:

IF FN_1W_RESET=FALSE PRINT "No devices found":END
REM Start temperature conversion
PROC_1W_PUT(&CC):REM Skip ROM
PROC_1W_PUT(&44):REM Convert T
T=TIME:IF INKEY(75)>TRUE REPEAT:UNTIL TIME>T+75:REM Delay 750ms

INKEY(75) is used to delay for 750ms however as this can be skipped by pressing a key a delay loop is provided as a safety measure.

After this, all of the devices on the network are enumerated as before:

REM Search for all temperature sensors on the bus and display their readings
PROC_1W_SEARCH_RESET
REPEAT F%=FN_1W_SEARCH(&F0,ID)
  IF F% PROC_1W_PRINT_TEMP(ID)
UNTIL F%=FALSE

PROC_1W_PRINT_TEMP should check to see whether the device ID corresponds to a temperature sensor (its family code, the least-significant byte, should be &28) and if so it should retrieve the temperature value and print it:

REM Print a single sensor's reading
DEFPROC_1W_PRINT_TEMP(ID)
LOCAL T
IF ID?0<>&28 ENDPROC:REM Must be a temperature sensor
T=FN_1W_READ_TEMP(ID):IF T=-999 ENDPROC:REM Read sensor and check for error
@%=&20409:PRINT MID$(FN_1W_ID$(ID),3,12);":",T;" deg C":@%=&90A
ENDPROC

@% controls the way numbers are printed – in this case it is changed to show four decimal places in a field width of 9 characters. When printing the device ID the first two characters and last two characters are stripped off as these correspond to the CRC and family code which are not particularly useful in this case.

FN_1W_READ_TEMP(ID) needs to fetch the temperature from the sensor with the specified ID or return -999 on error. A specific sensor can be addressed by first sending the match ROM command (&55) followed by the 64-bit device ID. After this the scratchpad RAM can be read by sending the "read scratchpad" command (&BE) then reading as many bytes as are required. We only need the first two, but will read nine as this includes all eight bytes of scratchpad RAM plus a CRC so we can verify the data is valid:

REM Retrieve a single sensor's reading
DEFFN_1W_READ_TEMP(ID)
LOCAL T
IF FN_1W_RESET=FALSE =-999
PROC_1W_PUT(&55):PROC_1W_PUTS(ID,8):REM Match ROM
PROC_1W_PUT(&BE):PROC_1W_GETS(SCRATCH,9):REM Read scratchpad
IF FN_1W_CRC_CHECK(SCRATCH,8)=FALSE =-999:REM Check CRC
=SCRATCH!-2DIV65536/16:REM Convert to degrees C

The final line converts the reading to °C. This is a signed 16-bit value stored in the first two bytes of the scratchpad memory. BBC BASIC's ! indirection operator reads a 32-bit value, so by reading from two bytes earlier (-2) the 16-bit temperature value is loaded into the most significant word of a 32-bit integer, and an integer divide of this by 65536 shifts this back down into the least significant word (where it should be) with the sign properly extended (so if it was a negative value before it will still be negative after the division). The value is then divided by 16 using a regular floating-point division as each unit of the temperature sensor's reported value corresponds to 1/16°C.

A complete demo program listing is shown below. Choosing option "3) Show DS18B20 temperatures" will show the temperatures of any connected DS18B20 temperature sensors.

  10 REM 1-WIRE DEMONSTRATION FOR Z88 : BEN RYVES 2023
  20 *NAME 1-Wire Demo
  30 DIM ID 7,SCRATCH 8
  40 PROC_1W_INIT
  50 :
  60 REM Main demo loop
  70 REPEAT PROC_1W_DEMO_MENU
  80   ON ERROR PRINT:END
  90   PRINT "<Press any key>";
 100   REPEAT UNTIL INKEY(0)=TRUE:IF GET
 110 UNTIL FALSE
 120 END
 130 :
 140 REM Main menu
 150 DEFPROC_1W_DEMO_MENU
 160 CLS:PRINT CHR$1;"1B";"1-Wire Demonstration for Cambridge Z88";CHR$1;"1B"
 170 ON ERROR END
 180 REPEAT
 190   PRINT '"Please choose a demo: (press ESC to exit)"
 200   PRINT "1) Enumerate devices"
 210   PRINT "2) Scan iButton tags"
 220   PRINT "3) Show DS18B20 temperatures"
 230   M%=GET-ASC"0"
 240 UNTIL M%>0 AND M%<4
 250 ON ERROR OFF
 260 PRINT
 270 ON M% PROC_1W_DEMO_LIST_DEVICES, PROC_1W_DEMO_TAG, PROC_1W_DEMO_SHOW_TEMPERATURES
 280 ENDPROC
 290 END
 300 :
 310 REM Device search demo
 320 DEFPROC_1W_DEMO_LIST_DEVICES
 330 PROC_1W_SEARCH_RESET
 340 REPEAT F%=FN_1W_SEARCH(&F0,ID):IF F% PRINT FN_1W_ID$(ID)
 350 UNTIL F%=FALSE:ENDPROC
 360 :
 370 REM ID tag scanning demo
 380 DEFPROC_1W_DEMO_TAG
 390 ON ERROR GOTO 50
 400 PRINT "Tap a tag on the reader (press ESC to exit)"
 410 REPEAT
 420   REPEAT UNTIL FN_1W_RESET:REM Wait for device to be present
 430   PROC_1W_PUT(&33):REM Read ROM
 440   PROC_1W_GETS(ID,8):REM Fetch ID
 450   IF FN_1W_CRC_CHECK(ID,7) AND ID?0=1 VDU 7:PRINT "Detected ";FN_1W_ID$(ID);" at ";TIME$:REM Print if valid
 460   REPEAT UNTIL FN_1W_RESET=FALSE:REM Wait for device to be disconnected
 470 UNTIL FALSE
 480 ENDPROC
 490 :
 500 REM Temperature demo
 510 DEFPROC_1W_DEMO_SHOW_TEMPERATURES
 520 IF FN_1W_RESET=FALSE PRINT "No devices found":ENDPROC
 530 REM Start temperature conversion
 540 PROC_1W_PUT(&CC):REM Skip ROM
 550 PROC_1W_PUT(&44):REM Convert T
 560 T=TIME:IF INKEY(75)>TRUE REPEAT:UNTIL TIME>T+75:REM Delay 750ms
 570 REM Search for all temperature sensors on the bus and display their readings
 580 PROC_1W_SEARCH_RESET
 590 REPEAT F%=FN_1W_SEARCH(&F0,ID)
 600   IF F% PROC_1W_PRINT_TEMP(ID)
 610 UNTIL F%=FALSE
 620 ENDPROC
 630 REM Print a single sensor's reading
 640 DEFPROC_1W_PRINT_TEMP(ID)
 650 LOCAL T
 660 IF ID?0<>&28 ENDPROC:REM Must be a temperature sensor
 670 T=FN_1W_READ_TEMP(ID):IF T=-999 ENDPROC:REM Read sensor and check for error
 680 @%=&20409:PRINT MID$(FN_1W_ID$(ID),3,12);":",T;" deg C":@%=&90A
 690 ENDPROC
 700 REM Retrieve a single sensor's reading
 710 DEFFN_1W_READ_TEMP(ID)
 720 LOCAL T
 730 IF FN_1W_RESET=FALSE =-999
 740 PROC_1W_PUT(&55):PROC_1W_PUTS(ID,8):REM Match ROM
 750 PROC_1W_PUT(&BE):PROC_1W_GETS(SCRATCH,9):REM Read scratchpad
 760 IF FN_1W_CRC_CHECK(SCRATCH,8)=FALSE =-999:REM Check CRC
 770 =SCRATCH!-2DIV65536/16:REM Convert to degrees C
 780 :
 790 REM 1-WIRE ROUTINES
 800 END
 810 DEFPROC_1W_INIT
 820 ow_code_size=294:DIM ow_code ow_code_size-1
 830 RXE=&E1:M_RXERXD=&10
 840 TXC=&E4:M_TXCITX=&08
 850 SC=&400
 860 FOR opt=0 TO 2 STEP 2
 870   P%=ow_code
 880   [OPT opt
 890   .ow_buf DEFB 0 \ temporary transfer buffer
 900   .ow_conf DEFB 0 \ stores last bit conflict index
 910   :
 920   .ow_reset
 930   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:SBC A,A:LD (ow_buf),A:RET NZ \ check bus is idle
 940   DI:LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
 950   LD B,120:DJNZ P% \ delay
 960   AND NOT M_TXCITX:OUT (TXC),A \ release bus
 970   LD B,18:DJNZ P% \ delay
 980   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:CCF:SBC A,A:LD (ow_buf),A \ sample presence
 990   LD B,100:DJNZ P% \ delay
1000   EI:RET
1010   :
1020   .ow_put_carry
1030   JR C,ow_put_1 \ fall-through
1040   :
1050   .ow_put_0
1060   DI
1070   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
1080   LD B,15:DJNZ P% \ delay
1090   AND NOT M_TXCITX:OUT (TXC),A \ release bus
1100   NOP \ delay
1110   EI:RET
1120   :
1130   .ow_put_1
1140   DI
1150   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
1160   NOP \ delay
1170   AND NOT M_TXCITX:OUT (TXC),A \ release bus
1180   PUSH HL:POP HL \ delay
1190   IN A,(RXE):AND M_RXERXD:SUB M_RXERXD:CCF \ sample bit
1200   LD A,(ow_buf):RRA:LD (ow_buf),A \ store bit
1210   LD B,7:DJNZ P% \ delay
1220   EI:RET
1230   :
1240   .ow_put_byte
1250   LD C,A:LD B,8 \ value to send in C, send 8 bits
1260   .ow_put_loop
1270   SRL C:PUSH BC:CALL ow_put_carry:POP BC \ shift and send single bit
1280   DJNZ ow_put_loop \ loop
1290   RET
1300   :
1310   .ow_put_bytes
1320   LD A,B:OR C:RET Z:DEC BC \ have we finished?
1330   LD A,(HL):INC HL \ fetch
1340   PUSH BC:CALL ow_put_byte:POP BC:JR ow_put_bytes \ send and loop
1350   :
1360   .ow_get_byte
1370   LD B,8 \ 8 bits to receive
1380   .ow_get_loop
1390   PUSH BC:CALL ow_put_1:POP BC \ receive single bit
1400   DJNZ ow_get_loop \ loop
1410   LD A,(ow_buf):RET \ store
1420   :
1430   .ow_get_bytes
1440   LD A,B:OR C:RET Z:DEC BC \ have we finished?
1450   PUSH BC:CALL ow_get_byte:POP BC \ get a byte
1460   LD (HL),A:INC HL:JR ow_get_bytes \ store and loop
1470   :
1480   .ow_search
1490   LD DE,(ow_conf):LD D,0:LD C,1:LD B,64
1500   .ow_search_loop
1510   PUSH BC:CALL ow_put_1:CALL ow_put_1:POP BC:RLCA:RLCA \ get bit, !bit
1520   AND 3:JR Z,ow_search_conf \ 00 = conflict
1530   DEC A:JR Z,ow_search_1 \ 01 = 0 bit
1540   DEC A:JR Z,ow_search_0 \ 10 =  1 bit
1550   SCF:RET \ report failure
1560   .ow_search_conf
1570   LD A,B:CP E \ how does bit index compare to last conflict
1580   JR C,ow_search_0_conf \ 0, update current discrepancy
1590   JR Z,ow_search_1 \ 1, no update
1600   LD A,(HL):AND C:JR NZ,ow_search_advance \ old bit = 1, just advance
1610   LD D,B:JR ow_search_advance \ old bit = 0, update current discrepancy
1620   .ow_search_1:LD A,C:OR (HL):LD (HL),A:JR ow_search_advance
1630   .ow_search_0_conf:LD D,B \ fall-through
1640   .ow_search_0:LD A,C:CPL:AND (HL):LD (HL),A \ fall-through
1650   .ow_search_advance
1660   LD A,(HL):AND C:SUB C:CCF:PUSH BC:CALL ow_put_carry:POP BC \ return the ID bit
1670   RLC C:JR NC,P%+3:INC HL \ advance mask
1680   DJNZ ow_search_loop
1690   LD A,D:LD (ow_conf),A
1700   XOR A:LD (ow_buf),A:RET \ report success
1710   :
1720   .ow_crc
1730   LD B,8:LD DE,(ow_buf):LD D,A \ E = accumulated CRC, D = value to add
1740   .ow_crc_loop
1750   LD A,E:XOR D:SRL D:SRL A:JR C,ow_crc_odd \ XOR and shift bits
1760   SRL E:DJNZ ow_crc_loop:LD A,E:LD (ow_buf),A:RET \ even CRC value
1770   .ow_crc_odd:SRL E:LD A,&8C:XOR E:LD E,A:DJNZ ow_crc_loop:LD (ow_buf),A:RET \ odd CRC value
1780   :
1790   .ow_crc_block
1800   XOR A:LD (ow_buf),A \ reset CRC
1810   .ow_crc_block_loop
1820   LD A,B:OR C:LD A,(ow_buf):RET Z:DEC BC \ have we finished?
1830   LD A,(HL):INC HL:PUSH BC:CALL ow_crc:POP BC:JR ow_crc_block_loop \ update CRC
1840   ]
1850 NEXT
1860 IF P%-ow_code<>ow_code_size PRINT"Code size: "P%-ow_code:END
1870 ENDPROC
1880 :
1890 REM Resets bus, retuns TRUE if any devices are present
1900 DEFFN_1W_RESET:CALL ow_reset:=?ow_buf=0
1910 REM Transmits a single byte
1920 DEFPROC_1W_PUT(A%)CALL ow_put_byte:ENDPROC
1930 REM Transmits a block of bytes
1940 DEFPROC_1W_PUTS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_put_bytes:ENDPROC
1950 REM Receives a single byte
1960 DEFFN_1W_GET:CALL ow_get_byte:=?ow_buf
1970 REM Receives a block of bytes
1980 DEFPROC_1W_GETS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_get_bytes:ENDPROC
1990 :
2000 REM Starts enumerating devices on the bus
2010 DEFPROC_1W_SEARCH_RESET:?ow_conf=TRUE:ENDPROC
2020 REM Searches for next device on bus. Pass search type &F0 for all devices, &EC for alarming devices. Returns TRUE if next device found
2030 DEFFN_1W_SEARCH(A%,ID)IF ?ow_conf=0:=FALSE ELSE IF FN_1W_RESET=0:=FALSE ELSE PROC_1W_PUT(A%):H%=ID DIV256:L%=ID:CALL ow_search:=?ow_buf=0
2040 :
2050 REM Converts ID bytes into string
2060 DEFFN_1W_ID$(ID)LOCAL I%:S$="":FOR I%=7 TO 0 STEP -1:IF ID?I%>15:S$=S$+STR$~(ID?I%):NEXT:=S$:ELSE:S$=S$+"0"+STR$~(ID?I%):NEXT:=S$
2070 REM Converts string into ID bytes
2080 DEFPROC_1W_ID$(ID,ID$)LOCAL I%:FOR I%=0 TO 7:ID?I%=EVAL("&"+MID$(ID$,15-I%*2,2)):NEXT:ENDPROC
2090 :
2100 REM Calculates the CRC of a block of data
2110 DEFFN_1W_CRC(L%,C%)LOCAL H%,B%:H%=L% DIV256:B%=C%DIV256:CALL ow_crc_block:=?ow_buf
2120 REM Checks if a CRC at the end of a block of data matches
2130 DEFFN_1W_CRC_CHECK(L%,C%)=FN_1W_CRC(L%,C%)=(L%?C%)

Temperature logger

All of this can be put together into a program that logs the temperature from any connected sensors to a CSV file on the Z88. The main loop can look similar to the one above that searches for and displays the temperature readings for any connected DS18B20 sensors, however it will instead call a PROC_1W_LOG_TEMP procedure that handles logging the data to a file instead of printing it on the display:

REM Log a single sensor's reading
DEFPROC_1W_LOG_TEMP(ID)
LOCAL T
IF ID?0<>&28 ENDPROC:REM Must be a temperature sensor
T=FN_1W_READ_TEMP(ID):IF T=-999 ENDPROC:REM Read sensor and check for error
ENTRY$=FN_DATETIME$(TIME$)+","+STR$T:REM Timestamp and temperature reading
ID$=MID$(FN_1W_ID$(ID),3,12):REM ID without CRC and family code
CSV$=ID$+".CSV":REM Name of CSV file
C=OPENUP CSV$:REM Open the CSV for update
IF C=FALSE C=OPENOUT CSV$:PRINT#C,"Time,"+ID$:REM Create new CSV if required
PTR#C=EXT#C:PRINT#C,ENTRY$:REM Write entry to end of CSV
CLOSE#C:REM Close the CSV
PRINT CSV$,ENTRY$:REM Display on screen
ENDPROC

The procedure will fetch the value from the sensor and then turn the ID into a CSV filename by stripping off the CRC and family code and appending ".CSV". It will then try to open the existing file, and if one doesn't exist it will create a new one and write the column headers to it. It will then seek to the end of the file and append the timestamp and the temperature reading.

One further complication is that to make handling the CSV a bit easier, the timestamp is converted from the format returned by BBC BASIC's TIME$ function into "YYYY-MM-DD hh:mm:ss" format. This is handled by the following three functions, FN_DATE (which extracts and reformats the date component into YYYY-MM-DD format), FN_TIME (which extracts the time component into hh:mm:ss format) and FN_DATETIME which glues the date and time back together with a space in the middle:

REM Date formatting routines
DEF FN_DATE$(T$)
LOCAL C%,I%,J%,V%,R$
R$="":I%=1
FOR C%=0 TO 3 J%=INSTR(MID$(T$,I%)," ")
  IF C%=2 V%=1+INSTR("JanFebMarAprMayJunJulAugSepOctNovDec",MID$(T$,I%,3))DIV3 ELSE V%=VAL(MID$(T$,I%,J%-1))
  IF C%>1 R$="-"+R$
  IF C% R$=STR$(V%)+R$ IF V%<10 R$="0"+R$
  I%=I%+J%
NEXT
=R$
DEF FN_TIME$(T$) =MID$(T$,LEN(T$)-7)
DEF FN_DATETIME$(T$) =FN_DATE$(T$)+" "+FN_TIME$(T$)

One way to make this logging program more useful would be to get the computer to run it periodically (e.g. once per minute). The Z88's "Alarm" feature can execute a command whenever the alarm goes off and you can schedule recurring alarms so this sounds like an ideal starting point! When the program has run it would also be handy for the computer to switch itself off again. There is an OS call for this, OS_Off, which can be invoked from BASIC as follows:

REM SWITCH OFF ROUTINES
DEFPROC_SWITCH_OFF_INIT
switch_off_size=15:DIM switch_off switch_off_size-1
P%=switch_off
[OPT 2
LD HL,0:ADD HL,SP:LD SP,(&1FFE):PUSH HL
RST &20:DEFW &EC06:REM OS_Off
POP HL:LD SP,HL:RET:]
ENDPROC
DEFPROC_SWITCH_OFF:CALL switch_off:ENDPROC

As with the 1-Wire assembly routines you must first call an initialisation procedure (PROC_SWITCH_OFF_INIT) to assemble the routine before calling it with PROC_SWITCH_OFF. The actual OS_Off call is the RST &20H:DEFW &EC06 in the middle of all that. Unfortunately, OS calls tend to involve some memory paging and in the process BBC BASIC's RAM gets swapped out and when the OS routine tries to return it jumps back into some different memory – the computer certainly switches off, but then it soft resets instead of coming back on properly. This is why there's some additional boilerplate code around the OS call to move the stack pointer into a safe region of memory so the routine can return properly.

The complete temperature-logging program is now shown below:

  10 REM 1-WIRE TEMPERATURE LOGGER : BEN RYVES 2023
  20 *NAME 1-Wire Temperature Logger
  30 REPEAT UNTIL INKEY(0)=TRUE:REM Flush keyboard
  40 DIM ID 7,SCRATCH 8
  50 PROC_1W_INIT
  60 PROC_SWITCH_OFF_INIT
  70 REM Reset 1-Wire bus and check that at least one device is present
  80 IF FN_1W_RESET=FALSE PROC_SWITCH_OFF:END
  90 REM Start temperature conversion
 100 PROC_1W_PUT(&CC):REM Skip ROM
 110 PROC_1W_PUT(&44):REM Convert T
 120 T=TIME:IF INKEY(75)>TRUE REPEAT:UNTIL TIME>T+75:REM Delay 750ms
 130 REM Search for all temperature sensors on the bus and log their readings
 140 PROC_1W_SEARCH_RESET
 150 REPEAT F%=FN_1W_SEARCH(&F0,ID):IF F% PROC_1W_LOG_TEMP(ID)
 160 UNTIL F%=FALSE
 170 REM Switch the computer off
 180 PROC_SWITCH_OFF
 190 END
 200 :
 210 REM Log a single sensor's reading
 220 DEFPROC_1W_LOG_TEMP(ID)
 230 LOCAL T
 240 IF ID?0<>&28 ENDPROC:REM Must be a temperature sensor
 250 T=FN_1W_READ_TEMP(ID):IF T=-999 ENDPROC:REM Read sensor and check for error
 260 ENTRY$=FN_DATETIME$(TIME$)+","+STR$T:REM Timestamp and temperature reading
 270 ID$=MID$(FN_1W_ID$(ID),3,12):REM ID without CRC and family code
 280 CSV$=ID$+".CSV":REM Name of CSV file
 290 C=OPENUP CSV$:REM Open the CSV for update
 300 IF C=FALSE C=OPENOUT CSV$:PRINT#C,"Time,"+ID$:REM Create new CSV if required
 310 PTR#C=EXT#C:PRINT#C,ENTRY$:REM Write entry to end of CSV
 320 CLOSE#C:REM Close the CSV
 330 PRINT CSV$,ENTRY$:REM Display on screen
 340 ENDPROC
 350 REM Retrieve a single sensor's reading
 360 DEFFN_1W_READ_TEMP(ID)
 370 LOCAL T
 380 IF FN_1W_RESET=FALSE =-999
 390 PROC_1W_PUT(&55):PROC_1W_PUTS(ID,8):REM Match ROM
 400 PROC_1W_PUT(&BE):PROC_1W_GETS(SCRATCH,9):REM Read scratchpad
 410 IF FN_1W_CRC_CHECK(SCRATCH,8)=FALSE =-999:REM Check CRC
 420 =SCRATCH!-2DIV65536/16:REM Convert to degrees C
 430 :
 440 REM Date formatting routines
 450 DEF FN_DATE$(T$)
 460 LOCAL C%,I%,J%,V%,R$
 470 R$="":I%=1
 480 FOR C%=0 TO 3 J%=INSTR(MID$(T$,I%)," ")
 490   IF C%=2 V%=1+INSTR("JanFebMarAprMayJunJulAugSepOctNovDec",MID$(T$,I%,3))DIV3 ELSE V%=VAL(MID$(T$,I%,J%-1))
 500   IF C%>1 R$="-"+R$
 510   IF C% R$=STR$(V%)+R$ IF V%<10 R$="0"+R$
 520   I%=I%+J%
 530 NEXT
 540 =R$
 550 DEF FN_TIME$(T$) =MID$(T$,LEN(T$)-7)
 560 DEF FN_DATETIME$(T$) =FN_DATE$(T$)+" "+FN_TIME$(T$)
 570 :
 580 REM SWITCH OFF ROUTINES
 590 DEFPROC_SWITCH_OFF_INIT
 600 switch_off_size=15:DIM switch_off switch_off_size-1
 610 P%=switch_off
 620 [OPT 2
 630 LD HL,0:ADD HL,SP:LD SP,(&1FFE):PUSH HL
 640 RST &20:DEFW &EC06
 650 POP HL:LD SP,HL:RET:]
 660 ENDPROC
 670 DEFPROC_SWITCH_OFF:CALL switch_off:ENDPROC
 680 :
 690 REM 1-WIRE ROUTINES
 700 END
 710 DEFPROC_1W_INIT
 720 ow_code_size=294:DIM ow_code ow_code_size-1
 730 RXE=&E1:M_RXERXD=&10
 740 TXC=&E4:M_TXCITX=&08
 750 SC=&400
 760 FOR opt=0 TO 2 STEP 2
 770   P%=ow_code
 780   [OPT opt
 790   .ow_buf DEFB 0 \ temporary transfer buffer
 800   .ow_conf DEFB 0 \ stores last bit conflict index
 810   :
 820   .ow_reset
 830   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:SBC A,A:LD (ow_buf),A:RET NZ \ check bus is idle
 840   DI:LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
 850   LD B,120:DJNZ P% \ delay
 860   AND NOT M_TXCITX:OUT (TXC),A \ release bus
 870   LD B,18:DJNZ P% \ delay
 880   IN A,(RXE):AND M_RXERXD:CP M_RXERXD:CCF:SBC A,A:LD (ow_buf),A \ sample presence
 890   LD B,100:DJNZ P% \ delay
 900   EI:RET
 910   :
 920   .ow_put_carry
 930   JR C,ow_put_1 \ fall-through
 940   :
 950   .ow_put_0
 960   DI
 970   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
 980   LD B,15:DJNZ P% \ delay
 990   AND NOT M_TXCITX:OUT (TXC),A \ release bus
1000   NOP \ delay
1010   EI:RET
1020   :
1030   .ow_put_1
1040   DI
1050   LD A,(SC+TXC):OR M_TXCITX:OUT (TXC),A \ hold bus low
1060   NOP \ delay
1070   AND NOT M_TXCITX:OUT (TXC),A \ release bus
1080   PUSH HL:POP HL \ delay
1090   IN A,(RXE):AND M_RXERXD:SUB M_RXERXD:CCF \ sample bit
1100   LD A,(ow_buf):RRA:LD (ow_buf),A \ store bit
1110   LD B,7:DJNZ P% \ delay
1120   EI:RET
1130   :
1140   .ow_put_byte
1150   LD C,A:LD B,8 \ value to send in C, send 8 bits
1160   .ow_put_loop
1170   SRL C:PUSH BC:CALL ow_put_carry:POP BC \ shift and send single bit
1180   DJNZ ow_put_loop \ loop
1190   RET
1200   :
1210   .ow_put_bytes
1220   LD A,B:OR C:RET Z:DEC BC \ have we finished?
1230   LD A,(HL):INC HL \ fetch
1240   PUSH BC:CALL ow_put_byte:POP BC:JR ow_put_bytes \ send and loop
1250   :
1260   .ow_get_byte
1270   LD B,8 \ 8 bits to receive
1280   .ow_get_loop
1290   PUSH BC:CALL ow_put_1:POP BC \ receive single bit
1300   DJNZ ow_get_loop \ loop
1310   LD A,(ow_buf):RET \ store
1320   :
1330   .ow_get_bytes
1340   LD A,B:OR C:RET Z:DEC BC \ have we finished?
1350   PUSH BC:CALL ow_get_byte:POP BC \ get a byte
1360   LD (HL),A:INC HL:JR ow_get_bytes \ store and loop
1370   :
1380   .ow_search
1390   LD DE,(ow_conf):LD D,0:LD C,1:LD B,64
1400   .ow_search_loop
1410   PUSH BC:CALL ow_put_1:CALL ow_put_1:POP BC:RLCA:RLCA \ get bit, !bit
1420   AND 3:JR Z,ow_search_conf \ 00 = conflict
1430   DEC A:JR Z,ow_search_1 \ 01 = 0 bit
1440   DEC A:JR Z,ow_search_0 \ 10 =  1 bit
1450   SCF:RET \ report failure
1460   .ow_search_conf
1470   LD A,B:CP E \ how does bit index compare to last conflict
1480   JR C,ow_search_0_conf \ 0, update current discrepancy
1490   JR Z,ow_search_1 \ 1, no update
1500   LD A,(HL):AND C:JR NZ,ow_search_advance \ old bit = 1, just advance
1510   LD D,B:JR ow_search_advance \ old bit = 0, update current discrepancy
1520   .ow_search_1:LD A,C:OR (HL):LD (HL),A:JR ow_search_advance
1530   .ow_search_0_conf:LD D,B \ fall-through
1540   .ow_search_0:LD A,C:CPL:AND (HL):LD (HL),A \ fall-through
1550   .ow_search_advance
1560   LD A,(HL):AND C:SUB C:CCF:PUSH BC:CALL ow_put_carry:POP BC \ return the ID bit
1570   RLC C:JR NC,P%+3:INC HL \ advance mask
1580   DJNZ ow_search_loop
1590   LD A,D:LD (ow_conf),A
1600   XOR A:LD (ow_buf),A:RET \ report success
1610   :
1620   .ow_crc
1630   LD B,8:LD DE,(ow_buf):LD D,A \ E = accumulated CRC, D = value to add
1640   .ow_crc_loop
1650   LD A,E:XOR D:SRL D:SRL A:JR C,ow_crc_odd \ XOR and shift bits
1660   SRL E:DJNZ ow_crc_loop:LD A,E:LD (ow_buf),A:RET \ even CRC value
1670   .ow_crc_odd:SRL E:LD A,&8C:XOR E:LD E,A:DJNZ ow_crc_loop:LD (ow_buf),A:RET \ odd CRC value
1680   :
1690   .ow_crc_block
1700   XOR A:LD (ow_buf),A \ reset CRC
1710   .ow_crc_block_loop
1720   LD A,B:OR C:LD A,(ow_buf):RET Z:DEC BC \ have we finished?
1730   LD A,(HL):INC HL:PUSH BC:CALL ow_crc:POP BC:JR ow_crc_block_loop \ update CRC
1740   ]
1750 NEXT
1760 IF P%-ow_code<>ow_code_size PRINT"Code size: "P%-ow_code:END
1770 ENDPROC
1780 :
1790 REM Resets bus, retuns TRUE if any devices are present
1800 DEFFN_1W_RESET:CALL ow_reset:=?ow_buf=0
1810 REM Transmits a single byte
1820 DEFPROC_1W_PUT(A%)CALL ow_put_byte:ENDPROC
1830 REM Transmits a block of bytes
1840 DEFPROC_1W_PUTS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_put_bytes:ENDPROC
1850 REM Receives a single byte
1860 DEFFN_1W_GET:CALL ow_get_byte:=?ow_buf
1870 REM Receives a block of bytes
1880 DEFPROC_1W_GETS(L%,C%)LOCAL H%,B%:H%=L%DIV256:B%=C%DIV256:CALL ow_get_bytes:ENDPROC
1890 :
1900 REM Starts enumerating devices on the bus
1910 DEFPROC_1W_SEARCH_RESET:?ow_conf=TRUE:ENDPROC
1920 REM Searches for next device on bus. Pass search type &F0 for all devices, &EC for alarming devices. Returns TRUE if next device found
1930 DEFFN_1W_SEARCH(A%,ID)IF ?ow_conf=0:=FALSE ELSE IF FN_1W_RESET=0:=FALSE ELSE PROC_1W_PUT(A%):H%=ID DIV256:L%=ID:CALL ow_search:=?ow_buf=0
1940 :
1950 REM Converts ID bytes into string
1960 DEFFN_1W_ID$(ID)LOCAL I%:S$="":FOR I%=7 TO 0 STEP -1:IF ID?I%>15:S$=S$+STR$~(ID?I%):NEXT:=S$:ELSE:S$=S$+"0"+STR$~(ID?I%):NEXT:=S$
1970 REM Converts string into ID bytes
1980 DEFPROC_1W_ID$(ID,ID$)LOCAL I%:FOR I%=0 TO 7:ID?I%=EVAL("&"+MID$(ID$,15-I%*2,2)):NEXT:ENDPROC
1990 :
2000 REM Calculates the CRC of a block of data
2010 DEFFN_1W_CRC(L%,C%)LOCAL H%,B%:H%=L% DIV256:B%=C%DIV256:CALL ow_crc_block:=?ow_buf
2020 REM Checks if a CRC at the end of a block of data matches
2030 DEFFN_1W_CRC_CHECK(L%,C%)=FN_1W_CRC(L%,C%)=(L%?C%)

When run this will log the temperatures of all connected sensors to CSV files as described above then switch the Z88 off. The "Alarm" popdown can be used to set up an alarm that runs the program once per minute (or at any other desired interval) by choosing an alarm type of "execute". This will effectively type in the supplied command, and so by setting it to #BRUN"TEMPLOG.BBC"~E it will press □+B to switch to BASIC (#B), type in RUN"TEMPLOG" and then press Enter (~E).

Setting up the alarm this way each time can be a bit tedious, so to make things easier here's a CLI file that can be used to set up the alarm:

.;Set up temperature logging alarm
#A
~R~E
~D~D
##BRUN"TEMPLOG.BBC"~~E
~D
~D~R~D~R~S~U~S~U~R~D

This contains keystrokes in a similar fashion to the "command" field in the alarm settings and can be "executed" from the Z88's Filer; here #A presses □+A to enter the Alarm pop-down, ~R, ~D or ~U move the cursor right, down or up and where we need to type literal # or ~ signs they are doubled up (## or ~~). This will enter all of the required details to set up an alarm that will run the task once per minute forever, at which point they can be adjusted if required (e.g. to change the interval). Pressing Enter will create the alarm, and leaving the Alarm popdown will set it in motion. To finish data collection the Z88 can be switched back on as normal for the alarm to be cleared.

The only other point of note is that I found that the computer seemed to get a bit "gummed up" with queued keypresses. This could be because it never sits idle after handling the alarm; it runs the BASIC program then switches the computer off, waiting for the next alarm to be run. This is why a simple loop to flush the keyboard buffer occurs at the start of the program, and the computer seems much happier for it.

The temperature logs in the CSV files can be used to generate a chart like the following:

I captured data from three sensors over a 24 hour period; one outside (green line), one in my bedroom (red line) and one in my office (blue line). You can see how the central heating kicks in at 07:30, and I turned it up a little after 12:00. During the day the temperature in the bedroom moves up and down as the heating switches on and off, but the temperature in the office appears to be more consistent and a bit higher – the sensor is near where I am sitting and my desktop computer, which is likely contributing some heat.

Conclusion

What was originally intended to be a quick project to make use a couple of electronic components I had been sent in error soon turned into what I thought was an interesting demonstration of what can be done with the Cambridge Z88 using its stock software and some very basic additional hardware, further cementing my appreciation for the well-designed device.

The files accompanying this post can be downloaded below:

ONEWIRE.BBC – 1-Wire demonstration program.
TEMPLOG.BBC and TEMPLOG.CLI – Temperature logging program and CLI file to set up the alarm.
templogs.zip and templogs.xlsx – Sample data captured by the temperature logging program.

SmartBox experimentation with DOS, RISC OS and C#/WinForms

Mon, 06 Nov 2023 18:25:36 +0000

My latest eBay purchase was influenced by a desire for some practical test/prototype equipment, a bit of nostalgia and a desire to learn something new.

A lot of my projects involve some sort of microcontroller running some software that will take inputs, perform decisions on them, and produce outputs. Getting to that stage tends to involve quite a lot of "boilerplate" hardware and software setup, and I'd quite like something that I can just plug in and get cracking with and write some quick test code instead of having to assemble a circuit on a breadboard or faff around with a clumsy IDE.

When I was at school in the 1990s one of the devices that got me into microcontrollers in the first place was a computer control system based around the Economatics SmartBox. This plugs into a computer via a serial connection, has eight simple digital inputs, eight simple digital outputs, four analogue inputs and four motor drivers. Programs could be written in a BASIC-like language or in flowchart form, and once you'd run and tested them on the SmartBox you could program them to a PIC microcontroller to run without the host computer.

All along I'd assumed that the SmartBox was a simple interface box that relied on the host computer to do all of the processing, but doing some digging I found a thread on StarDot that delved into the heart of the machine and saw that there's a 65C02 CPU inside along with 32KB of RAM and the OS runs from a socketed 8KB ROM. As a long-term Z80 fan I thought it was time I should see how the other side lived – in spite of my fondness for the BBC Micro I don't own one and have not programmed any 6502 assembly, so a SmartBox seemed like it would also provide an affordable 6502 computer for experimentation.

Of course, one challenge was going to be finding the supporting software for the venerable SmartBox. Fortunately in the StarDot thread people had shared archives of the DOS, BBC Master and RISC OS software. One of the many handy features of DOSBox-X is its ability to connect an emulated serial port to a physical one in the host system, and so after building a serial cable for my SmartBox (using a pinout found, once again, via the StarDot thread) I was able to hook it up to my PC and get it working with SmartMove, the BASIC-like programming environment for the SmartBox.

When the software is first run it needs to download SmartMove code into the SmartBox. This is because the programming environment and interpreter is actually running on the SmartBox itself, and the SmartMove software on the host PC is simply loading that interpreter onto the box (found in an accompanying file of 65C02 machine code named AL.COD) and then providing a user interface to that environment as a sort of terminal. This means you can close the SmartMove software (and unplug the serial cable) and your program will continue running on the SmartBox.

This ability to load and execute code directly on the SmartBox is one of the things that intrigued me as a way to get into 65C02 programming, but for the time being I was interested in digging deeper into the how the existing SmartMove software was interfacing with the box with the intention of writing a simple Z80 host interface that I could then adapt to the Cambridge Z88, my CP/M computer and maybe even the TI-83 Plus calculator series. Fortunately the documentation for the serial protocol used by SmartMove application has been documented so I was able to prototype a crude version of the software in C# using WinForms. It needs some serious tidying up before I can release it but as a basic test it does the job:

The ability to build new versions of the interface software for different platforms without needing to worry about porting over the BASIC interpreter seems sensible considering there were versions of SmartMove available for DOS, BBC Master, RISC OS and Apple Macintosh. All could use the same AL.COD but would just need to provide the relevant UI, input and output routines specific to their host platforms.

I had been using the DOS version of SmartMove as the initial inspiration of the user interface for my C#/WinForms implementation, however the screenshots of the RISC OS version in the user manual looked rather more visually appealing and an archived copy of this software was available. Unfortunately, I don't own an Acorn Archimedes, I was unable to get the software running properly on modern RISC OS on a Raspberry Pi (even with various compatibility shims in place) and I couldn't find an emulator that handled the serial port in a similar fashion to DOSBox-X. However, the excellent Arculator has source code available and armed with a copy of the 6651 UART datasheet I thought I'd have a go at hacking in the feature myself.

"Hack" is definitely the operative word and though my code is abominable it does work well enough to get the available RISC OS software working on my PC. It's downloadable from here and requires the addition of the host PC's serial port name to arc.cfg (e.g. serial_port = COM1).

The above screenshot shows the RISC OS version of SmartMove which provided some additional inspiration for how a GUI version of the software should work. As I'd previously loaded some procedures onto the SmartBox via my C# version I could then bring the same procedures up for editing in the RISC OS version of the software. Handy!

The Logicator software can be used to build programs using flowcharts instead of a BASIC-like programming language. As far as I'm aware Logicator directly accesses the inputs and outputs from a number of different host interface boxes and doesn't rely on 65C02 code loaded onto the box like SmartMove, but this does mean that when you close Logicator your program stops aas it's relying on the host PC to run the show. However, included with the archive of RISC OS software is an application called SmartFlow which first loads a flow chart "interpreter" into the SmartBox:

Once loaded you can then load a Logicator-format flowchart onto the SmartBox where it can be run without being connected to a host PC:

All in all it's been quite interesting to dig into the SmartBox and get a feel for how it works and what can be done with it. To this end I recorded a video demonstration of the SmartBox and its usage within RISC OS, though so far I feel I'm only really scratching the surface!

Adding 11KB of RAM to a CP/M 3 system with a single NAND gate chip

Wed, 30 Aug 2023 01:35:00 +0100

It's been quite a while since I posted about my Z80 Computer project. This is a home-made Z80 computer I built back in 2010 that features a 10MHz Z80 CPU with 64KB RAM that runs CP/M 3. It can drive an internal LCD, TV or VGA monitor at 320x240 (monochrome only) and unfortunately is a project I was never too happy with due to several compromises I had to make in its design – though at the time I was happy enough I got it to work at all! The video output was limited by both my choice to use an internal graphical LCD and the limitations of the dsPIC33F I chose to use to drive it and the software was all a bit half-baked. I could run the generic CP/M version of BBC BASIC on it, but this lacks graphics and sound support, for example.

More recently my work on adapting BBC BASIC to the Sega Master System had reignited my interest in 8-bit programming, though that too was imperfect due to the limitations of the Master System's VDP. I was further encouraged by coming third in the "Retro not Vintage" competition on /r/retrobattlestations, though I'm not sure I was quite worthy of a podium finish.

With this in mind I started work on improving the computer. I replaced the existing dsPIC33F VDP with a new one based around a dsPIC33E. This newer microcontroller has 32KB of RAM and can run at up to 70 MIPS, a big upgrade from the previous 16KB RAM and 40 MIPS. This provides me with enough video RAM to store the largest BBC Micro screen mode frame buffer (20KB) as well as the necessary CPU grunt to look up pixel data from colour palettes and output it to the screen. I've implemented all eight of the standard BBC Micro screen modes, from the high-res 640x256 (in two colours) MODE 0 to the low-res 160x256 (in sixteen colours) MODE 2 along with the Teletext-compatible MODE 7. This is all controlled via a BBC Micro-compatible VDU driver and the results all seem quite faithful with no real compromises.

There was even enough CPU power left over on the microcontroller to implement BBC Micro-compatible SOUND and ENVELOPE, and with the source code for the CP/M version of BBC BASIC having been released since I last worked on the project it made it much easier to add all of the graphics and sound routines into the version of BBC BASIC specific to my computer.

To get an idea of what the computer is like to use, I recorded a little demo video here. However, this is not really what I wanted to write about in this post – I wanted to cover an easy way to free up some RAM by implementing banked CP/M 3.

Non-banked versus banked CP/M

I chose CP/M 3 as the OS for my computer instead of CP/M 2 as I'm using an SD card for storage and CP/M 3 has native support for disk sector sizes that do not directly match the file record size and it will handle the blocking/unblocking for you (CP/M's file records are 128 bytes long, SD card sectors are 512 bytes long). One other nice feature of CP/M 3 is the existence of a "banked" version which allows it to run on systems with more than 64KB of RAM. As far as user programs are concerned they still run in a flat 64KB memory space, however the OS can move certain parts of itself as well as disk and directory buffers into a separate memory bank where they are only accessed when needed, freeing up space in the "transient program area" (TPA). As well as more memory for user programs the banked version provides a much improved line editor when typing at the command-line, password protection of files and more descriptive error messages.

Naturally, when I read about this I thought it would be an obvious choice for my computer. As it is, I'm using a 128KB RAM chip but have tied A16 low as I didn't have any kind of MMU or bank-switching hardware setup (32KB and 128KB RAM chips are available in abundance, 64KB ones less so, and using a 128KB chip with the address line tied low involved a lot less soldering than two separate 32KB RAM chips). I did have an emulator where I could try to prototype the hardware changes to support a banked CP/M 3, however I was not able to get a banked version of the OS built and working so gave up – after all, I had a 49KB TPA, which seemed like it would be good enough.

With the other improvements to the computer recently I thought it worth reinvestigating. I did a bit of hunting to see if I could find any recommendations for a simple setup but most of what I could find ended up being a lot more complicated than what I was really looking for. After a bit more experimentation I was able to end up with a banked version of CP/M running on my computer and all I needed was a single NAND gate chip.

Memory requirements for banked CP/M

The memory layout of banked CP/M is actually quite a bit simpler than a lot of the threads I could find online seemed to make out. All you really need is a shared common area at the top of memory that will always be accessible regardless of the current state of the selected bank, and memory below that which can be switched between multiple banks. When booting the computer bank 0 will be selected, so both the common (resident) and banked parts can be copied to memory, and then bank 1 will be swapped in to provide the large TPA.

In my case, as I'm using a 128KB RAM chip, I will use A16 as the bank selection bit. When low this will provide access to the lower 64KB RAM on the chip, when high it will provide access to the upper 64KB RAM. To implement the common area at the top of memory, you then just need to check to see if the address is above the boundary between banked and common memory and if so to force A16 either high or low (it doesn't matter which, as long as it's consistent) so that when the address is in the common area the same bank will be accessed, regardless of the state of the bank selection bit.

Bank switching with simple logic

A simple way to implement a common area in upper memory is with AND (to detect the high address) and OR (to force the A16 high if it's a high address) logic, like this:

Here we use a 4-input AND gate to detect any memory address in the top 4KB of the chip (address lines A12 to A15 will go high at %1111000000000000 which gives a common region of $F000 to $FFFF). If that's the case, then the output of the 4-input AND gate will be high, which when ORed with the bank selection bit will force A16 high whenever we're in the common memory area. If we're below the common memory area then the value of the bank selection bit will pass through directly to A16, allowing us to bank switch the lower area of memory. Or, to summarise in a truth table:

In					Out
A12	A13	A14	A15	BANK	A16
1	1	1	1	x	1
0	x	x	x	0	0
0	x	x	x	1	1
x	0	x	x	0	0
x	0	x	x	1	1
x	x	0	x	0	0
x	x	0	x	1	1
x	x	x	0	0	0
x	x	x	0	1	1

However, it would be easier if we could implement this on a single chip. A 4x 2-input NAND gate chip (such as the SN74ALS00AN) should do the job when wired up as follows:

The truth table is a little different this time around:

In				Out
A13	A14	A15	BANK	A16
1	1	1	x	1
0	x	x	0	1
0	x	x	1	0
x	0	x	0	1
x	0	x	1	0
x	x	0	0	1
x	x	0	1	0

When accessing the banked region of memory A16 is the inverse of the bank selection bit. This doesn't matter, though, as long as there's a consistent mapping between logical addresses and the physical RAM addresses it will work even if it's "backwards". There's also one fewer address line, which means that the common area now runs from %1110000000000000 = $E000 to $FFFF, providing a common area of 8KB. In practice I didn't find this made a difference to the amount of memory available in the TPA; whether the common area was 4KB, 8KB or 16KB I was able to bring the TPA up to 60KB (from 49KB in the non-banked system), though it does eat into the amount of memory available on page 0 for disk and directory buffers. As I'm loading from an SD card (which is much faster than the floppy discs of yore) the reduced buffer space is less of a concern to me.

Fortunately there was enough space inside the computer (and a single remaining pin on the I/O controller to act thas bank selection bit) to add the NAND chip and drive A16. At last I have access to 120KB of my 128KB RAM chip... but what about the software?

Building a banked version of CP/M

I will start with the assumption that you have been able to build a non-banked version of CP/M 3 and got that running on your computer, as there is a lot less that can go wrong when doing so. Once you've got that working there's not too much to add to your BIOS to make it support banking, however I did run into a few issues with missing files and some misinterpretation of how things should work until I was able to get it working.

I used the "Developers Build Directory for CP/M 3" from The Unofficial CP/M Web site as my source for CP/M 3. This contains the GENCPM tool that will be used to generate the CPM3.SYS that will need to be loaded into memory by your boot loader. In my case I get my I/O controller to copy CP/M from the SD card into memory at boot – if you've already got the non-banked version of CP/M 3 booting then you'll be familiar with this, but do pay attention to table D-1 in the CP/M 3 system guide which points out the two parts of CP/M to load – the "resident" and "banked" portions. Both parts need to be loaded on a banked system, and both need to be loaded into page 0.

To get that far you will need to have relocatable copies of your banked BIOS (BNKBIOS3.SPR) and the BDOS (RESBDOS3.SPR and BNKBDOS3.SPR) ready to be used by GENCPM. I couldn't find a ready-made copy of these BDOS modules, but you can build them using RMAC and LINK as shown below:

RMAC RESBDOS
LINK RESBDOS3=RESBDOS[OS]

PIP BNKBDOS3.ASM=CPMBDOS2.ASM,CONBDOS.ASM,BDOS30.ASM
RMAC BNKBDOS3
LINK BNKBDOS3=BNKBDOS3[OS]

The banked BDOS source code is split between three different source files which need to be combined with PIP first, then can be built. For the sake of completeness, if you wanted to build the non-banked BDOS3.SPR you'd use a very similar set of commands, just with CPMBDOS1.ASM instead of CPMBDOS2.ASM:

PIP BDOS3.ASM=CPMBDOS1.ASM,CONBDOS.ASM,BDOS30.ASM
RMAC BDOS3
LINK BDOS3=BDOS3[OS]

The other important ingredient is your banked BIOS, BNKBIOS3.SPR. I don't get on with 8080 syntax so I assemble my BIOS3.MAC with Microsoft's M80 in Z80 mode (instead of RMAC).

RMAC SCB
RMAC BIOSKRNL
M80 =BIOS3
LINK BNKBIOS3[B]=BIOSKRNL,BIOS3,SCB

If you had previously edited BIOSKRNL.ASM to state banked equ false remember to change it to banked equ true as well!

The only additions you should need in your BIOS are implementations of ?xmove and ?bank. ?bank is an easy one, and just switches to the memory bank requested in the A register. In my case I handle that just by outputting A to the I/O port that handles bank switching:

; Select Memory Bank
; Entry Parameters: A=Memory Bank
; Returned Values:  None
; You must preserve or restore all registers other than the
; accumulator, A, upon exit.
?bank:
if banked
	out (bank$select),a ; change this for what your hardware requires
endif
	ret

(To retain compatibility with my old banked BIOS I wrap the changes in an if banked condition – banked equ true appears earlier in the file).

?xmove is a little more complicated – this states that the subsequent ?move operation (which copies BC bytes from DE to HL) should transfer data from one memory bank to another. Note that this only affects the next ?move operation; if ?move is called again afterwards without ?xmove then it should perform a copy within the same bank as before.

Fortunately the inter-bank copy is limited to 128 bytes so you can simply implement this by temporarily copying the data from one bank into a 128 byte buffer in common memory, then copying the data back to the destination bank. It's not exactly efficient, but it keeps the hardware simple.

; Memory-to-Memory Block Move
; Entry Parameters: HL=Destination address
;                   DE=Source address
;                   BC=Count
; Returned Values:  HL and DE must point to
;                   next bytes following move operation
?move:
	ex de,hl
	ldir
	ex de,hl	
	ret

; Set Banks for Following MOVE
; Entry Parameters: B=destination bank
;                   C=source bank
; Returned Values:  None	
?xmove:

if banked
	; Store the source/destination bank numbers
	ld (mov$src$b),bc
	; Make sure that the next call to move (via ?mov vector) uses the banked move routine.
	ld bc,banked$move
	ld (?mov+1),bc
	ret

banked$move:
	
	; Select source bank
	ld a,(mov$src$b)
	call ?bank
	
	; Swap registers from CP/M to Z80 conventions
	ex de,hl
	
	; Preserve destination and length
	push de
	push bc
	
	; Copy from source to buffer
	ld de,mov$buf
	ldir
	
	; Recover length and destination, preserve source
	pop bc
	pop de
	push hl
	
	; Select destination bank
	ld a,(mov$dst$b)
	call ?bank
	
	; Copy from buffer to destination
	ld hl,mov$buf
	ldir
	
	; Recover source
	pop hl
	
	; Swap registers from Z80 to CP/M conventions
	ex de,hl
	
	; Make sure that the next call to move (via ?mov vector) uses the regular move routine.
	ld bc,?move
	ld (?mov+1),bc
	ret

mov$src$b:
	db 0
mov$dst$b:
	db 0

mov$buf:
	ds 128
else
	; Unbanked
	ret
endif

This implementation works by changing the ?mov vector in the BIOSKRNL to point at our banked$move routine after a request to ?xmove. Once we've carried out the banked move, the original ?move routine is restored to the ?mov vector.

Once you have assembled and linked your BNKBIOS3.SPR, RESBDOS3.SPR and BNKBDOS3.SPR you can use GENCPM to create your new CPM3.SYS. You'll need to answer some questions differently to support the banked system:

Bank switched memory? Y.
Common memory base page? E0 (if using the NAND gate circuit above – our common area starts at $E000).
Number of memory segments? 1 – we have three in total (bank 0, bank 1 and common) however bank 1 and common are not included in the segment table so should be ignored here.
Memory segment table base, size, bank: 01, 90, 00 (we want to keep CP/M out of the "zero page" so start the segment from $0100, CP/M 3 starts at $9100 so we have $9100-$0100=$9000 as our size, the bank number is 0).

Before being prompted for the memory segment table GENCPM will display where CP/M 3 itself is using memory so you can use that to figure out how much free space you have on your bank zero for your segment definition. However, if you enter a value that is too large GENCPM will automatically reduce the size for you.

After this you will be prompted to create disk and directory buffers for each of your disk definitions – pay attention to available space to get an idea of how many buffers you can create, but if in doubt just allocate a single buffer for each disk/directory as prompted as that will at least get you booted, then you can experiment with larger buffers later.

I did intentionally start my segment from $0100 instead of $0000 and this is to avoid problems with interrupts and to keep the zero page free. My computer design uses interrupts to signal to the Z80 that keys are available (for example) instead of requiring it to constantly poll the I/O controller. However, I did find that if I interrupted the CPU (e.g. by pressing a key) when it had switched over to page 0 it would hang the computer as the ISR vector had been switched out from underneath it. My ISR is in common memory and I just make sure that when the computer boots it installs its interrupt vectors in every memory bank so that it doesn't matter which is currently swapped in, it'll always find its way to the common ISR.

After making these changes I was greeted with a 60KB TPA instead of the previous 49KB TPA – 11KB of extra memory is well worth it, and the improved line editor in CP/M 3 is another nice bonus. I did think that implementing this was going to be a nightmare, but in the end I only needed one extra NAND gate and a few easy changes to the software.

Addendum (31st August 2023): One other change you will need to implement is to support disk operations reading from or writing to specific memory banks. I forgot to mention this earlier as it's handled by the setbnk routine inside BIOSKRNL, and that routine stores the selected DMA bank number in the @dbnk variable. When your BIOS performs a disk read or write operation it will need to preserve the current bank number, switch to the bank number in @dbnk, carry out the read or write operation, then restore the previous bank number.

In my case, disk I/O is handled by the AVR I/O controller where operations are set up by sending over the DMA address, sector and track numbers, drive index and then performing a read from either the "read" or "write" ports to initiate the I/O operation and retrieve the status. The only change required was to make sure that the bank number is also sent over before initiating the I/O request so the AVR knows which bank it should be accessing:

fd$copy$ptrs:
	
	ld hl,(@dma)
	ld a,l
	out (disk$dma$l),a
	ld a,h
	out (disk$dma$h),a
	
	ld hl,(@sect)
	ld a,l
	out (disk$sector$l),a
	ld a,h
	out (disk$sector$h),a
	
	ld hl,(@trk)
	ld a,l
	out (disk$track$l),a
	ld a,h
	out (disk$track$h),a
	
	ld a,(@adrv)
	out (disk$drive),a
	
	if banked
		ld a,(@dbnk)
		out (disk$dma$bank),a
	endif
	
	ret

fd$write:
	call fd$copy$ptrs
	in a,(disk$write)
	ret

fd$read:
	call fd$copy$ptrs
	in a,(disk$read)
	ret

I'm pretty sure I didn't forget anything else!

Reverse engineering Z-Tape for the Cambridge Z88

Sat, 10 Jun 2023 02:21:53 +0100

When reading about the Cambridge Z88 computer and its available software I bumped into the occasional mention of Z-Tape by Wordmongers, a system that allowed you to back up files from your Z88 to a cassette recorder. I had wondered how this worked, assuming there some sort of external hardware to connect the cassette recorder to the Z88 (likely via its serial port). I'd done some work on tape loading and saving myself for the Sega Master System and had come up with a somewhat hacky but minimal solution that relies on abuse of a hex inverter. Surely a commercially-released product would have a better way of doing things, or at least so I thought!

More recently I noticed someone had uploaded a copy of the application and some accompanying documentation to the Cambridge Z88 page on SourceForge, so I downloaded it to take a look and was very surprised at what I found:

That can't work, surely? The output for recording seems sensible enough, using the 1Ω resistor to ground on the output to reduce the level down to something that could be fed into a sensitive microphone input, but just running the earphone output directly into the RS-232 port's CTS line doesn't seem like it would do the job. There's only one way to find out, though, and that's to build a cable and try it out and to my surprise it does indeed work!

I have had a few issues with this, however. The program appears to require that the phase of the data played back into the Z88 matches the phase that it was recorded. Both of my cassette recorders reverse the phase when playing back the recordings. Fortunately one of them does have a phase reversal switch, and two wrongs in this case does make a right and by setting the phase switch to "reverse" it allows Z-Tape to load back the recorded data.

The overall loader is not particularly reliable, though. It relies on a very strong output from the cassette recorder to successfully register a signal on the Z88's serial port, and I find I have to rewind to try again quite often. That it works at all with such a simple cable is certainly impressive, though.

In my testing I wrote a little BASIC program that crudely checks the signal level on the RS-232 input. You can use this to test the strength of your cassette recorder's output: it will display a rolling progress bar with the approximate signal strength. With my cassette recorder I can get over 80% when playing back a block, but I can't register anywhere near that when connecting the Z88 to my PC's audio output or my phone's headphone socket and consequently can't load back recordings from those devices.

10 *NAME Tape Level Test
20 REPEAT
30   S%=0
40   FORI%=0TO99:S%=S%+(GET(&E5)AND1):NEXT
50   S%=50-ABS(50-S%)
60   PRINT'S%*2;"% ";CHR$1;"R";CHR$1;"3N";CHR$(32+S%);" ";CHR$1;"G";CHR$1;"3N";CHR$(32+(50-S%));" ";CHR$1;"3-RG ";
70 UNTIL INKEY(0)<>-1
80 PRINT

Once I'd experimented with Z-Tape and a cassette recorder I thought it would be interesting to see how it worked and whether I could reverse-engineer the format used. I connected the Z88 to my PC, made some recordings, and then set to work.

Bit-level format

The first thing to do is to establish the base frequency. After taking a recording from the Z88, I checked it in Audacity's frequency analyser and found a strong peak at 1590Hz:

There is also a strong peak at 3195Hz, which is very close to twice the other peak's frequency (halving it gives us 1597.5Hz, close to 1590Hz). Based on these measurements it would seem that the base frequency is around 1600Hz, and likely that the tape format is a combination of 1600Hz and 3200Hz tones. Zooming into the recorded waveform shows the two different tones:

A common way to record data on tape is to use one full cycle of the base frequency to represent a "0" bit and two full cycles of twice the base frequency to represent a "1" bit. This means that the data is the same length regardless of how many "0"s or "1"s appear in the data, and looking at the length of data blocks in the recording they were all the same length, so it seems this is a possible candidate.

The phase of the signal is also important. If we represent the signal as a sine wave, a phase of 0° would start at zero, increase in the positive direction for the first quarter of the wave, head down in the negative direction for the next half of the wave, before returning to zero in a positive direction in the last quarter of the wave. Conversely a phase of 180° would start from zero but go negative in the first half of the wave before going positive in the second half of the wave. The phase can be determined by looking at the start of the signal after a period of silence:

As the signal goes positive first after a period of silence we can confirm the signal has a phase of 0°. In summary, the bit-level format required by Z-Tape is as follows:

Base frequency of 1600Hz.
Phase of 0°.
"0" bits encoded as one full cycle at base frequency (1600Hz).
"1" bits encoded as two full cycles at twice the base frequency (3200Hz).

Block-level format

Now that we have a stream of bits, we can group them into blocks of data on the tape. Each block starts with a leader or pilot tone, which is effectively a long stream of "1" bits (3200Hz). This lasts 1.25 seconds, after which there is a very brief silence (around two full waves in length) followed by the stream of bits that make up the actual block data.

I created some files on the Z88 that followed certain obvious patterns, for example a file that alternated $00 bytes and $FF bytes so you'd expect to see eight consecutive "0" bits in the recording followed by eight consecutive "1" bits. This would help check to see if there were any start, stop or parity bits in the data (or if it was just eight plain bits of data). I also had a file that contained all of the numbers from $00 to $FF consecutively, so you'd be able to see a clear pattern of byte values counting up and use this to check whether the data was sent least-significant or most-significant bit first.

Using these files I quickly found that the data in each block always starts with two zero bits (immediately after the leader or pilot tone) and is then sent in plain 8-bit bytes (no start, stop or parity bits) with the least significant bit sent first. Each block always contains 1031 bytes of raw data, no matter the size of the file being transmitted. I knew that there was a checksum as Z-Tape would occasionally grumble when loading about a checksum error and I could see that after transferring small files there'd be data at the start of the block, a gap filled with zeroes, followed by a final non-zero data byte. I assumed this was the checksum, and found that by adding up all 1031 bytes in the block the result always came to zero. The checksum can therefore be calculated by setting a counter to zero, subtracting the value of every byte in the 1030 data bytes of the block, and then appending the counter value to as the 1031^st byte of the block.

In summary, the block-level format is as follows:

1.25 seconds of 3200Hz leader or pilot tone (stream of "1" bits).
Silence for the duration of two full cycles.
Two "0" bits, sent as two full cycles of the 1600Hz tone.
1030 data bytes, each sent as eight plain bits, least significant bit first.
- "0" bits sent as one full cycle of 1600Hz tone.
- "1" bits sent as two full cycles of 3200Hz tone
Checksum data byte, sent in same manner as other data bytes, but calculated such that adding up all 1031 data bytes in the block results in 0.

There is approximately half a second of silence between data blocks, though the actual amount of time depends on how much work the Z-Tape application has to do to prepare each block. When building the catalogue before sending a large number of files I've seen gaps over 24 seconds long!

Block contents

Each block always contains 1030 bytes of data plus a checksum byte, and for the sake of simplicity I'll ignore the checksum in the discussion below.

The first byte of each block's data determines what sort of block it is. I've identified six different block types.
The next two bytes are the size of the data included in the block, least significant byte first, though sometimes this value is incorrect or missing depending on the particular type of block.
After that are two bytes that record the block number, least significant byte first. The first block has a block number of 0 and this counts up one for every block on the tape.
After this you'll find the actual data associated with the block, normally up to 1024 bytes, with the rest of the block padded with zeroes.

Blocks $04 and $05: Catalogue blocks

When storing a selection of files on tape Z-Tape writes a catalogue file first containing a list of files. The final block in the catalogue is sent with a block type of $05, if more than one block is required to represent the catalogue then preceding partial catalogue blocks use a type of $04.

Catalogue blocks always have a reported size field of zero.

Each file entry is stored in a record 28 bytes long. As each block can store up to 1025 bytes of user data this allows for up to 36 files to be described in each catalogue block.
The records always start from offset 5 into the block (one byte block ID, two byte size = 0, two byte block number) and each takes the following format:

Bytes 0~15: Filename.
Byte 16: 0 (NUL terminator for filename).
Bytes 17~21: File size as floating-point number (four byte mantissa, MSB first, followed by exponent).
Bytes 22~24: Three byte time (centiseconds since start of day, LSB first).
Bytes 25~27: Three byte Julian date (number of days since Monday 23rd November 4713 BC, LSB first).

Filenames can be up to sixteen characters long (12 filename characters, a dot, three extension characters). They can be mixed case.

The file size being a floating-point number took me a while to figure out! This is the numeric format used by BBC BASIC (Z80) and is also internally used by the Z88 OS for its FPP routines. The format for this number can be found in the BBC BASIC documentation, though for the sake of simplicity if you're creating your own catalogue in Z-Tape format note that it does accept the "special case" real number where the exponent is set to 0 and the mantissa is a regular integer. If you're decoding tapes created by Z-Tape you'll need to decode the floating-point number yourself, though.

The date and time are in the format used internally by the Z88 OS. The only challenge here is the Julian day is outside the range that can be represented by some programming language date and time functions which can complicate matters. Here's a snippet of C# that works if you're trying to convert a catalogue date and catalogue time to a .NET DateTime object:

var catalogueDate = DateTime.FromOADate(catalogueDateNum - 2415019);
catalogueDate = catalogueDate.AddMilliseconds(catalogueTimeNum * 10);

Blocks $01 and $06: File start blocks

These blocks appear at the start of a file. Block type $06 is used if the whole file data can fit in a single block, $01 if additional blocks containing the rest of the file will follow.

The block size is used here to determine how many bytes of data are present. This will be the size of the whole file if the block type is $06, $03E0 (992 bytes) if the block type is $01.
Block bytes from 5 to 31 contain a copy of the filename, padded with zeroes. This must be in UPPERCASE, regardless of how the file was listed in the catalogue, otherwise the Z-Tape loader will be unable to recognise the file by name (this one took a while to puzzle out!)

After this comes the file data. If this is a block type $06 that's the end of it, but if it's block $01 more file data will follow...

Block $02 and $03: File data blocks

These blocks contain raw file data from offset 5 (there is no filename field, as with blocks $01 and $06) and appear in the middle or end of files. If the block type is $02 then this block appears in the middle of the file and it always contains 1024 bytes of data, though the header will report it contains $03E0 (992 bytes) and should be ignored. If it's block type $03 then that corresponds to the end of the file, and the data length should be taken into consideration.

Block types summary

The following table documents the block types. All multi-byte numeric values are transmitted least significant byte first with the exception of the floating-point numbers representing the file sizes in the catalogue described earlier.

Offset	Catalogue		File
Offset	Partial catalogue block	Final catalogue block	File fits in single block	First file block	Middle file block	Last file block
0	$04	$05	$06	$01	$02	$03
1~2	$0000		Data length		$03E0	Data length
3~4	Block number (starting from 0 for the first block)
5	Up to 36 28-byte records listing the files about to follow.		The UPPERCASE name of the file, zero-padded to 27 bytes in length.		1024 bytes of file data.	Data length bytes of file data.
32	Up to 36 28-byte records listing the files about to follow.		Data length bytes of file data.		1024 bytes of file data.	Data length bytes of file data.
1030	Checksum calculated so that adding up all 1031 bytes results in 0.

Creating Z-Tape audio on a PC

This is all well and good, but what's the point of it? The information above may be useful if someone has an old tape that they needed to recover data from but no longer had a Z88, though that seems like a fairly remote possibility. Another possibility could be to create Z-Tape data from files on PC and then play it back to transfer data from the PC to the Z88. Alternatively, a selection of programs could be stored on a CD and loaded onto the Z88 from a portable CD player when out and about.

Maybe not the most useful ideas, but here's a C# function that will take an array of filenames and generate a series of data blocks in the Z-Tape format, including a catalogue:

static byte[][] CreateBlocksFromFiles(string[] files) {

    List<byte[]> blocks = new List<byte[]>();

    // generate the catalogue
    for (int firstFileInBlock = 0; firstFileInBlock < files.Length; firstFileInBlock += 36) {

        // which is the last file in the block (+1) that we will write to the file?
        var lastFileInBlock = Math.Min(files.Length, firstFileInBlock + 36);

        // catalogue block data is 1030 bytes, same as all other blocks
        var catalogue = new byte[1030];
        
        // if the is the last block in the catalogue, block type is 0x05, otherwise it's 0x04
        catalogue[0] = (byte)((lastFileInBlock == files.Length) ? 0x05 : 0x04);

        // current block number
        catalogue[3] = (byte)(blocks.Count >> 0);
        catalogue[4] = (byte)(blocks.Count >> 8);

        // write each file for this block to the catalogue
        var catalogueOffset = 5;
        for (int fileInBlock = firstFileInBlock; fileInBlock < lastFileInBlock; ++fileInBlock) {

            var file = new FileInfo(files[fileInBlock]);

            // file name (can be mixed case)
            Array.Copy(Encoding.ASCII.GetBytes(file.Name.PadRight(16, '\0')[..16]), 0, catalogue, catalogueOffset, 16);

            // file size (Z-Tape normally uses floating-point values)
            catalogue[catalogueOffset + 17] = (byte)(file.Length >> 24);
            catalogue[catalogueOffset + 18] = (byte)(file.Length >> 16);
            catalogue[catalogueOffset + 19] = (byte)(file.Length >> 8);
            catalogue[catalogueOffset + 20] = (byte)(file.Length >> 0);

            // file date/time
            var writeTime = file.LastWriteTime;

            // time is centiseconds since midnight
            var fileTime = (int)(writeTime.TimeOfDay.TotalMilliseconds / 10);
            catalogue[catalogueOffset + 22] = (byte)(fileTime >> 0);
            catalogue[catalogueOffset + 23] = (byte)(fileTime >> 8);
            catalogue[catalogueOffset + 24] = (byte)(fileTime >> 16);

            // date is Julian day number
            var fileDate = (int)(writeTime.ToOADate() + 2415019);
            catalogue[catalogueOffset + 25] = (byte)(fileDate >> 0);
            catalogue[catalogueOffset + 26] = (byte)(fileDate >> 8);
            catalogue[catalogueOffset + 27] = (byte)(fileDate >> 16);

            catalogueOffset += 28;
        }

        blocks.Add(catalogue);

    }
    
    // write each file to the tape
    foreach (var filePath in files) {

        var file = new FileInfo(filePath);

        using (var fileData = file.OpenRead()) {
            do {

                var fileBlock = new byte[1030];

                // current block number
                fileBlock[3] = (byte)(blocks.Count >> 0);
                fileBlock[4] = (byte)(blocks.Count >> 8);

                // how much data can we store in the block?
                var maxBlockData = 1024;
                var blockDataOffset = 5;

                if (fileData.Position == 0) {

                    // if it's the first block for the file, store the filename (must be UPPERCASE)
                    Array.Copy(Encoding.ASCII.GetBytes(file.Name.ToUpperInvariant().PadRight(16, '\0')[..16]), 0, fileBlock, blockDataOffset, 16);
                    blockDataOffset = 0x20;

                    // can't store as much in the first block due to all the header info we just wrote
                    maxBlockData = 992;

                    // what sort of block is it?
                    if (file.Length > maxBlockData) {
                        fileBlock[0] = 0x01; // first block in a multi-block file
                    } else {
                        fileBlock[0] = 0x06; // single block for the whole file
                    }

                } else {

                    // what sort of block is it?
                    if (file.Length > fileData.Position + maxBlockData) {
                        fileBlock[0] = 0x02; // continued data block in a multi-block file
                    } else {
                        fileBlock[0] = 0x03; // last data block in a multi-block file
                    }

                }

                // how much data can we actually copy?
                var actualBlockData = Math.Min(maxBlockData, (int)(file.Length - fileData.Position));

                // read the data
                if (fileData.Read(fileBlock, blockDataOffset, actualBlockData) != actualBlockData) {
                    throw new InvalidDataException();
                }

                // store the data size
                fileBlock[1] = (byte)(actualBlockData >> 0);
                fileBlock[2] = (byte)(actualBlockData >> 8);

                blocks.Add(fileBlock);

            } while (fileData.Position < fileData.Length);
        }

    }

    return blocks.ToArray();
}

Once the blocks have been generated, we can convert them to a tape format like UEF:

static void WriteUef(string filename, IEnumerable<byte[]> blocks, ushort baudRate = 1600, bool reversePhase = false) {

    using (var uefFile = File.Create(filename))
    using (var uefWriter = new BinaryWriter(uefFile)) {

        // Header
        uefWriter.Write(Encoding.ASCII.GetBytes("UEF File!\0"));
        uefWriter.Write((byte)0x0A); // minor version
        uefWriter.Write((byte)0x00); // major version

        // Chunk &0113 - change of base frequency 
        uefWriter.Write((ushort)0x0113);
        uefWriter.Write((uint)4);
        uefWriter.Write((float)baudRate);

        // Chunk &0115 - change of phase
        uefWriter.Write((ushort)0x0115);
        uefWriter.Write((uint)2);
        uefWriter.Write((ushort)(reversePhase ? 180 : 0));

        // Write each block to the UEF
        foreach (var block in blocks) {

            // Calculate the checksum
            byte checksum = 0;
            foreach (var b in block) {
                checksum -= b;
            }

            // Chunk &0110 - carrier tone
            uefWriter.Write((ushort)0x0110);
            uefWriter.Write((uint)2);
            uefWriter.Write((ushort)(baudRate * 5 / 4));

            // Chunk &0112 - integer gap
            uefWriter.Write((ushort)0x0112);
            uefWriter.Write((uint)2);
            uefWriter.Write((ushort)2);

            // Chunk &0102 - explicit tape data block 
            uefWriter.Write((ushort)0x0102);
            uefWriter.Write((uint)2);
            uefWriter.Write((byte)14); // bit count = (chunk length * 8) - 14 = 2 bits
            uefWriter.Write((byte)0); // 2 zero bits

            // Chunk &0102 - explicit tape data block 
            uefWriter.Write((ushort)0x0102);
            uefWriter.Write((uint)(2 + block.Length));
            uefWriter.Write((byte)8); // bit count = (chunk length) * 8 - 8
            uefWriter.Write(block);
            uefWriter.Write(checksum);

            // Chunk &0112 - integer gap
            uefWriter.Write((ushort)0x0112);
            uefWriter.Write((uint)2);
            uefWriter.Write((ushort)(baudRate / 2));
        }
    }

}

A .wav file is probably an easier format to work with, however!

static void WriteWav(string filename, IEnumerable<byte[]> blocks, int baudRate = 1600, bool reversePhase = false, uint sampleRate = 48000, uint channelCount = 1, ushort bitsPerSample = 16) {

    // generate cycles
    var cycleSampleCount = sampleRate / baudRate;

    var bits = new byte[3][]; // good old ternary logic - true, false, and file_not_found.
    
    for (int b = 0; b < 3; ++b) {
        bits[b] = new byte[cycleSampleCount * bitsPerSample / 8 * channelCount];
    }

    for (int c = 0; c < cycleSampleCount * channelCount; ++c) {
        double a = ((c / channelCount) * Math.PI * 2.0d) / cycleSampleCount;

        for (int b = 0; b < 3; ++b) {
            
            double v = b == 2 ? 0 : Math.Sin(a * (1.0d + b));

            if (reversePhase) v = -v;

            switch (bitsPerSample) {
                case 8:
                    bits[b][c] = (byte)Math.Round(Math.Max(byte.MinValue, Math.Min(byte.MaxValue, 127.5d + 127.5d * v)));
                    break;
                case 16:
                    short vs = (short)Math.Round(Math.Max(short.MinValue, Math.Min(short.MaxValue, (short.MaxValue + 0.5d) * v)));
                    bits[b][c * 2 + 0] = (byte)(vs >> 0); bits[b][c * 2 + 1] = (byte)(vs >> 8);
                    break;
            }
        }
    }


    using (var wavFile = File.Create(filename))
    using (var wavWriter = new BinaryWriter(wavFile)) {

        // RIFF header
        wavWriter.Write(Encoding.ASCII.GetBytes("RIFF")); // chunk ID
        
        var riffDataSizePtr = wavFile.Position;
        wavWriter.Write((uint)0); // file size (we'll write this later)

        wavWriter.Write(Encoding.ASCII.GetBytes("WAVE")); // RIFF type ID

        // chunk 1 (format)
        wavWriter.Write(Encoding.ASCII.GetBytes("fmt ")); // chunk ID
        wavWriter.Write((uint)16); // chunk 1 size
        wavWriter.Write((ushort)1); // format tag
        wavWriter.Write((ushort)channelCount); // channel count
        wavWriter.Write((uint)sampleRate); // sample rate
        wavWriter.Write((uint)(sampleRate * channelCount * bitsPerSample / 8)); // byte rate
        wavWriter.Write((ushort)(channelCount * bitsPerSample / 8)); // block align
        wavWriter.Write((ushort)bitsPerSample); // bits per sample

        // chunk 2 (data)
        wavWriter.Write(Encoding.ASCII.GetBytes("data")); // chunk ID
        var waveDataSizePtr = wavFile.Position;
        wavWriter.Write((uint)0); // wave size (we'll write this later)

        var waveDataStartPtr = wavFile.Position;

        // write half a second of silence
        for (int i = 0; i < baudRate / 2; ++i) {
            wavWriter.Write(bits[2]);
        }

        // Write each block to the WAV
        foreach (var block in blocks) {

            // write 1.25 seconds of carrier tone
            for (int i = 0; i < baudRate * 5 / 4; ++i) {
                wavWriter.Write(bits[1]);
            }

            // write gap
            wavWriter.Write(bits[2]);
            wavWriter.Write(bits[2]);

            // write two 0 bits
            wavWriter.Write(bits[0]);
            wavWriter.Write(bits[0]);

            // calculate the checksum as we go
            byte checksum = 0;

            // write all of the bytes in the block
            for (var i = 0; i < block.Length + 1; ++i) {

                // fetch the byte to write
                byte b;

                if (i < block.Length) {
                    // use data from the block and update the checksum
                    b = block[i];
                    checksum -= b;
                } else {
                    // write the checksum
                    b = checksum;
                }

                // write each bit, LSB first
                for (int bit = 0; bit < 8; ++bit) {
                    wavWriter.Write(bits[b & 1]);
                    b >>= 1;
                }
            }

            // write half a second of silence
            for (int i = 0; i < baudRate / 2; ++i) {
                wavWriter.Write(bits[2]);
            }
        }

        // update wave size
        var waveDataEndPtr = wavFile.Position;
        
        wavFile.Seek(waveDataSizePtr, SeekOrigin.Begin);
        wavWriter.Write((uint)(waveDataEndPtr - waveDataStartPtr));

        // update RIFF size
        wavFile.Seek(riffDataSizePtr, SeekOrigin.Begin);
        wavWriter.Write((uint)(waveDataEndPtr - 8));

    }

}

But, I hear you say, didn't you earlier mention how a PC's audio output was now powerful enough to drive the Z88's serial port? I did indeed, and that's why I've also put together this little circuit:

This is based on the tape interface circuit I devised for the Sega Master System and uses an SN74LS04N hex inverter chip as an amplifier to drive the Z88's CTS line. It's designed to be powered from the Z88's serial port which provides 5V at 1mA on the DTR pin. This current limit does seem awfully low and I have seen it reported as 10mA in some places but I'm not sure if that's a typo or not — the user manual states 1mA. In my testing this circuit consumes between 2mA-3mA which is much more than 1mA but it does still work, however I would strongly recommend doing your own testing before hooking anything up to your Z88's serial port. The other hex inverter chips I tried all consumed over 20mA in this use which is far too much for the Z88! There was a noticeable difference in current consumption depending on whether unused inputs were tied high or tied low, so please do your own testing.

The presence of a phase switch does allow this circuit to be used with recorders that reverse the phase when recording but don't provide a phase reversal switch of their own to fix this on playback.

All in all I'm very impressed that the Z-Tape software works as well as it does considering the simplicity of the hardware, and it's been a lot of fun digging into how it works.

Updated TI-83 Plus BootExec with support for TI's "Silver Link" driver

Wed, 07 Jun 2023 01:32:26 +0100

The previous release of the TI-83 Plus BootExec program relied on temporarily replacing TI's Silver Link driver with WinUSB if you wanted to use the Silver Link USB cable. I've updated the program so it will try to use TI's driver if it's available, or WinUSB if not. This should help people who can't (or don't want to) temporarily replace TI's driver.

The updated application can be downloaded, as before, from the same link: ti83p-bootexec.zip.

Updated TI-83 Plus BootExec with USB "Silver Link" support

Sun, 04 Jun 2023 17:52:26 +0100

This is a quick update to the TI-83 Plus BootExec program described in a previous journal entry. The program now supports the USB "Silver Link" cable (as well as the serial "Black Link" it previously supported) though to access the USB device you do need to temporarily replace TI's supplied driver with a generic WinUSB one which can be organised with ti83p-bootexec.zip.

Unbricking a TI-83 Plus calculator with a link buffer overflow

Fri, 02 Jun 2023 16:53:13 +0100

A few years ago I started running into problems with my TI-83 Plus graphical calculator. I was unable to install applications – it would keep locking up when "defragmenting". In the end I attempted to reinstall the operating system to see if that would cure matters, but that failed too and in the process left the calculator in a state where it wouldn't boot at all. Switching it on you'd be presented with a screen prompting you to reinstall the OS:

Waiting...

Please install
calculator
software now.

If you tried to install the OS over the link port it would switch to a progress screen but then get permanently stuck at the 0% mark until you pulled a battery out.

I eventually found a program called Overflow by Brandon Wilson which described similar symptoms and a possible cause – a corrupt certificate page. Considering the problems I'd been having with the flash ROM before attempting the OS reinstallation it seemed possible that my certificate page might have become corrupt and that was preventing me from reinstalling the OS.

The Overflow program describes a technique whereby it can transfer a user-supplied program to the target calculator by sending a very large variable packet and taking advantage of a lack of bounds checking in the calculator's boot code. Unfortunately, I was unable to get it to work on my TI-83 Plus, in spite of many repeated attempts. I eventually bought a replacement calculator, though being a newer model and built to a much cheaper standard I was always a bit disappointed that my original calculator was lingering, bricked, in a drawer.

Photo of the repaired calculator (right) next to the its temporary replacement (left) – note the missing ID on the repaired calculator.

More recently I decided to revisit the problem, got a better understanding of just how the Overflow program worked and found a way to get it work on my original TI-83 Plus. The photo above shows the two working calculators I now have, though as I ended up having to erase the certificate page on the one on the right it now lacks an ID.

How Overflow works

The basic technique exploited here is that the TI-83 Plus boot code does not bounds-check the length of the link packet we're sending it, so by sending a very large packet we can overflow the intended buffer right up to user memory, send over a program we wish to execute, and then overwrite the Z80 stack with the address of our program so that when the link routines return it executes our program rather than returning to the boot code.

Overflow satisfies this process by filling up the memory as described above, then sending some correcting data so that the checksum for the oversized packet is equal to zero, and then sending a constant stream of zeroes until the transfer fails. The last two bytes of a transfer are the checksum, and by previously correcting the packet's checksum to zero this means that the packet will be seen as valid.

At this point the transmitting calculator detects the link error and tries to read back the acknowledgement from the receiving calculator, and all should be well.

Unfortunately, the TI-83 Plus seems to be more fussy about how it handles linking errors and once the attempt to send too many zero bytes has failed it just displays an error message and switches off, rather than letting us receive the acknowledgement before executing our payload.

Looking at the documentation for Overflow it seems to have been intended more for the TI-84 Plus series calculators, so it could be that they are more forgiving of the linking errors.

Trial-and-error with zero padding

If the problem is that we're sending too many zero bytes, one option is to count how many zero bytes we can send successfully. Once the attempt has failed, we can then make sure that on our next attempt we only send just the right number of zero bytes (based on our previous count) and no more, then check for the acknowledgement from the receiving calculator. To my delight this strategy works well, and is provided by the application's -zeropad option.

Unfortunately as over 30,000 zeroes need to be sent each time the exploit packet takes a long time to transmit and as we now need to do it twice this can really slow things down! Once a safe number is known this can be specified with -zeropad=<count> but it's still a time-consuming process.

Fixed-size packets for quicker transmission

The problem here is not knowing the size of the packet we're transmitting. The packet does start with a length parameter, however as the "number of bytes left to receive" counter is stored on the calculator's stack by the receiving routine we end up overwriting that with our exploit payload and the total number of bytes left to receive will end up depending on the particular stack level at the time.

In my testing the variable ends up being stored on the stack at the same address ($FFC1 for normal transfers, $FFBF for ones where the flash was previously unlocked). Knowing this means that as we trample over the stack deploying our exploit we can at least make sure that we leave that value in the state it should be for the current point in the packet transfer.

This is implemented in the program with the -fixed parameter, which executes much more quickly than the -zeropad one and only needs to run through once. It is however reliant on knowing exactly where on the stack the "number of bytes left to receive" variable is stored; if it's different from the two presets baked into the program it can be changed with -fixed=<hex addr>.

The program itself

In case it helps anyone else out, the program can be downloaded from this link. It's a .NET application and requires a computer with a serial port and a "black link" compatible serial cable (I use a home-made cable), which I appreciate is not exactly the most modern solution but is what I have access to.

It will allow you to transfer a standard "noshell" TI-83 Plus assembly program to the target calculator, with or without flash unlocked. As this is a potentially risky operation (especially with flash unlocked, which would allow you to completely brick the calculator by damaging the boot code) any such programs are left as an exercise to the user to be used at their own risk. The original Overflow program contains much more useful information, including a sample program that can erase the certificate page, though be warned that as written is is not designed for the TI-83 Plus and will erase the wrong page and so will need to be modified before use. This is only recommended as a last chance for calculators that are otherwise bricked and unusable!

Update 4th June 2023: The program now supports the USB "Silver Link" cable, though you will need to temporarily replace TI's driver with a generic WinUSB driver using Zadig. The download link is the same as before.

Update 7th June 2023: The program will now try to use TI's driver for the "Silver Link" USB cable, if available. This avoids the need to temporarily replace it with the WinUSB driver.

Using a VDrive to access USB flash drives from a Cambridge Z88

Sat, 13 May 2023 03:11:02 +0100

The VDrive is a handy module for electronic projects that need to access files on a USB flash drive. It's based around a USB host microcontroller and comes preinstalled with some firmware that provides control over the drive with simple commands sent via a serial connection (UART or SPI).

A few years ago I started putting together some code to connect the module to my Cambridge Z88 computer. All I needed was a way to power the drive and a MAX232 chip to translate the computer's RS-232 interface to the VDrive's logic levels, and after around 150 lines of BBC BASIC I had a program that could show directory listings, let me browse folders, and fetch files from the USB drive to the Z88's file system.

This worked well enough but was a bit clumsy. For example, to maintain good performance rather than alternate between reading a single byte from the drive and writing it to the local file system it's better to read and write larger chunks at a time. BBC BASIC doesn't provide a built-in way to do that, though you can read or write CR-terminated strings. When you read each part of the file this way you therefore need to decide whether the string you've just read is a certain length because you've reached a CR terminator (which isn't included in the read string), whether you've reached the end of the file, or whether the string buffer is full, and from that piece the file back together. I got this working quite well but it's still fundamentally an inelegant hack. Doing it properly would require some assembly code, and that would also be required for some other operations (such as properly transferring date and time modification information) that are otherwise not possible from pure BASIC.

Fortunately, BBC BASIC has a built-in assembler and that makes integration of assembly code in BASIC programs quite a bit easier than it would otherwise be. However, as I considered the amount of assembly code required would be quite high, I thought it might be more sensible to just rewrite the program as a native Z88 popdown application.

Status dialog shown when fetching a file from the drive

This is what I ended up doing, and it can be downloaded from its product page. It was quite a lot of fun to learn my way around the Z88's OS – not just for things like file handling, date and time manipulation, and integration with menu and help system but for some of the challenges involved in writing Z80 code for a system that shares memory between multiple running applications (and the file system) rather than my usual environment of having a big block of contiguous RAM to do whatever I fancied in.

The directory listing is the most obvious place where I had to rely on dynamic memory allocation. Each file or folder name being sent in a directory listing by the VDrive is allocated its own memory and I arranged the names together in a linked list that is sorted with an insertion sort.

Being my first Z88 application it's not especially well written but I've been using it for a while now and it seems to work well enough so I've released it, both on this very website and on GitHub.

Take your TI-83 Plus online with a TIWiFiModem

Mon, 27 Mar 2023 20:38:24 +0100

One of the issues holding me back with my development of the Light Gun Commando project (aside from a lack of free time due to the day job) was running out of prototyping breadboards and the difficulty of swapping between different console adaptor boards for testing.

Normally by this point I'd have started soldering together more permanent prototypes on little circuit boards, but I've been having a difficult time with the boards I've got in stock apparently being made of a metal that's impossible to solder to. They were very cheap, but for some reason the solder joints would end up coming out blobby, make poor connections, be prone to bridges and generally not "wetting" the pads at all. This makes hardware prototyping very frustrating and time-consuming, and though I'd tried different solder (no change), different temperatures (higher heats just meant the pads would unglue from the board more quickly), more flux (just more cleaning required afterwards) and other attempts to clean the boards before use (including light sanding) I wasn't getting very far.

I eventually bought a set of new circuit boards from a more reputable seller but before cracking on with my light gun adaptors I thought I should try a more straightforward weekend project and I ended up building myself a RetroWiFiModem.

This is a device that looks like an old dial-up modem and though it does have an RS-232 serial port on the back to connect it to a computer it doesn't attach to a phone line but instead connects to a modern Wi-Fi network. You can send it Hayes-style AT commands and "dial out" to a domain name which will then open a Telnet (or raw socket) connection to the remote computer and allow you to exchange data. As long as your old computer has a terminal emulator on it you can use this to connect to and browse online services such as BBSes.

I had a lot of fun building this and setting this up – especially as I can confirm that the circuit went together extremely easily on my new prototyping circuit boards – and it reminded me that I'd seen a terminal emulator program for the TI-83 Plus calculator around 20 years ago by the name of Telnet 83 Plus. The documentation accompanying the program had lots of information in it about how to connect to a modem using the calculator's grey serial link cable which directly translates the calculator's link protocol to true 9600 baud RS-232, unlike the black cable which I owned which just uses the control lines to bit-bang the calculator's link protocol. As I never had the equipment for this the program only ever ended up being a curiosity to me, but having seen how well the RetroWiFiModem worked I thought it could be adapted for use on a calculator.

To do this I wrote a simple implementation of the calculator's link protocol in a class that inherited from the Arduino's Stream class. This is the same class that the Serial class inherits from, so having done that all I needed to do was a find-and-replace of Serial.* in the original source code with tilp.* and I had a version of the RetroWiFiModem that worked when connected to a calculator. As I also wanted this version to be a little more pocket-sized I designed it around the cheap ESP-01 or ESP-01S modules, which lacks the pins to drive the status LEDs on the original version so this ended up being a slightly more slimmed-down version of the project. It still has all the networking features, though, and the end result is the TIWiFiModem:

To interact with the modem I was using Telnet 83 Plus however I'd encountered a few bugs with this program, including incompatibility with newer TI-83 Plus calculators with slower display drivers (resulting in a scrambled image on the LCD), a lack of overflow checking on the receive buffer that would cause it to truncate long transfers and the inability to type certain keys in uppercase. Fortunately the source code was included so I dusted off my Z80 assembler and fixed these issues, along with shaving a few thousand bytes off the program size, improved compatibility with some VT100 sequences, a mode that automatically keeps the cursor within the view of the screen and local echo. These changes, along with the firmware for the modem, can be found on the TIWiFiModem Github page.

If you'd like to see what the TIWiFiModem is all about before building one yourself, I put together a video demonstrating it which is embedded above.