This is my Vlog of PDOS development. Now in reverse chronological order. Note that the latest entry may have broken links because of the enormous difficulty I have trying to upload large files (the sad stories are worthy of a Shakespearean tragedy - Aleco's electricity going up and down like a yoyo, typhoons, fiber connected to a coconut tree, wifi dropping out due to incomplete installation, webhost not doing file resume, numerous bugs in the "free" (no-one gives a shit about it) software the webhost uses, and all underpinned by a bloodyminded pig-headed user who refuses to use Youtube like normal people because he believes it is all of the above clowns (other than the typhoons) who should be changing their ways, not him, and that all problems can be solved with a B52s carrying JDAMs). It could take days for the complete set to get up, so I don't want to update this page every time one of them finally makes it. Note that when I switched to using a Unix system I decided for some reason to try sftp and found the reput command which seems to have solved the issue.
Received Microsoft C 6.0. The last version that can run on an 8086. Not shown on the video is that it was later shown to be sufficiently ANSI X3.159-1989 compliant to handle the PDOS/86 source code.
386SX alive but didn't last enough minutes to do any work. Owner rambled on for much longer than the computer was of any potential use. Something about Mary?! WTF?
386SX alive and incredibly managed to boot PDOS/386 from floppy, with caveats!
386SX alive again. Reported that the floppy disk was bad, so I disabled that, specified a Type 24 hard disk (40 MB), and for the first time saw MSDOS attempt to boot, but apparently hung on HIMEM.SYS.
386SX came alive again, so I could do limited testing, briefly. Also received another copy of Visual Studio 2005 Professional and Windows 2000 Professional.
Received another Visual C++ 4.0 (with bundled 1.52C), IBM VisualAge C++ for Windows 3.5, and Visual Studio .NET 2002.
80386SX alive but dead, like Leonard Cohen.
80386SX still dead. Waffled on at length about the price of rice in China.
Received 32-bit Microsoft Visual C++ 4.0 standard edition full box which includes the 16-bit Visual C++ 1.52C disk. 80386SX dead.
80386SX alive - speculation continues.
80386SX dead - speculation abounds.
80386SX came back to life after 24 hours of rest. But - even though it presumably doesn't run Doom, can it run PDOS/386? Note that a couple of minutes of free speech (thanks Philippines!) were lost because it turns out you can't multitask the calculator at the same time as recording video after all, and I didn't immediately notice the problem.
Received my 80386SX laptop. Attempted to use it to prove that PDOS/386 does CHS addressing properly for hard disks. And the result is ...
Got UCX64 running on real hardware. Also received some old PC hardware (floppy drives, controllers and serial ports). Demonstrated the Chinese computer (with Zhaoxin processor) and Chinese UEFI/BIOS being switched between "UEFI" and "legacy" to boot PDOS/386 also.
UCX64 now self-hosting, received Visual Studio 2003 Enterprise Edition, ISA expansion for Book 8088, Borland C 5.0 and a new laptop with a Chinese-made processor (Zhaoxin/Kaitian?) and semi-Chinese-made OS (Kyrin/Kylin?-Linux) which has Chinese and English as options for the OS, but the BIOS (F1 for Lenovo) is Chinese-only.
Received Hand 386 plus Microsoft C 6.0 and 7.0 and IBM PC DOS 7 and tried out PDOS/386 on the Hand 386.
Unveiled a new bunch of goodies, including Windows 3.0 (boxed), so was able to start Windows on the Book 8088.
Tested UC8086 on the Book 8088. Also checked the license agreement of a boxed Visual C++ 2.0.
Mostly use of the Book 8088 computer in conjunction with Microsoft C 5.1. Last video stopped a couple of minutes short without my knowledge I think due to limited space on my smartphone.
Received Book 8088 computer (with NEC V20 - ie 8080 capable - not just 8080), Visual Studio 2013, Visual C++ 2.0, Visual C++ 1.52C and MSDOS 6.22 Upgrade.
Received Windows 95 on floppy disk and MASM 6.11 (Microsoft Assembler) on floppy disk.
Received AS3955-1991 aka ISO/IEC 9899:1990 aka ANSI X3.159-1989 and Visual C++ 2003.
Received MSDOS 6.22 (again), Windows for Workgroups 3.11 (again) and OS/2 1.2 (for the first time in my life).
Made another attempt to modify PDOS/386 to ignore bad sectors on floppy disks.
Received full versions of OS/2 2.0 and Windows 98 Second Edition.
Received Windows for Workgroups 3.11.
Attempted to install Windows 95.
Attempted to install Windows 98.
Showcased a treasure trove of old software (mainly C compilers) recently purchased from Ebay (mainly US).
Attempted to read Microsoft C 5.1 720k 3.5" floppies. A couple of segways into religion/politics, and apologies if any Carabao were unduly alarmed. I'm from Queensland.
Attempted to install new version of PDOS/386 onto hard disk, in preparation for reading Microsoft C 5.1 (from 1988) from 3.5" floppies, and after (off-camera) preparatory work had shown that the old version of PDOS was not correctly reading the (believed to be) 720k floppies (in a 1.44 MB drive).
Proved that booting from a floppy image on CD now worked, followed by an attempt to show the effect of rudimentary caching. 203 seconds boot time was reduced to 136.
2023-05-14 video 1. (youtube). Attempted to get a real floppy disk to read and write, with limited success. File exceeded 2 GB so the link is to youtube. The original data that can be reconstructed with copy /b x+y z is 2023-05-14 video 1 part 1 and 2023-05-14 video 1 part 2
2023-05-13 video 1. Attempted to get a floppy image on CD to boot. Got a divide by zero at least.
2023-05-03 video 1. Mentioned absence due to change of plans due to breakthroughs, including proof that PDOS/86 ran on a real IBM PC AT (80286) clone (Compaq), from a 360k floppy. Video abandoned after a couple of minutes because my daughter was brought in, sleeping.
2023-04-20 video 1. I think here I explained about the DB9 serial port and writing a driver for it.
2023-04-18 video 1. I think here I had a problem with a corrupt USB stick when trying to reproduce a problem with the Magellan.
Introduction to setup.
Below is some historical information that can be ignored.
Ok, now I found out that my server has a 2 GB limit on uploads. So much for everything being 64-bit. And I also found out that an hour of video on my smartphone is about 4 GB. I don't know how to split an MP4, but I do know how to use xychop, and I just updated it to use unsigned long instead of signed long. So depending on msvcrt.dll I may at least be able to split this file in two, and in future I will watch the time. However, that means that the second file will not be in proper MP4 format. Hopefully one day forensic scientists will be able to make the second half of the video viewable. Or you could just do a copy /b file1+file2 file3.mp4 yourself. Whatever. Or maybe wait for it to come out on TV. Oh yeah, and before you ask - hey moron, don't you know that 2 GiB is different from 2 GB - well, yes, I do, but I don't know if the programmers who produced that error message do. And before you then have a followup - hey moron, why is it 1,999,999,999 instead of 2,000,000,0000 if that's the limit in the error message? Well, I don't know whether the programmer typed < or <=.
Update! Note that even the first file wouldn't play for some people because it was detected as corrupt, but fortunately someone else (Dimaguy) has split the video properly, so now there are two usable parts.
Update 2! It has now been uploaded as a single file to Youtube, so that is now the main link.
2023-04-17 video 2 part 1 (split properly).
2023-04-17 video 2 part 2 (split properly).
2023-04-17 video 2 part 1 - original, bad - see sad story above.
2023-04-17 video 2 part 2 - original, bad - even sadder story.
