Jump to content
IGNORED

The Compact Computer 40 (CC40)


Recommended Posts

True, but HEXTIr removes the need for PCIF.  I was wondering why the ELF95 piece was needed.  I finally had a chance to dload and found the answer in the install text file:

 

Quote

The EFL program is required to use HEXTIr or the PC-Interface together with the TI-95 PROCALC. EFL stands for Extern File Load and must be stored in the RAM of the TI-95 in the MEM area. In addition, a small routine written in assembler is required with which long file names can be entered. This routine is stored in a data file name +PC in the MEM area.

I didn't realize the TI-95 could not do old"..." like teh cc40 and ti-74

 

Link to comment
Share on other sites

True, but HEXTIr removes the need for PCIF.  I was wondering why the ELF95 piece was needed.  I finally had a chance to dload and found the answer in the install text file:

 

The EFL program is required to use HEXTIr or the PC-Interface together with the TI-95 PROCALC. EFL stands for Extern File Load and must be stored in the RAM of the TI-95 in the MEM area. In addition, a small routine written in assembler is required with which long file names can be entered. This routine is stored in a data file name +PC in the MEM area.

I didn't realize the TI-95 could not do old"..." like teh cc40 and ti-74

 

Correct.. in fact, with the original PC interface you had to type in and assembly language program on the calculator manually to be able to use it

 

Sent from my Pixel 6 Pro using Tapatalk

 

 

 

Link to comment
Share on other sites

23 hours ago, brain said:

Can you share any more details on what this EFL95 does and why it is needed?  Not disputing the need, I want to appreciate the effort, but I'm not sure what the issue was that was addressed...

 

Jim

 

The old bugs were in the loading routine on page 3-12 of the "PC Interface Guidebook", also called PCIF manual, and in the PCL program loaded with it. Peter had built workarounds into his TIIF2 program to deal with this. Thanks to EFL, he was now able to take these workarounds out again. HEXTIr works exactly according to the HEXBUS protocol and therefore it did not work together with the loading routine and the PCL program.

 

The loading routine had the problem that a data length was given with every CIO-I/O command. HEXTIr didn't like that with the CLOSE either. It is so that after the first CIO command, i.e. the OPEN, on the far right in register B there is no longer the data length but a different value. With the original PCIF.EXE it must have been a 4. This value is the exponent in the internal number representation of the TI-95 and so a 30 could be added to 64000 to get device 100, command code 3. Since the right digit before the next CIO has to be set to 0, I now divide so that 6.4 is in register B and add 0.003. Both TIIF2 and HEXTIr are satisfied with this.

 

PCL had to be corrected in 3 places:

The attempt to load a program with GET from HEXTIr led to the I/O error 3 "File not found". There is this line in exactly one place in the PCL:
  3 STB 23DE                  ;03  : Read command
After that I added this line and now loading programs works without any problems.
  0 STB 23D8              ;0000: data lenght for Read
The error is that these 12 bytes are put together in one place for the I/O command. First for the open including the file name. Then the same place for the read is adapted and reused. At the memory location 23D8 the length of the file name + 3 was left and HEXTIr rightly reports an error. On page B-10 of the TI-95 Programming Guide there is an extra note next to the Read Command: Data lenght - -Enter 0000 (because you are not sending any data to the device)

 

Then there was the most obvious problem with PUT: After each save with HEXTIr, the program was increased by 2 bytes. In the hex editor on the PC I can see that it is 0D 0A. They are appended to the end of the file. After loading, this end of file is the beginning of the program and they are displayed as the two commands BRK and +/-, where BRK internally has the value 0A and +/- has 0D. I was at a loss and thought, then I have to delete the two commands by hand after each load. Luckily Peter knew advice: "The only solution left to you: Eliminate the bug in PCL95: You MUST set the INTERNAL flag explicitly. In the data in the open command, this is sent first in a byte before the file name." The correction consists in changing the value 128 in the command "128 STB 23CD" to 136. This also sets the device attribute from Output Mode = 128 to iternal file = 8. But for the menu item TXT it still had to be 128, which made some changes necessary.

 

The next problem was in the TXT menu. PGM saves a TI-95 program as a text file. Unfortunately, the build in function LP (List Program) checks internally whether a printer is connected by attempting an OPEN without a file name against the device specified as the output device. At this point in time, this is HEXTIr with device number 100 and HEXTIr cannot do anything with an OPEN without a name. LP does not send CLOSE afterwards. The text file was created with HEXTIr but remained empty. A storage action immediately following, for example 32K cartridge to SD, then wrote in the TXT file instead of in the file name specified for it. The solution was then easier than expected. There are commented ROM listings for the TI-95 on this website: https://www.rskey.org/CMS/index.php/the-library/13 The LP function can be found in the file rom-cd1.95u. It is written in the normal TI-95 keycode and is quite short. This line triggers the annoying OPEN: 
2D7C SBA 128 test if a printer is connected 
I have now transferred the source code of the LP function to EFL without this line and now the output of a program as a TXT file works as desired. 

 

I have removed the DEV menu item that is no longer required for changing the device number. I plan to add DIR in its place so that the names of the programs stored on the SD card can be displayed step by step. Load and delete should also be possible there.

  • Like 2
Link to comment
Share on other sites

8 hours ago, KlausO said:

The loading routine had the problem that a data length was given with every CIO-I/O command. HEXTIr didn't like that with the CLOSE either. It is so that after the first CIO command, i.e. the OPEN, on the far right in register B there is no longer the data length but a different value. With the original PCIF.EXE it must have been a 4. This value is the exponent in the internal number representation of the TI-95 and so a 30 could be added to 64000 to get device 100, command code 3. Since the right digit before the next CIO has to be set to 0, I now divide so that 6.4 is in register B and add 0.003. Both TIIF2 and HEXTIr are satisfied with this.

If HEXTIr should deal with this, I am open to making the changes necessary, but your description makes it sound it was a bug in the original code.  Let me know, though

 

Quote

The next problem was in the TXT menu. PGM saves a TI-95 program as a text file. Unfortunately, the build in function LP (List Program) checks internally whether a printer is connected by attempting an OPEN without a file name against the device specified as the output device. At this point in time, this is HEXTIr with device number 100 and HEXTIr cannot do anything with an OPEN without a name. LP does not send CLOSE afterwards. The text file was created with HEXTIr but remained empty. A storage action immediately following, for example 32K cartridge to SD, then wrote in the TXT file instead of in the file name specified for it. The solution was then easier than expected. There are commented ROM listings for the TI-95 on this website: https://www.rskey.org/CMS/index.php/the-library/13 The LP function can be found in the file rom-cd1.95u. It is written in the normal TI-95 keycode and is quite short. This line triggers the annoying OPEN: 
2D7C SBA 128 test if a printer is connected 
I have now transferred the source code of the LP function to EFL without this line and now the output of a program as a TXT file works as desired. 

While I feel (as you appear to as well) HEXTIr is rightly reporting an error, I can work to handle this issue if folks feel this is the right thing to do.

 

Jim

Link to comment
Share on other sites

In my opinion there is no need to change HEXTIr, I just wanted to explain why there is now EFL and why you can't just use the old PCL. EFL corrects the bugs in the original code and will have more features than PCL. So 32k modules can now also be saved and loaded with it. The original PCL only knew 8k modules.
 

  • Like 1
Link to comment
Share on other sites

Thanks for the note and the work you did.  It's very much appreciated and that you also support HEXTIr is most gratifying.

 

And yes, I share your opinion on needed changes, but I've had to implement "bug for bug compatible" pieces of projects before, and while I sometimes struggle with doing that, it's a valid use case at times.

 

Jim

Link to comment
Share on other sites

  • 2 months later...

Regarding the CC-40, am I right to assume it lacks the data that the CC40+ and TI-74 contains which allows them to load programmes from cassette? 

 

Device 1 is not recognised by the CC-40. I dug out my old hexbus to dockbus adapter I used to connect the PCIF to the CC40 many years ago just out of interest to see if the CC-40 would recognise the TI-74 cassette interface.

Edited by mutantcamel1979
Link to comment
Share on other sites

13 hours ago, mutantcamel1979 said:

Regarding the CC-40, am I right to assume it lacks the data that the CC40+ and TI-74 contains which allows them to load programmes from cassette? 

 

Device 1 is not recognised by the CC-40. I dug out my old hexbus to dockbus adapter I used to connect the PCIF to the CC40 many years ago just out of interest to see if the CC-40 would recognise the TI-74 cassette interface.

Yes, the CC40 lacks the necessary circuitry to load data from tape, an idiotic design choice by TI if you ask me and likely the main reason the CC40 never took off. 

That said, we now have a reliable SD-based solution but unfortunately there is still zero new program development for that little but quite capable machine...

Link to comment
Share on other sites

There is Haunted House which I helped to adapt.

 

Surprised no one else has thought about text adventure games for the TI Handhelds.

 

I really want to see if I can get my PCIF working on a modern laptop via USB. Failing that I might buy one of those SD Hexbus Drives.

 

I think I typed Haunted House on a TI74 long before I had a PCIF and saved it onto cassette. Sure it took over 20 minutes to save/load!

 

Maybe I am a purist and prefer to use the original tech as much as possible!

 

Regards

Phil

Edited by mutantcamel1979
  • Like 2
Link to comment
Share on other sites

There is Haunted House which I helped to adapt.
 
Surprised no one else has thought about text adventure games for the TI Handhelds.
 
I really want to see if I can get my PCIF working on a modern laptop via USB. Failing that I might buy one of those SD Hexbus Drives.
 
I think I typed Haunted House on a TI74 long before I had a PCIF and saved it onto cassette. Sure it took over 20 minutes to save/load!
 
Maybe I am a purist and prefer to use the original tech as much as possible!
 
Regards
Phil
Have you seen the new Arduino based cassette interface for the 74 and 95…?

9e86752020ea4adafe643f98b03083f6.jpg

Sent from my Pixel 6 Pro using Tapatalk

Link to comment
Share on other sites

27 minutes ago, mutantcamel1979 said:

There is Haunted House which I helped to adapt.

 

Surprised no one else has thought about text adventure games for the TI Handhelds.

 

I really want to see if I can get my PCIF working on a modern laptop via USB. Failing that I might buy one of those SD Hexbus Drives.

 

I think I typed Haunted House on a TI74 long before I had a PCIF and saved it onto cassette. Sure it took over 20 minutes to save/load!

 

Maybe I am a purist and prefer to use the original tech as much as possible!

 

Regards

Phil

Hey Phil! Yes, it was fun working on the adaptation of Haunted House :)

  • Like 1
Link to comment
Share on other sites

On 2/20/2022 at 7:17 AM, mutantcamel1979 said:

Thanks - fingers crossed it works on the TI74! Would save hours trying to type programs directly onto it!

works fine on TI74 and I'd assume the same on a CC40 

 

save "1.test" saves to the device (you have to use pc terminal and  capture to capture the data in ascii not HEX, this is made easier in linux with scripts in his github with windows it requires a program called realterm) 

old "1.test" loaded from the device (send the same file back)

 

Greg

Edited by arcadeshopper
  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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