mrvan

My CC-40 has 18 KB RAM. If I install the memory cartridge (Retro Innovations - CC-40 512 MB memory board), will the 32 KB RAM visible at any given time be able to be used as program space, where I have 18 KB + 32 KB = 48 KB? The two address ranges are contiguous.

Does the CC-40 BASIC create strings with enough storage just to contain it's value or is it allocating perhaps the maximum possible length? Is there a way to determine how much memory is being used by a running program?

Yesterday appeared to be a disaster. My two puppy miniature schnauzers got into the living room where my CC-40, HEXTIr and RPI were setup and running. It seems they ran around the table and caught the power cord and all but the CC-40 fell to the floor. I found it later in the day. Sadly the HEXTIr failed over and over with I/O errors after this incident. I could see the riser pins seemed a bit bent as were the HEXBUS connector pins. Ooff. I spent the morning removing the riser pins and replaced all with wires between the two boards. It worked, thankfully. I've been considering moving the HEXTIr into a HEXBUS modem enclosure, so perhaps this was a "helpful" accident as I would probably have never gotten to such a project. I've been writing the hangman game with ANSI graphics via the HEXTIr and it's working now with just a few more improvements to go. The program file is 2970 bytes now. My CC-40 has 18 KB RAM so no big deal, but this is also just hangman.

I definitely understand your dream for the UNIXy OS and all it brings. I also have a strong preference for Unix type operating systems, the C libraries, and stream-based file concepts. These are all quite possible with even 32 KB RAM and a TIPI. Prefer larger screen real estate (80 columns), then F18A gets you there. I'm sure a lot can be done with managing memory in clever ways but the paging has impacts to performance. Multi-tasking as well. And it's still a 1976 era 16 bit CPU with a 16 bit (well 15) address bus. I'm not trying to dissuade you. I like you ideas. I've also pressed the boundaries on the software side creating my own Unix like variant. I enjoy the challenges and figuring out the best compromises that live within the current TI-99 state of the art hardware and ecosystem. My wife does puzzles and Mahjong and I do this. I look forward to where you go! I'd be happy to get some extra performance if you can make it happen!

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. cc40disp.mov

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.

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?

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?

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

Excellent. This is good info! Thank you!

@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

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.

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

The ANSI codes do indeed work. cc40ansi.mov

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. cc40_display_demo.mov

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"?

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

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.

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

I've started taking a stab at connecting the HEXTIr via serial port to a RPI, but not getting very far. I always receive 830 bytes from the below programs, where every byte is hex 00, regardless of any baud rate, parity or stop bit permutation. It's possible I'm missing the syntax for the serial port open on line 100 to set baud rate, etc. but the only syntax I found was for the TI-99 and the CC-40 seems to require something different and I've not found any documentation or examples. If @brain or others could share their method for checking out the serial port that would be helpful and I'd gladly plagiarize. The BASIC program is 100 open #1,"20", display, output 105 for i=1 to 50 110 print "hello world!" 115 next i 120 close #1 The C program I used on the RPI, permuting through the baud, parity and stop bits, is // C library headers #include <stdio.h> #include <string.h> // Linux headers #include <fcntl.h> // Contains file controls like O_RDWR #include <errno.h> // Error integer and strerror() function #include <termios.h> // Contains POSIX terminal control definitions #include <unistd.h> // write(), read(), close() int main() { // Open the serial port. Change device path as needed (currently set to an standard FTDI USB-UART cable type device) int serial_port = open("/dev/ttyUSB0", O_RDWR); // Create new termios struct, we call it 'tty' for convention struct termios tty; // Read in existing settings, and handle any error if(tcgetattr(serial_port, &tty) != 0) { printf("Error %i from tcgetattr: %s\n", errno, strerror(errno)); return 1; } tty.c_cflag &= ~PARENB; // Clear parity bit, disabling parity (most common) tty.c_cflag &= ~CSTOPB; // Clear stop field, only one stop bit used in communication (most common) tty.c_cflag &= ~CSIZE; // Clear all bits that set the data size tty.c_cflag |= CS8; // 8 bits per byte (most common) tty.c_cflag &= ~CRTSCTS; // Disable RTS/CTS hardware flow control (most common) tty.c_cflag |= CREAD | CLOCAL; // Turn on READ & ignore ctrl lines (CLOCAL = 1) tty.c_lflag &= ~ICANON; tty.c_lflag &= ~ECHO; // Disable echo tty.c_lflag &= ~ECHOE; // Disable erasure tty.c_lflag &= ~ECHONL; // Disable new-line echo tty.c_lflag &= ~ISIG; // Disable interpretation of INTR, QUIT and SUSP tty.c_iflag &= ~(IXON | IXOFF | IXANY); // Turn off s/w flow ctrl tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL); // Disable any special handling of received bytes tty.c_oflag &= ~OPOST; // Prevent special interpretation of output bytes (e.g. newline chars) tty.c_oflag &= ~ONLCR; // Prevent conversion of newline to carriage return/line feed // tty.c_oflag &= ~OXTABS; // Prevent conversion of tabs to spaces (NOT PRESENT ON LINUX) // tty.c_oflag &= ~ONOEOT; // Prevent removal of C-d chars (0x004) in output (NOT PRESENT ON LINUX) tty.c_cc[VTIME] = 10; // Wait for up to 1s (10 deciseconds), returning as soon as any data is received. tty.c_cc[VMIN] = 0; // Set in/out baud rate to be 9600 cfsetispeed(&tty, B9600); cfsetospeed(&tty, B9600); // Save tty settings, also checking for error if (tcsetattr(serial_port, TCSANOW, &tty) != 0) { printf("Error %i from tcsetattr: %s\n", errno, strerror(errno)); return 1; } // Write to serial port unsigned char msg[] = { 'H', 'e', 'l', 'l', 'o', '\r' }; write(serial_port, msg, sizeof(msg)); // Allocate memory for read buffer, set size according to your needs char read_buf [256]; // Normally you wouldn't do this memset() call, but since we will just receive // ASCII data for this example, we'll set everything to 0 so we can // call printf() easily. memset(&read_buf, '\0', sizeof(read_buf)); // Read bytes. The behaviour of read() (e.g. does it block?, // how long does it block for?) depends on the configuration // settings above, specifically VMIN and VTIME int num_bytes; int i; while (1) { num_bytes = read(serial_port, &read_buf, sizeof(read_buf)); // n is the number of bytes read. n may be 0 if no bytes were received, and can also be -1 to signal an error. if (num_bytes < 0) { printf("Error reading: %s", strerror(errno)); return 1; } // Here we assume we received ASCII data, but you might be sending raw bytes (in that case, don't try and // print it to the screen like this!) // printf("Read %i bytes. Received message: %s", num_bytes, read_buf); if (num_bytes) { fprintf (stdout, "%d: ", num_bytes); for (i = 0; i < num_bytes; i++) { fprintf (stdout, "%d ", read_buf[i]); } fputs ("\n", stdout); fflush (stdout); } } close(serial_port); return 0; // success };

Has the idea of an external display for the CC-40 been realized, other than the small number TI produced? I'm all in for one. I was thinking about the hexbus device's RS232 port and the possibility of connecting it via RS232-USB dongle to a Raspberry PI with connected monitor. I'm sure this wouldn't break any speed records but 9600 baud, assuming that's the max for this device, isn't terrible, at least for text. Many of us used VT terminals back in the day and many were operating at that speed, and also had ability to create text effects such as bold, reverse video and colors. Although this wouldn't be deeply integrated (ROM-based) without a lot of work, it'd be pretty easy to write a handful of BASIC methods to at least prove the idea. Other than the speed limitation, it also wouldn't be terribly difficult to emulate more advanced features with a Linux application with a linked graphics package such as SDL, and have that app connect via the USB/serial. I imagine with a bit more ingenuity an external keyboard could also be attached via the RPI.

Although there's definitely some cleanup to do in the pre-processor tool chain, I was able to get 'r up, write a few simple basic programs, convert to CC40 and TI99 programs, transfer them to both the CC-40 and the TI-99, and execute successfully. The syntax for the language extensions mimics QuickBasic a fair amount. The TI99 tool chain steps are: text enhanced basic -> lang ext preprocessor -> XDT -> final XB program and basic text representation -> transfer to TI99 disk image -> run MAME with XB GEM The CC40 tool chain steps are: text enhanced basic -> lang ext preprocessor -> XDT -> final basic text representation -> convert with TIIF2 -> copy to SD card -> load SD card into HEX-TI-r The TIIF2 tool actually does a pretty good job generating the program files. Small quirks (file must be named *.b40), access control violation dialogs popping up, and can't quit the program. The goodness of the over program though is high so I feel less need to spin my own, particularly now that I realize I can develop for both the CC-40 and TI-99 at the same time and test on the TI99. hello.bas: func main (argc, argv$()) print "hello world!" return 0 funcend test.bas: func main (argc, argv$()) for i = 0 to 10 print i; next i print i = 0 do while i <= 10 print i; i = i + 1 loop print i = 0 do print i; i = i + 1 loop while i <= 10 print for i = 0 to 10 select i case 0 print "The"; case 1 print "quick"; case 2 print "brown"; case 3 print "fox"; case 4 print "jumps"; case 5 print "over"; case 6 print "the"; case 7 print "lazy"; case 8 print "dog"; case 9 print "."; case else end select print " "; next i print return 0 funcend

The HEX-TI-r HEXBUS disk drive arrived early week from @arcadeshopper. I set it up this morning and was able to save and retrieve a program on the device. It is a game changer for the CC-40 allowing straight forward transfer of programs and files via an SD Card. Now, to resurrect my TI XB tool chain. It should work well for the CC-40. I've not touched it since I moved from XB to GCC for the TI-99.

TIIF2 does the encoding and decoding correctly. I was able to decode one of the CC-40 programs that came on an SD card. This is more than enough to get me started, so thank you very much! TIIF2 is bit clunky on my laptop, as it's a DOS-type program running in Windows, and in my case within a Windows emulator on a Mac. I would very much like to see the TIIF2 source code that does the encode/decode operations and generate a portable, probably C, program to do the encode/decode. The interfacing to my CC-40 will be via the Hexbus drive with it's SD card. The program files are written directly in the SD card's root directory. Also I anticipate pushing the program into MAME once support is present for hexbus devices, which I presume is needed for even the simplest of external interfaces including RS232. So I'm still looking for a more direct tool, source for one, or even just something that describes the encoding specification if I need to write the code myself.

I want to write CC-40 BASIC software (as text) on my Mac and transfer it to the CC-40 for execution. A new hexbus storage device is on the way, so I'm looking into the how. It'd be great if text-based BASIC could simply be read in, such as with the OPEN command but I don't expect it. For TI 99 XB, there's a tool, xbas99.py, which is part of the xdt99 package. That tool provides encoding/decoding to/from text/XB format. If nothing else exists, this tool could be a starting point, it maybe even quite close to what is needed. I presume has a differing set of tokens, possibly format, etc. Any knowledge of such a tool for the CC-40?