mrvan

March 29

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.

March 29

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?

March 29

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.

March 26

On 2/29/2024 at 9:16 PM, hhos said:

I was intending to start a thread for creating a new design for a memory expansion, but I have thought more about it, and I think that would be premature. What I really want is a UNIXy operating system for the TI99/4A. An operating system would give us the system for allocating memory and other resources that I'm looking for.

I personally am not interested in the PEB SRAM based memory expansions. They have their merits. For instance they have far fewer timing requirements. The timing requirements they do have are almost nonexistent, seemingly solving themselves. Inside the console they might be the only solution I would go for in fact. But in the TI99 PEB they are not any faster than the DRAMs, unless you apply some of Nouspikel's "Controlling the wait-state generator" mods. And as Ksarul has pointed out, they are expensive. DRAMs are much cheaper and have greater capacities, especially when you get into memory modules. Solving the 4 wait state per access problem is far more problematic for them, but I do have an idea that doesn't have much to do with the aforementioned Nouspikel mods. The math works out so far, but the actual application almost always deviates from perfection.🙂

I've done some schematics for SAMS to expand to 16MB. Two add a possibility of using 48K-64K of physical memory address space. Two provide further address decoding to provide a DSR ROM. I'm uploading these files as an offering to anyone who wishes to continue to support a larger SuperAMS, or add DSR ROM to their own SAMS.

This thread is dedicated for the express purpose of creating an alternative to the zero wait state mod offered by Thierry Nouspikel's "Controlling the wait-state generator". While Thierry did a remarkable job coming up his solution, it doesn't have a chance of satisfying the specs for reading from a 4116 DRAM, not even close, in fact. I believe it is possible to do so without altering the 16/8 bus multiplexer(Thierry's "wait-state generator"), which I just call 16/8MUX. My current goal is to raise the 3 MHz clock rate that governs the 32K RAS/CAS logic to 9 MHz.

16M-SAMS-(0.1).zip 4.23 MB · 10 downloads

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!

March 25

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.

March 22

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.

March 21

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?

March 19

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?

March 17

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.

March 17

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!

March 16

@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

March 16

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.

March 15

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?

March 15

The ANSI codes do indeed work.

March 14

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.

March 13

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

March 13

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.

March 12

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.

March 11

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.

March 11

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_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

};

March 10

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.

March 9

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

March 9

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.

March 5

On 3/3/2024 at 7:56 PM, pixelpedant said:

TIIF2 can encode and decode CC-40 BASIC programs (and TI-74, and TI-95).

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.

March 3

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?

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by mrvan