Sheep64 wrote:
I am hugely concerned by your crisis of confidence. I hope that it is only related to moving home which can perturb the hardiest of souls.
Thanks for the concern. Today we knock a wall down. It's a wall supporting some building on the floor above, so only mildly concerning ... I'm also struggling with getting my home office going - it's a low priority to getting a working kitchen going (then bathroom, livingroom, etc... !!!)
Sheep64 wrote:
I share your despair that everything looks like Unix. However, if you make legacy ABI wrappers to a Unix kernel then, yes, everything looks like Unix. However, if a Unix wrapper is an equal peer with your Commodore and Acorn wrappers then you have much more freedom. It is trite to say that the limitation is your imagination but I find pre-Unix systems such as Data General Nova and
Hewlett-Packard 2116 inspire me as much as Ruby, Commander X16 or Foenix C256.
I find your software particularly inspiring. Among all of the projects described on the 6502 forum, I look towards Ruby as the best template for software. You have shown empirically that Acorn BASIC remains relevant as a shell, assembler and bytecode interpreter. Indeed, all of my doodles which fall short of this criteria are discarded. In particular, I hope that all of my hardware choices will run your software environment with very little modification. Actually, your awesome success gives me a crisis of confidence. Where I would make different design decisions, I am left doubtful that my vaporware my not achieve feature parity with your implementation.
If you want ideas for future development, I suggest:-
- Applications which require minimal processing power, such as home security, medical diagnosis, audio or CAD. I would be particularly interested in circuit CAD.
- Look to systems which were destroyed by Unix and Windows, such as CP/M, VMS and Tandem.
- Look to other hypothetical forks of technology, such as Commander X16 and Foenix C256.
Things I have in the back of my mind are other OSs - or papers describing other OSs. One is just called OS6 - and you won't find much about it - I've found just 2 papers. It's written in BCPL and ran on something called a Modular One at (I think) Oxford University.
Another 2 similar are Mouses and EMAS. To find more you'll need to search for the archives of Edinburgh University.
However having a subset of Posix style "system calls" isn't that bad, plus the Acorn MOS style interface for "machine control" is, for now, working on Ruby. What these don't give me is multi-tasking, but that's OK. I am currently doing that inside the BCPL VM. That effectively gives me "hardware multitasking" (probably more correctly multi-threading). The global linkage area in BCPL is not a million miles from EMAS either (at a glance, anyway) so there are some interesting parallels.
The unixy-like thing I might have been thinking of is more the actualy shell or command-line interface. Without going full-on GUI what do you do? A unix shell is a powerful and easy to use thing. It's possible I've been spoiled though - the concept of std IO redirection and pipes is something I want (but is there a better alternative?) Also the concept of "do one thing well" is what I also want, although even there, my "ls" command has sort built in (although the sort functions are part of the run-time shared library, but even so, it makes "ls" a few lines longer that it needs to be - at the convenience of not having to do what I remember under Unix v6, e.g.
ls | sort | pr -4 -l1 or some-such.
Quote:
I find your work to be a unique and intriguing transatlantic blend of technology which could have occurred if Commodore, Apple, Atari and Acorn worked more closely. I am disappointed to see you take a route towards Unix. A very anti-Unix path wo0uld be support for typed filing systems. These were common on mini-computers. Furthermore, Apple and Commodore systems have binary, text and/or fixed length records. I'd like to see a special type to implement line based deduplication. This would allow endless revisions of assembly to be held compactly. This would aid bootstrap of a self-hosting system (able to produce its own Gerber files). I've had success with multiple directory types. Specifically, an abbreviated directory type with a fixed number of entries, short compressed names and no time-stamp meta-data. This works very well for core branches of a filing system.
I've never been a fan of a typed fileing system - I can see its advantaged, but at the lower level a string of bytes can be read by anything. Fixed length records are implemented with seek (and more efficiently with a filing system that supports sparse files) One of the first filing systems I used was Apple DOS and 31 character filenames (with spaces). I was somewhat dismayed with MS DOS when I used it latterly and it's 8.3 limits - right out of CP/M. The Ruby filing system has 21 character filename support.
But things like long filenames, file types, record lengths, and de-duplication need more CPU cycles, more RAM and more lines of code. The Apple binary or text based files were merely an operating system convention - the on-disk format is the same. Commodore used another CPU to handle it's filing system. As for the Acorn ones - I can only wonder at what they were smoking when they came up with that format. It must have made sense to someone at the time, but I never got the hang of it. Ruby supports a 32-bit timestamp, 32-bit load address, 32-bit execution address and a 32-bit 'flags' field - one bit of which is used to denote 'locked'. These are enough attributes to satisfy most Acorn MOS and Apple DOS/ProDOS requirements but does leave room for expansion.
Quote:
One of the newbies suggested audio as ADSR envelopes. I believe this would work particularly well with remote desktop. Indeed, I suggest a large extension to POSIX stdin, stdout and stderr to include an audit log, multi-user multi-touch GUI, ADSR/PCM audio and 2D rendering. In particular, none of this requires piping or I/O redirection. However, if you want to implement redirection, please provide a mechanism to construct a meaningful progress bar. For inspiration, note where AmigaOS diverges from POSIX. For example, Amiga binaries are able to determine CLI or GUI invocation. This could be extended to cover console, text windowing or bitmap windowing. This is in opposition to Unix derivatives, such as Plan9, which attempt to eliminate the distinction between text and graphic windows.
On the ADSR front - take a look at the Acorn "envelope" command and sound system. Ruby supports this by sending the data over the serial line to the "smart terminal". (Supported, but not currently implemented - the smart terminal is based on my RTB BASIC interpreter which does support it, so it's only an hour or 2's work to carry it into Ruby)
And on "smart terminals" the fore-runner to X windows worked as a multiplexor on the host sending a serial stream to it's smart terminal to make sure the right characters went to the right windows. This is potentially feasible but long down the to-do list.
Quote:
I would strongly suggest a "yield processing time" system call. In the trivial case, it would do nothing and return immediately. However, this hook provides enough upward compatibility for all applications to migrate to their own 16 bit address-space, with or without pre-emptive multi-tasking. In particular, this eliminates several horrible heuristics to guess if a process is busy or idling. Trivial environments may otherwise be single user, single tasking, single core, single threading similar to CP/M, Commodore, Acorn or other systems.
That's only going to work on well written applications. However it's similar to the BCPL coroutine mechanism and the early Acorm ARM OS which was co-operative multi-tasking.
The multi-tasking/threading I have in my BCPL VM works similar to the way the Transputer did (does) it - after a fixed timeslice, the next key instruction will force a task switch. In the Transputer it's a jump instruction - it's similar in my BCPL VM, only I have to do extra to preserve the VMs registers for that task - the transputer just trashed them, so the compiler writer was expected to generate code that did not rely on the register contents after a jmp instruction (only 3 registers so not the end of the world) I could do this in my VM, but I don't have control over the code the compiler generates (yet - for no reason that I don't yet want to dive into the source code of the compiler)
Quote:
I recommend a key/value store. This allows all applications to use buddy allocation within a 16 bit address-space and for all applications to share one instance of a slab allocator. It also allows applications to share data. The most obvious benefit is that text editing is not limited by an application's address-space nor any particular bank switching scheme.
In the BCPL system there is no bank-switching. It's also a 32-bit system. My text editor, written in BCPL can edit files up to about 400KB in size in a 512KB RAM system. Sharing data - well with no MMU, the possibilities are endless
However I'm looking at the CSP model - transputer links and channels, so a program can open a channel, write data to it - which will stall, then another program can read from that channel and so on. With clever coding then a channel can be a hardware link to another system.... That's for the future though.
Quote:
A system call for key/value store check-point would allow applications to be mirrored and implement hot fail-over in the manner of Enterprise Java. Indeed, a carefully crafted API and filing system would allow seamless file, program and desktop migration; possibly via virtual machine containers running on commodity hardware. A key/value store with nested transaction isolation has separate merit. In particular, it offers a convenient interface for shared-nothing parallel processing. This eliminates most of the deficiencies around POSIX threading in combination with POSIX mmap().
Where do you draw the line though? This is a hobby retro project (for me, but there are other systems out there) - it's do-able, but more code, more debugging, more to go wrong.
Quote:
I have many issues with POSIX but the sprawling API is an increasingly large attack surface with decreasingly freedom of choice for implementation. In particular, it is an increasingly thin veneer over an MMU with TLB. It also requires single cycle privilege violation detection. 6502 can be extended to compete in this field. However, without economies of scale and access to contemporary fabrication facilities, it is almost guaranteed to fail. I am also concerned that it is a lost battle. Android and iOS are deprecating virtual memory and instead rely upon journal state to implement fast re-start. A key/value store may hold the necessary state. This would allow operating system development to entirely skip any phases requiring virtual memory.
Separately, I have found that 6502 is highly suited to run WebAssembly which is already supported by 40 languages. In particular, it makes no assumption about FPU support and only requires little-endian representation. In this regard, 6502 competes equally with x86. JavaScript implementations are increasingly migrating to WebAssembly as an intermediate representation. This works in a manner which is compatible with Forth, Pascal, C and Java.
Personally, I don't think there is anything to compete with - it's a hobby level project - which isn't to say this isn't possible, but be realistic. I did plan early on to treat this as a "what if" - meaning "what if I applied what I know today to something I used 40 years ago". I came up with a poor mans BBC Micro because that for me was the pinnacle of the 8-bit micro world at the time - and while there were 6502 systems with getter graphics and sound, the BBC Micro was the ultimate programmers and hardware engineers 8-bit micro. I ran a complete factory automation system on a network (yes, network - Econet) of BBC Micros in the early 80's. We had automated loaders, CNC machines to control, AGVs and a large materials transport system - all controled by BBC Micros in "islands of autonomy" using the network for job control and routing. (All coded in BCPL)
I'll re-read this later - that wall isn't going to knock down itself ...
-Gordon