brain

Yeah, I saw some references to XMODEM, and it makes sense that it developed from there. Thanks for the insight. I should have guessed there was a container format for TI files, but never really thought about it. Handling directories in the TIPI way might be tough, given the precedent set by the TI74, but that's not a TIFILES issue per se. Jim

Hmm, might need to rethink how we do things, then. We allow dots in filenames, but I can see why that would cause issues. The ti74 allows directories, but uses '/' to denote that. In the Commodore arena, the TIFILE format is called the X00 format, and is a 32 byte header that replicates the CBM directory header, (same idea). The X is replaced with P,S,R,U depending on file type (Program, Sequential, Relative, User), and the number is incremented as needed to ensure all names are 8.3 compliant and unique (as the format was created for an old DOS emulator long ago. On newer SD-based drives for the CBM line, we support both native files (JIM.PRG) and X00 files (JIM.P00) alongside each other for loading, and for saving, there is a preference in the drive that tells the system how to format the files (if set to X00 format, all new files are stored in that format). But, if a file is a X00 file, the filename displayed to the calling system is the one in the X00 file, not the name of the file on disk. It does slightly slow down the system, as the file must be opened and the header read, but the AVR handily makes quick work of it, so I think the process is OK. I like re-using the TIFILES format in this case (128 bytes left QUITE a bit of room for future expansion :-)), but I have a feeling folks will still want to support the native formats. Jim

We've Yes, I've implemented OLD and SAVE by just directly loading the aforementioned files from FAT into the cc40. Since all that is functioning well, the team has moved onto DATA files. However, on the disk side, both files are opened the same way (hexBus open, hexbus read, hexbus close for old, hexbus open,write,close for save). The only thing denoting a data file is LUN!=0 in the PAB sent. Jim

Also, in general, if I want to write out 4 "records", so i, i^2, sqrt(i) and sin(i) to a file using VARIABLE DISPLAY, but I don't want to do " : ", do I just do: 1 print#2:i 2 print#2:i^2 3print#2:sqrt(i) 4print#2:sin(i) And the fact that those occur on different lines means the drive will put them in separate records? Jim

Thanks. So, it appears that the record length for a VARIABLE record is not needed, since it doesn't make any difference (well, I guess when you open the file for reading, it has to be the same number, but that's the only check, I assume). Are there lots of utilities and/or emulators that use this TIFILES format? And, when you store a file in the FS in teh TIFIES format, what filename do you give it? In this case, with TESTTEXT as the filename via BASIC, if the file on the Linux FS "TESTTEXT.FIAD" or soemthing like that? Less confused, but now need to read up the TIFILES format, since we have been storing the files in native FAT format on the SD card, no special header. Jim

So, where does the 254 record size get stored? It must be in some preamble to this data (the 00-7f data now shown). I would think, since I asked for 254 byte records, I would only get 1 record per sector. Still a bit confused, I am. Sorry. Jim

OK, thanks (FIXED versus VARIABLE). If you can provide a few variations (FIXED, VARIABLE, DISPLAY, INTERNAL), that's always helpful. Or, any guidance on how the file will change depending on the setting is likewise helpful. I didn't realize " : " denotes a delimiter in these records. And, if you want to send an actual ':' in a field, how do you do that? Jim

OK on the colon. On the cc40, it's a comma, not a colon, for reference. Hmm, so everything you put in a single print statement, barring " : " delimiters, would get dumped into 1 record. That simplifies my disk code, I think. So, if I wanted to print 4 records with that single print statement, I'd do: print #2:i;" : ";i^2" : ";sqrt(i)" : ";sin(i)" : ";""" test""" And, with the colon chars in place to denote fields, I don't need the triple """ to capture a retain leading spaces, so i could do: print #2:i;" : ";i^2" : ";sqrt(i)" : ";sin(i)" : ";" test" And, when I read the resulting fields back in, can I do input #2:a$,b$,c$,d$,e$ or can you share the code needed? Jim

Hmm, is there anyway you (or someone else) can provide the TIPI (or actual TI disk) raw file image of a TI program that does this: 100 open #2, "dsk1.test.txt,OUTPUT,VARIABLE 254" 130 for i = 1 to 10 150 print#2,i,i^2,sqrt(i),sin(i),""" test""" 160 next i 170 close #2 (I tried to convert from cc40 basic to ti basic, but perhaps I missed something). A few things I am trying to sort: If the record length is 254, then does that mean the i and i^2 are separated by 254 spaces in the file, or just 9 (assuming a comma is a 10 char boundary) If I print multiple things in the one line, is that 1 record, or 5 records? Jim

I apologize that I am not completely familiar with the TI 99/4A, so I am hoping there are some gurus out that who can help. I am the principal developer on HEX-TI-r, the HexBus SD card drive solution for the TI cc40. https://github.com/go4retro/HEXTIr The goal is to create a compatible mass storage solution for this device, which had a drive announced but never released. The good news is that primary drive operations work fine now, thanks to initial code by myself and improvements by a handful of developers. Now, the group is turning their attention to variable files, which are supported by the cc40 TI BASIC, but there's little information on how such files should be created, and how the disk drive would have originally stored the resulting data. I was hoping that the TI 99/4A, maybe with some expansion cart from back in the day, or some other TI platform, implemented this functionality and there was not knowledge on the implementation. We can (and have) created a workable solution for our implementation, but I am always interested in historical correctness, if possible. jim

Release 0.9.1.3 is on github. Regression in saving larger files fixed hardware type 1 (non Arduino layout) compilation fixed I finally figured out how to make a bootloader work on the atmega328, so the bootloader can now update the code from the SD drive. Jim

Release v0.9.1.2 is pushed to github: https://github.com/go4retro/HEXTIr/releases/tag/v0.9.1.2 RTC year returned as 4 digits, and can be sent as 2 or 4 digits Spaces trimmed from front and back of received filename General code cleanup Jim

I went ahead and merged the code into master, and created a release (v.0.9.1.0). I continue to test, so please open issues if anything is found. Jim

If a previous sreid_mods Arduino sketch worked, then no HW mods are needed. The only mod I'm aware of of historical note is the switch of LED and BAV lines. The repo has been updated the current preferred wiring, and I am trying to find a way to easily make a nice wiring diagram that shows the arduino itself and the SD card shield, so help folks. All that said, if folks are making new units, Peter Engels (of TIIF2 fame), is now engaged on the project and he found that, under long periods of access (think, running the clock app and the program talks to the drive 2 times per second), the internal pullup resistors in the Arduino on the HexBus lines are just not enough to keep everything sane. Through Stephen Reid (who works for TI and has added lots of functionality to the project, we've known for some time that the proper HexBus circuitry includes 6 8.2K ohm resistors on the 6 HexBus lines, pulled to 5V. I also had included them (well, 10K) in my original HEXTIr PCB, but omitted them for the Arduino build, to save create time). Adding those makes for a more robust setup, so I'd include them (and will do so in the diagram I am making) in a new build. But, the internal pullups are still enabled, so units with the resistors will still work (and, arguably, a proper clock app would not ping the drive RTC 120 times a minute. It would read the clock and set an internal one, but the current app turns out to be a nice stress test for the unit). Jim

Whew! OK. If folks here cna help with a quick "test the printer" and "test the serial port" programs, I will test those and if the code passes, I will merge this back into the main branch, which should bring us full circle, and then I'll make a release. Jim

Actually, with the new 'libmerge' codebase, no arduino libraries are used, so no errors about missing a DS3231 library (won't hurt if you dload or add it, but it won't be used).

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

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

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

Always looking for good test clips. What are you looking to get out of them? Jim

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

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

Not a standalone unit. U64, 1541U, and Chameleon offer REU capabilities, though. I do actually know of 2 standalone projects aiming to bring a small REU to fruition, but nothing to sell, yes

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

Thanks!