The Compact Computer 40 (CC40)

[mrvan]

8 hours ago, brain said:

The defaults in the code are:

 

https://github.com/go4retro/HEXTIr/blob/51ea22df26cbc6beedb13e90dd0e530246948a9c/src/serial.cpp#L569-L584

 

    _config.ser.bpsrate = 300;
    _config.ser.echo = TRUE;  // TODO see exactly what this means.
    _config.ser.length = LENGTH_7;
    _config.ser.line = LINE_CRLF;
    _config.ser.nulls = 0;
    _config.ser.overrun = _cfg.overrun;
    _config.ser.parchk = FALSE;
    _config.ser.parity = PARITY_ODD;
    _config.ser.stopbits = STOP_0;
    _config.ser.xfer = XFER_REC;

The XFER_REC should cause an issue, as defined by the HexBus-Specifications.pdf doc, page 242, but it looks like I did not implement it at all, so all XFER_* behave like XFER_CHAR, which is char in, char out...

 

See if those settings help.  If not, I'd hook it up to a terminal program and boot the system.  It might be that your build has debugging, which is either 57600 or 115200/n/8/1, and it overrides serial.  If so, my bad.  I try to turn it off when a build is ready, but I might forget at times.

 

If you need debugging, I can help, but it'll be a week, as I can't get to my lab this week.

 

Jim

Thanks Jim. I'll try the defaults and then the two high speeds at 8/n/1 tonight and let you know.

[mrvan]

16 hours ago, mrvan said:

Thanks Jim. I'll try the defaults and then the two high speeds at 8/n/1 tonight and let you know.

Having reduced down to 300 baud, the characters being read are now non-zero but garbage. Nothing comes through at the two higher speeds.

v+nvkN6c,vcnv+nvkNvc,vcnv+nvkNvc,vcnvbnvkn6kNvclvbnv+nvkNvc,vcnvbnvkn6kNvc,vbnv+nvkN

Kinda looks like Curly trying to say something, Nyuk Nyuk Nyuk.

 

I've permuted every setting, for data size, parity odd/even/none, stop bits all to no avail. Sigh.

 

But I feel confident the speed is 300 baud. 

[brain]

OK, well, that at least does not look like debug info, so there's that.

 

Here's a few things we can try, before I get home, if you can program your unit with a new binary.

 

1) we can program an debug binary, and you should see debug information (that would at least validate the serial port is working)

2) I can pre-open a serial connection and send some test data our on bootup. 

 

Jim

 

[mrvan]

11 hours ago, brain said:

OK, well, that at least does not look like debug info, so there's that.

 

Here's a few things we can try, before I get home, if you can program your unit with a new binary.

 

1) we can program an debug binary, and you should see debug information (that would at least validate the serial port is working)

2) I can pre-open a serial connection and send some test data our on bootup. 

 

Jim

 

I've not programmed one of these units but am willing with instructions and pointing to the file.

[mrvan]

On 10/21/2023 at 9:44 PM, brain said:

I don't think open #255,"se dev=21" will work.  THere's no device number in the open statement.  Checking my manual, open needs to be :  open #<channel>, "<device_number>.<open parms>"

 

So, I think it's open #255,"20.se dev=21"

 

And then the close will fail, because device 20 is gone, but you need to do it to clean up the BASIC pointers.

 

Then, try to open #255,"20.b=9600" should succeed.

 

If the se dev=21 works, then the next step really should be to do open #255,"21.st", which is supposed to permanently store the new device number.

 

 

I had missed previously any documentation for settings in opening a serial port. I see the "20.b=9600" from your post. What are the parity and stop bit settings and what a properly formatted open look like? "20.b=9600.p=n.s=1"?

[brain]

• 

I would try it with and without the spaces after the commas, it looks like I trim, but my se=21 is broken, so perhaps the space trimming is as well.

 

This is from the Specifications PDF, which is what I wrote against.

[mrvan]

20 hours ago, brain said:

• 

I would try it with and without the spaces after the commas, it looks like I trim, but my se=21 is broken, so perhaps the space trimming is as well.

 

This is from the Specifications PDF, which is what I wrote against.

I have initial success with open #1,"20.B=57600",output. 115200 seems to be slightly flakey as some characters are occasionally received wrong with all else still correct.

By default this seems to be baud=57600, parity=odd, stop bits=1 and those settings are just fine for now. I'm happy to see the beginnings of this project actually work.

 

The video shows a very simple BASIC program communicating via the HEXTIr serial port to a Raspberry Pi 3, as viewed from an SSH session from a Mac to the RPI. The program on the RPI simply opens the serial port and reads characters, interpreting only a form feed to clear the screen or otherwise display the character directly. The CC40 program simply opens the port, sends a form feed to clear the screen, loops from 1-50 with print I; "Hello World!" & chr$(10), and then loops again 0-50 with print I, and then closes the port.

 

It will be easy to send command sequences to set screen position and other interesting effects (color, bolding, inverse video). Being within an ANSI-compatible terminal I believe it should already handle such ANSI escape sequences.

 

[mrvan]

The ANSI codes do indeed work. 

 

 

[brain]

Cool!

 

This gives me some initiative to finish the Pi Zero W HEXTIr Display adapter I started.  I was working on porting the HEXTIr code to the Pi, and got busy with other things.

Edited March 15 by brain

[mrvan]

On 1/1/2024 at 6:28 PM, Vorticon said:

Pretty much I did not have the needed adapter and I have currently no other use for the RS232 peripheral so may as well put it to good use. It also has a parallel port so I may at some point print out data to a printer as well.

Any chance you have a lead on more of these HEXBUS RS232 peripherals?

[+Vorticon]

47 minutes ago, mrvan said:

Any chance you have a lead on more of these HEXBUS RS232 peripherals?

No idea. I've had mine for a couple of decades. They are very hard to come by these days unfortunately.

[mrvan]

On 3/14/2024 at 9:15 PM, Vorticon said:

No idea. I've had mine for a couple of decades. They are very hard to come by these days unfortunately.

Thanks for responding. My search turned up pretty much only history / museum links for these.

 

The HEXTIr serial works fine but as you know the HEXTIr is always the terminating device on the HEXBUS chain. No complaints with it at all--it is great. The CC-40 world greatly opened up with the work @brain and all the other contributors made in this thread. These CC-40s are actually pretty nice machines and it'd be great for them to be nice weekend runners rather than just boxed up in the closet.

[mrvan]

@brain, is there a users guide for the HEXTIr beyond the file on GitHub.

 

A few areas where I could use help are:

- Serial port vs printer port. Are these both available and at the same time? Do they appear as separate ports on the external connected PC? Serial port settings for open command

- Can the SD card be ejected and reinserted with the HEXTIr on, at least if no files are open

- Directories - I see how to create them, but not sure what is required for the open command

[+Ksarul]

On 3/14/2024 at 11:26 PM, mrvan said:

Any chance you have a lead on more of these HEXBUS RS232 peripherals?

You might want to contact mdude on eBay, as he seems to be the last source of NOS HexBus peripherals out there.

[+Vorticon]

This should help a little:

To get a directory:
OLD "100.$" then LIST

DEVICE NUMBER IS 100

Power up drive then CC40 then cycle power on drive to activate.

For the drive, there are two options:
 
open #1,"100"
print#1,"cd /jim/path/to/cc40/files"
 
If using the regular open, note that the filename MUST be absent, or the system will assume a file is to be opened.  Commands can be sent via print statements, and the response code will note the results.
 
Alternatively, the "special command LUN" is available:
 
Either:
open #255,"100"
print#1,"cd /jim/path/to/cc40/files"
 
OR:
open #255,"100.cd /jim/path/to/cc40/files"
<and you can print more commands to perform after the open.
 
You can also chain the commands:
 
On either LUN:
print #<LUN>,"md /jim,cd /jim"
 
On the CMD LUN:
open #255,"100.md /jim,cd /jim"
 
I would not recommend chaining commands, as the parser will fail on the first error, but there's no way to return which command failed.
 
On serial and printer, the non CMD LUN option is already supported, as it was part of the original standard:
 
open #1,"20.B=19200,D=8,S=1,P=N"
 
Such commands will set the configuration of the current serial connection.
 
The special CMD LUN on these devices will set the global defaults:
 
FOr instance, to set the default bps rate for all new connections that don't absolutely specify it, do:
 
Either:
open #255,"20.B=9600"
 
or
open #255,"20"
print #255,"B=9600": rem set global BPS rate default to 9600.
 
The CMD LUN offers 2 additional features on each device.
 
To change the device number of a device, open it's CMD LUN and issue a device number change command:
 
Either:
 
open #255,"<devno>"
print #255,"DE=<new_device_number>"
 
or
 
open #255,"<devno>.DE=<new_device_number>"
 
A close afterwards will fail, because the device number changes immediately.
 
To store new global defaults for serial or printer, or device numbers for any of the devices supported (clock, serial, printer, drive), the command:
 
"ST"
 
issues on the CMD LUN of any device will write the current configuration to EEPROM, which will be read when the system restarts.
 
Drive commands:
 
static const action_t dcmds[14] MEM_CLASS = {
                                  {DISK_CMD_CHDIR,    "cd"},
                                  {DISK_CMD_CHDIR,    "chdir"},
                                  {DISK_CMD_MKDIR,    "md"},
                                  {DISK_CMD_MKDIR,    "mkdir"},
                                  {DISK_CMD_RMDIR,    "del"},
                                  {DISK_CMD_RMDIR,    "delete"},
                                  {DISK_CMD_RMDIR,    "rmdir"},
                                  {DISK_CMD_RENAME,   "rn"},
                                  {DISK_CMD_RENAME,   "rename"},
                                  {DISK_CMD_RENAME,   "mv"},
                                  {DISK_CMD_RENAME,   "move"},
                                  {DISK_CMD_COPY,     "cp"},
                                  {DISK_CMD_COPY,     "copy"},
                                  {DISK_CMD_PWD,      "pwd"},
                                  {DISK_CMD_NONE,     ""}
COPY and PWD are not implemented as yet.  rename is "rn newname=oldname"
 
Note that some commands have synonyms.  Note that the cc40 spec also defines a "delete" operation, like open and read, which should preferably be used for programs.  This cmd is mainly for directory removal, but it (currently) also works on files.
 
Serial Options:
 
static const action_t cmds[] PROGMEM = {
                                        {SER_CMD_BPS,       "b"},
                                        {SER_CMD_BPS,       ".ba"},
                                        {SER_CMD_LEN,       "d"},
                                        {SER_CMD_LEN,       ".da"},
  {SER_CMD_PARITY,    "p"},
                                        {SER_CMD_PARITY,    ".pa"},
                                        {SER_CMD_PARCHK,    "c"},
                                        {SER_CMD_NULLS,     "n"},
                                        {SER_CMD_STOP,      "s"},
                                        {SER_CMD_ECHO,      "e"},
                                        {SER_CMD_LINE,      "r"},
                                        {SER_CMD_TRANSFER,  "t"},
                                        {SER_CMD_OVERRUN,   "o"},
                                        {SER_CMD_NONE,      ""}
These are all of the form <opt>=<value>
 
Serial Option Alternates emulated from TI 99/4A:
 
static const action_t ti_cmds[] PROGMEM = {
                                            {SER_CMD_TW,    ".tw"},
                                            {SER_CMD_NU,    ".nu"},
                                            {SER_CMD_CH,    ".ch"},
                                            {SER_CMD_EC,    ".ec"},
                                            {SER_CMD_CR,    ".cr"},
                                            {SER_CMD_LF,    ".lf"},
                                            {SER_CMD_NONE,  ""}
                                          };
The above are very specific.  .tw by itself means stop bits needs to be 1.
 
The HexBus spec describes the mappings (though, you can see I disagree with some of them.  Maybe folks can let me know if the official TI specs for modems and such agree with this or me:
 
    cmd = (sercmd_t) parse_cmd(ti_cmds, &buf, &len);
    switch (cmd) {
    case SER_CMD_TW:
      cfg->stopbits = STOP_1;
      break;
    case SER_CMD_NU:
      cfg->length = LENGTH_6;
      break;
    case SER_CMD_CH:
      cfg->parchk = TRUE;
      break;
    case SER_CMD_EC:
      cfg->echo = FALSE;
      break;
    case SER_CMD_CR:
      cfg->line = LINE_NONE; // seems wrong
      break;
    case SER_CMD_LF:
      cfg->line = LINE_CR; // Seems wrong
      break;
Printer options:
static const action_t cmds[] PROGMEM = {
                                        {PRN_CMD_CRLF,      "c"},   // ALC printer/plotter
                                        {PRN_CMD_CRLF,      "r"},   // 80 column printer
                                        {PRN_CMD_COMP,      "s"},   // alc printer/plotter
                                        {PRN_CMD_SPACING,   "l"},   // 80 column printer
You can see the full mappings for the units in the source, which is pretty easy to read:
 

 

[mrvan]

1 hour ago, Vorticon said:

This should help a little:

To get a directory:
OLD "100.$" then LIST

DEVICE NUMBER IS 100

Power up drive then CC40 then cycle power on drive to activate.

For the drive, there are two options:
 
open #1,"100"
print#1,"cd /jim/path/to/cc40/files"
 
If using the regular open, note that the filename MUST be absent, or the system will assume a file is to be opened.  Commands can be sent via print statements, and the response code will note the results.
 
Alternatively, the "special command LUN" is available:
 
Either:
open #255,"100"
print#1,"cd /jim/path/to/cc40/files"
 
OR:
open #255,"100.cd /jim/path/to/cc40/files"
<and you can print more commands to perform after the open.
 
You can also chain the commands:
 
On either LUN:
print #<LUN>,"md /jim,cd /jim"
 
On the CMD LUN:
open #255,"100.md /jim,cd /jim"
 
I would not recommend chaining commands, as the parser will fail on the first error, but there's no way to return which command failed.
 
On serial and printer, the non CMD LUN option is already supported, as it was part of the original standard:
 
open #1,"20.B=19200,D=8,S=1,P=N"
 
Such commands will set the configuration of the current serial connection.
 
The special CMD LUN on these devices will set the global defaults:
 
FOr instance, to set the default bps rate for all new connections that don't absolutely specify it, do:
 
Either:
open #255,"20.B=9600"
 
or
open #255,"20"
print #255,"B=9600": rem set global BPS rate default to 9600.
 
The CMD LUN offers 2 additional features on each device.
 
To change the device number of a device, open it's CMD LUN and issue a device number change command:
 
Either:
 
open #255,"<devno>"
print #255,"DE=<new_device_number>"
 
or
 
open #255,"<devno>.DE=<new_device_number>"
 
A close afterwards will fail, because the device number changes immediately.
 
To store new global defaults for serial or printer, or device numbers for any of the devices supported (clock, serial, printer, drive), the command:
 
"ST"
 
issues on the CMD LUN of any device will write the current configuration to EEPROM, which will be read when the system restarts.
 
Drive commands:
 
static const action_t dcmds[14] MEM_CLASS = {
                                  {DISK_CMD_CHDIR,    "cd"},
                                  {DISK_CMD_CHDIR,    "chdir"},
                                  {DISK_CMD_MKDIR,    "md"},
                                  {DISK_CMD_MKDIR,    "mkdir"},
                                  {DISK_CMD_RMDIR,    "del"},
                                  {DISK_CMD_RMDIR,    "delete"},
                                  {DISK_CMD_RMDIR,    "rmdir"},
                                  {DISK_CMD_RENAME,   "rn"},
                                  {DISK_CMD_RENAME,   "rename"},
                                  {DISK_CMD_RENAME,   "mv"},
                                  {DISK_CMD_RENAME,   "move"},
                                  {DISK_CMD_COPY,     "cp"},
                                  {DISK_CMD_COPY,     "copy"},
                                  {DISK_CMD_PWD,      "pwd"},
                                  {DISK_CMD_NONE,     ""}
COPY and PWD are not implemented as yet.  rename is "rn newname=oldname"
 
Note that some commands have synonyms.  Note that the cc40 spec also defines a "delete" operation, like open and read, which should preferably be used for programs.  This cmd is mainly for directory removal, but it (currently) also works on files.
 
Serial Options:
 
static const action_t cmds[] PROGMEM = {
                                        {SER_CMD_BPS,       "b"},
                                        {SER_CMD_BPS,       ".ba"},
                                        {SER_CMD_LEN,       "d"},
                                        {SER_CMD_LEN,       ".da"},
  {SER_CMD_PARITY,    "p"},
                                        {SER_CMD_PARITY,    ".pa"},
                                        {SER_CMD_PARCHK,    "c"},
                                        {SER_CMD_NULLS,     "n"},
                                        {SER_CMD_STOP,      "s"},
                                        {SER_CMD_ECHO,      "e"},
                                        {SER_CMD_LINE,      "r"},
                                        {SER_CMD_TRANSFER,  "t"},
                                        {SER_CMD_OVERRUN,   "o"},
                                        {SER_CMD_NONE,      ""}
These are all of the form <opt>=<value>
 
Serial Option Alternates emulated from TI 99/4A:
 
static const action_t ti_cmds[] PROGMEM = {
                                            {SER_CMD_TW,    ".tw"},
                                            {SER_CMD_NU,    ".nu"},
                                            {SER_CMD_CH,    ".ch"},
                                            {SER_CMD_EC,    ".ec"},
                                            {SER_CMD_CR,    ".cr"},
                                            {SER_CMD_LF,    ".lf"},
                                            {SER_CMD_NONE,  ""}
                                          };
The above are very specific.  .tw by itself means stop bits needs to be 1.
 
The HexBus spec describes the mappings (though, you can see I disagree with some of them.  Maybe folks can let me know if the official TI specs for modems and such agree with this or me:
 
    cmd = (sercmd_t) parse_cmd(ti_cmds, &buf, &len);
    switch (cmd) {
    case SER_CMD_TW:
      cfg->stopbits = STOP_1;
      break;
    case SER_CMD_NU:
      cfg->length = LENGTH_6;
      break;
    case SER_CMD_CH:
      cfg->parchk = TRUE;
      break;
    case SER_CMD_EC:
      cfg->echo = FALSE;
      break;
    case SER_CMD_CR:
      cfg->line = LINE_NONE; // seems wrong
      break;
    case SER_CMD_LF:
      cfg->line = LINE_CR; // Seems wrong
      break;
Printer options:
static const action_t cmds[] PROGMEM = {
                                        {PRN_CMD_CRLF,      "c"},   // ALC printer/plotter
                                        {PRN_CMD_CRLF,      "r"},   // 80 column printer
                                        {PRN_CMD_COMP,      "s"},   // alc printer/plotter
                                        {PRN_CMD_SPACING,   "l"},   // 80 column printer
You can see the full mappings for the units in the source, which is pretty easy to read:
 

 

Excellent. This is good info! Thank you!

[mrvan]

2 hours ago, Ksarul said:

You might want to contact mdude on eBay, as he seems to be the last source of NOS HexBus peripherals out there.

I've contacted him. Thank you for the lead.

[brain]

On 3/16/2024 at 11:16 AM, mrvan said:

Thanks for responding. My search turned up pretty much only history / museum links for these.

 

The HEXTIr serial works fine but as you know the HEXTIr is always the terminating device on the HEXBUS chain. No complaints with it at all--it is great. The CC-40 world greatly opened up with the work @brain and all the other contributors made in this thread. These CC-40s are actually pretty nice machines and it'd be great for them to be nice weekend runners rather than just boxed up in the closet.

Actually, it doesn't need to be.  Just wire up a second port attached to the first, or use a Y-cable, and you can add devices after it.

 

Jim

[brain]

On 3/16/2024 at 11:22 AM, mrvan said:

@brain, is there a users guide for the HEXTIr beyond the file on GitHub.

 

A few areas where I could use help are:

- Serial port vs printer port. Are these both available and at the same time? Do they appear as separate ports on the external connected PC? Serial port settings for open command

- Can the SD card be ejected and reinserted with the HEXTIr on, at least if no files are open

- Directories - I see how to create them, but not sure what is required for the open command

They are both in the build, but I can't guarantee your specific device has them both enabled in the compile.  If you use the hex/bin files from the github, I turn all of them on (clock, parallel, serial, disk)

 

Serial is on the serial port.  5V parallel is available as a serial stream (not enough pins on the unit for a real parallel port) on portD, pin 5.  You'll need something that can handle 5V TTL serial to use it

 

Yes, SD is hotplug compatible.  It will corrupt files if they are open when you change disks.

 

I see someone else copied in the instructions for md/cd/rd

 

jim

 

 

[mrvan]

On 3/17/2024 at 8:00 PM, brain said:

Actually, it doesn't need to be.  Just wire up a second port attached to the first, or use a Y-cable, and you can add devices after it.

 

Jim

Hi Jim, thank you for the great info. It seems then I could purchase a second HEXTIr and update the device ids? If so will it remember the updates between power cycles?

[brain]

Yes (there's a command to "save" the config.

That said, I know there's a bug in the se(t) command for device IDs.  It's been a zoo here, but let me see if I can fix that bug.  Obviously, you can mod the code and recompile, which is what I did to temp fix.

 

Jim

[mrvan]

On 3/14/2024 at 7:55 PM, brain said:

Cool!

 

This gives me some initiative to finish the Pi Zero W HEXTIr Display adapter I started.  I was working on porting the HEXTIr code to the Pi, and got busy with other things.

Hi Jim, are you thinking of creating a new HEXTIr based on the Pi Zero, or just the display adapter? If the HEXTIr with storage, serial port and clock, that would be great and provide a solution that could allow network access to storage, similar to the TIPI for TI99.

 

I've been pondering the display adapter and have taken some time to read the TI specification for it. It seems to define a semi-smart terminal with built in editing type functions and has some vector graphics ability. It is quite unique to the CC-40 and is pretty decent. It seems there's options to weigh, though, whether to recreate the product that TI did, or create something different but still fills the same type of need. 

 

I suppose it comes down to philosophy. I think there's an option for a HEXTIr display device that simply maps to an ANSI terminal and thus implements according to standards. There are tools out there still, mostly used by BBSs (those few that remain) to generate ANSI images, which could be cool for games and similar. There's also simple libraries to write the ANSI codes for formatting characters, colors, etc. as well as controlling the screen, position, etc.

 

This site, for instance, provides immediate conversion of a jpeg to ANSI art https://dom111.github.io/image-to-ansi/ that one can nearly copy past into an app.

 

Thoughts?

[mrvan]

This is an example of ANSI art, in RGB. The picture is an arch in the Alabama Hills near Lone Pine CA, where a large percentage of the 1950-1960 westerns were filmed. 

Edited March 22 by mrvan

[brain]

On 3/21/2024 at 12:19 AM, mrvan said:

Hi Jim, are you thinking of creating a new HEXTIr based on the Pi Zero, or just the display adapter? If the HEXTIr with storage, serial port and clock, that would be great and provide a solution that could allow network access to storage, similar to the TIPI for TI99.

 

I've been pondering the display adapter and have taken some time to read the TI specification for it. It seems to define a semi-smart terminal with built in editing type functions and has some vector graphics ability. It is quite unique to the CC-40 and is pretty decent. It seems there's options to weigh, though, whether to recreate the product that TI did, or create something different but still fills the same type of need. 

 

I suppose it comes down to philosophy. I think there's an option for a HEXTIr display device that simply maps to an ANSI terminal and thus implements according to standards. There are tools out there still, mostly used by BBSs (those few that remain) to generate ANSI images, which could be cool for games and similar. There's also simple libraries to write the ANSI codes for formatting characters, colors, etc. as well as controlling the screen, position, etc.

 

This site, for instance, provides immediate conversion of a jpeg to ANSI art https://dom111.github.io/image-to-ansi/ that one can nearly copy past into an app.

 

Thoughts?

Well, I thought doing the display adapter would be a good test.  Once the HexBus protocol is in place, additions would be much easier.

 

Mainly I felt the Pi0 was one of the cheapest options with HDMI already on board, with a low cost.  It's vastly overkill, but HDMI is hard to design into something, due to the licensing fees.  Still, with the Pi, pretty much any peripheral is possible.

 

To your philosophy, I did intend for 2 variations of the display.  One would be local (HDMI) and one would be remote (ANSI as one sub-option and web display as another).  But, local seemed fastest to implement.

[mrvan]

On 3/21/2024 at 11:01 PM, brain said:

Well, I thought doing the display adapter would be a good test.  Once the HexBus protocol is in place, additions would be much easier.

 

Mainly I felt the Pi0 was one of the cheapest options with HDMI already on board, with a low cost.  It's vastly overkill, but HDMI is hard to design into something, due to the licensing fees.  Still, with the Pi, pretty much any peripheral is possible.

 

To your philosophy, I did intend for 2 variations of the display.  One would be local (HDMI) and one would be remote (ANSI as one sub-option and web display as another).  But, local seemed fastest to implement.

That all sounds pretty good and will likely be somewhat faster than the use of serial. I was thinking that there might be yet further variations where the CC40 can add sprites, send sound, maybe more to the RPI via HEXBUS.

 

Attached is a video for an extension to the serial/ANSI prototype to print image and text files. Starts with a friend's HS picture, then prints the US Declaration of Independence, a picture of an arch in the Alabama Hills in CA, followed by a picture of my miniature schnauzer.

 

I found that I could not reliably send more than 16 characters at a time via the serial port (via print #254, text), so simply broke up any outgoing text to 16 or fewer bytes. Perhaps this is serial buffer size limit? Since this is all written in basic, that undoubtedly slows this down quite a bit, not to mention small HEXBUS calls.

 

The demo sends a total of about 60KB over the serial port. Very occasionally I receive an error, once every 3-4 runs. I should have written the error number down but will provide next time I have some time to work this.