trn

While I'm not necessarily 100% anti-AI, it would completely eliminate all the potential for learning and any "fun" from this project.

Yes, DR-DOS/Novell DOS 7 has a full 386 preemptive multitasking kernel and a decent API, which was essentially unused, with a few exceptions.

See https://web.archive.org/web/20160809210402/http://www.drdos.... and https://web.archive.org/web/20170211175548/http://drdos.net/... for more details

Actually, while the TPA is "flat", the OS model is using only segmentation for protection and not paging currently. Just the segment is quite large:)

Thank you, as this is my project. As I said in the README, it's as much of a learning experience as it is a "practical" project. Using AI would eliminate the fun.

Yes, currently the system boots from a floppy disk (stage1 -> stage2 loader), which then loads the OS (CBIOS/BDOS/CCP) and an (384K) initial ramdisk, and currently runs out of memory, so once the OS is booted the disk can actually be removed from the system.

Once there is more proper disk support, the initial ramdisk can become optional, though a more proper ramdisk implementation is planned, which will make supporting floppy-disk-only systems easier.

Hi there, this is my project. And yes, you are essentially correct. It can actually work in a little less than 2MB, but this was done this way for simplicity, and to avoid, for now, what would be a more complicated memory map and paging requirements.

We also have a new CP/M-86 emulator at https://github.com/johnsonjh/emu2-cpm86

Multics MR12.9 is under active development. The current release is MR12.8, released August 8, 2023: https://multics-wiki.swenson.org/. While Multics no longer commercially supported, many of the current developers were previously involved with the project from its time at MIT and Honeywell Bull.

See https://dps8m.gitlab.io/ for more information.

While we do want to support GCOS, it'll be GCOS-3, and that is if we can find system tapes. We are actually planning another blog post soon that will touch on this.

Now, Multics does have GTSS (GCOS Time Sharing Simulator), which Dean has helped us get working.

There is an general information page available: https://dps8m.gitlab.io/sb/MR12.8/documentation/info_segment...

This facility is based on GCOS-3 4JS3, and it does work, although the software that we have available for it is minimal.

GCOS-8 is a different beast entirely. While there is the possibility that a future version of the simulator could theoretically run GCOS-8 in the future (as most of the work necessary overlaps with supporting CP-6), this is not something that we're going to support as GCOS-8 is a current commercial product.

If you want to run GCOS-8, you'll have to purchase an Atos BullSequana M9600 mainframe - https://atos.net/wp-content/uploads/2020/09/BullSequana_M_Br...

> you're not allowed to add additional usage restrictions to GPL software

SIMH is not GPL'd software.

I'll give an unpaid plug to https://www.softintegration.com/ for their Ch product, which is beyond excellent (and has existed for a very long time.) Clang-Repl/Cling is, however, nice to see, especially as it is open source.

I should also mention that the PDF documentation has some graphics showing how these components are (physically) connected together at https://dps8m.gitlab.io/dps8m-r3.0.1-archive/R3.0.1/omnibus/... (pages 49 through 52).

If you'd prefer not to have to view the PDF, the images are reproduced here: https://imgur.com/a/x3fy4nO

Yes, I was simplifying a bit :) Those who are interested should take a peek at https://dps8m.gitlab.io/dps8m/Overview/#supported-components to see all the various components that make up the DPS mainframe system.

Perhaps, however, SIMH (http://simh.trailing-edge.com/, https://opensimh.org/) also calls itself a simulator rather than an emulator. Six of one, half dozen of the other, I guess!

Yes, this interpretation is correct.

It should be noted that not all of the hardware is strictly "emulated" (or simulated, if you prefer that term) in the traditional sense of interpreting each hardware instruction. The DPS in the name means "distributed processing system", and this is not merely a marketing term.

The DPS series, like many other mainframes, have multiple independent systems working together. For example, IO is handled by a FNP (frontend network processor) which was a (physically) separate minicomputer, with its own CPU, OS, etc. There were various FNP models (16-bit and 18-bit systems) produced. The DPS8M software implements the FNP at a high level, rather than running its original software (though there is both an FNP software simulator and a FPGA FNP project underway).

We did have some internal debate on if the system is a "simulator" or an "emulator", but really, it can be both, depending on how pedantic you want to be.

The biggest reason for the name being what it is, however, is that since the beginning, the software was called the "DPS8M Simulator", and even if emulator might be (arguably) a better name, it's not worth changing it at this point.

Disclosure: I'm one of the developers.

Edit: There are also some optimizations in place (https://dps8m.gitlab.io/dps8m-r3.0.1-archive/R3.0.1/global/S...) that blur the lines between emulator, simulator, and virtual machine.

See the homepage at https://dps8m.gitlab.io/ as well for more details.

I will confirm that Vile is an excellent editor. I don't know if I'd consider it a vi-clone, because the vi-ness is kind of skin-deep, but it's performant and works well.

(In school, early 90's, there was a large vile following on VMS, which is where I mostly used it. I don't recall why it was preferred to Vim on VMS, however. Perhaps we didn't have Vim easily available or installed. But I digress.)

Do you have a summary of those changes or a repo up anywhere? If they are general-purpose you might consider sending a PR upstream to n-t-roff

It should be simple, mostly fixes and no major features or refactoring.

pEmacs is "even better" for minimalists.

https://github.com/hughbarney/pEmacs

Stripped -Os build using link-time GC on Linux x86_64 glibc:

     30 KB  pe*

Compare to portable mg:

    132 KB  mg*

OpenVi is ...

    278 KB  bin/vi*

An even smaller vi implementation is Xvi.

     56 KB  src/xvi*

This would be an 'ersatz' vi since it is not built on top of a real ex-mode.

Even tinier ersatz-vi clones exist (`levee`, `s`, `VIrus`) but these are not complete implementations.

OpenVi uses only secure functions (snprintf, strlcpy, etc.) as a matter of policy.

This may lead to a more secure editor for untrusted files, but it depends on how careful the other editors are. (I haven't examined them at that level.)

I dogfood OpenVi and use it for OpenVi development, however, 99% of my normal programming workflow is (terminal-based) NeoVim.

The other 1% is Eclipse or VSCode ... and I have VSCode setup to use the embedding functionality of NeoVim.

Of particular note, the lack of `expandtab` in Nvi and Traditional vi may be more of a showstopper than lack of multibyte glyph rendering for many.

Cleanly doing UTF-8 support (the "right" way) is planned but is certainly non-trivial ... for example, see:

https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf and http://www.usenix.org/events/usenix99/full_papers/hagino/hag...

Nvi2 (and Nvi1) are excellent editors, but I wouldn't want to copy the Nvi2 implementation directly. This has been talked about elsewhere*

* https://misc.openbsd.narkive.com/9NHoQv8L/nvi-and-unicode#po...

To give a quick overview of ':set'-able options (`:set all` output) of the various editors that derive from 'nvi' ... [no Nvi2 here ... yet] ...

Nv1 [nvi-1.81.6-45-g864873d3 (2022-02-21)]:

    noaltwerase     nocomment       noignorecase    nomodeline      noreadonly      noshowmode      nottywerase
    noautoindent    noedcompatible  keytime=6       msgcat="./"     noredraw        sidescroll=16   noverbose
    autoprint       escapetime=1    noleftright     noprint=""      remap           noslowopen      warn
    noautowrite     noerrorbells    lines=24        nonumber        report=5        nosourceany     window=23
    backup=""       noexrc          nolisp          nooctal         noruler         tabstop=8       nowindowname
    nobeautify      noextended      nolist          open            scroll=11       taglength=0     wraplen=0
    cdpath=":"      filec=""        lock            optimize        nosearchincr    tags="tags"     wrapmargin=0
    cedit=""        flash           magic           path=""         nosecure        noterse         wrapscan
    columns=117     hardtabs=0      matchtime=7     print=""        shiftwidth=8    notildeop       nowriteany
    nocombined      noiclower       mesg            prompt          noshowmatch     timeout
    directory="/tmp"
    fileencoding="UTF-8"
    inputencoding="UTF-8"
    paragraphs="IPLPPPQPP LIpplpipbp"
    recdir="/var/tmp/vi.recover"
    sections="NHSHH HUnhsh"
    shell="/bin/zsh"
    shellmeta="~{[*?$`'"\"
    term="screen-256color"

OpenVi [7.0.13-dev (OpenVi) 02/20/2022]:

    noaltwerase     nocomment       noiclower       mesg            report=5        taglength=0     nowindowname
    noautoindent    noedcompatible  noignorecase    noprint=""      noruler         tags="tags"     wraplen=0
    autoprint       escapetime=2    noimctrl        nonumber        scroll=11       noterse         wrapmargin=0
    noautowrite     noerrorbells    keytime=6       nooctal         nosearchincr    notildeop       wrapscan
    backup=""       noexpandtab     noleftright     open            nosecure        timeout         nowriteany
    nobeautify      noexrc          lines=23        path=""         shiftwidth=8    nottywerase
    nobserase       noextended      nolist          print=""        noshowmatch     noverbose
    cdpath=":"      filec=" "       lock            prompt          noshowmode      novisibletab
    cedit=""        noflash         magic           noreadonly      sidescroll=16   warn
    columns=117     hardtabs=0      matchtime=7     remap           tabstop=8       window=22
    imkey="/?aioAIO"
    paragraphs="IPLPPPQPP LIpplpipbpBlBdPpLpIt"
    recdir="/var/tmp/vi.recover"
    sections="NHSHH HUnhshShSs"
    shell="/bin/zsh"
    shellmeta="~{[*?$`'"\"
    term="screen-256color"

OpenBSD vi [7.0-current]:

    noaltwerase     escapetime=1    noleftright     path=""         noshowmatch     warn
    noautoindent    noerrorbells    lines=36        print=""        noshowmode      window=35
    autoprint       noexpandtab     nolist          prompt          sidescroll=16   nowindowname
    noautowrite     noexrc          lock            noreadonly      tabstop=8       wraplen=0
    backup=""       noextended      magic           remap           taglength=0     wrapmargin=0
    nobeautify      filec=" "       matchtime=7     report=5        tags="tags"     wrapscan
    cdpath=":"      noflash         mesg            noruler         noterse         nowriteany
    cedit=""        hardtabs=0      noprint=""      scroll=17       notildeop
    columns=108     noiclower       nonumber        nosearchincr    timeout
    nocomment       noignorecase    nooctal         nosecure        nottywerase
    noedcompatible  keytime=6       open            shiftwidth=8    noverbose
    paragraphs="IPLPPPQPP LIpplpipbpBlBdPpLpIt"
    recdir="/tmp/vi.recover"
    sections="NHSHH HUnhshShSs"
    shell="/usr/local/bin/zsh"
    shellmeta="~{[\*?$`'"\"
    term="screen-256color"

Traditional vi [n-t-roff Heirloom vi (01/14/2017)]:

    noautoindent            nomodelines                     noshowmode
    autoprint               nonumber                        noslowopen
    noautowrite             open                            nosourceany
    nobeautify              nooptimize                      tabstop=8
    directory=/var/tmp      paragraphs=IPLPPPQPP LIpplpipbp taglength=0
    noedcompatible          prompt                          tags=tags /usr/lib/tags
    noerrorbells            noreadonly                      term=screen-256color
    noexrc                  redraw                          noterse
    flash                   remap                           timeout
    hardtabs=8              report=5                        ttytype=screen-256color
    noignorecase            scroll=17                       warn
    nolisp                  sections=NHSHH HUnhsh           window=35
    nolist                  shell=/usr/bin/zsh              wrapscan
    magic                   shiftwidth=8                    wrapmargin=0
    mesg                    noshowmatch                     nowriteany

Don't confuse OpenVi/OpenBSD-vi, nvi1, and nvi2. These are all different programs that share the same heritage.

OpenVi is derived from OpenBSD vi, which derives from nvi version 1.79, released in 1996. There has been 25+ years of independent development as part of the OpenBSD base system and has diverged greatly in that time, with the development going in a different direction.

Nvi1, currently on version 1.8x, is maintained at https://repo.or.cz/nvi.git - I believe the latest version of this editor does have multibyte support, but this is not the OpenVi/OpenBSD version of the editor.

Nvi2 shares heritage as well but also, quite far removed from the original code, is actively maintained at https://github.com/lichray/nvi2 and also includes multibyte support.

(IIRC) the multibyte support in both Nvi1 and Nvi2 derives from nvi-m17n, developed as part of the KAME project by the late itojun - http://www.itojun.org/itojun.html ... the last update to nvi-m17n was about 3 years ago, and is available at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files

Currently, optimizing for size using link-time garbage collection with GCC 11.2 on an x86_64 glibc Linux system gives a good idea of the changes over time and the different direction these editors have taken. OpenVi is also simplified in structure and does not have the three levels of abstraction of Nvi 1.8x - there is no library interface layer.

For OpenVi, the compiled binary is 280K, and for Nvi1 (nvi-1.81.6-45-g864873d3) the compiled binary is 528K (36K for vi, 528K for libvi).

OpenVi has a single configuration standard with no dependencies beyond curses.

Nvi1 has many options beyond trace/debug ("widechar" "gtk" "motif" "threads" "perl" "tcl" "db3/4" "internal-re") - so at least 255 different build variations are possible.

(I've not yet built Nvi2 myself on Linux so I can't provide an really fair comparison yet, but I will, and I'll summarize the data in an FAQ section of the README)

Nvi1 (https://repo.or.cz/nvi.git) looks like:

    36K    vi
    24K    vi-ipc
    108K   vi-motif
    492K   libvi.so.0.0.0
    660K   total

OpenVi does not - it's a single monolithic binary:

    280K   bin/vi

(Note that I was using the defaults here, I'm sure that it's possible to trim down Nvi 1.8x further, but I'm comparing the default compilations, optimized for size (GCC, -Os, -fdata-sections, -ffunction-sections, link-time GC enabled), but Nvi 1.8x is a much more complicated program, and has a different feature set, and different supported options.

But, these are all different editors at this point. A lot happens in 25 years.

https://copyfree.org/standard/licenses is worth a look

Using Carsten Kunze's actively maintained continuation of Gunnar Ritter's (outstanding) traditional ex/vi project is highly recommended. See https://github.com/n-t-roff/heirloom-ex-vi/.

The parent project on SourceForge hasn't had any activity for 15 years, nor a release in 17+ years, and contains various known bugs, all of which are fixed in Carsten Kunze's project.