Fascinating project :-) Roops
On Tue, 5 Aug 2025, 20:53 Paul Edwards, < [email protected]> wrote: > If MSDOS/PCDOS had been ported to the mainframe > (or any other CPU - even the 80386), something would > have had to be changed, as you can't do an 8086 INT 21H > to request DOS services. > > With that in mind, z/PDOS-generic is my rendition, which > I have previously announced. > > This time, it can run under MVS: > > COPY INDD=((I1,R)),OUTDD=I2 > IEB167I FOLLOWING MEMBER(S) LOADED FROM INPUT DATA SET REFERENCED BY > I1 - > IEB154I BIOS HAS BEEN SUCCESSFULLY LOADED > IEB144I THERE ARE 0000287 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY > I2 > IEB149I THERE ARE 0000019 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY > IEB147I END OF JOB -00 WAS HIGHEST SEVERITY CODE > ^Lcopying from file dd:in, mode binary > to file dd:out, mode binary > 9564 bytes copied > > ^Lcopying from file dd:in, mode text > to file dd:out, mode text > 123 bytes copied > > ^L > bios starting > enter command, exit to exit > about to execute program with entry point 02019408 > welcome to PDOS-generic > running as dd:pdos > before printing parm > argv1 is -c > about to open disk > done open > lba is 1f8 > fat type is > opening dd:config > shell name is :dd:pcomm > about to call app at address 024DF8B0 > welcome to pcomm > type help for help > > enter a command > d > a > t > e > > Tue Aug 5 19:06:58 2025 > > enter a command > d > i > r > > PDOS > TEST TXT > COMMAND EXE > CONFIG SYS > ád > DEVEL > BIOS EXE > PDOS EXE > TEST2 TXT > XXX TXT > TEST C > TEST S > át > TEMP ZIP > DOS > > > To some extent it is "proof of concept", but we have a > competent engineer (Dat Nguyen) from Vietnam who > is expected to refine this in due course. > > There was one issue, which Dat has been working on > for months (a large part of which was training). > > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/stdio.c#l1743 > > /* this done_first variable is a workaround for what is presumed > to be a bug in mvssupa.asm > The first time a write is done, the read buffer should be > overwritten from the beginning. > But all subsequent writes require the first 4 bytes to be > skipped. We need someone to look at the mvssupa.asm. > Gerhard Postpischil wrote the relevant mvssupa.asm code, > but he died years ago > */ > > > Is anyone interested in looking at the S/370 assembler here: > > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm > > > You can obtain z/OS PCDOS from https://pdos.org > (second occurrence of PCDOS) > > > There is expected to be a z/OS Windows in due course, that > allows you to write minimal programs using msvcrt.dll. I have > already demonstrated that on the 68000. > > > Another development since the zpg announcement is that > z/PDOS-generic can now (effectively) drive a PC serial port > so it can run a BBS (pdpbbs.exe) or dial one (devil.exe). > Since it runs under an emulator, it is down to what the > emulator can provide. In my case, that is mfemul.exe, and > that runs under Windows, which means the mainframe can > run the BBS under real Windows. > > I also produce a Windows mini-clone, which uses UEFI, and > I have asked Dat to work on enabling serial port there too, > which would in turn allow Virtualbox on a Mac M1 to run a > mainframe BBS. Since the mainframe is being emulated > either way, you can run it on a Mac. > > Note that with a second OSA/ICC tunneling through a > Windows/Linux box with a real RS232 port, you should > be able to attach a real traditional modem to a mainframe, > depending on the definition of "attach". > > Also note that I have only demonstrated z/OS PCDOS running > in batch, but it should run under TSO too. > > If you had a 3270 emulator that was able to switch to an > EBCDIC version of ANSI X3.64, you should be able to run > microemacs under TSO this way. There should probably > be some standard way of the software signaling to the > terminal emulator that it is switching between 3270 and > EBCDIC ANSI. > > One other plan afoot (the groundwork has already been > prepared) is to create an EBCDIC version of x86 > Windows. This should allow certain mainframe data (that > behaves using the PDPCLIB rules) to be offloaded to > a PC and then certain C90 applications could do things > like quickly searching a large file, not under emulation, > and offloading work from the mainframe. > > Another thing is that you can produce ASCII Windows > executables from the mainframe, as gccwin now works > there. You can produce EBCDIC Windows executables > too, but I haven't yet published an OS to run them. > > That's all I can think of at the moment. > > BFN. Paul. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
