The Compact Computer 40 (CC40)

[brain]

From Discord:

 

Quote

m5dk2nToday at 1:51 AM

The reason is that the whole file content is returned with the first INPUT. This is the desired behaviour to load a file with the OLD command but not for to INPUT a single 'record'. The hex_drv_read has to be extended/modified that both OLD/INPUT are working. We have to find out how much data to send for the actual read. Maybe @sreid1960 has an idea how to do it.(edited)

m5dk2nToday at 9:42 AM

A possible solution could be to add a header with the data length received in the hex_drv_write and prepend it to the data written on disk. So that we can send back exactly that amount of data when hex_drv_read is called. We would do this only for LUN!=0.

NEW

sreid1960Today at 5:00 PM

For programs such as given in the issue, where you are writing out numbers to a normal DISPLAY type file, ASCII data is written... a 1 is written as 20h 31h 20h (an ASCII 1 with a space character before and after). To write true numbers to a file, we had what is known as INTERNAL file format which wrote the data in native form to the file. When read back, the data could be read in native form as well. The Arduino side of the sketch has some internal format implementation, but its definitely not 100%. I can get the first number from a file in this format, but the EOF() test in my test program says I'm at EOF after the first read. The logic analyzer confirms that all the data was returned in the first read. If my memory is correct, there is a way using the VARIABLE option with open to specify the amount of data to read on each operation...

[5:00 PM]

however, different value numbers may take different amount of space.

JIm

[+Vorticon]

OK thanks for the update. I might be able to get it to work for numerical values using INTERNAL and a record length of 1. Let me play with this a bit more and see... As for DISPLAY type, there is also a workaround if the data is formatted with pre-defined separators and read back as a single string which can subsequently be sliced into individual values by the program with the understanding that the file could not exceed 255 characters. Ugly, but feasible...

[+Vorticon]

So I can get file ops to work with numerical values using the INTERNAL file mode and the VARIABLE x option, with x being the maximum length of the numerical values expected, including the decimal point (if dealing with floats).

For example, if I write a file with numbers for 1 to 10, then to read them I have to specify OPEN #1, "100.TEST",INPUT,INTERNAL,VARIABLE 2

Any value greater than 2 for this data set will yield a data error when read via INPUT #.

Same goes with string data, except here we will omit the INTERNAL specification.

Obviously not an ideal solution if you have unpredictable data element lengths, but should work in most common situations otherwise.

[brain]

If you can redo your app as a "test", I can put it in a tests directory, and we can use it to further develop the code.  LOAD/SAVE was the most important, but we can add additional functionality (I jsut need to understand how it should work).

 

An ideal test would be to open a file, clean it out, store a value or two there, close it, open it again, read the file data, and if the data is as expected, note success.  If not, not what was read versus what was expected.  I can then keep running it over and over until I can get the code to work correctly.

 

Jim

[+Vorticon]

Here you go:

 

10 PRINT "NUMERIC DATA TEST":PAUSE
20 PRINT "WRITING DATA":PAUSE 2
30 OPEN #1,"100.NUMTEST",OUTPUT,INTERNAL
35 FOR I=1 TO 10:PRINT #1,I:NEXT I:CLOSE #1
40 PRINT "READING DATA":PAUSE 2
50 OPEN #1,"100.NUMTEST",INPUT,INTERNAL
60 FOR I=1 TO 10:INPUT #1,N
70 IF N<>I THEN PRINT "READ ERROR!":PAUSE:CLOSE #1:STOP
80 NEXT I:CLOSE #1
90 PRINT "PASSED NUMERIC TEST!":PAUSE 2
100 PRINT "STRING DATA TEST":PAUSE
110 PRINT "WRITING DATA":PAUSE 2
120 OPEN #1,"100.STRTEST",OUTPUT
130 FOR V=65 TO 75:PRINT #1,CHR$(V):NEXT V:CLOSE #1
140 PRINT "READING DATA":PAUSE 2
150 OPEN #1,"100.STRTEST",INPUT
160 FOR I=1 TO 10:INPUT #1,S$
170 IF S$<>CHR$(64+I) THEN PRINT "READ ERROR!":PAUSE:CLOSE #1:STOP
180 NEXT I:CLOSE #1
190 PRINT "PASSED STRING TEST!":PAUSE 2
200 PRINT "FILE OPS SUCCESS!":PAUSE

 

[brain]

I hate to ask, but is there any way I can get the stored copy of this program from your SD card? ?

 

Jim

[+Vorticon]

Sure.

FOPSTEST

[brain]

Thanks!

[+dhe]

Hey Vorticon,

   Arcadeshopper is sending me one of these devices.

   I own a copy of: Data and File Management for the TI-99/4A by John P. Grillo

   I think file I/O is pretty much a new nugget to mine on the CC-40/TI-74 (though there might be some info, in old TI Calculator Newsletters, related to the Mechatronics Drive). Do you have any feel for how close the file I/O commands on the CC-40 to a 99/4a in BASIC?

 

[+Vorticon]

1 hour ago, dhe said:

Hey Vorticon,

   Arcadeshopper is sending me one of these devices.

   I own a copy of: Data and File Management for the TI-99/4A by John P. Grillo

   I think file I/O is pretty much a new nugget to mine on the CC-40/TI-74 (though there might be some info, in old TI Calculator Newsletters, related to the Mechatronics Drive). Do you have any feel for how close the file I/O commands on the CC-40 to a 99/4a in BASIC?

 

Practically identical with the exception of placing a colon instead of a comma before the list of parameters or variables. For example:

 

CC40: OPEN #1, "100.test", OUTPUT

TI 99/4A: OPEN #1: "DSK1.test", OUTPUT

 

CC40: PRINT #1, I

TI 99/4A: PRINT #1: I

 

So unless the program is using direct access to files via assembly language routines, it should be trivial to convert the file I/O from the TI to the CC40.

[+dhe]

It's a blackbox, it's a ardunio, it's a hexbus drive!

 

Received my hexbus drive yesterday from Arcadeshopper.

 

A couple of questions, before I get started:

1) Does the hump on the hexbux cable go towards, or away from the board?

2) Does this device need a 9V or 12V power supply?

3) Which needs to be on first, the drive or the CC-40?

 

Thanks Arcadeshopper!

 

 

[+arcadeshopper]

It's a blackbox, it's a ardunio, it's a hexbus drive!
 
Received my hexbus drive yesterday from Arcadeshopper.
 
A couple of questions, before I get started:
1) Does the hump on the hexbux cable go towards, or away from the board?
2) Does this device need a 9V or 12V power supply?
3) Which needs to be on first, the drive or the CC-40?
 
Thanks Arcadeshopper!
 
 

Up away from the board
I use the USB cable to power it
Drive on first

Sent from my LM-V600 using Tapatalk

[wolhess]

On 8/7/2020 at 2:27 PM, dhe said:

It's a blackbox, it's a ardunio, it's a hexbus drive!

 

Received my hexbus drive yesterday from Arcadeshopper

Hi Greg, @arcadeshopper 

if you have more boxes to sell, can I use this box to connect it to my TI-74? 
I‘m searching a storing solution for my little TI-74‘s.

[+arcadeshopper]

It should work just need a cable adapter ymmv

Sent from my LM-V600 using Tapatalk

[brain]

Manfred pushed some updates into the sreid_mods branch to hopefully handle inputting data from HEXTir.  I'd appreciate folks trying it out.

 

Jim

 

[brain]

On 8/18/2020 at 1:12 AM, brain said:

Manfred pushed some updates into the sreid_mods branch to hopefully handle inputting data from HEXTir.  I'd appreciate folks trying it out.

 

Jim

 

Looks like newest tip of sreid_mods branch passes the FOPSTEST listed above, FWIW.

 

Jim

 

[+Vorticon]

On 8/18/2020 at 1:12 AM, brain said:

Manfred pushed some updates into the sreid_mods branch to hopefully handle inputting data from HEXTir.  I'd appreciate folks trying it out.

 

Jim

 

Excellent news! I'll test it out. With that issue out of the way, I believe the storage problem for the CC40 is now resolved. 

I am very grateful for the work by all involved. The lack of storage for the CC40 has been a vexing situation for decades...

Time to start thinking about new programs for it  

[+dhe]

Vorticon,
If you can let me know the upgrade procedure, that would be most helpful.
Thanks,
Dan

[brain]

6 hours ago, Vorticon said:

Excellent news! I'll test it out. With that issue out of the way, I believe the storage problem for the CC40 is now resolved. 

I am very grateful for the work by all involved. The lack of storage for the CC40 has been a vexing situation for decades...

Time to start thinking about new programs for it  

Evidently, there's "random" files to implement, and a few odds and ends like that.

 

Right now, I am trying to merge the various branches into a common chunk of code that compiles to the same thing in both Arduino and native builds, and figure out how to do releases in github.

 

At present, I have the tip of the libmerge branch using common fat/sd libraries and clock libraries for both builds.  This should help folks who have the arduino build environment but are using the ds1307-based SD card shield, since the older Arduino build assumed a ds3231 RTC which is a bit different.

 

Once I can convert the rs232 routines over to native, I will be ready to merge the code back into the master and folks can just grab it from there (or a release).

 

Jim

[+Vorticon]

I downloaded the latest sreid version from Github, and while it compiles fine on the arduino, I get an IO Error 255 for any file ops on the CC40...

[brain]

1 hour ago, Vorticon said:

I downloaded the latest sreid version from Github, and while it compiles fine on the arduino, I get an IO Error 255 for any file ops on the CC40...

DId you compile and dload from the Arduino IDE?  I'll check that just in case (hard to test all the combos all the time).

 

jim

[+Vorticon]

15 minutes ago, brain said:

DId you compile and dload from the Arduino IDE?  I'll check that just in case (hard to test all the combos all the time).

 

jim

Yup

[brain]

The arduino IDE build all the way back to reid's initial commit no longer works for me (it fails on the SD init in an Arduino Uno, but works fine on the Arduino Nano that reid used to develop), but the native build runs fine.  At this point, since we're going to get rid of the SD library, I will jsut finish fixing the libmerge branch and then try it in the various options (using the IDE).  If it works, I'll have you try that, since I'm more confident of that code.

 

Jim

 

[brain]

OK, I think I have removed the last of the Arduino specific code fragments from the IDE build in branch libmerge.  I tested with my Arduino UNO in native and IDE and it worked fine.  Vorticon, if you could try it, I'd appreciate hearing if it works. 

 

Jim

[+Vorticon]

7 hours ago, brain said:

OK, I think I have removed the last of the Arduino specific code fragments from the IDE build in branch libmerge.  I tested with my Arduino UNO in native and IDE and it worked fine.  Vorticon, if you could try it, I'd appreciate hearing if it works. 

 

Jim

Success! Works perfectly and passes the FOPSTEST. Nicely done