OSDev.org

PDOS-generic, in one of its forms, is now available on the Google Play Store:

https://play.google.com/store/apps/deta ... l=en&gl=US

You need to marry this up with one of the distributions from http://pdos.org if you want pre-made apps.

The ARM32 version has more apps available. The ARM64 version currently only has an integer-only version of bwbasic, but the underlying technical issues have now been fixed (after enormous effort) and I am cutting a new release (normally takes half a day) that will provide a fully functional bwbasic and micro-emacs so that basically all you need is a smartphone (ubiquitous even in the 3rd world), add a USB keyboard for around US$3, and voila, you have a computer that enables you to learn BASIC, just like back in the Good Old Days (TM).

This mob:

https://en.wikipedia.org/wiki/One_Laptop_per_Child

burned through millions of dollars trying to get a computer for under US$100, but never got below US$200.

Depending on how you count - it can be done for US$3. I bought some new, but old model tablets for about US$20. And I can buy a new smartphone with OTG support for around US$40. (I live in the Philippines currently).

BFN. Paul.

I need technical things to quietly do on my tablet; thanks! However, there are issues; some of them rather serious.

The on-screen keyboard appears over the text, so you can't see what you're typing. Granted, I should be using an external keyboard of some sort, but until I find one comfortable in my particular usage, I'm stuck with the OSK. Of all the console-type interfaces I've used on mobile, Gforth handles the OSK's chaos about as well as can be done, resizing the console when the keyboard opens & closes, preserving scrollback. Having said that, I'm not a huge console fan so others might disagree.

The font is a mess; a proportional font with letters placed on a fixed pitch without regard for their width. It is not the only app so affected on this tablet, nor the worst. ConnectBot draws a proportional font a line at a time while the cursor follows a fixed-pitch grid. In PDAndro you can see what character the cursor is on; in ConnectBot you can't. So, what to do about it? Including a font is the safest option, but where to find a public domain font? If I remember rightly, font glyphs can't be copyrighted, only font files, so if you convert a font to another format, it should be public domain. (Check that before you do it.) What format to use? Mobile devices come in a wide range of DPIs, so you'll want something scalable or a selection of sizes of bitmap font. I've also seen large font images scaled; it kind-of works but I find myself using a larger size font than I do with bitmap fonts or good truetype rendering.

Single-orientation is a little annoying, though not too bad in landscape and not as much as when batteries were smaller. The issue is charging while using it; single-orientation disallows choosing which side the charging lead ends up. Honestly, I blame Android for allowing this more than apps for choosing it.

It restarts every time I switched to Pdandro from another app. Text remains on the console, but there's a "bios starting" message. I can accept this, I think auto-kill is reasonable in mobile use, but I'd like to know, does PdAndro flush memory-mapped files when killing programs for such a restart? Are there PDos programs which are written to work with auto-kill? On return to the app, will it resume the program which was running previously, or will it return to the shell? Returning to the shell would be a huge nuisance if I were using a program under Pdandro to augment my use of another app, such as taking notes for a strategy game. It also makes it impossible to consult documents outside pdandro while coding in pdandro.
...
Oh. The shell forgets even the current directory when it restarts. This restarting on every switch, even when I take the briefest of peeks at another app or even the home screen, has got to stop.

Why does the shell default to Downloads? Can i change it?

I'd have to disable cursor blinking to use it for any length of time.

On a lighter note, is the screen texture available for programs to poke at? I enjoy writing graphics rendering code.

It's a bit more complicated than that. Better stick to fonts that are already public domain. (Some of these fonts are public domain, but they'd need to be scaled up to be useful on a high-DPI tablet screen.)

Ah, so it is. There goes my wishful thinking.


I considered suggesting those fonts -- the X fonts -- but only really remembered "fixed" and the fact that many people don't like it. It's just as well I didn't. Booting up my old (2001) Linux VM, I see there isn't really one font called fixed; it's a whole assortment with different foundry names. Some of them are nice, but that applies equally to the fonts at your link.

Everything you mentioned is related to the user interface provided by Android with about 800 lines of Kotlin code. This code was written by Jean-Marc for me as a favor, after I told him that I just needed something minimal. So I was given something minimal - public domain too. And Robert is the one who published on the Google Play Store - "because he could" - not because he committed to maintaining that code. My work starts when the Kotlin code calls C code, which is called libbios.so aka bios.exe (you can run this executable on a Linux ARM machine standalone or under qemu-arm). So I'm the one responsible for the fact that it says "press enter to exit" when actually you need to type "exit" to exit. That message is correct when run a different way. Anyway, I've already fixed that so it should find its way onto the Google Play Store in due course.

Are you aware that there is a Windows 11 for ARM? And that it is - at least for now - maybe not for long - capable of running 32-bit programs as well as 64-bit? And are you aware that there is an msvcrt.dll (both 32-bit and 64-bit - same as for the x64)?

Well, I only found that out myself for sure a few days ago when I received my Lenovo Thinkpad x13s (ARM 32/64 CPU, Windows 11 OS) and I have been busy with yet another person (from Slovakia) on converting my 32-bit ARM executables from pdos-generic a.out format (that doesn't exist anywhere else) to Win32 ARM format dependent on msvcrt.dll (similar to mingw).

What that means is you're about to get a mini Windows clone on your Android, unless there is some insurmountable technical barrier that I am not yet aware of (e.g. pdld isn't working right at the moment). And that would include a full toolchain and editor giving you the ability to reproduce everything, including libbios.so, - but excluding the Android stuff such as Kotlin - byte-exact.

If that works, I'll be moving on to ARM64 and doing the same thing - creating valid Win64 ARM64 executables. But you won't get a toolchain on the Android itself (because gcc 3.2.3 doesn't have ARM64). If your machine is 32/64 then I asked for it to install the 32-bit versions as priority for this reason.

And then I'll reassess the next priority (e.g. the outstanding MSDOS 4.0 rebuilding work - I have a VHD on my website - built from source on Windows 2000, not on MSDOS 4.0 itself).

I doubt that my priority will be to learn Kotlin and produce a more sophisticated version of the PdAndro user interface.

However, I'm willing to pay an Android hobbyist to work on that. I'm not willing to pay full western contract rates for an unlimited time which is what people normally demand to work on software. I'm an individual, not a company.

Do you know someone who is interested in doing Android work who can fix the problems you identified? They would need to agree to make any code changes public domain.


Exactly as it was on MSDOS. You can use the (provided) microemacs to read text documents.

I was only attempting to reach MSDOS to get a baseline. I've been trying to produce MSDOS (on arbitrary hardware) for 30 years (the anniversary came up a bit over a week ago).

Advances from MSDOS need to be negotiated, or perhaps that opens up the possibility for a commercial quality derivative. It's all public domain so it there are zero restrictions on what you do.

Do you have any suggestions that don't involve me personally writing non-C90 code?

At some level I am leery about making any changes to that barely-supported Kotlin code, because it will detract from the simplicity. Someone added multitasking and VM to PDOS/386, then left, leaving me holding the bag (and for where it ended up - PdAndro - probably useless), and it took a lot of effort just to #ifdef it out so that it returned to something I could understand and maintain. Having said that, more than the minimum (ie text only) was indeed added to PDOS/386 - you can display a JPEG now - using valid Windows code - so in the end, I do add enhancements that are provided.


It was my plan to allow an extension to ANSI X3.64 to enable graphics mode, and then when you to a screen location - can't remember the sequence - ESC 10;20m or whatever - when you do that, it would actually be to pixel at row/column 10/20 - or 700/500 - whatever large screen you have - and then when you write an "X" it would draw a pixel in the current color. Not expecting that to be fast. But I am expecting that to be simple and understandable and portable unlike triple-buffered 500 fps true-color liquid-nitrogen-cooled super-graphics.

Alternatively - I could potentially partially? fund some sort of startup to make a commercial version. And the new code would no longer be public domain, but presumably copyrighted and closed-source by that company. If someone has a vision?

The Android would be just one place that this software could run. I run the exact bios.exe/libbios.so on my Pinebook Pro.

Fair enough. It's nice when someone does something for you for free, but it's no use expecting too much. There are always issues when writing software for more than one device.


I was vaguely aware, in a "things that happen on other planets" kind of way. I had no idea you could just buy ARM Lenovo Thinkpads with Windows 11. I'm looking at my collection of Thinkpads, but I'm thinking of the few older binaries I still use. Most of them are actually open source, they just haven't been ported for ages.


Thanks. It turns out my tablet is 64-bit only. It's also particularly bad for my eyes, so I've got my very old 32-bit phone out & will see how that goes. If the app doesn't work, I've got some other ideas.


I must admit I don't understand the current interest in MSDOS 4. It was hated back in the day; people stuck with MSDOS 3.3 for compatibility reasons. Then again, perhaps the incompatibilities were actual improvements. Such seems to be the way of computing.


I can understand that. I dip into modern tech every now and then, and usually get nothing but a headache! Sometimes it works out better though.


I wish I did! I don't know anybody these days. I'll try to have a look at font choices; grouping the X/that_terminal fonts by license, but can't make any promises. I first want to finish the extensibility part of smollex BASIC -- "It smol, but it can grow!" It's based on bootBASIC so I don't have control over its license, unfortunately.


Unfortunately, single-tasking OSs expose one of my biggest weaknesses: I struggle to hold information in my head in the very short term. I rediscover this every time I go back to DOS. However, microemacs might well be powerful enough to work around this. I don't need multitasking as such, just preservation of the state of different apps/windows/documents/etc. so I can flick between them. Now I recall SetEdit worked quite well for me, but it broke and I never fixed it. Microemacs may well suit me better.


I might try to do a little bit to it myself, though I've not done well with C in the past.

Honestly, if the OS guarantees to save my programs' cached disk data when killing it, I can imagine writing programs to work with that, especially with memory-mapped files. The real problem is that I'm a slow coder and we have many decades worth of software written on the assumption that the OS and hardware are reliable. Forth seems to be the only exception, as development platforms go, but I'm a very slow coder in Forth.


Well, you support mmap, so I guess I don't. Thanks.


Oof! Yeah, it's no good trying to maintain code you don't understand. I don't even like to use software which has unmaintained parts.


Haha! Yeah... but I go back to 8-bit Ataris which were actually somewhat simpler to work with than ANSI terminals. A linear framebuffer is a simple thing to understand, but just the ability to set pixels is good.




I guess you could, but I don't know. When a business takes on a project, how well they'll do can be quite uncertain. Besides, I can't afford to pay for anything right now.

It turns out that even my 2013 phone won't let me exec my own binaries. I'm only allowed to create files where I'm not allowed to exec, and vise versa. (I should have rooted it when the info was easy to find.) Can I download the APK without using the Google Play store?

PdAndro is designed to work within that restriction. No rooting required.


This (from Robert) appears to be up-to-date:

https://github.com/robertapengelly/Pdos ... o/releases

You might want to get that, plus ucarm.zip while it still matches. The major switch to win32arm has been experiencing technical difficulties, which has delayed it - but they may have been resolved.

And just to be clear - it doesn't do that by emulation of some sort - it runs executables at full native ARM32 speed.


The technical difficulties have been overcome. However, there will be a delay as I see how far I can push this now that it is working (with -O0).

-rw-r--r-- 1 kerravon kerravon 4120064 May 10 12:17 gcc-new.exe
[kerravon@paul-pinebook gcc]$ cmp gccprm.exe gcc-new.exe
[kerravon@paul-pinebook gcc]$

[kerravon@paul-pinebook gcc]$ file gccprm.exe
gccprm.exe: PE32 executable (console) ARMv7 Thumb (stripped to external PDB), for MS Windows, 6 sections
[kerravon@paul-pinebook gcc]$

Unfortunately I spoke too soon.

The compiler that is able to reproduce itself (above) is about 6 times slower than the near-identical one (especially judging by file size) produced on x86 via cross-compile.

I think that is because the x86 has a proper 64-bit double, but for ARM I am using 32-bit floats and doubles (because I only have single precision public domain code in PDPCLIB and I am using soft float in the first place because the machine definition for ARM is using old pre-VFP instructions that are no longer supported on real hardware).

So I'm keeping it at -O0 until -O0 is working properly natively.

And I'm about to do a fresh build which means there will be a mismatch likely starting in the next 24 hours until PdAndro copies across the new bios.exe.

BFN. Paul.