Jump to content
sparkdrummer

The Compact Computer 40 (CC40)

Recommended Posts

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

  • Like 1

Share this post


Link to post
Share on other sites

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. 

584CEF1B-B62A-4A44-86DE-B169530A93B5.jpeg

97CBC3D0-5902-4467-896E-D49B472C6708.jpeg

1C58A266-2026-426B-B581-703D9B432830.jpeg

8A5E874E-67D3-4ED1-A262-4C06148BF289.jpeg

613222EB-9A76-4DCB-80DC-7833C601A615.jpeg

ADA9A9A7-692D-4A79-BE04-4C68D89CD066.jpeg

FF5263D0-CD02-4342-983F-9967716CFFC0.jpeg

0850FED2-491F-4A5A-8FB2-BC31D14C41CB.jpeg

FB71A217-0F88-4950-9F76-49F65CA74F4C.jpeg

8B01E937-A0DB-4BC7-AA1E-59F6F858D707.jpeg

65F77191-A5A0-443F-A0C5-956B77A8F4AF.jpeg

A4F1518F-F54C-4D86-8D53-B5E30957DB66.jpeg

C3BDAFE0-6191-4DCA-8787-55C04AC4458F.jpeg

  • Like 10

Share this post


Link to post
Share on other sites

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

  • Like 5

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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 by brain
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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

  • Like 2

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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!

  • Like 2

Share this post


Link to post
Share on other sites

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

 

Peter

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...