-
Notifications
You must be signed in to change notification settings - Fork 1
/
PUP2B.txt
583 lines (462 loc) · 21.5 KB
/
PUP2B.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
T. Jennings
Fido Software
164 Shipley
San Francisco CA 94107
VERSION HISTORY
Version 1a: Nov 87
FEATURES: First version; "pile" based message system,
interface consists of a stack of messages with the most
recent at the top. "Topics" used to partition messages. No
caller base.
Version 2a: 28 Dec 87
FEATURES: Linear message base, accessed by dates. Topics
more like Fido type "message areas". Simple caller data
base, hashed lookup and entry, no passwords. Caller base
recorded "last connected on" time and date, used to
reference last-read messages. PROBLEMS: Calling in without
reading anything "updated" (sic) the last-read message info.
Last-read didn't take into account last-read for each topic.
Version 2b: 28 Jan 88
FEATURES: Caller records contain last-read date for each
possible topic; last-read is properly handled in all cases.
Slightly improved topic handling.
-*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*-
I M P O R T A N T
Filenames changed, please rename them:
MESSAGE.DAT -> PUPPY.DAT
MESSAGE.IDX -> PUPPY.IDX
The format of the message base index file changed: you MUST
run 2a-to-2b.EXE to convert it. No data is lost. It fixes
the dates to the new compact format.
-*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*- -*-*-
Puppy
PLEASE NOTE: This does not pretend to be a nice neat ready
to use BBS package. It is intended as a kit of sources, with
a pclone demonstration program, so that you can build your
own, hopefully on the zillions of small non-pclone machines
out there.
Pup is a very modest project: it is a very small scale
bulletin board, targeted mainly for the current low-end type
machines; Z80, 64K, maybe 500K disk storage, primitive DOS.
It of course works fine on MSDOS; there is a pclone version
available. (Ask)
By Jan/Feb of 88, Pup will have a full featured FidoNet
compatible network interface. The design is complete, and
some code is done.
While the pclone version is where new things get tested, it
is NOT the point of Pup. There are already more than enough
pclone BBSs to choose from; Pup however would fit very
comfortably into the smallest possible pclone these days,
and probably a good use for all those dead PC Jrs out there
somewhere.
BBSs have escalated in complexity way out of proportion to
their usefulness; most BBSs are used by highly skilled
people with lots of resource$ to talk to people like
themselves. This is fine, but most of the world isn't in the
position to sit $1,000 (or more!) in a corner of the room
for one special purpose only.
Also, the trend is towards larger, more complex systems,
wide area networking, extremely high throughput data
transfers and other things that just push the likes of Fido,
Opus, TBBS an order of magnitude or two out of the range of
many (if not most) people who might benefit from them.
Seems we've forgotten that the original intent of BBSs was
to communicate with other people. It is not obvious to me
that talking to more people is better. The best BBSs I've
ever used, of any type, at any time, were all very small
systems; RCP/Ms, Apple][/GBBS, etc. Most used awful
software, but were still the best (meaning most useful or
most amusing) systems I've run across. There's a hint there,
I think.
I would love to see Pup ported to CP/M (especially: that
awful Heath/Zenith H-89 under ZDOS) and Apple ][ PRODOS or
something.
.pa
.he Copyrights, trademarks, money, that sort of thing.
S H A R E W A R E
Puppy is shareware; if you like it or find it or parts of it
useful, then mail me what you think it's worth. $40 is
suggested. Less will not be considered an insult. In return,
I will mail you a diskette with the latest & greatest on it.
Check out the pclone version, show it to people, see what
your reaction is. It should be portable as-is to small
machines.
OK, down to brass tacks. (What on earth does that mean?) I,
Tom Jennings, do business as Fido Software, at the address
below. My commercial products are copyrighted works, and my
sole source of income. Copyrighted works produced by me will
be marked as such:
Copyright Tom Jennings 1987, etc
This is very straightforward. These are commercial products;
you want, you pay. Or the guy in the big car over there will
make you pay double later, OK?
Now for years I have been writing programs and distributing
them, in binary and some in source form, but I've never made
it very clear what their status was. Partly this is because
the previous environment (less cutthroat) was more friendly
and less demanding, and partly because I just wasn't that
organized. This is to change starting now. (now?)
The following notice will be firmly affixed to all programs
produced by me that are not commercial copyrighted works.
Please don't utter the phrase "public domain" because that
means something awful:
(k) All Rights Reversed
(hail Eris) This means: what you do with it is up to you. I
ask though, that if you distribute it, you provide sources
as part of the package, at no extra cost or penalty or
obligation to the person receiving it; and that you also do
not remove the (k) All Rights Reversed notice. I also ask
that you don't change the version number, if there is one;
you will only needlessly confuse people when I come out with
a new version. Hint: Add your own IDs after it, like "1-AB"
where "AB" is your version number.
"Fido" is a trademark of Tom Jennings. It you utter it send
me a dollar. "FidoNet" is a registered trademark of Tom
Jennings. If you even think it send me two dollars. If you
use both, send me ten dollars and your first born child. All
rights reserved, and all wrongs righted. So there.
Fido Software
164 Shipley
San Francisco CA 94107
(415)-764-1629, FidoSW, using Fido v12 1:125/111
(415)-882-9835, ch@os, using Puppy v1
soon will be known as 1:125/164
If you have anything to contribute, please do.
.pa
Historical Curiosities: An Editorial
A little history is in order here. I, like hundreds of
others, have been hanging out on BBSs and writing free
programs since Ward & Randy's CBBS in the late 70's. Nothing
new or unique or interesting here.
Fido, started in 1984, is by far the most popular and well
known program I have ever produced. To say it exceeded
anything I ever planned for it is an understatement.
Requests for diskettes got so heavy that I started charging
for diskettes; as demand for functions and reliability
increased, by many hundreds of people, it slowly turned into
a part-time business.
Now it eventually became obvious that this wasn't a typical
free BBS program, and that others wanted to write FidoNet
compatible programs; Thom Henderson had sucessfully gotten
SeaDog running. An effort went into documenting the protocol
(Randy Bush did a wonderful job with the FSC001 doc a year
later) and making structures public, etc. Interface
information was released with each version, and work was
started towards the real technical specification,
culminating in FSC001.
Eventually, Fido/FidoNet became a full time job. I now
derive all of my income from it. (I license Fido/FidoNet to
mostly small to medium companies and non-military
governmental agencies.) Because of this, Fido is no longer
free, starting with version 12. (You can now use previous
versions for free; v11 manuals once again available for $35)
My roots and heart is still in the hobbiest end of things,
and Fido Software is hardly a traditional software company.
I am working on new software for hobbiests, both "free" and
"shareware". I now fund this development from licensing
Fido, and hopefully other sources in the future. I'm hardly
getting rich from this, and that's not the point.
My goal today is somewhat subversive I suppose; I want to
see more non-technical people use computers for
communicating in ways not traditionally though of, and on
small cheap machines; not by throwing money at high-end
pclones or traditional services. (You're supposed to do
wierd things with computers, that's what they're for!)
Traditional media in the U. S. is getting more and more
restricted to lowest-common-denominator, safe, bland,
*profitable* mindless pap. (Did you know: only 26
corporations own 1/2 or more of all media in the US:
magazines, books, TV, radio, newspapers, etc? Source:
"Fairness & Accuracy in Reporting", June 87) Individuals and
small groups running BBSs and writing 'zines is one way to
promote free (as in open) communications.
Some have asserted that I'm a greedy programmer trying to
milk money from peoples hobby with Fido (how dare I charge
money) and that I don't care about much else.
I will merely say: I've been writing free software since
1979, and have had phenomenal, unexpected success with
Fido/FidoNet, which I have basically given to the world,
gratis. My attitudes haven't changed much, except to get a
bit more radical. Time will tell, as it always does.
OK, I'll shut up now.
.pa
Pup's FidoNet interface
Suffice to say at this point, it will be both high
performance, and will fit very nicely on a 64K Z80 with a
couple of decent sized floppies.
Keep in mind it's not meant to act as a gateway to all of
Western Europe. You would probably have a hard time even
making it a Net Host.
What it will do though is run up to 16 echo conferences at a
higher software-performance level available on any machine
today, period. No space- and time-consuming packeting and
unpacketing, no external conferencing packages.
Use of the nodelist will be optional; for echo conferences,
only the system information for the next-in-line system
(Pup, Fido, Opus, etc) is needed.
The method is: on-the-fly packeting and unpacketing. The Pup
FidoNet code uses XMODEM to send the packet, as per FSC001
specifications. However, instead of generating a packet file
ahead of time, then XMODEMing it out, when XMODEM goes to
"read" a block from the packet file, it uses a state machine
to generate the data as it goes. Because the message base is
one contiguous file, with a memory resident index,
performance is not a problem. This part is already coded.
The receiver does a similar thing. As XMODEM receives
blocks, it would normally write them to a packet file for
later unpacking into messages. In Pup, the blocks are not
written to a file, but decomposed byte by byte into the
message base directly. Again, because of the message base
design performance isn't an issue.
28 Dec 87: the packeter is complete, and should send
messages before new years. The unpacketer should take
another week. The current program size is 42K, not including
the unpacketer. Expected total executable size: 48K.
.pa
.he Pup the Bulletin Board
Pup has all the usual amenities, but it doesn't appear that
way when you first look at it. There's only ten commands or
so total.
The message base consists of two files, one that contains
the message body text, and the other is an index with the
usual TO:, FROM:, etc information, as well as the TOPIC
information. (More on Topics later.)
Pup's message base is created once when SET-PUP is run, and
never changes in size. (You can set the size of each message
and the number of messages.) (And later there will be a way
to change the size, but not right away.) The advantages: it
never grows to fill your disk; performance is extremely good
(if you format the disk first, you will be guarenteed that
all sectors in the file are contiguous); there is no need
for message base maintenance.
The caller base (new on v2) uses an identical process. There
is a single preallocated file that contains one record per
caller. Each record contains a name, a time & date, and
screen settings. The callers name at login is hashed into an
index (CCITT CRC-16 was laying around) and is very quick. It
has the same advantages as the message base, plus not having
to search linearly at login. The disadvantage is that it can
potentially bump out existing callers whose names happen to
have the same CRC. Tough tootsies.
If you get the idea that I am intentionally leaving out
things considered "important", you are right. Nothing is
sacred.
Back to the message base.
The fixed length message file is treated as a ring buffer;
once all the slots are filled, adding a new message at one
end overwrites one at the other end. The two ends of the
buffer are of course one single point, which is stored in
the system file. (Dont lose it!)
Message numbers don't have much meaning in this environment.
Messages are identified by date. The two "ends" of the
message base are considered the "newest" and the "oldest".
There is code in the message base to handle messages in this
manner.
When you first login to Pup, you are positioned at the first
message created since you last logged in; if this is your
first call, you see the oldest message. You hit "CR" to read
messages sequentially until you reach the newest message.
Now a huge monolithic message base isn't much fun to poke
around in. This is where Topics come in.
Pup can have up to 16 topics; you must have at least one.
Topics are the usual grouping, areas, subjects, that sort of
thing. In Pup though, instead of rigid barricades that
messages must be forced within, in Pup you can hop Topics at
will.
When reading messages, you can choose which which topics you
wish to see, including "all". If you choose one topic, then
those are the only messages you will see. If you choose
"all", then you see messages in any topic; this is nice for
browsing a board for the first time or two. If you're only
interested in two or three topics, you can select only those
and you will see no others.
When you enter a message, Pup puts it into the last-read
topic, so that even if you have "all" or many topics
selected messages go into the right place.
.pa
Puppy and human callers
Pup didn't have a caller base until v2. This wasn't as awful
as it sounds; the only problem was it made it hard to keep
track of new messages that came in after you last logged in.
Old systems such as CBBS made you just remember or write
down message numbers (I never did) or made you poke around
for 15 minutes while you refreshed your memory. The "last
message read" markers in Fido's system are a nightmare of
problems and limitations, who needs that. These are
important issues, and need some new thought and design, they
can't be coded away.
The other uses for a caller record are trivial, such as
their name and screen settings.
Be warned: Pups caller file is nothing more than a notepad
for the caller. It is not a security system. Its purpose is
to remember screen settings and what new messages were
entered since last call, and thats it. See the design
philosophy box below.
Pups caller file is fixed length, and created by SET-PUP.
Pup indexes records by creating a CRC-16 hash code from the
ASCII users name and jams into the caller file. (The fixup
hash on hits as of v2a needs work.) It is very quick, but
has the disadvantage of overwriting other caller names with
the same CRC.
DESIGN PHILOSOPHY
Its a little wierd at first ... but you get used to it. One
objection that pops to mind is: how do I know that that
person is who he says he is? Well, you don't. Actually ...
if you are conversing with someone (not what you call what
happens when there are 500+ people using a system!) it's
pretty obvious. Also, it's not much of a challenge and not
worth the bother of entering stupid messages. Remember also,
this isn't targeted at the mainstream BBS crowd.
How do you run a system then, with upwards of 500 different
people per month? Get a Fido or other large scale (large
resource) type program, which fits those sort of
installations perfectly.
.pa
OK, enough: what's on the disk
The end result of all the crap in the Pup package is two
programs and a few support files:
PUP.EXE the Pup program
SET-PUP.EXE the Pup installer
PUP.SET Pup configuration text file
FIDO2PUP.EXE Fido to Pup message converter
WELCOME.PUP the initial welcome message
FILES.PUP list of download files
MAIN.HLP various help files ...
MESSAGE.HLP ...
EDIT.HLP ...
Set-Pup creates these:
PUPPY.SYS main system file
PUPPY.CLR the caller file
PUPPY.DAT (was MESSAGE.DAT) the message base
PUPPY.IDX (was MESSAGE.IDX) message bsae index
SET-PUP reads the text file PUP.SET and compiles it into the
PUPPY.SYS file that contains the installation type goodies
(modem type, node number, limits and controls) and creates
an empty message base, if one doesn't already exist.
PUP is the BBS program, and reads all the other junk.
FIDO2PUP puts any Fido .MSG messages into the Pup message
base, and leaves the highest numbered one as the Top
message. Gives you something to start with.
.pa
The complete list of files is:
Include files:
ASCII.H
PUPMEM.H
PUPPY.H
DRIVER.H
LATTICE.ASH
Various tools for compilation:
C.BAT
PUP MAKE file
PUP.LNK PLINK command file
IBM.LIB pclone serial driver library
DRIVER.DOC Pup/Fido driver specification
PUPMAIN.C Pup main() and main loop
PUP.C Pup commands
LOGIN.C Caller login process
MSGBASE.C the message base system
FILES.C Pup file commands
QUOTE.C signon quotations
SCHED.C the scheduler
EDIT.C message editor
* Not ready yet
*FIDONET.C FidoNet main control
*FSC001.C FSC001 protocol module
*PACKETER.C Packeter module
*UNPACKETER.C Unpacketer module
*TOPICMAP.C Topic map controls
XMODEM.C XMODEM/TELINK protocol handler
MODEMIO.C (not so) low level I/O
MDMFUNC.C modem drivers
SUPPORT.C misc. support routines
PRINTF.C a real printf()
MS-C.C DOS dependent C routines
MS-ASM.ASM DOS dependent ASM routines
ABORT.ASM
FIDO2PUP.C Fido msg converter
SET-PUP.C config program
PUP.SET sample config file
FILES.PUP sample files list
WELCOME.PUP sample welcome file
QUOTES.PUP sample quotations
MAIN.HLP sample help files
MESSAGE.HLP
EDIT.HLP
.pa
.he Implementation Notes
GENERAL
Data structures and other definitions of global importance
to Pup are in PUPPY.H, which is included by all .C files in
Pup. When you change this file, recompile all modules; the
make file provided will do this with RMAKE.EXE from Phoenix
Software.
Global static data is defined in PUPMAIN.C, and references
to it via #extern's are in PUPMEM.H. All sources except
PUPMAIN.H include PUPMEM.H. It's the easiest way I've found
to manage external data; the one time it's a pain is if you
add or delete a global variable (in PUPMAIN.C); you have to
recompile everything. Oh well.
SERIAL INTERFACE
The serial I/O driver provided, IBM.LIB, is for pclones
only; you will need to write equivelant routines for
whatever your machine is, even on CP/M. Most are pretty
simple, and even polled is OK; Pup will even allow typeahead
on polled machines, due to the lookeahead done in MODEMIO.C.
Note that the drivers as defined in DRIVER.DOC are rather
complex; you don't need anything but the low level serial
parts. (Poke through MODEMIO) Why not prune DRIVER.DOC and
pass out a proper version?
Pup uses a three or four wire modem installation. It needs:
Tx Data obviously
Rx Data obviously
Ground obviously
CD Carrier Detect (pin 6 or 8)
DTR Data Terminal Ready (pin 20)
DTR is optional; see below.
Pup has a parameter "cd-bit" in PUP.SET; this is the bit
mask pup uses to check for CD on the serial port. Pup ANDs
the contents of the status register with the cd-bit, and if
the result is not zero, then the modem is assumed to be
online.
CALLER INTERFACE I/O
Basically, the I/O system is the same as Fido and has all of
it's features: full typeahead, output pause (^S, ^Q),
background abort-detect (^C, ^K), typeahead flush (^F),
"command-ahead" (ie. "D N FILENAME.EXT X" executes a whole
download command skipping all the prompts), formatted I/O,
complete carrier loss detection with no programmatic
overhead, dead-user timer, full time limit enforcement.
In theory, you should never have to mess with anything in
MODEMIO. And be careful if you do, it's filled with
recursive and effecient stuff, and I think it's pretty well
commented. It does a lot just as it stands; it is four years
accumulated work and experience.
MODEM SUPPORT
As implemented, Pup will support just about any Hayes type
modem. The modem must have a CD (Carrier Detect) line. DTR
is recomended, but not required.
The initialization specified in PUP.SET should set the modem
to numeric result codes and autoanswer OFF. Pup answers the
phone by waiting for a RING result code, then issuing an ATA
command, and waiting for the CONNECT 1200 (or 2400, etc)
message, and then assumes it's online and connected. No
hocus pocus or complicated autobaud.
LITTLE ENDIAN vs. BIG ENDIAN
This is the endless "Intel" vs. "Motorola" argument. I
really don't care either way; neither does Pup. The only
part that cares about byte order is the FidoNet interface,
and there you have no choice.
The only time this might matter is if you were to generate a
message base on a Z80 and physically copy it to a 6502
machine; you'd have to convert byte order. For locally
generated data, it's not an issue.
FUNCTION PORTABILITY
I tried to keep things down to two kinds of portability
problems: C language data typing and O/S functionality.
On C data types, most things don't care; general purpose
counters etc are just "int"s, etc. For ones that matter,
almost all want to be either 8 or 16 bit data. For these, I
defined two types: BYTE and WORD. In the Lattice 2.12/MSDOS
version, BYTE is defined as char, and WORD as int. Change
accordingly to fit your system. These are defined in
PUPPY.H.