DOS ain't dead

> > Well, PDOS-generic, anyway.
> >
> > Commands date/time, copy, dir, type, exit are working.
> >
> > Works on ARM Chromebook, Android smartphone and Android netbook.
> >
> > https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0
>
> Hi Paul. An ARM version of MS-DOS is no MS-DOS. I may look and behave
> similar to MS-DOS, but it cannot run real (x86) DOS software. So it's not
> "MSDOS".

It runs "real" DOS software at the source code
level if the Pos interface is used.

Some people were looking forward to a 32-bit
version of MSDOS.

If Microsoft had produced a 32-bit version of
MSDOS that ran in PM32 and required people to
recompile using a 32-bit compiler, and didn't
run 16-bit software, would you have said

"Microsoft's 32-bit MSDOS may look and behave
similar to MSDOS, but it cannot run real (8086)
DOS software, so it's not MSDOS"?

And if Microsoft had produced a version of
MSDOS for the Atari (68000), would you have said
that that wasn't "real" either?

Would you have said that CP/M-86 (a real thing)
is not "real CP/M" because it doesn't run CP/M
8080 binaries?

> I suggest coming back when you can run Norton Commander or any of its
> clones; no matter if on ARM or X86.

I suggest we redesign MSDOS with a view to an
ARM v7 eventual port.

I've produced a POC but I am not claiming it is
perfect. I'm after feedback.

Hello tom,

> asking to run gorilla.bas (which requires a genuine MS interpreter) or DOOM
> (which I agree is pretty demanding), is indeed a high margin to clear.

donkey.bas, not gorilla.bas! I suspect donkey.bas might not be as hard to "port" to a ARMv7-based chip running non-Microsoft code, as it might first seem.

Google recently (2018) put out a JavaScript-based BASIC interpreter that can already run donkey.bas: https://github.com/google/wwwbasic .

The donkey.bas code contains one POKE into the BASIC interpreter's data segment — which is OK to ignore — and one PEEK into the IBM BIOS's data area.

> I suggest coming back when you can run Norton Commander or any of its
> clones; no matter if on ARM or X86.

I guess that will also be a good goal to aim for.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I suggest coming back when you can run Norton Commander or any of its
> clones; no matter if on ARM or X86.
A "DOS-like" OS on the ARM does sound exciting and enchanting. I appreciate your work and effort toward that end. We all start somewhere, and with ARM processors becoming more and more used, probably soon to 'replace' Intel chips due to reduced instruction set and scalability, we'll be "forced" to abandon Intel artechicture soon. So, "MS-DOS for ARM" is most welcomed, indeed.

Get Xtree Gold running on the ARM, and I'll be impressed! This is the "best" file manager / viewer / utility for DOS ever made, in my opinion. I still use it daily, and its interface is perfect.

> > Well, PDOS-generic, anyway.
> >
> > Commands date/time, copy, dir, type, exit are working.
> >
> > Works on ARM Chromebook, Android smartphone and Android netbook.
> >
> > https://github.com/jeanmarclienher/Pdos-PdAndro/releases/tag/rel0.7.0
>
> I'll allow referring to this as a DOS. After all there were many Disk
> Operating Systems out there, not all 8086-based MS-DOS-compatibles.
>
> However, what interests most of us here is the family of DOSes that I call
> 86-DOS. They are based on the original 8086, compatibles, or running
> applications in the Real or Virtual 86 Mode of more recent x86 machines.
> DPMI adds 16-bit and 32-bit PM capabilities, but the common thread is still
> an 86-DOS compatible interface.

And if applications written for 86-DOS, at least
moving forward, use the Pos* interface, they can
be recompiled as 80386-DOS and ARMv7-DOS, with
no source code changes.

BFN. Paul.

> I know nothing about ARM programming etc. but I would be interested in
> running programs that I want to write myself for an android smartphone.
> Would your work allow say a FreeBASIC program to be launched from a
> smartphone?

If FreeBASIC is C90-compliant, then yes, it should work.

> The complete lack of standardization of the ARM platform is a real problem,
> nothing FB devs can do anything about. This isn't Linux's fault per se.
> Every ARM device has its own variation on the boot loader, custom device
> tree, proprietary bits, etc. So there's no universal ARM Ubuntu
> distribution, for example, that runs on every device. Most custom devices
> like Pine's run their own distro that sometimes is based on something
> standard, but not always. So it's incredibly hard to support Linux binaries
> on ARM. If ARM ever finally got a standardized platform the way
> Intel-compatible PCs have with standardized booting, standardized device
> layouts, then Intel would be in serious trouble! Maybe if Microsoft would
> get serious about Windows on ARM then we'd see some standardization. Or
> Maybe Apple's M1 family will spur some of this.

My design relies on something completely different.

I am sort-of dependent on the ARM syscalls being
standard, which I think they already are.

Even if they're not, I can get around that by having
a custom executable for just that non-standard device.

YOUR applications will work unchanged, because they
make NO syscalls and call NO DLLs.

That's what pdos-generic is.

Note that I tried it on 3 completely different devices
(chromebook, netbook, smartphone), and the syscalls, and
thus the applications (that don't make syscalls), all
worked fine.

Non-C90 applications can probably be made to work - C90
isn't magic - but probably require a lot of effort
setting up the required infrastructure to replace my
infrastructure.

Also, POC isn't completely complete yet. Maybe I'm
missing a concept that will be revealed later.

BFN. Paul.

> I know nothing about ARM programming etc. but I would be interested in
> running programs that I want to write myself for an android smartphone.
> Would your work allow say a FreeBASIC program to be launched from a
> smartphone?

As I mentioned before - if FreeBASIC is C90-compliant,
it should be able to be built for PdAndro.

However, I'm only familiar with bwbasic - which is an
interpreter. So yesterday I built that and that is now
available if you get the latest PdAndro from here:

https://github.com/o-ksi-d/Pdos-PdAndro/releases/tag/rel.0.61.0

and UCARM from http://pdos.org

You just need to type "bwbasic" and then you can go:
print 3 + 4

Or you can use the included microemacs and go:

e test.bas

then:

for x = 1 to 5
print "hi", x
next

ctrl-x, ctrl-s to save
ctrl-x, ctrl-c to exit
(ctrl-g to cancel if you stuff up a command)

Then

bwbasic test.bas

There is a BASIC tutorial available at http://pdos.org
which I intend to update soon for this new environment
and include in ucarm.zip

The One Laptop Per Child people never managed to get
the price below US$200.

Smartphones are ubiquitous worldwide. For US$2 you can
turn it into a computer and start learning how to
program.

When you've cut your teeth on BASIC, you can move to the
included C compiler.

There is only one small fly in the ointment. I had to
make a special version of bwbasic that doesn't use floating
point, as floating point is not yet properly supported in
this environment. For some reason the ARM hardware doesn't
have the instructions, and there is no software emulation
being done somewhere that would cover it. I could use
soft-float but don't have floating point routines of my
own (pdpclib just has stubs which are enough for some
things but not if you really want to use floating point).

BFN. Paul.