brain

I question your statement that there are not 32K options at economical prices, but there's a few projects online to build your own: https://github.com/dikdom/VIC-20-RAM-ROM-Expansion I know there's a design that fits completely in the space between the edge connector and the edge of the case, but I can't find the list. I know I also designed VICMem for some folks at ECCC/VCF-MS a few years back, and cna put the project files up.

IN a word, no. You *might* be able to create a specialized serial connection to replace it, but it would require probably FPGAs on both sides, and a VERY fast clock speed. The idea would be to marshall all of the PEB signals at the TI very quickly and then shift them out via a serial line to the same kind of thing on the PEB side, which would then unmarshall them and present them to the PEB as before. Then, close to the end of the cycle, do the reverse, taking into account that certain lines need to be handled special because they are IO lines (address never needs to be sent back, but data does on a read cycle, and the CRU stuff needs to be handled special as well). Possible, yes. practical, less so. A better bet would be to shrink all of the PEB functionality and move it to the TI, like TIPI and other solutions do. Jim

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.

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

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

Is there any additional data on this? Unless the design itself is marginal, I would not think a 3MHz design would need impedence matched traces. @Phoenix, I think the newest EAGLE (post 7.X) does them. I don't know for sure, since I keep a hold of my purchased 7.X version of EAGLE instead of the new subscription version.

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

Cool!

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

Peter says: "RWRAM.B40/74/C40/74 allows to read/write/verify RAM/ROM 8/32k images. ROM is clearly r/o." They would be in the same dir as the other BASIC programs I linked to.

I'll try to have Peter write a little app to show how to use 255 (which is not set in stone, as we found a use case that makes 255 potentially better to send drive commands, so we might move it to 254). Jim

I don't think any devices in cc40 have a prefix, all are numbers (100 -109 or so for drives, etc.). 230 is just an arbitrary number chosen for the RTC function, but it's not gospel, if there's a better number to use. But, yes, the idea is to open, and any read will deliver the various parts of the date and time. An open to write will set the date/time. Given the nature as a hobby effort at present, I'll admit documentation is not a primary focus, but I agree there's value. It'd be grand if there were one or more folks interested in helping with that effort, while we continue to add new features to the source Jim

Right now, to keep the main branch in a nice working state, I've been checking the INTERNAL and such updates into the pengels_mods branch (which is working, and you can try it if desired. I think Peter has all the file modes working quite correctly and he even implemented a special LUN [255] to allow folks to dump and read back binary images - which won't work with normal INTERNAL mode, as I understand). Peter put Basic listings of all the apps in yesterday, so feel free to grab: https://github.com/go4retro/HEXTIr/blob/pengels_mods/BASIC/CC40/CLOCK.B40

There's a clock.pgm and setclock.pgm apps int he BASIC folder that can be used to read and set the clock. Jim

Most of the SD card shields have a DS1307 RTC on board. If yours does, pop in a battery and use. jim

No issue, but the code didn't previously support RELATIVE files, and we switched DISPLAY files stored on disk to use CRLF has the line delimiter. It makes it easier to edit with PC tools or load in files from other platforms. Jim

Peter Engels has been working to enable all the DISPLAY and RELATIVE modes. His work is in the pengels_mods branch, if folks want to try it.

@Ksarul Is there a way to describe how the banking is done on these other devices? @wierd_w I like the idea, but I would consider making it more bulletproof. Since a writeable GRAM device is possible using today's tech, it seems prudent to make the "write" more compatible with such GRAM devices. Maybe use the 1fff location as the address to "write", or something like that. I'd love to prototype a GROM with this capability for test. Jim

In the code you quoted of mine, I was asking if that line of BASIC was the proper way to delimit fields on the TI (The presence of the colon after the channel number marks it as TI BASIC, as cc40 requires a comma there. A subsequent note indicated I had the syntax wrong, as it is print #2:i : i^2, but when I tried that on the cc40, it failed to run. cc40 will not accept colons in between variables, so I could not emulate it. Which is OK. I thought, perhaps, when I thought the delimiter was " : " (with quotes), that we should use the " : " in our code as opposed to the "," we were using, but it appears in both cc40 and TI BASIC, separating fields in a single print statement is done by manually adding in commas between the data elements. That was what we had in our code when I first asked the question here, which is why I said in my last note that it was where we started. Jim

You must understand I am talking about actions performed on the cc40, not the TI99/4A. My point was that we have been able to denote the "fields" in the print statement on the cc40. On the cc40, we were doing: print #2, i,i^2 (and so on) but, in DISPLAY mode, what is sent to the drive is: 1 1 (and so on). In other words, a column-aligned set of fields, but no way to see if the original was 1 field or 2. TO ensure the data was interpreted as fields on the cc40 drive, we modified the output to: print #2,i;",";i^2;","; ... and so on. Then, the data comes through to the drive with the commas in the stream, analogous to your previous note #36 about putting the commas in manually. Currently, we are storing the commas in the file itself. When the input #2 is executed, and we send the data with the commas in the data stream, the INPUT cc40 function parses the data into comma separated values and places them in their respective variables, assuming the correct type and no eof and such. And, it is SQR() on cc40 as well. I was copying the program freehand and added the 'T' Jim

OK, we were doing this (add in the commas) before, to create the field delimiter, in DISPLAY mode, but I was concerned it was wrong. Jim

OK, for internal storage, I take away from this that the next input statement will advance the record number. If it's possible for you to send the actual raw file it created, that's appreciated as well. Jim

I can understand 1 record per LINPUT. Makes sense to me. It would be nice to know if you don't input all of a record but then move to a new line number, if the counter advances to the next record or not. Jim

On the cc40/ti74, the same thing occurs. If you do print #2,a,b,c,d,e$ you will get the variables separated by spaces (aligned in columns if one uses the commas instead of semicolons) but no commas in the resulting data. On the cc40, data is sent at the byte level, with minimal buffering. Here is an output of the logs for the print#2, i;"'";i^2... statement Write File 0000| 20 31 20 2c 20 31 20 2c 20 31 20 2c 20 2e 38 34 | 1 , 1 , 1 , .84| 0010| 31 34 37 30 39 38 34 38 20 2c 22 20 20 20 20 20 |14709848 ," | 0020| 20 20 42 52 41 49 4e 2c 4a 49 4d 22 | BRAIN,JIM" | From an IO perspective, the data above is prepended by a 9 byte PAB block, that signifies the record boundary, but we are also using the comma to denote a boundary, to approximate the " : " of the 99/4a Jim

Sadly, while cc40 BASIC will tokenize: 150 print#2,i : i^2 for example, it will not run. And, when doing an input, cc40 basic expects the incoming data stream to the computer to be field separated by commas. Thus, while we can potentially store files in the same way, the same approach in BASIC will not work. How does one read multiple records in 1 line on the 99/4A? On the cc40, it's input #2, a$,b$,c$ and so on Jim