OSDev.org

I started using BBSes and Fidonet around 1987-88.

At one point I started running my own BBS, with an FTN mailer to exchange files/messages automatically.

I then began replacing the BBS software I was using with public domain (not GPL etc) software.

This then extended to the OS itself, and PDOS/386 was born in 1994, and now available from http://pdos.org

PDOS/386 is basically what I expect a 32-bit replacement for MSDOS to look like, with the benefit of hindsight. ie the MSDOS look, but Win32 executables.

A short time ago I uploaded a new PDOS beta which includes the ability to do zmodem file transfers in an FTN-like manner.

I'd now like to consolidate what I have. ie are there things in the design that should change, and I'd like bug fixes. I'm willing to pay something like US$50 for any bug fix that is of interest to me.

Is there anyone interested in working on this project, or reviving early BBS technology using public domain software?

There are other things I would like to do too, like get the public domain subc compiler enhanced so that it can compile the PDOS source base. Currently I use a derivative of GCC 3.2.3 called gccwin. There's a whole ecosystem to enhance in tandem in the coming decades, and I'd like to discuss "direction".

I find this stuff super exciting. I have also operated a BBS for many years. I didn't have an IBM PC at the time and was running my own software (a mix of BASIC and assembly to support x/y/z modem) on a CoCo3 (Tandy Color Computer 3).

At some point I was writing my own custom BBS OS so that I could work on the BBS at the same time it was servicing phone calls.

I wish I had time/energy to join in your project, but I am afraid I don't. I will take a closer look when I find some time.

All the best to you and your project!

kzinti wrote:I find this stuff super exciting. I have also operated a BBS for many years. I didn't have an IBM PC at the time and was running my own software (a mix of BASIC and assembly to support x/y/z modem) on a CoCo3 (Tandy Color Computer 3).

I'm very happy to see someone else out there finds the BBS concept exciting! The PDOS/386 kernel is about 100k in size, so I don't think I can target small computers. But the zmodem code is only about 20k (not including the C library), so maybe that bit can be. I did have an idea of a Commodore 64 with an 80386 coprocessor running the OS and presenting an MSDOS interface, but still able to run 6502 programs natively.

I don't remember my zmodem implementation to require that much memory.

The main difficulty for me at the time was to figure out how to calculate CRCs. These were the days before the Internet where you could just Google it and I was around 14 years old at the time. I did have the zmodem spec, but I couldn't make sense of what the CRC was and how to compute it. What I ended up doing is reverse engineering the code from an existing Terminal software that supported zmodem. Ah the nostalgia!

kzinti wrote:I don't remember my zmodem implementation to require that much memory.

The core zmodem is 11k:

.text 0x00401b80 0x2ac0 temp.a(zmcore.o)
0x00401b9c zmcoreInit
0x00403bac zmcoreSend
0x00401bcc zmcoreTerm
0x00401b80 zmcoreDefaults
0x00401ce8 zmcoreReceive

But there are additional support routines, plus 2k static data for the CRCs you mentioned:

.data 0x00405000 0x820 temp.a(zmcore.o)

BFN. Paul.

I think my memory is failing me. I read a bit on zmodem and I haven't implemented it. I did implement xmodem, xmodem + CRC and ymodem (which did require CRC, but again my memory might be failing me).

kzinti wrote:I think my memory is failing me. I read a bit on zmodem and I haven't implemented it. I did implement xmodem, xmodem + CRC and ymodem (which did require CRC, but again my memory might be failing me).

Yeah, zmodem is non-trivial to implement. But now that I have working and debugged (by others who used it in anger) public domain C90 code, it should be able to be implemented anywhere with 20k to spare. I think I need to make contact with some BBS folk. I've already reached out to my normal contact but no reply yet.