![\"\"](\"https://z80.timholyoake.uk/media/posts/75/2026-08-29-133919_1920x1080_scrot-1024x777.png\")
\nI was talking to Derek of Extreme Kits at the RC2014 Assembly 2.0 about having to underclock the Pico 2 for the MZ-80K and MZ-80A emulations in the Pico MZ. Derek has the opposite problem on the Pico RomWBW, as it doesn't run quite as quickly as a real RC2014.
\nThere are a couple of obvious differences between the two systems, the first being that the MZ-80s run their Z80 at 2MHz, whereas the RC2014 runs at 7.37MHz. The other obvious difference is the Z80 emulation. The Pico RomWBW uses Gabriel Gambetta's libz80, whereas Pico MZ uses Nicolas Allemand's superzazu.
\nWhen I first started experimenting with the Pico MZ I was using libz80 too, but fairly quickly replaced it with superzazu as I needed something that passed all of the zexall / zexdoc tests. It also had the benefit of using the MIT license, which is how I wanted to license Pico MZ.
\nWhat I've never done is benchmark the two cores. As both have very similar interfaces, it's straightforward to experiment with changing them in Pico RomWBW1. As I'd noted previously, I'd also forked and bug fixed a copy of libz80 to correct some erroneous behaviour when running the Digital Research CBASIC compiler on Derek's RC2040.
\nUsing my standard prime number benchmark, these were the results I got with the three z80 cores I tried and on a real RC20142.
\n| Core | \nTime (seconds) to generate primes < 10,000 | \nPercentage improvement vs standard libz80 | \n
| Standard libz80 | \n213s3 | \n- | \n
| My libz80 fork | \n197s | \n7.5% | \n
| Superzazu | \n163s - 169s4 | \n23.5% - 21% | \n
| Real z80 on a RC2014 | \n143s | \n33% | \n
All things being equal, the superzazu core seems to be more efficient than the libz80 core, even with the speed improvements I made in my fork. This naturally comes at a cost as libz80 is written in a way that's easier (for me) to understand the code.
\n", "author": { "name": "Tim" }, "tags": [ ], "date_published": "2026-10-21T11:50:03+01:00", "date_modified": "2026-10-25T15:57:10+00:00" }, { "id": "https://z80.timholyoake.uk/pico-mz-release-3-1/", "url": "https://z80.timholyoake.uk/pico-mz-release-3-1/", "title": "Pico MZ Release 3.1", "summary": "This is the first release of Pico MZ in 2026. It fixes a number of problems that I've found since the 3.0 release last November and introduces the ability to read and write multi-block BSD (BASIC sequential data) files. For ease of use (and code maintenance) it combines the MZ-80K,A…", "content_html": "
This is the first release of Pico MZ in 2026. It fixes a number of problems that I've found since the 3.0 release last November and introduces the ability to read and write multi-block BSD (BASIC sequential data) files.
\nFor ease of use (and code maintenance) it combines the MZ-80K,A and 700 emulations into a single .uf2 file per Pico platform type when using a Pimoroni VGA demo base. In other words, one .uf2 file for the Pico and one for the Pico 2.
\nThere's a third .uf2 file that supports all three emulations for both of the RC2014 Pico and RP2040 VGA boards.
\nThe emulator type is selected at power on by holding down a button. Button 'A' is for the MZ-80A, 'B' or 'C' for the MZ-700. No button press at start up results in the emulator booting into MZ-80K mode.
\nThe most difficult piece of work was implementing multi-block data files. The sheer number of different ways each combination of Sharp MZ model and language tape approaches this is mind-bending. There's a note in the 1996 Sharp Users Club magazine Volume 16/3 referring to the development of SUPERCOPY that reads:
\n\"This is where the fun starts! ... Sorting out these differences, and finding ways of accommodating them, has taken us the best part of the last three months, but we have succeeded ...\"
\n\nThe article goes on to explain the key differences in BSD file format between the machines and it's fortunate that the developers of SUPERCOPY did so, as it only(!) took me a couple of weeks to implement data file handling for the SP-5025, SA-5510 and S-BASIC dialects. There's more work to do - for example, the Knight's Wee Fortran compiler doesn't use any of the three formats I've implemented so far (and so still won't save Fortran source code to 'tape' on my emulator) but that will need to wait.
\nIt will need to wait not least because the code implementing cassette tape emulation was already unstructured and rather fragile before I started to implement BSD files. It's now even more unstructured and fragile. To carry on extending cassette data file handling and hopefully implement disk data files, the code desperately needs refactoring. Definitely a winter job.
\nCombining the source code for the MZ80-K/A and MZ-700 emulations has also thrown up other opportunities for simplification and refactoring, particularly around keyboard and memory handling.
\nAlong the way to the 3.1 release I've found weirdness in busy_wait_us() and/or TinyUSB that makes using the Pico SDK 2.3.0 a non-starter for the time being. I've rationalised the way the emulator is slowed down to match real hardware by more closely linking timing delays to the number of Z80 t-states that have elapsed. I've smoothed out yet more issues in keyboard handling - the issue log for the project reads like a long lament on the differences between USB and Sharp MZ keyboards. Memory dump handling has been improved and bugfixed (again). Saving programs to sd card works more reliably. The documentation has been updated.
\nThat will definitely do for the time being. The emulator is not perfect (far from it), but it's good enough for most of my purposes and hopefully yours too, should you decide to try it.
\nThe new and improved Pico MZ will get its public debut at the RC2014 assembly at the end of September. I hope to see you there.
\nPico MZ release 3.1.1 is now available. There are a couple of bugs resolved that impacted keyboard handling on some games (for example, the MZ-700 and MZ-80K versions of Space Panic).
\n![\"A](\"https://z80.timholyoake.uk/media/posts/75/20250110_093313-1024x642.jpg\")
\nWhen the RC2014 assembly 2.0 was announced for Saturday 26th September 2026 at The National Museum of Computing, I decided to sign up as an exhibitor to give the first public outing of my Pico MZ Emulator. I had an enjoyable time at the first assembly last year. Everyone was very friendly, so it seemed less intimidating than diving into the deep end at another retrocomputing event.
\nThe Pico MZ is RC2014 adjacent for a number of reasons, not least that it will run happily on a Pi Pico VGA Terminal with an SD card backpack or on a RP2040 VGA Terminal card.
\nMy plan is to show it running 'The Valley' (and other programs) alongside a real MZ-700. I'm intending to bring along my own RC2014 also running 'The Valley' - a port I created from my Sharp MZ version a little while ago. It was an interesting exercise getting it to run on a VT100 terminal emulator rather than a memory mapped display, but the code remains true to the original.
\n![\"A](\"https://z80.timholyoake.uk/media/posts/74/20260807_160518-1024x696.jpg\")
\nI'm currently trying to make sure that everything works properly and that I have a foolproof system1 to ensure that I don't leave a vital cable or three behind at home in Devon.
\nI look forward to seeing fellow RC2014 and retrocomputing enthusiasts at the Assembly.
\nI made it to the Assembly and had a very enjoyable time meeting everyone and showing off the Pico MZ. It was also a great event for hatching my winter plans to extend the Pico MZ, tinker with the emulator on the Pico RomWBW to see if I can make it run more quickly and generally think of dozens of possible new projects.
\n![\"The](\"https://z80.timholyoake.uk/media/posts/74/1000002773-1024x768.jpg\")
\nIt's rained nearly every day since the start of 2026 in Devon. On January 27th the River Otter reached it's highest recorded level. The picture below was taken from the footbridge in Ottery St Mary that afternoon. The river was around a metre off its peak at this point, but was still a couple of metres deeper than normal and over twice as wide.
\n\n\n\n![\"The](\"https://z80.timholyoake.uk/media/posts/73/1000002643-1024x768.jpg\")
All the bad weather has meant that it's been difficult to do very much outside, so I've been entertaining myself working through 2020's Advent of Code using (mostly) Fortran 77. I finished the final puzzle this afternoon and that appears to have signalled a change in the weather for tomorrow! My solutions and commentary are in this repository, so I don't intend to go into a blow-by-blow discussion here.
\n\n\n\nI think the solutions that I'm happiest with are those for day 19 and day 24. Day 19 was fun, as I realised early on that the puzzle was about parsing a context free grammar. The design decisions I took in part 1 made part 2 straightforward. It's good that Fortran 77 doesn't have a regular expression capability as standard, because although an approach based on regex would have worked for part 1 it would not have been much fun trying to get part 2 to work that way.
\n\n\n\nDay 24 required a little thinking before realising that a hex coordinate system was needed. Creating an implementation of the Hexagonal Efficient Coordinate System was fun. The code isn't the most compact I could have written but is very readable. The 'Life' algorithm required for part 2 was also interesting to write, even after implementing a 'Life' algorithm in 3D and 4D for day 11.
\n\n\n\nThe most frustrating puzzle was definitely that set for day 20. Part 1 wasn't too bad and I found a shortcut to find the four corners of the jigsaw without having to completely assemble it. Part 2 wasn't so forgiving and is over 450 lines of code! It's fortunate that the tiles all have unique edge matches with other tiles, otherwise I'd still be writing a solution now. I did manage to take liberties with the now deprecated EQUIVALENCE statement to map 2D grids onto 1D arrays and also use a DATA statement, so I certainly stretched Fortran 77 to the maximum.
\n\n\n\n![\"The](\"https://z80.timholyoake.uk/media/posts/73/2026-02-16-172738_1920x1080_scrot-1024x777.png\")
With the exception of dipping into recursion for a couple of problems, all of the code I wrote should work happily on any 32 bit compiler (such as Sun's) of the early 80s. I suspect even the recursion will work on the Sun Fortran compiler if the Fortran 90 RECURSIVE keyword is omitted.
\n\n\n\nOne thing I was asked about while working through the puzzles was why I use STOP 8 to indicate a serious failure has happened. It's simply that STOP 8 was the most frequent error message that the PAFEC DOGS computer aided design system spat out when something had gone horribly wrong! DOGS was the first commercial software suite that I ever wrote code for, so that error code will stay with me forever.
\n\n\n\n\n", "author": { "name": "Tim" }, "tags": [ ], "date_published": "2026-02-16T21:16:12+00:00", "date_modified": "2026-02-17T03:08:39+00:00" }, { "id": "https://z80.timholyoake.uk/building-a-pico-romwbw/", "url": "https://z80.timholyoake.uk/building-a-pico-romwbw/", "title": "Building a Pico RomWBW", "summary": "At the end of September I attended the first RC2014 assembly at The National Museum of Computing. I'd gone with strict instructions not to buy any more computers, but I couldn't resist buying a Pico RomWBW kit with a wooden case from Derek of Extreme Kits. Having moved house in…", "content_html": "\nAt the end of September I attended the first RC2014 assembly at The National Museum of Computing. I'd gone with strict instructions not to buy any more computers, but I couldn't resist buying a Pico RomWBW kit with a wooden case from Derek of Extreme Kits. Having moved house in August, a holiday booked in October and Christmas rapidly approaching, it took me until the new year to get around to building it.
\n\n\n\nThe kit emulates a Z80 running Wayne Warthen's RomWBW software. This is something I've been meaning to try out for a while, and buying the Pico RomWBW kit seemed like a good way to do it.
\n\n\n\nThe build took me most of a day. I found the trickiest part was assembling the case. I managed to break a part of the base before I'd persuaded the front and back panels into it, but nothing so bad that a bit of glue couldn't fix. The thing I was most worried about before starting was soldering the micro SD card holder to the pcb, but my soldering technique is obviously better than I feared as it presented no real difficulty.
\n\n\n\nHere's a few pictures of the build in progress.
\n\n\n\n![\"\"](\"https://z80.timholyoake.uk/media/posts/72/Board1-1024x768.jpg\")
![\"\"](\"https://z80.timholyoake.uk/media/posts/72/Board2-1024x768.jpg\")
![\"\"](\"https://z80.timholyoake.uk/media/posts/72/PicoRomWBW-pcb-built-1024x768.jpg\")
![\"\"](\"https://z80.timholyoake.uk/media/posts/72/PicoRomWBW-completed-1024x768.jpg\")
I chose to build the Pico RomWBW using a Pico 2 I had in my 'cardboard box of doomed projects', as I remember Derek saying that it was a bit of a struggle to fit all of the software into the more limited RAM on an original Pico. I think this decision future-proofs my 'investment' (!)
\n\n\n\nFlashing the Pico 2 with the correct image and setting up the SD card was straightforward. The system booted correctly first time. I love the simulated disk noises it makes when it's running.
\n\n\n\nI'm now playing with various disk images from the RomWBW repository while trying to get my head around the very impressive documentation supplied by Wayne. There's a lot to look at - it's an incredible piece of work.
\n\n\n\nI've also built my own .uf2 file for the kit using Derek's source code and the version of libz80 I fixed a couple of years back so that it calculates square roots correctly when running CBASIC. I really need to get around to pushing my fixes back to the original author, but it's not straightforward as it's moved on somewhat since I forked it.
\n\n\n\nThis was a good way to start 2026!
\n\n\n\n\n", "author": { "name": "Tim" }, "tags": [ ], "date_published": "2026-01-07T15:05:32+00:00", "date_modified": "2026-01-07T15:05:32+00:00" }, { "id": "https://z80.timholyoake.uk/advent-of-code-2025-in-fortran-77-mostly/", "url": "https://z80.timholyoake.uk/advent-of-code-2025-in-fortran-77-mostly/", "title": "Advent of Code 2025 in Fortran 77 (mostly)", "summary": "This year's Advent of Code was reduced to 12 days of puzzles. Thankfully, as I managed to complete the last puzzle I had outstanding (Day 10, part 2) a couple of days ago. In previous years I've skipped puzzles that took me a lot of effort, thinking that I'd have…", "content_html": "This year's Advent of Code was reduced to 12 days of puzzles. Thankfully, as I managed to complete the last puzzle I had outstanding (Day 10, part 2) a couple of days ago. In previous years I've skipped puzzles that took me a lot of effort, thinking that I'd have the time to catch up later. Of course, I never did. So this is the first year I've managed to complete the whole problem set - and before Christmas to boot.
\n![\"The](\"https://z80.timholyoake.uk/media/posts/71/2025-12-24-104921_1920x1080_scrot-1024x688.png\")
\nI used Fortran 77 this year and stuck to the standard fairly well. I resorted to recursion on a couple of days as writing iterative solutions was too painful to contemplate. I also used bitwise XOR and AND to help solve Day 10's puzzles.
\nBack in the 1980s when I was porting Fortran code to various minicomputers and workstations there were f77 compilers that supported both of these extensions, but they didn't form part of the standard until Fortran 90 was ratified. I remember one instance of almost being held hostage over a weekend by a customer who was getting a crash in our software due to an unexpected recursion in some Fortran code, until we discovered late on the Friday afternoon where the problem was and fixed it. For anyone interested, the computer (and compiler) in question was the Harris HCX1.
\nMy Fortran 77 is pretty rusty as I last used it professionally around 30 years ago. But I think it has improved since last year's Advent of Code. For example, I'm no longer using COMMON blocks to pass data between subroutines and functions! COMMON has it's use of course, but not in the relatively small programs Advent of Code requires. Rediscovering list directed i/o has helped reduce the complexity of puzzle input parsing too.
\nI wrote notes each day as I solved the problems and these are in my repository with the code, so I won't repeat them here. I was happiest with my solution for day 7. Just about every other solution I've seen since I finished (I don't go anywhere near the internet to avoid spoilers until I have) used recursion, but even for part 2 it's not necessary to get a well-performing piece of code. On my Pi4B, parts 1 and 2 combined need just 0.08s to run.
\nThe toughest day for me was undoubtedly Day 10. It was the first time I broke with the standard to use recursion, as well as the bitwise operators. The second part took a lot of thinking about, a number of long walks, lots of paper and pen followed by half a dozen aborted attempts at writing the code over several days until I managed to get it to work for the sample data. Even then the puzzle data had a nasty surprise hidden in it that took a quick hack to work around.
\nFor posterity, here is the (final) pen and paper version of the algorithm I devised:
\n![\"A](\"https://z80.timholyoake.uk/media/posts/71/20251223_150953-768x1024.jpg\")
\nHaving looked at other Day 10 solutions since, I know that it would never have occurred to me to either use a 3rd party library like many Pythonistas seemed to do, or attempt (what I regard as) the heavy mathematics of Gaussian elimination2. However, I've since noticed that someone else came up with a very similar approach to mine several days before I did - and has helpfully provided a tutorial and a proof for the method.
\nLast year I wrote a quick and dirty insertion sort to help with a couple of the problems. I used the same algorithm again but it really came unstuck against the 500,000+ items that required sorting on Day 83. I hit a similar time sink on Day 9, but this time there were *only* 120,000+ items to sort. As I've had some free time since I finished this year's event I've played with a few more (non-recursive) sorting algorithms. Here are the results ... unsurprisingly, the heapsort algorithm wins out every time!
\n| Puzzle (hardware) | \nInsertion Sort O(n2) | \nBubble Sort O(n2) | \n'Optimised' Bubble Sort O(n2) | \nHeap Sort O(n log n) | \n
|---|---|---|---|---|
| Day 8, part 1 (Pi 5) | \n68s | \n482s | \n492s | \n0.09s | \n
| Day 8, part 1 (Pi 4B) | \n348s | \n1,180s | \n1,190s | \n0.27s | \n
| Day 8, part 1 (Pi 1B) | \n14,725s | \n- | \n- | \n5.7s | \n
I enjoyed myself more this year than previously, mostly due to the reduced number of problems to solve and the posts from the community of Mastodon 'Adventers' all solving the problems in their own way across multiple languages4.
\nThank you to Eric Wastl and your team for the puzzles and I hope that there will be a 2026 edition in a little over eleven month's time!
\nWhen I first started thinking about writing an emulator for the Sharp MZ-80K in September 2024, I decided that I was only going to attempt that model and no more. 15 months later (and a surprising RetroChallenge 2024/10 win)1 and here I am with a MZ-80A and MZ-700 emulator as well. Never say never, I suppose.
\nThe code is scruffier than I'd like it to be, but it does seem to work reasonably well. The main changes / additions compared to the MZ-80K and MZ-80A emulators were:
\n![\"\"](\"https://z80.timholyoake.uk/media/posts/70/20251126_173502-1024x519.jpg\")
\nI took the opportunity to clean up some pieces of code that also affect the MZ-80K and MZ-80A emulation, so I needed to put the emulator through regression testing and benchmarking. With the exception of the RC2014 VGA boards running as a MZ-80K2, all of the MZ variants are within +/-0.32% of the run time on a real machine when tested with a BASIC program that finds the primes up to 7,500.
\n![\"\"](\"https://z80.timholyoake.uk/media/posts/70/20251102_162751-1024x768.jpg\")
\nThe full benchmark results are in the project's documentation directory if you're interested, along with completely re-written notes explaining how to install and use the Pico MZ as a MZ-80K, MZ-80A or MZ-700.
\nThe current release (v3.0.0 as of me writing this post) for Pico/Pico 2 on a Pimoroni VGA demo base and the Pico on RC2014 VGA cards can be found in the usual place.
\nHave fun - and do let me know if you find any issues. (I guarantee that I will find a showstopper within an hour of hitting the 'publish' button ...)
\nAnyway, I'm taking December off from working on the Pico MZ to have some fun with Advent of Code. Depending on the implementation difficulty of the problems, I may even try to solve a couple with S-BASIC.
\nI'm making decent progress with adding MZ-700 emulation to the Pico MZ. As far as I can tell I have functionally correct code and I haven't broken the MZ-80K and MZ-80A emulations. I've even managed to update the documentation!
\n\n\n\nI've limited testing to the Pico for the moment, as my Pico 2 with headers seems to have disappeared during our recent house move. I have a couple of Pico 2's without headers, so I need to find my soldering iron. Hopefully that will be soon so that I can get a first release out before Advent of Code 2025 starts.
\n\n\n\nThe last couple of days have been spent benchmarking the code so that the Pico MZ runs as close to the correct speed of the original hardware as possible. This has been much easier to achieve with the MZ-700 emulation as it's in a separate executable (.uf2). I've had to compromise a little with the MZ-80K/A code as these compile into a shared executable (80A mode is selected by holding down button A during power on).
\n\n\n\nEven so, I'm happy with the results.
\n\n\n\n| MZ-80K | MZ-80A | MZ-700 | |
| Real hardware | 618s | 569s | 358s |
| Pico mounted on a Pimoroni VGA board | 618s | 570s | 358s |
| RC2014 Pico VGA and RC2014 RP2040 VGA cards | 627s (1.5% slower) | 563s (1% faster) | 357s |
![\"A](\"https://z80.timholyoake.uk/media/posts/69/20251120_160702-1024x648.jpg\")
I've also been playing games on the MZ-700 emulator. Of course I have. I'm still as bad at them as I was 40 years ago.
\n\n\n\n![\"A](\"https://z80.timholyoake.uk/media/posts/69/20251117_140049-1024x641.jpg\")
Now, where did I put my soldering iron?
\n", "author": { "name": "Tim" }, "tags": [ ], "date_published": "2025-11-20T16:29:34+00:00", "date_modified": "2025-11-20T16:30:20+00:00" }, { "id": "https://z80.timholyoake.uk/a-pico-mz-700/", "url": "https://z80.timholyoake.uk/a-pico-mz-700/", "title": "A Pico MZ-700 ?", "summary": "Autumn is here, so it means that the Caterham is SORNed until the spring, giving me time to tinker with some retrocomputing projects. The first project I'm attempting is to write a MZ-700 emulator for my Pico MZ platform. I've started off by creating a branch of the Pico MZ-80K/A…", "content_html": "\nAutumn is here, so it means that the Caterham is SORNed until the spring, giving me time to tinker with some retrocomputing projects. The first project I'm attempting is to write a MZ-700 emulator for my Pico MZ platform.
\n\n\n\nI've started off by creating a branch of the Pico MZ-80K/A code as many aspects will be similar. For the moment I'm creating a separate uf2 so that the code doesn't get overly complex. This means I have a new main program, VGA display module, keyboard handler and ROM definition file. Once I've got it working I may try to consolidate everything onto a single uf2, but to do that neatly there's quite a bit of code refactoring required. And re-testing of the MZ-80K/A code that already works. So for the moment I'm keeping the new code at arms length.
\n\n\n\nThe big differences with the 80K/A are that the MZ-700 uses an 8 colour display supporting 512 characters, has a faster clock, uses banked memory and has a different keyboard matrix to implement. There's also support for Sharp's QuickDisk and floppy disk formats, but I shall restrict myself to cassette tape emulation for the time being as that should be identical to the earlier MZ-80s. The MZ-731 had an inbuilt printer/plotter, but that's also not on my initial list of emulation targets.
\n\n\n\nThe first job I've attempted is to get colour output. This hasn't been too difficult to achieve and seems to work nicely on a Pico. I've not started over clocking the Pico to get the 3.5MHz Z80 emulation speed I need, so this is encouraging. I am concerned that I won't be able to over clock the Pico enough to get an accurate MZ-700 emulation, but fortunately the Pico 2 should have plenty of headroom.
\n\n\n\n![\"Sharp](\"https://z80.timholyoake.uk/media/posts/68/20251021_170630-1024x747.jpg\")
I was recently sent a copy of Knight's WEE FORTRAN by Sharpworks who had rescued it from a tape belonging to HereBeDragons.
\n\n\n\nThere are a couple of references to it in issues 3 and 4 of the Knight's International Sharp User Group newsletters. In 1981 it retailed for £30+VAT and Knight's were \"certain that KNIGHTS WEE FORTRAN will soon become as popular as our KNIGHT TAPE BASIC COMMANDER, KNIGHT DISK COMMANDER, and KNIGHT DIS-ASSEMBLER.\" Despite their certainty I'm not sure that it did become as popular as the other three titles. It definitely wasn't a tape that I'd seen before on a MZ-80K.
\n\n\n\nOr ... had I seen it before? Some time ago I used the MZ-700 RealFortran compiler that had been distributed in German by a company called BBG. Knight's WEE FORTRAN probably pre-dates this version by a couple of years, but both are nearly identical. At the same time I'd also played with a compiler that introduced itself as SOSZ80. This would appear to be exactly the same piece of software as the Knight's WEE FORTRAN compiler, except for the screens identifying the software's producer.
\n\n\n\nSoftware piracy was in its infancy in the early 1980s. Even so, it appeared to be affecting Knight's. Graham Knight's final word in issue 1 of their newsletter reads \"I have been surprised to see our programs running in three shops who did not buy them from us. Purchasers of our programs are reminded that they should not be copied for use on other user's computers. Perhaps those who are ripping off our programs would like to send some food for Fang and Claw our 'pets'.\"
\n\n\n\nAssuming that Knight's wrote this compiler, it might appear that the SOSZ80 version is a direct unauthorised copy. The BBG tape is slightly different as my previous article notes, but it still looks as if it is a copy with a few patches, one of which removed the IRND (random integer) function.
\n\n\n\nCase closed? Do Fang and Claw get their food? Well, perhaps not. One error message common to all three versions is \"OBJECT PROGRAM NOTHING !\" This message appears if you forget to compile your FORTRAN source before running it. The language used by this message is strange enough to a native English speaker (why not use something like NO EXECUTABLE FOUND) to suggest that the origin of the compiler might not have been Scotland after all.
\n\n\n\n![\"A](\"https://z80.timholyoake.uk/media/posts/67/20250718_141433-1024x500.jpg\")
Perhaps Knight's licensed it from elsewhere for the UK market - and perhaps BBG and SOSZ80 did likewise for theirs?
\n\n\n\nThe answer is lost somewhere in the mists of time ... unless, of course, you know differently! Please let me know if you can help solve this minor mystery from more than 40 years ago.
\n\n\n\nThe copy of WEE FORTRAN rescued by Sharpworks has the real variable printing bug described in Knight's International User Group Newsletter 4. It's also referred to in the March 1983 (Vol. 3, issue 1) Sharp Users Club magazine. Although the compiler correctly stores and manipulates real variables, they are always displayed as 14087 by the WRITE statement and are not printed correctly.
\n\n\n\n![\"\"](\"https://z80.timholyoake.uk/media/posts/67/20250719_142642-1024x406.jpg\")
Fortunately the patch is simple to apply. It claims to correct the printing issue (but not when WRITE is used to display the variable on screen!) and also provides a '.F' format specifier allowing reals to be output in a 10 character wide field rounded to 3 decimal places.
\n\n\n\n![\"\"](\"https://z80.timholyoake.uk/media/posts/67/2025-07-19-161358_1920x1080_scrot-1024x751.png\")
Even with this patch, WRITE (//,A,//) still sends 14087 to the screen, but using WRITE(//,A.F,//) gives a sensible result. I don't (yet) have a printer simulator for the Pico MZ-80K/A, so I can't check that the printer part of the patch works.
\n\n\n\n![\"\"](\"https://z80.timholyoake.uk/media/posts/67/20250719_162656-1024x553.jpg\")
Playing with this has also uncovered a bug in the Pico MZ-80K/A's tape handling. The FORTRAN compiler allows source code to be stored in tape data files with a block length of 256 bytes. If the source code is under 256 bytes, the file is written correctly to the SD card. If it is over 256 bytes, the write fails. I suspect this issue will also affect other multi-block files - for example, BASIC tape data files. The problem is now logged and I will get around to fixing it in due course.
\n", "author": { "name": "Tim" }, "tags": [ ], "date_published": "2025-07-18T14:32:54+01:00", "date_modified": "2025-07-26T14:53:51+01:00" } ] }