The Compact Computer 40 (CC40)

[brain]

My understanding is that the cassette routines used the pins, but not the protocol, so the cassette unit must be the only device on the bus (no daisy chain).

 

The key to getting this work is whether the CPU ROM routines have any "traps" or "exits" that can be used to extend the functionality.  If not, it'll be extremely difficult to add the capability.  If there are, it should be a simple matter to put the 74 routines ona  ROM card, patch them into the traps, and there you go.

 

However, I will say the idea has no appeal to me (sorry, lots of things are academically interesting, but that's as far as I take them), so I'd invite someone else to tackle.

 

Jim

[+acadiel]

Ever wanted to see a Wafertape drive?  How about a tape?  Or a 10 pack?  
 

Had to remove some rusty screws and clean up a little rust on the IC legs inside, but the mechanism looks in ok shape. 

[+acadiel]

 

[brain]

Cool!

 

[+Ksarul]

Nice new toy for you to play with, @acadiel

 

[brain]

HEX-TI-r (pronounced like the person's name, Hector :-)) Updates

• Configuration and per device commands enabled:
  • Peter Engels contributed code to enable disk commands: chdir, mkdir, rmdir, rename.
  • Old configuration device (#222) is gone (code never was complete) and replaced with per device global configs
    • open #255,"<device>[.<optional commands>]"
    • print #255,<commands>"
    • close #255
    • Where commands are: "DE=<devnumber> and ST (store config in EEPROM)
  • Drive can also be opened in command mode via open #<1-254>,"<device>" (no filename)
  • Both global commands and disk ops can be combined via comma: "chdir /jim,mkdir jim2"
  • All known device-specific options supported (B=300 and such for serial, L=N for printer) on open string
  • Set global serial and printer defaults via #255 LUN (open #255,"20.B=19200,D=8,P=N" for example
  • ST command will save all global defaults and current device numbers to EEPROM, which will be loaded again on next boot.
• A bunch of code cleanup and code size minimization

The serial device (#20) is routed to the USB serial device on the Arduino, which will be available when not uploading new code.

 

This means one can run multiple HEXTIrs on the same bus, daisy chaining them, after setting the devices to be unique.

Code size is approach 32kB on Arduino build (strangely, native Makefile build is only 29K), so we are approaching feature complete state.

 

I have been testing here on my Arduino, so I think all should be good, but I'd always like a few more testers before we merge into master:

 

https://github.com/go4retro/HEXTIr/tree/eeprom

 

Due to the need to use 255 for CMD mode, RAW mode LUN is now 254.

 

(I realize I still need to get updated BASIC programs for the BASIC repo directory that use the new LUN).

 

Jim

[brain]

Small fix for serial routines (code was not allowing bps rate change) and a minimal implementation of reading the firmware version back (open the command channel and read a string).  Version bump to 0.9.2.1.  Have not heard anyone testing the code, so not sure of status, but my testing has been successful, and I am currently considering the system feature complete.

 

I also uploaded the working bootloader for the non Arduino (standalone) version of the device (https://github.com/go4retro/HEXTIr-bootloader).  With this, a self contained professionally produced unit that automatically updates itself is possible.  Let me know if there is any interest.  Expected cost would be around $50.00.

 

Jim

[+Vorticon]

5 minutes ago, brain said:

Small fix for serial routines (code was not allowing bps rate change) and a minimal implementation of reading the firmware version back (open the command channel and read a string).  Version bump to 0.9.2.1.  Have not heard anyone testing the code, so not sure of status, but my testing has been successful, and I am currently considering the system feature complete.

 

I also uploaded the working bootloader for the non Arduino (standalone) version of the device (https://github.com/go4retro/HEXTIr-bootloader).  With this, a self contained professionally produced unit that automatically updates itself is possible.  Let me know if there is any interest.  Expected cost would be around $50.00.

 

Jim

Jim, count me in for 1 unit

[brain]

Additional testing looks good, one more bug fix for reading a directory via program, so I've merged the code into master.  Evidently, I cannot create a Github release on a generic commit on a branch, which was where 0.9.2.0 and 0.9.2.1 was, so I bumped the version to 0.9.3.0 and created a release:

 

https://github.com/go4retro/HEXTIr/releases/tag/v0.9.3.0

 

Jim

 

[+Vorticon]

1 hour ago, brain said:

Additional testing looks good, one more bug fix for reading a directory via program, so I've merged the code into master.  Evidently, I cannot create a Github release on a generic commit on a branch, which was where 0.9.2.0 and 0.9.2.1 was, so I bumped the version to 0.9.3.0 and created a release:

 

https://github.com/go4retro/HEXTIr/releases/tag/v0.9.3.0

 

Jim

 

How does one issue the directory commands on the CC40?

[brain]

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:

 

https://github.com/go4retro/HEXTIr/blob/master/src/drive.cpp#L350 (350-429)

https://github.com/go4retro/HEXTIr/blob/master/src/serial.cpp#L44 (44-280)

https://github.com/go4retro/HEXTIr/blob/master/src/printer.cpp#L51 (51-127)

 

I hope that helps. Let me know if others are needed.

Edited October 3, 2020 by brain

[+Vorticon]

Excellent! Thank you!

[KlausO]

On 10/2/2020 at 8:46 PM, brain said:

I also uploaded the working bootloader for the non Arduino (standalone) version of the device (https://github.com/go4retro/HEXTIr-bootloader).  With this, a self contained professionally produced unit that automatically updates itself is possible.  Let me know if there is any interest.  Expected cost would be around $50.00.

 

Jim

I would like to have such a device.

[pengels]

Hi all,

 

I'm new here, my name is Peter Engels from Germany.

 

Does anybody know anything about a Software Development Kit for the CC40 to create own memory modules containing BASIC programs and subroutines? Or has anybody any information on how these files are stored and linked inside the module?

 

Peter

[+acadiel]

On 10/8/2020 at 11:45 AM, pengels said:

Hi all,

 

I'm new here, my name is Peter Engels from Germany.

 

Does anybody know anything about a Software Development Kit for the CC40 to create own memory modules containing BASIC programs and subroutines? Or has anybody any information on how these files are stored and linked inside the module?

 

Peter

As far as we know, nothing like that was ever released.  The only development material released was the ALDS (E/A) cart and the documentation which Ksarul is about to scan in.  Steve Reid likely has some data on the TI-74 side (he'd be the only source, though).

 

I'm sure some of the data exists *somewhere* because of the special cartridges (drill bits, horse racing, etc) that was written for the CC-40, and the insurance cartridges which were written for the TI-74, but to date, nobody has found any.

 

[Willybo]

On 10/8/2020 at 9:45 AM, pengels said:

Hi all,

 

I'm new here, my name is Peter Engels from Germany.

 

Does anybody know anything about a Software Development Kit for the CC40 to create own memory modules containing BASIC programs and subroutines? Or has anybody any information on how these files are stored and linked inside the module?

 

Peter

Peter,

   I went through this last century when I made a RAM cartridge out of a Finance cartridge. I have not been able to find my lab books from back then yet. What I used was some disassembled code and chapter 1 of the Editor Assembler Reference Manual. Chapter 1 explains the format of the header for the cartridges. Take a look at that first. If I find my lab books I will give you the info I had there.

 

   Willy

[+Ksarul]

Note that there is also one of the CC-40 cartridge development devices up for sale on eBay right now. I've seen four or five of them in the wild over the years (I already have one, and I think it may even be the same software revision). I have to look to see what documentation came with mine (if any).

[+dhe]

How do you pack your cc40?

I have a case I made in the 90's - It started life as an old cassette tape box like:

   https://www.ebay.com/itm/12-Cassette-Tape-Storage-Box-Carrying-Case-Faux-Brown-Suede-Black-Vinyl-Trim/163906644422?hash=item262998e9c6:g:KHYAAOSw74RdofmQ  (Purchased at Radio Shack)

  I pulled the cassette racks out and custom cut three pieces of foam bottom, middle with the cut outs and top.

   I was able to fit in the cc40 and a power adapter.

 

 But - (everyone knows pelican cases $$$$) - I stopped by harbor freight and they have their own line of cases called Apache, and I was thinking I could make a pretty sweet cc40 carrying case out of one of those.. But now I'd need to fit - cc40, power adapter, and a Hexbus drive!

[pengels]

Thanks for your answers! It seems, that the ALDS cartridge can do the job using CARTINIT and CARTLOAD. I'll try that.

 

Peter

[Hugo Cervantes]

On 3/12/2020 at 2:44 PM, meinhardm said:

Hi at all,

thank you for your response and interest. Oh there are a lot of questions. I'll try to answer them.

@Vorticon:

>>> Will you be sharing your design and software?
 
That's no problem but first I have to clean the code, finish my user manual and the box is not quite perfect yet. The project is not ready. So please give me some time to finish everything.
 
>>> Perhaps a video demonstrating its function?
 
That's a very good idea. I guess I can do this very quick (I hope so).
 
>>>  is the full Hexbus spec implemented?
 
Unfortunately not. I have only implemented things that I need for my calculator.
For example you can "old", "save" and "verify" programs (a kind of binary file).
With "list" it writes a plain text file, the source code.
"delete" deletes a file, "run" starts a program directly from sd card.
Data files can be written "sequential" or "random" with "display" or "internal" mode from basic program or basic prompt.
But this data access is not tested fully. I have to write a test program...
Within the calc mode of the TI-74 you can use the "print" function to print the content of the display to the connected pc.
The device uses the sdFAT library to manage the SD access. So the SD card is formated with FAT32 and limited to 32GB. But this should be more than enough for the 7710 Bytes of RAM. The SD card can be mounted and accessed without any problems from a PC.
 
One example for things that are not implemented are master and slave modes (I haven't understood it yet and I don't know if the TI-74 supports this). My device is always slave.
 
 
@Jim:
 >>>  is your source radically different from the version I have...
 
First I had a short look to your code. But to be honest I didn't understand it.
My programming skills where (and still are) not the best.
So I decided to learn how the communication works and how to program a microcontroller.
I managed it, but now the capacity of the microprocessor is at the end. This problem I have to solve next.
So I'm not quite sure If you can use something from my code and yes the code is very different.

 

 

Meinhard

 

Hi Meinhard, I am extremely interested on replicating your nice and smart solution for the TI-74 Mass Storage Device. Did you have a chance to organize and share your project? Otherwise perhaps some basic wiring/circuit diagram and Arduino coding would be enough? Thanks in advance! 

[brain]

I can't speak to Meinhard's application, but HEXTIr has been tested against the cc-40 and the TI-74 by Peter Engels (or TIIF fame) and all tests have passed.  He uses it with his TI-74.

 

Jim

[Hugo Cervantes]

On 11/5/2020 at 10:14 PM, brain said:

I can't speak to Meinhard's application, but HEXTIr has been tested against the cc-40 and the TI-74 by Peter Engels (or TIIF fame) and all tests have passed.  He uses it with his TI-74.

 

Jim

Hey Jim, thanks for your update on this. I am almost ready to start the implementation of the Arduino-based interface for my TI-74.

 

However I have a problem: I have not been able to get the Arduino Data Logger Extension card, but I have the smaller, Micro SD Card Reader generic module. While looking at the documentation provided at your GitHub, I just found under HEXTIr/pcb/Fritzing/ the attached image, showing implementation with this SD card reader. Could I use it instead of the Data Logger following the connection diagram provided there, and if so, would I have to change and/or use a different *.ino program (under HEXTIr/src/) to flash the Arduino UNO from my Windows laptop?

 

Thanks in advance!

Hugo

[brain]

6 hours ago, Hugo Cervantes said:

Hey Jim, thanks for your update on this. I am almost ready to start the implementation of the Arduino-based interface for my TI-74.

 

However I have a problem: I have not been able to get the Arduino Data Logger Extension card, but I have the smaller, Micro SD Card Reader generic module. While looking at the documentation provided at your GitHub, I just found under HEXTIr/pcb/Fritzing/ the attached image, showing implementation with this SD card reader. Could I use it instead of the Data Logger following the connection diagram provided there, and if so, would I have to change and/or use a different *.ino program (under HEXTIr/src/) to flash the Arduino UNO from my Windows laptop?

 

Thanks in advance!

Hugo

Yes, though you also need to tie pin 8 and 9 to ground (since this uSD board does not bring out WP or Card Detect.)

 

Should work fine with the stock Arduino build.  Let me know if there are any issues, as I have the same little board here and I can wire it up and test it if needed.

 

Jim

[brain]

Just now, brain said:

Yes, though you also need to tie pin 8 and 9 to ground (since this uSD board does not bring out WP or Card Detect.)

 

Should work fine with the stock Arduino build.  Let me know if there are any issues, as I have the same little board here and I can wire it up and test it if needed.

 

Jim

Oh, clock functions might have an issue, since this has no clock.  So, keep that in mind.  If it does cause issues, we can turn the clock function off in config.h (comment CONFIG_CLOCK=1 out).

 

Edited November 11, 2020 by brain
addl info

[Hugo Cervantes]

On 11/10/2020 at 9:24 PM, brain said:

Oh, clock functions might have an issue, since this has no clock.  So, keep that in mind.  If it does cause issues, we can turn the clock function off in config.h (comment CONFIG_CLOCK=1 out).

 

Thanks again Jim. I succesfully implemented the diagram circuit (image above), including ground connection for pins 8 & 9 as you suggested. I was able as well to flash my Arduino UNO with the latest SRC.INO with no problem, so I tested it after connecting my TI-74 with the ribbon cable. Unfortunately I am not able yet to save/load programs. After typing SAVE "100.TEST" with a small program loaded, I am getting E0 I/O ERROR 39 "100". Any ideas/suggetions? 

 

During my troubleshooting, I tested my SD card reader with basic Arduino libraries and it works fine (read/write files), so that's not the issue. I tried as well to turn the clock function off (as you indicated on your comment above), however, I was not able to find CONFIG_CLOCK=1 in config.h. Should I look somwhere else? 

 

Thanks again for your comments and suggestions. I think I am pretty close to get this working! 
Hugo