Boot-to-Basic is a fond memory for many of us, but booting to Forth, or Scratch, or any other language, fits the same kind of idea: how nice it might be, to have a device which boots into a self-contained programming environment, preferably instantly, and preferably without distractions. And it turns out, there are quite a few possibilities.
The CG Maximite powers on to BASIC and has composite video or VGA out.
The fignition has a composite out and powers on to forth.
Raspberry Pi boots to whatever the SD Card has. That could be a Linux suitably configured (how?) or a RISC OS, or a Coder environment.
There are, now, some modern remakes or updates on classic retrocomputing platforms: THEC64, Spectrum Next, MSXVR
I see a number of recent works on Z80, 6502, 68000 computers that boot into BASIC, CP/M or at least a selection menu, but most of them are āheadlessā, i.e. without monitor and keyboard. In the last year or so there are flurry of activities to build video/keyboard for these headless computers. This is my contribution to the recent trend in retro computing, a standalone Z80 SBC. Z80, 128K RAM, dual port video memory, CPLD glue logic on an inexpensive 2-layer 102mm x 102mm pc board. It has 64 column x 48 line monochrome text display and support PS2 keyboard. I also have VGA/keyboard board that plugs into RC2014 bus. Iām interested to see what video/keyboard projects other people are working on. This is a exciting time for retro computing.
Bill!
I see youāre using a VGA output - thatās another little conundrum we have, as to whether VGA, or composite, or RGB or even DVI is a good, sufficiently universal, way to drive a display. Thereās also the possibility of a directly attached OLED or LCD or similar.
It seems to me VGA is still supported, especially in the portable display markets (rear view camera, handheld display). VGA is also interesting because it still trace back to the scan line technology and challenges associated with that technology. The inexpensive OLED are certainly very cool. Many of them support I2C or SPI interfaces thatās pretty easy to do with retro technology.
Bill
@Plasmo, how do you communicate with the CF drive? I have an old TRS CoCo in the basement at my folksā that Iām planning to retrieve over the holidays. Iām interested in how modern solid state media can be used as mass storage for
You are probably thinking about something more like booting into a LISP interpreter, which is not hard to do (easy to change your shell in in Linux) but but any Linux distro with a reasonably standard terminal (e.g., bash) is already a full-featured programming environment.
This is one of my favorite things about the old UNIX philosophy - that extending the system by writing a shell-script, a compiled C program, or a library routine are all more or less conceptually equivalent - a little bit like the FORTH concept of building up larger words out of smaller words.
It makes me sad that so many systems still have this functionality built in (even embedded systems like wireless routers, or the Intel ME built in to their CPUs!) but most people seem to think itās not worth learning. There are a lot of questions on, e.g., Stack Exchange, that basically say āI have this problem, how do I fix it? By the way, I donāt use the terminal, and donāt want to learn how!ā
Itās perhaps a personal thing, but one thing I like about, say, RISC OS booting to Basic, as with the BBC Micro, and many other 8 bit micros, was that simple graphics were immediately available in that initial programming environment. I could experiment with geometry, draw graphs, even attempt to write a game. This is one thing which counts against running a python or perl or bash environment: no PLOT, no DRAW. Itās true that pygame offers something like this, and it may be that one could coax something out of bash.
Itās also notable that TIās graphical calculators offer quite an interesting environment, as well as a Z80 platform to explore, if you have the tools. Again, itās not quite what I was thinking of, but itās something. (The numworks calculator offers python.)
@Paganini,
The CF interface is based on IDE interface, but it doesnāt have to that complex. The basic is 8-bit data line, 3 address lines, a reset, chip select, read strobe and write strobe. For Z80 you can just about connect the CF interface directly to the Z80 bus plus a bit of I/O address decode for the chip select.
Bill
PS, CF interface is simple enough it can be coax into a small (512byte) bootstrap EPROM with a bit of state machine help.
Then I accidentally yanked a cable. And the SSD was bricked.
This (the lack of any safe auto power-down) is for me the major letdown of the Pi, as itās really easy to corrupt your boot media. While somewhat symmetrical to the boot problem, shutdown behavior is seldom in the spotlight.
Edit: Iād say, safe and instant power-down (as in simple power cycling) of ROM-booting devices is an aspect at least as charming as instant-on.
I suspect even making a copy of boot media is pain on a big machine.
DD could found for for windows the last tme I checked, but that was about
5 years ago with windows 7.
I donāt disagree that the lack of an automatic power down is unfortunate, but reading the whole article, this sounds like a total failure of the actual USB device, which is somewhat different.
Most of my Pi failures have been from SD card demise, which is more common than would be desirable. This is another big benefit of those ROM-booting devices. Even their relatively fragile and unreliable 4116 RAMs lasted 30+ years.
I wonder whether CF disk is more robust than SD disk with respect to disk corruption? Or perhaps it is the way SD is used. Lately my retro designs are ROM-less, booting out of CF disk like the one in the picture of this topic. Corruption of CF disk is not something Iāve encountered, but then it is CP/M so disk is not in use constantly.
Bill
I stand corrected. (Is USB boot specific to the Pi 400?)
But it really reminded me of some more SD Card related issues, and (apparently) I immediately took the jump.
Yeah, the immediate graphics, however low-res, even just the blocku graphics character sets, were an important part of that. I am a hardcore terminal text weenie, but the thrill of also having something to draw, yay. (And in many environments of yore one also had some sound generation capabilities.)
Even those that didnāt, actually got kind of it. Compare the PET 2001.
Which reminded me of another one for the remakes section of the list:
The Mini PET comes with 4 sets of ROMs, 3 version of the original PET 2001 ROMs and a special Mini PET ROM.
Iāve been running two Pi 3 for many years, as printer servers, and the SD cards are fine. But I recently bought a few Pi 4 variants to play with, and then while working on one of them the brand new Samsung SD card failed, after using it for an hour - it got extremely hot and āfdiskā showed its size as 512 bytes. I yanked it and used another SD card (which worked). I was about to convert both Pi cards to run from Samsung T5/T7 SSD disks, which they now do, but that SD card failure got me concerned. So, failure not due to losing power, it just suddenly collapsed (and got hot too). As for power down corruption, a mini-UPS of some kind would be niceā¦ a gigacap thingy with a connection to a GPIO pin should be sufficient.
Booting to a programming envornment is easy for me.
POWER ON, address load button, run/stop button and
a $ prompt for the bootstrap loader.
Back the topic, I think one needs to read the fine print
with the sd cards, and get a only ones big as you need.
Bigger cards pack muli-level values per bit, making drop outs more
likely.You can get industrial SD cards, but bigger money for smaller cards. Can one adapt a PI to real disc and solve this problem?
