@emard Unix reads the the disk timestamp on startup. Whenever the disk is synced the disk timestamp is updated with the current system time. This way, time will not normally go backwards for file time stamps. In the late 70's your PDP-11 might crash once a day due to some hardware glitch - doing time this way was a useful feature to have. It also reminds me that I need to configure a daemon to sync the disk every 5 seconds; on my research setup I don't have that.
If the ESP32 is the time reference, why bother with the RTC chip (other than technical challenge)? The ESP32 might as well drive the emulated 99xx RTC chip directly.
ed, the original editor written by Ken Thompson himself. It is still mandated by the Unix standard, so OS X and Linux still have it.
viwas initially written by Bill Joy and is too large to run on the Mini Cortex. It needs separate I/D spaces which the 9995 does not support. It is supported on the 99000 though, so it is high on my list of to-do's. I do have the
seditor (I think I have it at
/s) which is a vi-like editor: https://github.com/udo-munk/s
server.cwas one of them.
@lawrie Yes, that delightful anecdote is how I got to use that on the Mini Cortex. The M209 cypher used on V5/V6 Unix was an assembler routine that I had to port I figured that if my implementation hashed both aline and ladne to ugiTjezp, I would have the algorithm correct.
The cypher was already weak at the time: with a few bits of hardware it would be susceptible to a brute force attack. In V7 (1979) it was replaced by triple DES as the crypt algorithm.
s port is something that I have not used much. It may have bugs. For sure I know it crashes if it has to load a file that is too big to fit in memory. Strange as it may sound,
ed is not all bad once you get (back) into it.
s commands are here: https://github.com/udo-munk/s/blob/master/commands.c#L17,L40 and the address specifiers are here: https://github.com/udo-munk/s/blob/master/address.c#L17,L53 All based on ancient
To save and exit the command is
To understand some of the key combinations, remember that
vi was written for the ADM-3A terminal keyboard:
If you find repeatable bugs, please let me know - maybe I can fix them easily.
@emard I like how fast it boots and gets prompt, even exe's are short, responds fast to prompt and only 6 MHz 16-bit CPU. Wonder are elf, ld, systemd all only to counterbalance for GB of RAM and GHz of CPU...
Well, the PDP-11 was a 6MHz 16-bit machine and the VAX 750 ran at 8MHz. That is the hardware both Unix and the Internet were invented with. Unix has had
ld since the earliest days. I don't care much for
systemd which is trying to do entirely too much - but at the same time
init is too simple a solution for a world with pluggable hardware.
elf (or at least dynamic libraries) are a good idea in a bigger memory space. Without it, V7 Unix has about 5KB of stdio code duplicated in dozens of binaries - surely that is not quite right either.
ls -alh /usr/bin/nextpnr-ecp5 -rwxr-xr-x 1 root root 111M kol 2 05:32 /usr/bin/nextpnr-ecp5
@emard Instead of 9600 I'd like to have 115200 ... :)
That is 12 times the speed. If we hook up h/w handshaking it is possible as a minimal fix, but that of course will not get your throughput up much. The problem is that the 9902 interrupts once for each character sent and received: at 12 times the speed the CPU would have a hard time to keep up. However, other manufacturers (read DEC) had I/O boards with buffers. It will not be too difficult to make a special UART chip in Verilog with buffers so that the CPU could R/W multiple bytes on each interrupt. What do you need it for?