I ordered one of these SC130 kits a while ago from Tindie ( after seeing this post), and finally got around to assembling it. All done in an afternoon, clear instructions and a quality board made it an easy and pleasurable build (but haven’t fitted all the sockets yet).
So what to do with it now?
Benchmark some Basics! There’s MBasic, BBC Basic, and Mallard Basic, at least.
Yea, that’s always the nit isn’t it?
For some, it all stops when the thing boots “Successful assembly!”. Obviously perhaps more interesting the more difficult the project is. I read some vintage forums and look at the work folks go through to get their legacy machines to boot up. Much less getting some real legacy project like a legacy mini computer or something.
But in the end, computers are tools and without application, tend to sit on the shelf.
I considered getting one of those boards and assembling it. But I’ve also done some work with machine simulators. And while these z80 boards are pretty neat, they’re functional to be sure, and perhaps a nice platform to do some hardware hacking from, they lack something for me.
After playing around with this stuff for a while, myself, I’m striving to get my SB180 board up. And I’m striving to get it going simply because it’s a floppy based system.
I’ve learned a few things working with the simulators and such.
One, box stock CP/M is quite awful as an OS. It’s really and truly is designed for a floppy based system. Using CP/M with a hard drive is borderline a disaster. Have 10’s of MB of files in a single flat structure is…terrible.
Now, to be fair, CP/M has User areas which can be used to break up the disk. But each of these User Areas is separate, and support for them is weak to say the least. Consider that if you want to use the ubiquitous PIP command (which is not part of the CP/M CPP, but must be run from disk), if your PIP.COM file is in User Area 0, it’s not accessible to, say, User Area 1. And this means that to use it, you need to make a copy of PIP.COM to the other User Areas where you want to access it. And that would suggest that you would use PIP to copy itself (because PIP is the utility you use to copy files on CP/M).
But PIP has no concept of User Areas. You can’t use PIP to copy from one User Area to another. Instead, you have to load PIP in to memory, switch User Areas, then SAVE the memory back out to a file. Hardly intuitive, and you have to do that for any other utility you want in the other User Areas.
And that’s just a single example. Now, if you’re running the classic, two floppy CP/M, with limited size floppies, it’s a much different world. You wouldn’t use User Areas. But part and parcel to that experience is being able to swap floppies. Using a single floppy disk as an organizational unit.
This is something you can’t easily do on the modern Z80s, because nobody does floppies anymore. (With good reason.) They’re not really set up for yanking Flash cards in and out. And a 32G flash card makes for a pretty lousy floppy. So, you end up with a floppy based OS with no floppies.
Mind, if you go beyond CP/M, such as Z system, or find other utilities, they all address issues like this to some degree. But out of the box, CP/M and large drives is just not a good experience.
Which brings us back to the SB180. Which does have floppies, and will give me a more “authentic” experience of trying to write software in that environment.
It was fun doing some BASIC on that fellows Altair that he’s live streaming.
So, that’s my goal. To actually do work on an actual system, with their tools, and their constraints. Build a fire rubbing two sticks together. Limited memory, slow CPUs, S L O W floppy systems. Folks used to get real work done on these things, so I’m going to try.
Conider the thread about the mini Unix on an LSI-11 with, what, 28K of RAM? A system that can regenerate itself, with a C compiler, run two tasks, and floppy disks, with 28K of RAM? Interesting challenge.
But with CP/M standard floppies were 8". Way more the information that a APPLE or TRS-80 had,
Was Unix the only OS for the PDP 11 that had a C compiler
in the late 1970’s?
The most common CP/M installations were all on 5 1/4 SD or DD floppies. Microsoft (or at least Bill Gates) has claimed (p.20, rightmost column) that the single largest homogeneous installation base was Apple ][ machines with the Microsoft Softcard installed. Certainly there were many thousands of Osborne, Kaypro, and TRS-80 machines running CP/M – many more than there ever were IMSAI or MITS machines with 8" floppy disks!
I don’t know what size 8" floppies were popular on those early, 8" CP?M machines, but I have to imagine it was not the end-of-life 1 MB+ 8" floppies used on larger computers. SD 8" disks were 256-512 kB, which is not dissimilar from DD 5 1/4" disks. It would be interesting to see numbers on this.
I have spent quite a bit of time running RT-11 on the PDP-11 with 5 MB and 10 MB RL01 and RL02 disks. RT-11, like CP/M, has a flat filesystem with no directory hierarchy whatsoever. It can be painful simply to list the disk, particularly with a 9600 bps or slower terminal interface (or with the VT-100 smooth scrolling!). Later CP/M machines often had much faster, memory-mapped CRT displays, which at least made the listing faster, but they didn’t necessarily make it easier to navigate hundreds of files on a flat disk structure.
As far as other systems with C compilers in the late 70s, many of the minicomputer operating systems (such as DEC’s RSX-11M) had C support, and by the early 1980s C was certainly available for micros, including for CP/M.
Leor Zolman has claimed that his BDS C, released in 1979, was the first C compiler for CP/M. Like many other early micro C implementations (such as Small C, first appearing in Dr Dobb’s Journal (go to p. 190) in May of 1980), it was not quite a “complete” C.
Does any one make a single board computer, that is 6809
based and not a COCO emulation? OS/9 level 2 was a great
little multitasking OS. I would be nice to compare that with the Z180 board.
Thanks for the observations on PIP.COM and the implications of user areas!
Regarding modern systems, wouldn’t it make sense to partition large modern drives into virtual floppies? These could even be folders/directories converted on the fly to floppy images by the firmware or the emulator. So, instead of changing directories from inside the OS, you’d rather change them from the outside to much the same effect. (It should be possible to add commands for changing or creating virtual floppies via some basic protocol.)
Edit: Mind that there are also logical drives (up to 16 per physical drive, up to 8 MB each, numbered only), which do pretty much the same thing.
One of the standard things to do in the land of Acorn is to use a container file with slots for some hundreds of floppies. Commonly any given game or application has a floppy to itself, and one mounts one, or up to four, floppy images from the container file onto ‘disk drives’ for access. It works very well, with the caveat that a utility program is needed to manipulate the images into and out of the container file.
Using these Benchmarks with the BASIC in the ROM. My rough timings came out as :-
| System | BM1 | BM2 | BM3 | BM4 | BM5 | BM6 | BM7 | BM8 | Avg |
|---|---|---|---|---|---|---|---|---|---|
| SC130 | 0.2 | 1.0 | 1.9 | 1.9 | 2.1 | 3.0 | 4.1 | 6.8 | |
| BBC (B ?) | 0.6 | 3.2 | 8.1 | 8.8 | 9.9 | 14.3 | 21.9 | 48 | 14.3 |
So it seems to be about five times faster than the BBC B.
Well it certainly possible, and, as you mentioned, the slicing up of large volumes in to 8MB chunks.
The way to handle it would probably be through some low level BIOS facility, with a custom app to do the swapping (i.e. it talks to the hardware, or tweaks the BIOS settings to look at the different chunks on the volume, and “mounts” them).
But, for example, the simulator I use, you can’t “swap floppies” behind its back. You have to shut down and restart. Mind, not that this is that big of a deal. In fact, on CP/M that essentially what you do when you swap floppies anyway, use ^C which is essentially a warm restart.
But you do lose some physicality of the experience.
With the simulator, I find the experience kind of ungainly, to be honest. Partly it’s the interface, partly its my unfamiliarity with it, and partly it’s the limited toolset avaiable in CP/M in the first place.
The standard 8" floppy was about 250K (which, honestly, is a lot).
The Apple 5 1/4" was 113K (13 sector), the TRS-80 was 85K, my Atari 800 was, like, 80K. There was ye olde use a hole punch to notch the floppy and flip it over trick for “double storage”.
The 360K floppy in the PC was quite a milestone for the day.
With my CP/M work, using the generic 8" floppies on a simulator, I was running in to the 64 file directory limit. This may be changed (I think) via reformatting it.
I don’t know how big the DEC floppies were, but I doubt they were much bigger than the 250K the 8" floppies were.
Well said. There’s always that feeling, you’re missing some essence of the real thing, which may also add some to the frustration that comes with the system anyway. (But now, you don’t know, whether this frustration somewhat justified or just an effect of the indirectness of the setup.) I guess, this also describes the value of these small, modern systems, as they provide a shortcut to the close-to-real experience. However, this often cuts out when it comes to the peripherals, which are an important aspect of a system, as well.
It was! As was the contemporary (even a bit earlier) 1.2 MB 8" disk. However, many of the other CP/M machines (and I think even the late TRS-80s?) had double density 5 1/4" floppies with formatted capacities in the 200 kB range. My Osborne 1, for example, has a DD expansion and can put about 180 kB on a disk. Even the majority of Apple Disk II units were 16 sector at 140 kB. Not so far from the 250 kB 8" single density disks. (Though, while I don’t know if any micros used a smarter encoding on 8" disks, the DEC RX02 puts 512 kB on single density 8" disks without issue by using a more efficient encoding.)
As far as files per directory, I believe that is (on most CP/M systems?) a property of the BIOS. The Osborne BIOS, for example, was capable of reading and writing a wide variety of formats (I’ve bought 5 1/4" new old stock disks that read cleanly as an empty CP/M volume at about 140+ kB, for example!), but it could only initialize Osborne-format disks.
I often find this to be the case in simulators, myself. For example, in PDP-11 SIMH, I find it annoying to halt the simulator, attach a different RL disk pack image, and continue the simulator … even though this takes far, far less time than taking the drive offline, waiting for it to spin down, physically changing packs, and spinning the drive back up! I think it is, as you mention, the lack of physicality of the experience.
With every thing now with single SD card slot, how do you copy SD data?
Well, precisely. Many of the hobbyist systems only support a single flash card. How, indeed, do you copy SD data?
The answer is you download it to your “real” machine, and then upload it back on to a new card. Or, you could use the host to build the card itself directly from the data.
Playing “swap the floppy” doesn’t work very will with a, say, 8MB partition, 2 CF cards, and 64K of RAM. Even if you could utilize the entirety of RAM, that’s 128 “swaps”.
Of course, back in the day, we didn’t “copy” hard drives, not really. Rather, we streamed them to tape, carted those over, and reloaded them. Tape offered comparable density to the hard drive itself, robustness in portability, and reasonable read and write performance.
Heck, on the Alpha Micros, we use VHS tapes and off the shelf VHS recorders much like the micro industry used cassettes. Later, these mostly got replaced by Exabyte drives utilizing 8mm video tapes for storage.
Mind, today, if you have a 115,200 baud serial connection (with hardware that can actually sustain 115K), that’ll download an 8M partition in under 15 minutes.
Of course, today the use cases are far different. Rarely, if ever, are the legacy systems a source of content or data. Rather, they’re the destination. All of the work is done on modern machines, crossassembled/compiled, written to fast media over fast interfaces, and then plugged in to the devices.
But this is one of the reasons why when I was approaching the design of a custom build, I settled on making USB connectivity a primary goal. The premise is to get interface the CPU to a “super I/O” device that can bridge to modern protocols like USB and TCP/IP. Once that bridge is made, you can plug as many USB fobs as you like in to a off the shelf hub and copy to your hearts content, or stream over TCP to a remote destination.
It doesn’t work yet, but I have all sorts of schemes in my head incrementally marching to that goal.
I have a version of DD for windows so I can use that,
as batch file under DOSBOX. The hardware I have only has
1 SD card slot,but I have header pins for expansion,
I plan to add two SD card slots there, once this virus is over.
(I am emulating a TTL computer - 64KB ram CPU and dual removable media and serial I/O in the 1974-1977 time frame so I see modern I/O as crappy designs made to save $$$ and make you by new hardware.)
Ben,
I wasn’t a big CP/M user back in the day, but I still enjoyed working with CP/M 2.2 and CP/M Plus. What I enjoyed the most was to write tools to do what CP/M could not do - one of the first things (as I imagine many did) was to write tools to fix and repair broken file systems (the simplest variant would be accidentally deleted files). I remember a small accounting firm which managed to destroy their whole customer base running on an MP/M system - I wrote a tool to recover it, fortunately it worked.
But that was just one thing - I actually liked that CP/M had so many limitations, because then there were a lot of opportunities to write something better. And when I think about it - that’s what I liked in bigger systems too, to find weak spots where I would write code to do it better. So, to get back to CP/M, “pip” is limited, so I would write a tool to handle user areas.
Systems which “just work” are actually very boring… as I never particularly enjoyed playing games etc. I liked, and still like, writing programs - but then there must be something that’s needed, something useful that can be added.
Hi all ! I’ve built many Z80/Z180 SBC over the last years, also using FPGAs (Grant Searle’s Multicomp derivatives). My last one is a Z180 based SC-126.
I run ZCPM3, an enhanced CP/M 3 with ZCPR3 improvements. It handles paths, aliases, named pseudo-directories, command history, etc.
Regarding CP/M 2.2 lack of User Areas handling, it actually had some rudimentary functionality to copy files between different user areas.
You had to use the [Gn] option where “n” is the user area to get the file, i.e:
B:
USER 1
PIP DESTFILE.EXT=A:SRCFILE.EXT[G0]
… will copy A:SRCFILE.EXT form User 0 to B:DESTFILE.EXT User 1 area.
This will work if you already had PIP.COM in B: User 1. If not, you had to go over this sequence of commands:
A:
USER 0
DDT PIP.COM
GO
USER 1
SAVE 28 PIP.COM
… and voilá, you had PIP.COM in User area 1 so you could copy file from any other user area. So possible but not practical…
Cheers,
José Luis.
I like this kind of thing - like learning to juggle! It’s good when things are possible, but not in an obvious way.
Well, it’s simply a snapshot in the evolution of things. CP/M kind of got caught in the middle.
DOS didn’t suffer from this as much, but that’s partially because the foundations were there in place in the beginning. There are quite dramatic differences between DOS 1 and DOS 2,3,4…
And DOS also matured in the static environment of the PC vs the chaos of CP/M systems.
All that said, I’d be curious to learn more about the “Mini Unix” and what compromises it made. An 8K floppy based OS with 28K total RAM, while supporting 2 tasks. I don’t know if the tasks were peers, or one was simply something like a spooler. Both the TRS-80 and FLEX had built in facilities for spooling, not as if a spooler is particularly resource intensive. Did DOS have one out of the box? I don’t recall.
But there’s something fundamental from a computer experience about lighting up the printer and letting it bang away in the background while you continued on with your work (just don’t take the floppy with the file you’re printing out of the drive…).
