Preservation is always good, and some of the software from the CP/M world can be quite useful.
People can use constant reminders that software can be good without taking gigabytes of memory for the most basic of functions. We can literally emulate an entire computer and run its OS and software faster and more efficiently than we can render a page in a web browser.
Indeed. You can go a very, very long way in productivity with Wordstar, Visicalc and Turbo Pascal on CP/M, each of which fit on a floppy. Many of us did.
The only thing new about those tools was they were available on an affordable, personal platform. Wang, among others, had Wordstar-like computer-based word processing for years at that point. Pascal was old hat. Visicalc was new and revolutionary, but the idea of using computers to simplify computation was primordial.
I get that there's a certain mentality that thinks nothing happened in computer productivity until 2010 or so (date marching forward as new grads enter the workforce), but when you don't bury your word processor or spreadsheet under a metric ton of useless UI candy and 'features' that less than 1% of your users actually use, you get some pretty lean, useful tools.
Oh absolutely, well said. I miss those days when time spent at the screen was intent time. For a long while now for me, it's basically just been a TV replacement.
> CP/M programs often behave in ways which would be damaging to modern hardware -- endless input-checking loops at full CPU speed, for example. To be honest, I do not know if this kind of thing would be damaging to a Pico, but I don't want to risk it. CPICOM has a number of pause points built in, to give the microcontroller time to idle. These do slow the system down even further, and I'm not sure whether they're necessary.
This shouldn't be necessary on an MCU. Any kind of sleep call is probably just spinning the CPU anyway. There's often support for deeper power saving states, but MCUs are generally designed to be run full speed all the time.
its my understanding that you cannot damage the physical CPU by software instructions, period. However, heat from multi-core operations is not the same. Hardware gets damaged by heat all the time. So "loops waiting for input" may never damage the hardware, but "causing more cores to operate at the same time" can cause heat damage on some setups..
There are CPUs out there that can be put into a "sleep" type mode. On the x86, there's the HLT instruction, which stops CPU execution until an interrupt happens. The 68k series has the STOP instruction, which does the same thing.
1) The Pico doesn't have an OS, by default. It's designed to run bits of code people have written in the SDK. There are no guarantees that someone won't write code that endlessly busy-waits checking for a condition, and no warnings that doing so can be harmful
2) It costs about $4. Is there really much to lose if you "risk it" with this software?
I mean more the issue where the computers were differing wildly enough that binary distribution of software was very limiting, so it made sense to offer source that could be massaged to run on specific setup.
23 comments
[ 3.5 ms ] story [ 66.5 ms ] threadhttps://www.ssllabs.com/ssltest/analyze.html?d=kevinboone.me
Preservation is always good, and some of the software from the CP/M world can be quite useful.
People can use constant reminders that software can be good without taking gigabytes of memory for the most basic of functions. We can literally emulate an entire computer and run its OS and software faster and more efficiently than we can render a page in a web browser.
Small and efficient is good :)
I get that there's a certain mentality that thinks nothing happened in computer productivity until 2010 or so (date marching forward as new grads enter the workforce), but when you don't bury your word processor or spreadsheet under a metric ton of useless UI candy and 'features' that less than 1% of your users actually use, you get some pretty lean, useful tools.
This shouldn't be necessary on an MCU. Any kind of sleep call is probably just spinning the CPU anyway. There's often support for deeper power saving states, but MCUs are generally designed to be run full speed all the time.
https://en.m.wikipedia.org/wiki/Halt_and_Catch_Fire_(computi...
1) The Pico doesn't have an OS, by default. It's designed to run bits of code people have written in the SDK. There are no guarantees that someone won't write code that endlessly busy-waits checking for a condition, and no warnings that doing so can be harmful
2) It costs about $4. Is there really much to lose if you "risk it" with this software?
CP/M was first developed in 1974, the FSF was founded in 1985, so I would say more like eleven years.
It couldn't. The ZX81 could.
https://www.sinclairzxworld.com/viewtopic.php?p=20645&sid=86...
https://github.com/guidol70/RunCPM_RPi_Pico
It's a port of RUNCPM:
https://github.com/MockbaTheBorg/RunCPM
I used it, but I can't remember whence that came. I also used 22NICE from Sydex. Info on such things:
https://www.cpm80.com/
https://www.sydex.com/index.html
http://www.primrosebank.net/computers/cpm/cpm_emul.htm