PDOS for Amiga

[meynaf]

Originally Posted by kerravon

Since I wish to write in standard C90 instead of making my code timing-sensitive and non-standard, I was thinking that what I should actually do is make the OS (PDOS) keyboard routine generate two ESC characters in response to the user pressing ESC. What do you think of that?

I suppose you could do this. Like C standard string formatting uses "%%" to represent "%" character.
But, don't standard ANSI sequences have a way to represent ESC key itself ?
If the answer is 'no' then it says ANSI is ill-suited for keyboard input

[kerravon]

Originally Posted by meynaf

I suppose you could do this. Like C standard string formatting uses "%%" to represent "%" character.
But, don't standard ANSI sequences have a way to represent ESC key itself ?
If the answer is 'no' then it says ANSI is ill-suited for keyboard input

According to:

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

<esc> <nochar> -> esc
<esc> <esc> -> esc

so it looks like it accepts both a timeout and a doubling of characters, so on systems with no timeout capability, code should be in place to look for the second ESC, and it seems appropriate for me to generate two of them.

[kerravon]

Originally Posted by kerravon

So I've proven the entire software suite I wish to run. All in C90.

Correction. Two bits of software (msged and the tobruk mail-processor) do directory traversal so have Windows-specific code to do that.

[kerravon]

I was thinking of how to add ANSI support to PDOS/386 and I decided to do some investigation of another interesting environment - UEFI shell. I looked up the specs to see if UEFI supported ANSI escape sequences and it seems it does not. It instead supports functions like SetCursorPosition(). Which is not much different from a traditional BIOS.

I think it would be good to have my application suite (gcc, including gccami) written using UEFI as the OS, as it is effectively a new OS. And the way I do that is to add support to the C library, PDPCLIB, not PDOS. So I was thinking that it is in PDPCLIB that I should be interpreting ANSI escape sequences and doing UEFI calls. And if I do that for UEFI I could also do it for BIOS, rather than putting it in PDOS/386. But I guess that is a fundamental problem - PDOS-generic is proper design, PDOS/386 is not.

The traditional BIOS is fundamentally an OS that allows me to open just 4 files - "0x80", "0x81", "0x82", "0x83". And it is an OS that gives me a memory map that I am required to suballocate myself.

UEFI instead allows me to open files by name on a FAT disk (I believe). I'm not sure if it supports long filenames. And I don't know what the memory allocation routines are like.

PDOS-generic would open flat files for its own FAT support on a UEFI system the same as it does on the Amiga. But it would open raw disks on a BIOS system.

[kerravon]

Hi folks.

pdos-generic was invented in this thread, inspired by the Amiga, and was shown to work on the Amiga as proof of concept.

There has been another development - it now works on an Android smartphone, also as proof of concept.

It effectively turns your phone into a computer running MSDOS - and using native ARM instructions instead of using Bochs emulation. I can get a brand new Android phone with OTG support for about US$40 and an external keyboard that allows touch-typing for about US$2 and the adaptor varies in price from about free to US$3.

And you can use it to program, once it is fleshed out with the functionality that already exists in PDOS/386.

Available here:

https://github.com/jeanmarclienher/P...s/tag/rel0.5.0

[kerravon]

A string of (apparent) advances on the mainframe, has led to a new possibility/challenge for PDOS-generic on the Amiga. As per this post:

https://groups.io/g/hercules-380/message/1664

I believe the Amiga allows a shell to be directed to a serial port, which would allow me to start sending zaps up. So I just need to provide a "zap" built in to the command.exe.

ie I am very close to a PDOS-generic Amiga, distributed as UCAMIGA (UC = University Challenge) like the other UC on http://pdos.org and no other tools are required and I can reconstruct everything on a 68020 Amiga.

I'm thinking this will be my next priority unless someone can point to a flaw in my logic for reconstruction on z/Arch (mainframe), 80386 and ARM.

[kerravon]

Originally Posted by kerravon

I believe the Amiga allows a shell to be directed to a serial port, which would allow me to start sending zaps up. So I just need to provide a "zap" built in to the command.exe.

ie I am very close to a PDOS-generic Amiga, distributed as UCAMIGA (UC = University Challenge) like the other UC on http://pdos.org and no other tools are required and I can reconstruct everything on a 68020 Amiga.

I have now done this body of work.

Would someone like to test it?

http://pdos.org/temp.zip

It needs about 30 MB of RAM to run.

Run like this:

bios.exe pdos.exe uc8086.vhd

The VHD is just an example FAT disk, not related to the Amiga. If it works, you can do a "dir" and see the contents.

[kerravon]

There has been a new twist to this story.

At http://pdos.org you can find UCX64 which converts a UEFI system into a Win64 system.

The PDOS-generic concept - invented in this thread - converted any existing OS into a PDOS OS, running at native speed, but using emulated disks. So in this case, using Amiga OS to run PDOS-generic executables so that complications like drivers for Amiga hard disks don't need to be replicated.

But UCX64 doesn't do that. It instead just leverages the existing OS - including file system - and instead just provides a shell, a C library and a loader.

And I was wondering if this shell-and-loader-only concept would apply to the Amiga.

So the Amiga has an existing file system, so that would be reused. But what sort of executables would be loaded? The Win32 API could be used the same way that UCX64 uses Win64 - the "glue" (intercept) is applied when resolving references to msvcrt.dll - it is switched to the native (UEFI-based) C library.

That's useful to provide a Win64 clone.

But what clone would run on the Amiga? Perhaps Atari? So a way of running Atari executables on the Amiga. But I think that would only be possible/useful if the Atari kept the C library as a separately loaded module. And the whole point of this would be to convert the Amiga into an Atari clone (or perhaps the reverse could be done).

Another possibility would be for the Amiga to run PDOS-generic executables, which are similar in concept to Win32 executables relying on msvcrt.dll (ie the way mingw32 works). ie the C library is kept separate from the C application - relying on the OS to effectively provide that.

Or maybe the Amiga could run Linux executables (with a separate libc.so) this way. Maybe this is already done? So a fairly minimal shell gives you a Unix system on the Amiga. Leveraging Amiga OS. And, at least nominally, restricting applications to pure C90 applications.

BFN. Paul.

[Bruce Abbott]

Originally Posted by kerravon

Or maybe the Amiga could run Linux executables (with a separate libc.so) this way. Maybe this is already done? So a fairly minimal shell gives you a Unix system on the Amiga. Leveraging Amiga OS. And, at least nominally, restricting applications to pure C90 applications.

Do you have any 'pure C90 applications' in mind that would be worth running on the Amiga?

[kerravon]

Originally Posted by Bruce Abbott

Do you have any 'pure C90 applications' in mind that would be worth running on the Amiga?

Microemacs 3.6 (slightly modified)? Public domain C90 source code.

Most of the tools I have are all oriented towards tool development - basically a circular argument I guess.

Oh - also msged for reading messages in a traditional BBS. Other BBS software such as tobruk (mailprocessor), zmodem (the serial port can be operated as a normal C file - that's how it is in PDOS/386 already). Normal noting that the C90 standard requires you to do an fseek before switching between read and write, so you have to do an fseek to 0 bytes from current location.

zip and unzip (but you won't have directory support in pure C90).

This source code is all available already - I used to compile for the Amiga in the early 1990s, so some stuff still has makefiles.

C:\devel\msged\src>type makefile.sas
# Makefile for SAS/C 6.55 for Amigados

.c.o:
sc DEFINE SASC DEFINE USE_MSGAPI OPTIMIZE $<

msgedam: ansi.o areas.o bmg.o config.o control.o date.o dialogs.o \
...

I don't think I have access to SAS/C at the moment.

The development tools like pdas could be used on the Amiga to build MSDOS executables in cross-compilation.

pdmake - very useful "make".

pdcc - C preprocessor is not specific to any processor.

diffutils are now pure C90 but not public domain if that's an issue.

Other gnu tools have similarly been bashed into C90 (as part of the work for MVS) - so m4, bison.

edlin, brexx.

[kerravon]

Oh yeah - I just remembered - I have gcc 3.2.3 and binutils for the Amiga too.

2022-11-04 19:55 197,120 arami.exe
2022-11-04 19:56 427,008 asami.exe
2022-11-04 19:56 1,996,800 gccami.exe
2022-11-04 19:56 363,008 ldami.exe
2022-11-04 19:57 361,984 odami.exe

These are Windows executables (dependent on just msvcrt.dll), but the (my slightly modified) source code is C90-compliant.

[Bruce Abbott]

That's disappointing. I already have CED, SASC, zip and unzip, and of course AREXX. I have already ported bison too.

I was hoping for something the Amiga doesn't already have, and/or that would be useful to have source code for.

[kerravon]

Originally Posted by Bruce Abbott

That's disappointing. I already have CED, SASC, zip and unzip, and of course AREXX. I have already ported bison too.

I was hoping for something the Amiga doesn't already have, and/or that would be useful to have source code for.

Well that depends on what you wish to do. If anyone can think of an application that can be written in pure C90 - or C90 with ANSI screen controls - and note that you can write a lot of stuff in just that - then there is now the ability to run it a different way. Obviously you were always able to run C90 applications on the Amiga - just run them through SAS/C or the various ports of gcc, or vbcc.

I spend most of my time doing OS development, and everything important I do is done within the limits of C90 (or very close to it, anyway). I am always conscious of whether I am exceeding the limits - e.g. my backup technology for Windows and/or the internet disappearing is that BBS software I mentioned. That BBS software will also potentially bypass the censorship of a dictator too, if you have a friend who lives under a dictator. They can't really stop people exchanging USB sticks, or at least it is a whole new level of difficulty.

So yeah - if it turns out that AMD and Intel have conspired to put a "drop dead" date in all their CPUs, set to activate on 2024-01-01, then the Amiga may be "last man standing" and if you have any bugs in the applications you use, you'll need the source.

Actually my personal interest is more going the other way - I wish to refight a war I lost. I incorrectly predicted that the Amiga would take over from the PC since it was a far superior machine. And so long as people stuck to writing their applications in a portable language - ie C90 - there should be no barrier to switching over to the Amiga.

But even with text applications people couldn't stick to the standard so that their code would be portable. Why was that?

One of the barriers was the fact that to get keyboard input you couldn't use ANSI controls - I thought ANSI had done a lousy job - but actually, they were all there (cursor keys). The problem was MSDOS's ANSI.SYS not providing that facility. And just a few months ago I discovered ANSIPLUS - probably the only thing in existence that does exactly that - allow you to define the input keys to be ANSI standard.

So if this had been written earlier, and another problem was MSDOS using the BIOS for screen output instead of directly manipulating the screen buffer, then people could probably have written portable applications suitable for recompilation on the Amiga.

So that's one of the things I wish to do - prove that it was purely down to software and/or culture preventing the Amiga from taking over.

It wasn't a matter of hardware being too slow, or the C standard being deficient.

(or was it? - I'm not sure that has been definitively proven - or even superficially investigated)

[kerravon]

Another update that may be of interest to the Amiga.

PDOS-generic (invented in this thread) has (sort of) morphed, for expediency reasons, into some sort of Frankenstein shell + loader.

That Frankenstein is available for Linux (search for win32lin at http://pdos.org) to provide a (limited) replacement for Wine ... in a single executable less than 50k.

I have tried to install Wine for multiple Linux systems, and it has downloaded huge amounts of data but not actually worked.

This version is suitable for my purposes. It has done this by sort of combining 2 C libraries into one (not 2 complete copies, it just deviates in certain circumstances). It relies on a consistent calling convention (ie cdecl), and also the processor must be the same. It also more-or-less requires the C library to be a DLL.

So I was thinking if this would be applicable to the Amiga.

I suspect that if an Amiga binary used the d7 standard (also invented in this thread), plus used the C library accessible via location 4 (or d7 in this case) memory location, that it would be possible to run it on the Atari using a similar 50k Frankenstein.

But just like win32lin and the enormous number of stepping stones (some of them in this thread, and I recently bought Microsoft C 6.0 to attempt to get 16-bit PDOS-generic which ended up getting/helping the required abstraction) required to get there - I have no idea if there is some show-stopper I haven't thought of.

[kerravon]

Originally Posted by kerravon

Another update that may be of interest to the Amiga.

Another update. Not so much for the Amiga but for this thread that invented PDOS-generic. The ARM version of PDOS-generic has started working to a reasonable extent. So you can buy a Pinebook Pro laptop as an alternative to an x86 laptop (I'm not sure there are any other options - I assume the 68000 Amiga doesn't come in laptop form).

See UCARM at http://pdos.org

Also - the MSDOS inspiration has largely served its purpose.

PDOS-generic as currently seen on ARM can be used to troll around a smartphone using a command prompt.

Well - you can all use it (ie the pseudo-BIOS) to troll around an Amiga filesystem if I add the appropriate code so that "dir" works.

In fact, for abstraction purposes, it might be better to use a more modern Amiga (PowerPC is it?).

That was actually my original desire. For people to write C90 applications and then all machines become viable. I wanted that done in the 1980s, but it could possibly be done in the 2020s instead. ie in the 1980s the Amiga was the superior machine but the failure to write in C90 meant that the software couldn't be ported easily.

So what is everyone here doing? Using what superior (by what measure?) machine, but Windows software doesn't work, so nobody uses the superior Amiga machine. But that Windows software could be written to C90 standards (so long as it is text mode - which is all blind people can "see" anyway), and if that is done (and I don't see a reason not to), then suddenly what superior Amiga or whatever hardware can be switched in?

Basically I'm in that situation myself now. After a lot of effort I have created a pure C90 environment, and now I can (nearly) switch to ARM. The superior hardware is the Pinebook Pro because it is cheaper and has longer battery life. But to me personally the superior hardware needs to be in laptop form. Probably others don't need that.

BFN. Paul.

[kerravon]

Originally Posted by kerravon

That was actually my original desire. For people to write C90 applications and then all machines become viable. I wanted that done in the 1980s, but it could possibly be done in the 2020s instead. ie in the 1980s the Amiga was the superior machine but the failure to write in C90 meant that the software couldn't be ported easily.

So what is everyone here doing? Using what superior (by what measure?) machine, but Windows software doesn't work, so nobody uses the superior Amiga machine. But that Windows software could be written to C90 standards (so long as it is text mode - which is all blind people can "see" anyway), and if that is done (and I don't see a reason not to), then suddenly what superior Amiga or whatever hardware can be switched in?

Someone elsewhere gave me the answer to this - Apple Macbook (M1 etc).

So I now need a 64-bit FreeBSD version of PDOS-generic.

BFN. Paul.