Any CoCo folks near Branson? There is a place there calledRetromania which is an 80s themed “attraction” with some 1980s arcade games, a few pinball machines, an 80s horror movie themed haunted house, VR and lots of 80s memorabilia. While I didn’t see any CoCo related stuff on display, I did see some Atari and Odyssey hardware. I kinda want to bring a CoCo ROM-PAK to donate to the display next visit ;-)

Over on the CoCo Facebook group, in a discussion about “why is I always used for loops”,Rob R.left a comment that caught my interest:

“… I have a vague memory that (at least on the Mod I) there were one or two letters that weren’t usable since they could be tokenized to a command. At least some two letter variables would be verboten, like ‘TO.'”

– Rob R. on Facebook

This made me wonder: how many are there? Here are the ones that I think would be problematic:

• AS – in Disk BASIC, there is an “AS” keyword used for the file system. “FIELD #1, 10 AS A$”
• FN – as in “DEF FNA(B)=B*42”
• IF – as in “IF A=1”
• ON – as in “ON X GOTO/GOSUB” or on the CoCo 3, “ON BRK GOTO” or “ON ERR GOTO”
• OR – as in “IF A=1 OR A=2”
• TO – as in “FOR I=1 TO 10”

Using any of these such as “TO=1” or “FN=3” will create a ?SN ERROR.

Are there others?

Also, some of these will work inColor BASIC that will not work if you haveExtended orDisk BASIC:

• “DEF FN” was added in Extended, so on a Color BASIC machine you should be able to use FN as a variable.
• “AS” was added in Disk BASIC, so you should be able to use AS on Color and Extended BASIC.

I wonder how many folks wrote BASIC programs using variables that were not allowed when they later added the Extended BASIC ROM and/or Disk BASIC, and wondered why they stopped working?

Until next time…

I have been doing website hosting as a hobby since the mid-1990s. I just set up a “business card” site for a local cafe (Douglas Cafe in Urbandale) we frequent. We’ve also done projects for them including making new menus, table top signs, window vinyl lettering, and street signs. To help boost their new website, I just wanted to post it here for the search engines to find:

https://www.douglascafe.com

While I do not actively persue website hosting anymore, I still have about 75 sites hosted here. My web hosting account is going up 25% my next renewal, so I may very well have to re-activate this as a business that takes money.

More to come…

In 1995, I sent this cover letter out with my resume. I managed to get the job, and that forever changed the direction of my career…

Allen C. Huffman
110 Champions Dr. #XXX
Lufkin, TX 75901

Microware Systems Corp.
1900 N.W. 114th St.
Des Moines, IA 50325-7077
Attn: Human Resources

May 7th, 1995

Dear Sir;

I am writing in regards to your Technical Training Engineer position. After learning of it’s availability I immediately wanted to express my interest. I possess a working knowledge of OS-9 which comes from daily use over the past six years and I believe this would be beneficial to your company.

I have programmed under OS-9 Level Two and OS-9/68K with several commercially marketed utilities and applications available. My creations include a sound driver, machine language space game, menu driven user interface library, and various file and printer utilities. Since 1990 I have owned and operated a company which creates and markets OS-9 products. I regularly attend annual conventions as a vendor and also give seminars dealing with OS-9 support and programming.

I have an active interest in Microware’s past, present and future and attempt to follow media coverage of developments such as the use of DAVID in set-top converters and OS-9 in places like Treasure Island in Las Vegas.

I am eager to provide further information about myself and my accomplishments either through an interview or additional correspondence. Feel free to contact me by mail, by telephone at (409) 637-XXXX, or by the internet at “coco-sysop@genie.geis.com”. Thank you for your consideration and I look forward to hearing from you.

Sincerely,

Allen C. Huffman

Almost exactly one month later, I received this e-mail:

INET00# Document Id: UX012.BUX0687704
Item 7490898 95/06/05 04:15
From: XXX@MICROWARE.COM@INET00# Internet Gateway
To: COCO-SYSOP Allen C. Huffman
Sub: Technical Training Engineer

Dear Allen,

I would like to discuss the technical training position Microware has open
with you on the telephone. Please call me at Microware, (515) 224-1929 at
your convenience, or email me a time I can reach you.

Sincerely,

XXX
Manager, Technical Training

=END=

It was (and still is) pretty amazing to me that a kid (well, early 20s) who had mostly worked retail was given a shot like this. And all because I went with a CoCo instead of a Commodore 64… Though, who knows, maybe I would have ended up working for Commodore in that universe…

Until next time…

See Also:part 1,part 2,part 3,part 4 and part 5.

This post is a departure from what most of the others are like. I am most certainlynot going to be using this “trick” I just learned.

Background

Recently in my day job, I was doing a code review and came across something that was most certainly not legal C code. In fact, I was confident that line wouldn’t even compile without issuing a warning. Yet, the developer said he did not see a warning about it.

The bit of code was supposed to be calling a function that returns a populated structure. Consider this silly example:

#include <stdio.h>// typedefstypedef struct {    unsigned int major;    unsigned int minor;    unsigned int patch;} VersionStruct;// prototypesVersionStruct GetVersion (void);// mainint main(){    VersionStruct foo;        foo = GetVersion ();        printf ("Version %u.%u.%u\n", foo.major, foo.minor, foo.patch);    return 0;}// functionsVersionStruct GetVersion (){    VersionStruct ver;        ver.major = 1;    ver.minor = 0;    ver.patch = 42;        return ver;}

But in the code, the call to the function was incomplete. There was no return variable, and even had “void” inside the parens. It looked something like this:

int main(){    VersionStruct GetVersion (void);    return 0;}

I took one look at that and said “no way that’s working.” But there had been no compiler warning.

So off I went to theOnline GDB Compiler to type up a quick example.

And it built without warning.

Well, maybe the default is to ignore this warning… So I added “-Wall” and “-Wextra” to the build flags. That should catch it :)

And it built without warning.

“How can this work? It looks like a prototype in the middle of a function!” I asked.

Yes, Virginia. You can have inline prototypes.

A brief bit of searching told me that, yes, inline prototypes were a thing.

This should give a compiler warning:

#include <stdio.h>

int main()
{
    function ();

    return 0;
}

void function (void)
{
    printf ("Inside function.\n");
}

When I built that, I received two compiler warnings:

main.c: At top level:
main.c:10:6: warning: conflicting types for ‘function’; have ‘void(void)’
   10 | void function (void)
      |      ^~~~~~~~
main.c:5:5: note: previous implicit declaration of ‘function’ with type ‘void(void)’
    5 |     function ();
      |     ^~~~~~~~

The first warning is not about the missing prototype, but about “conflicting types”. In C, a function without a prototype isassumed to be a function that returns an int.

Had I made function like this…

int function (void){    printf ("Inside function.\n");    return 0;}

…I’d see only one, but different, warning:

main.c: In function ‘main’:
main.c:5:5: warning: implicit declaration of function ‘function’ [-Wimplicit-function-declaration]
    5 |     function ();
      |     ^~~~~~~~

For the first example, the compiler makes an assumption about what this function should be, then finds code using it the wrong way. It warns me that I am not using it like the implied prototype says it should be used. Sorta.

For the next, my function matches the implied prototype, so those warnings go away, but a real “implicit declaration” warning is given.

Going back to the original “void” code, I can add an inline prototype in main() to make these all go away:

#include <stdio.h>int main(){    void function(void); // Inline prototype?        function ();    return 0;}void function (void){    printf ("Inside function.\n");}

I had no idea that was allowed.

I have no idea why one would do that. BUT, I suppose if you wanted to get to one function without an include file with a prototype for it, you could just stick that right before you call the function…

ButWhy would you want to do that?

I learned this is possible. I do not think I want to ever do this. Am I missing some great benefit for being able to have a prototype inside a function like this? Is there some “clean code” recommendation that might actually say this is useful?

“It wouldn’t be in there if it didn’t have a reason.”

Let me know what you know in the comments. Until next time…

Forty years ago, this is what my room looked like…UPDATED with photos!

Allen's room (so far):

+----------------------------------------------------------------------------+
-      | VCR,Jag,Etc.| | | CM8/VCR | |   TV   | || | C= Mon.|               ||
.\     |_____________| |_|_________|_|________|_||_|________|_______________||
. \                    |  _________ ______  ___ ||____ ____________ ....... ||
.  \                   | | .CoCo3. | MPI  ||Dsk||| HD |  Amiga500  | mouse  ||
-                      |_|_________|______||___|||____|____________|________||
|------|                       CHAIR                    CHAIR        |_____| |
| Boxes|                                                             |Term.| |
|      |                                                            _|_____|_|
|______|                                                            |  Ans. ||
|Shel| ______                             Floor Space!              | |---| ||
|-ves| |file|                                                       | |DMP| ||
|    | |thng|                                                       |_|___|_||
|    | |____|            -----------------------------------------------------
|____|                   |                                            |      "
|                        |              My Double Bed                 |      "
| /\                     |                                            |      "
| \K\                    |___________________________________________________-
|# \4\                        | Term.|                              | Lamp/  |
| # \/                        |      |                              | Radio  |
+----|.......|---------------------------------------------------------------+

Door into room on top left, closet on bottom left, window on bottom right.
Going clockwise:

Starting at top, metal "erector set" shelving containing misc. junk on top
shelf, two VCR drawer cabinets and Jag on second, SVHS and editing gizmos on
third, fourth has complete Sega Genesis/CD setup, and below is Sub-Etha
Software stuff (paperwork, software, etc.)

First computer desk is CoCo system with CM8 on VCR, and TV to the right.  A
set of medium sized powerer stereo speakers sits on the CM8 and another on the
Amiga monitor for great stereo seperation.  Dual power strips below this, too.
 (One with modem line and CoCo on it, the other is on "all the time" for VCRs
(clock) and TV).

Amiga desk is metal frame (not wood like CoCo) and has Amiga setup and
monitor, and TONS of books on shelves below right of desk.  A pull out sliding
"table" at the right has a WYSE terminal on it w/CoCo cube stored below it.

Next is a printer table (came with the desk) with the Friday and printer and
power strip.

Bed.

Table with clock, radio, and lamp.

Another table with hardware terminal (so I can hack while in bed, via serial
port on CoCo).

K4 keyboard setup with amp/speaker, sequencer, Midi disk drive, etc.

Bookshelf with magazines and misc. junk, and filing cabinet (on wheels, lid
opens from top).

Storage bins (used to lug CoCo stuff to 'Fests) stacked three high, full of
junk.

And this, my friends, is my room.  <whew>

          Allen

And here is me, in all my nerdy glory.

And this is what the other wall looks like, after returning home from a CoCoFest.

Don’t panic! The room didn’t always look like that…

Until next time…

Recently, I shared this way to crash a CoCo 3 in three easy steps:

1. Turn it on.
2. Type in “CLEAR 16500:WIDTH 40”
3. There is no step three.

I expected to do a follow-up once I had time to look at theSuper Extended Color BASIC Unraveled book and try to figure out what was causing this crash. I also planned to figure out what value triggered the first crash. I discovered this in a program that did a “CLEAR 17000” and I just went up and down trying to find a threshold where it crashed, and gave up at 16500.

But I am lazy.

And sometimes dense. It didn’t dawn on me that I might have been able to have the computer try to figure out when it crashed. But it did toJuan Castro. In the comments, Juan wrote:

First thing I thought was to increase the value of CLEAR in a loop to see exactly when it crashes… oops, you can’t, you nuked your loop counter with the CLEAR.

No problem, let’s use fixed memory for the counter. &H400, the start of the (now unused) text screen. We’ll start with 16000 (=&H3E80) and increment by one.

10 WIDTH 40
20 POKE &H400,&H3E:POKE &H401,&H80
30 GOSUB 80
40 AD=AD+1
50 GOSUB 90
60 PRINT AD:CLEAR AD
70 GOTO 30
80 AD=PEEK(&H400)*256+PEEK(&H401):RETURN
90 HI=INT(AD/256)
100 LO=AD-256HI
110 POKE &H400,HI:POKE &H401,LO
120 RETURN

It locks up at 16356 — suspiciously close to 16384. Only 28 bytes off. That’s probably close to how much the stack occupies. (Modulo some buffer headers, variable descriptors, and maybe some non-fatal stack corruption.)

– Juan Castro

Brilliant!

And I bet once we dig in (I believe William Astle has done this work in the past) we will find that location is where an 8K MMU block gets mapped in/out for manipulating the high res text screens. Or some other words to that affect that I do not know how to properly articulate.

More to come on this…

An interestingpost appeared on the Color Computer Facebook group the other day…Youngstown Ken posted:

AI on the CoCo? This is a simple language experiment that I think can be done on the coco if anyone would like to try the code. I asked Grok to write a basic program to read a 10MB corpus of sentences from a dictionary and then build a simple Markov graph db to predict the next word in a sequence.

– Youngstown Ken, via Facebook CoCo group

The attached link went to a Grok-generated conversation about the subject. You can read the short interaction here, and see the generated Python and BASIC-ish code:

https://x.com/i/grok/share/sXRGgHcIROsl7PPNXnF8D34MC?fbclid=IwY2xjawI15sRleHRuA2FlbQIxMQABHZVbpT6JU-bIDIQJoVd4KxBf4gJFb2oSJmYX9t9Y3sIShpw0nK6nmP8laA_aem_Q4MMZzgAmLsauqsrU5ID6g

So naturally, someone needs to try this and see if it would even work. AI is terrible at BASIC, though I did have some success talking it through some simple 32-column text screen game code when ChatGPT first made a big public splash a few years ago.

Let’s look at the second code variation it produced:

10 REM Two-Level Markov Chain Predictor for TRS-80 CoCo20 REM Vocabulary: 1000 words, Trigram model fits in 512KB30 DIM V$(999): REM Vocabulary array (1000 words)40 DIM F(999): REM Frequency array for vocab building50 DIM M(499,3): REM Model: 500 trigrams max (w1,w2,w3,prob)60 N=0: REM Number of trigrams loaded70 REM Pass 1: Build vocabulary from corpus.txt80 OPEN "I",#1,"CORPUS.TXT"90 FOR I=0 TO 999: F(I)=0: NEXT I: REM Initialize frequency100 IF EOF(1) THEN 140110 LINE INPUT #1,L$: REM Read line120 GOSUB 500: REM Process line for word frequencies130 GOTO 100140 CLOSE #1150 REM Sort top 1000 words by frequency (simplified)160 FOR I=0 TO 999: V$(I)="<UNK>": NEXT I: REM Default to <UNK>170 W$="":C=0: REM Temp word and count180 OPEN "I",#1,"CORPUS.TXT" : REM Reopen for word assignment190 IF EOF(1) THEN 230200 LINE INPUT #1,L$210 GOSUB 600: REM Assign top 1000 words220 GOTO 190230 CLOSE #1240 REM Pass 2: Build trigram model250 OPEN "I",#1,"CORPUS.TXT"260 IF EOF(1) THEN 300270 LINE INPUT #1,L$280 GOSUB 700: REM Build trigrams290 GOTO 260300 CLOSE #1310 REM Input sequence and predict320 PRINT "Enter two-word sequence (e.g., 'the quick'):"330 INPUT S$340 GOSUB 800: REM Extract last two words and predict350 PRINT "Next word:";W3$360 GOTO 320: REM Loop for more predictions500 REM Subroutine: Count word frequencies510 W$="":P=1520 IF P>LEN(L$) THEN RETURN530 C$=MID$(L$,P,1)540 IF C$=" " OR P=LEN(L$) THEN GOSUB 550: GOTO 570550 IF W$<>"" THEN FOR I=0 TO 999: IF V$(I)=W$ THEN F(I)=F(I)+1: GOTO 560: NEXT I560 W$="":P=P+1:GOTO 520570 W$=W$+C$:P=P+1:GOTO 520600 REM Subroutine: Assign top 1000 words (simplified)610 W$="":P=1620 IF P>LEN(L$) THEN RETURN630 C$=MID$(L$,P,1)640 IF C$=" " OR P=LEN(L$) THEN GOSUB 650: GOTO 670650 IF W$<>"" THEN FOR I=0 TO 999: IF V$(I)="" AND F(I)>C THEN V$(I)=W$:C=F(I): GOTO 660: NEXT I660 W$="":P=P+1:GOTO 620670 W$=W$+C$:P=P+1:GOTO 620700 REM Subroutine: Build trigrams710 W1$="":W2$="":W3$="":P=1:W=0720 IF P>LEN(L$) THEN RETURN730 C$=MID$(L$,P,1)740 IF C$=" " OR P=LEN(L$) THEN GOSUB 750: GOTO 770750 IF W$<>"" THEN W=W+1:IF W=1 THEN W1$=W$ ELSE IF W=2 THEN W2$=W$ ELSE IF W=3 THEN W3$=W$:GOSUB 900760 W$="":P=P+1:GOTO 720770 W$=W$+C$:P=P+1:GOTO 720900 REM Subroutine: Add trigram to model910 IF N>=500 THEN RETURN: REM Limit to 500 trigrams920 FOR I=0 TO 999: IF V$(I)=W1$ THEN W1=I:GOTO 930: NEXT I:W1=999930 FOR I=0 TO 999: IF V$(I)=W2$ THEN W2=I:GOTO 940: NEXT I:W2=999940 FOR I=0 TO 999: IF V$(I)=W3$ THEN W3=I:GOTO 950: NEXT I:W3=999950 FOR I=0 TO N-1: IF M(I,0)=W1 AND M(I,1)=W2 THEN M(I,3)=M(I,3)+1:RETURN960 M(N,0)=W1:M(N,1)=W2:M(N,2)=W3:M(N,3)=1:N=N+1970 RETURN800 REM Subroutine: Predict next word810 W1$="":W2$="":P=1820 IF P>LEN(S$) THEN GOTO 850830 C$=MID$(S$,P,1)840 IF C$=" " THEN W1$=W2$:W2$="":P=P+1:GOTO 820 ELSE W2$=W2$+C$:P=P+1:GOTO 820850 IF W1$="" THEN W1$=W2$:W2$="": REM Handle single word860 FOR I=0 TO 999: IF V$(I)=W1$ THEN W1=I:GOTO 870: NEXT I:W1=999870 FOR I=0 TO 999: IF V$(I)=W2$ THEN W2=I:GOTO 880: NEXT I:W2=999880 W3$="<UNK>":P=0890 FOR I=0 TO N-1: IF M(I,0)=W1 AND M(I,1)=W2 AND M(I,3)>P THEN W3$=V$(M(I,2)):P=M(I,3)900 NEXT I910 RETURN

This is surprising to me, since it does appear to be honoring the 2-character limit of Color BASIC variables, which is something my early interactions with ChatGPT would not do.

The original prompt told it to do something that could run on a CoCo within 512K. Even Super Extended Color BASIC on a 512K CoCo 3 still only gives you 24K of program space on startup. And, as I recently learned, if you try to use a CoCo 3’s 40 or 80 column screen and clear more than about 16K of string space,you get a crash.

I think I may give this a go. I do not understand how any of this works, so I do not expect good results, BUT I do want to at least try to see if I can make the program functional. If it expects to use 512K of RAM for string storage, this program is doomed to fail. But, 24K would be room for 1000 24-byte words, at least.

To be continued … maybe.

In the meantime, check out that Grok link and see what you can come up with. And let me know in the comments.

In the previous installment, I rambled on about the difference of “char *line;” and “char line[];”. The first is a “pointer to char(s)” and the second is “an array of char(s)”. But, when you pass them into a function, they both are treated as a pointer to those chars.

One “benefit” of using “line[]” was that you could use sizeof(line) on it and get the byte count of the array. This is faster than using strlen().

But if you pass it into a function, all you have is a pointer so strlen() is what you have to use.

While you can’t pass an “array of char” into a function as an array of char, you can pass a structure that contains an “array of char” and sizeof() will work on that:

#include <stdio.h>#include <stdlib.h> // for EXIT_SUCCESS#include <string.h>typedef struct{    char buffer[80];} MyStruct;void function (MyStruct test){    printf ("sizeof(test.buffer) = %zu\n", sizeof(test.buffer));}int main(void){    MyStruct test;        strncpy (test.buffer, "This is a test", sizeof(test.buffer));        function (test);    return EXIT_SUCCESS;}

You may notice that was passing acopy of the structure in, but stay with me for a moment.

If you have a function that is supposed to copy data into a buffer:

#define VERSION_STRING "1.0.42b-alpha"void GetVersion (char *buffer){    if (NULL != buffer)    {        strcpy (buffer, VERSION_STRING);    }}

…you can easily have a buffer overrun problem if the function writes more data than is available in the caller’s buffer. Because of this potential problem, I add a size parameter to such functions:

void GetVersion (char *buffer, size_t bufferSize){    if (NULL != buffer)    {        // Copy up to bufferSize bytes.        strncpy (buffer, VERSION_STRING, bufferSize);    }}

As long as the caller passes the correct parameters, this is safe:

char buffer[20];GetVersion (buffer, 20);

But the caller could still screw up:

char buffer[20];GetVersion (buffer, 200); // oops, one too many zeros

But if you use a structure, it is impossible for the caller to mess it up (though, of course, they could mess up the structure on their side before calling your function). The compiler type checking will flag if the wrong data type is passed in. The “buffer” will always be the “buffer.” No chance of a “bad pointer” or “buffer overrun” crashing the program.

To allow the buffer inside the structure to be modified, pass it in by reference:

#include <stdio.h>#include <stdlib.h> // for EXIT_SUCCESS#include <string.h>#define VERSION_STRING "1.0.42b-alpha"typedef struct{    char buffer[80];} MyStruct;void GetVersion (MyStruct *test){    strncpy (test->buffer, VERSION_STRING, sizeof(test->buffer));}int main(void){    MyStruct test;        GetVersion (&test);        printf ("Version: %s\n", test.buffer);    return EXIT_SUCCESS;}

Using this approach, you can safely pass a “buffer” into functions and they can get the sizeof() the buffer to ensure they do not overwrite anything.

But wait, there’s more…

It is pretty easy for a function to get out of control if you are trying to get back more than one thing. If you just want an “int”, that’s easy…

int GetCounter (){    static int s_count = 0;    return s_count++;}

But if you wanted to get the major, minor, patch and build version, you end up passing in ints by reference to get something like this:

void GetVersion (int *major, int *minor, int *patch, int *build){   if (NULL != major)   {      *major = MAJOR_VERSION;   }   if (NULL != minor)   {      *major = MINOR_VERSION;   }   if (NULL != patch)   {      *major = PATCH_VERSION;   }   if (NULL != build)   {      *major = BUILD_VERSION;   }}

Of course, anytime pointers are involved, the caller could pass in the wrong pointer and things could get screwed up. Plus, look at all those NULL checks to make sure the pointer isn’t 0. (This does not help if the pointer is pointing to some random location in memory.)

#include <stdio.h>#include <stdlib.h> // for EXIT_SUCCESS#define MAJOR_VERSION 1#define MINOR_VERSION 0#define PATCH_VERSION 0#define BUILD_VERSION 42typedef struct{    int major;    int minor;    int patch;    int build;} VersionStruct;VersionStruct GetVersion (){    VersionStruct ver;        ver.major = MAJOR_VERSION;    ver.minor = MINOR_VERSION;    ver.patch = PATCH_VERSION;    ver.build = BUILD_VERSION;        return ver;}int main(void){    VersionStruct ver;        ver = GetVersion ();        printf ("Version: %u.%u.%u.%u\n",        ver.major, ver.minor, ver.patch, ver.build);    return EXIT_SUCCESS;}

If you are concerned about overhead of passing structures, you can pass them by reference (pointer) and the compiler should still catch if a wrong pointer type is passed in:

#include <stdio.h>#include <stdlib.h> // for EXIT_SUCCESS#define MAJOR_VERSION 1#define MINOR_VERSION 0#define PATCH_VERSION 0#define BUILD_VERSION 42typedef struct{    int major;    int minor;    int patch;    int build;} VersionStruct;void GetVersion (VersionStruct *ver){    if (NULL != ver)    {        ver->major = MAJOR_VERSION;        ver->minor = MINOR_VERSION;        ver->patch = PATCH_VERSION;        ver->build = BUILD_VERSION;    }}int main(void){    VersionStruct ver;        GetVersion (&ver);        printf ("Version: %u.%u.%u.%u\n",        ver.major, ver.minor, ver.patch, ver.build);    return EXIT_SUCCESS;}

However, when dealing with pointers, there is always some risk. While the compiler will catch passing in the wrong structure pointer, there are still ways the caller can screw it up. For instance, void pointers:

int main(void){    void *nothing = (void*)0x1234;        GetVersion (nothing);    return EXIT_SUCCESS;}

Yep. Crash.

...Program finished with exit code 139
Press ENTER to exit console.

Give someone access to a function in your DLL and they might find a way to crash the program as simply as using a void pointer.

It is a bit trickier when you pass the full structure:

typedef struct{    int x;} BogusStruct;int main(void){    BogusStruct ver;        ver = GetVersion ();        return EXIT_SUCCESS;}

Compiler don’t like:

main.c: In function ‘main’:
main.c:38:11: error: incompatible types when assigning to type ‘BogusStruct’ from type ‘VersionStruct’
   38 |     ver = GetVersion ();
      |           ^~~~~~~~~~
main.c:36:17: warning: variable ‘ver’ set but not used [-Wunused-but-set-variable]
   36 |     BogusStruct ver;
      |                 ^~~

And you can’t really cast a return value like this:

int main(void)
{
    BogusStruct ver;

    (VersionStruct)ver = GetVersion ();

    return EXIT_SUCCESS;
}

Compiler don’t like:

main.c: In function ‘main’:
main.c:38:5: error: conversion to non-scalar type requested
   38 |     (VersionStruct)ver = GetVersion ();
      |     ^

Though maybe you could cast it if it was passed in as a parameter:

void ShowVersion (VersionStruct ver){    printf ("Version: %u.%u.%u.%u\n",    ver.major, ver.minor, ver.patch, ver.build);}int main(void){    BogusStruct ver;        ShowVersion ((VersionStruct)ver);        return EXIT_SUCCESS;}

Compiler still don’t like:

main.c: In function ‘main’:
main.c:44:5: error: conversion to non-scalar type requested
   44 |     ShowVersion ((VersionStruct)ver);
      |     ^~~~~~~~~~~

Hmm. Is there a way to screw this up? Let me know in the comments.

Until then…

Waybackwhen, I wrote this proposal for a very simple BBS networking protocol. There were several in existence, but the specs were always complicated. I wanted something someone could implement without a Phd ;-)

The following is a proposal for a new CoCo BBS message networking protocol created by Allen Huffman at Sub-Etha Software. This protocol was designed to easily allow the CoCo community to link BBSs together for mass communication within this network.

Background:

Several successful BBS networking protocols are already in existence such as FidoNet and WWIVNet. Although very powerful, these systems require large amounts of disk space to operate and have so far been limited only to systems with hard drives.

Introducing the Sub-Etha Net:

The proposed “Sub-Etha Net”, henceforth known as SENet, will be a low-hardware CoCo specific network designed for the sole purpose of linking the online CoCo community together with one massive public message base.

At this time, no private messages between systems will be supported. This will greatly limit the amount of overhead required by each system. Current protocols have required each system within the net to store a “net list” containing information on ALL systems within the network. SENet will not require such a list and no “hub” systems are needed.

How it Will Work:

In order to link with the network, the Sysop will simply insert the phone number of the system it wishes to net with and configure a few settings which control when and what it will transfer. The system you plan to net with will also add your number to its listing. Once this has been done, no further configuration will be required. A simple message pointer flag stored for each system is all that is required to keep track of messages.

An Example: System A will call System B and transfer messages.

At the specified time, System A dials a number stored in it’s net list.

Upon connection, System A waits for a prompt (such as “Press Return:”) then sends an escape code and it’s phone number (in the form ###-###-####) to System B.

System B will look up that number in it’s net list and either ACKnowledge or request the number to be resent (in case of line noise).

If several unsuccessful attempts are made, System B will disconnect. (If this was caused by line noise, this forces System A to redial and try for a better connection.)

After a successful connection, System A sends a four byte number stored in it’s net list which instructs System B to send all messages it has from that number on.

System B then sends messages (with appropriate error checking).

System A will ACKnowledge the transfer (or request data to be resent).

Depending on System B’s configuration, System B will either send a final ACKnowledgement and disconnect, OR it will send it’s four byte number for a message request.

System A then sends messages (with appropriate error checking).

System B will ACKnowledge the transfer (or request data to be resent).

System A will send a final ACKnowledgemend and disconnect.

Message base structure:

To keep things a simple as possible, the message base will contain only the following information…

• From: Name of poster (30 characters)
• Subj: Message subject (40 characters)
• Date: Date/time posted (6 character packet)

This allows the message “header” to fit in one 80 column line of information. Any other information such as “To:” or “Reply to:” will be contained in the actual message text portion of the file. This allows excellent flexibility for future expansion.

I wonder what else I will find in my archives. I still think something like this was a good idea — low overhead, simple to implement even in BASIC (though requiring an assembly language remote terminal driver), and “just enough to get the basic stuff done.”

Maybe one day we’ll do something like that using a CoCo and a$10 WiFi Modem for it ;-)

Until then…