9640News

There were two folders, a C99M and a C99T. I wasn't for sure, but the C99T had a single file that may be the only file necessary to compile C99M as a TI-99/4A version. Beery

It was available in the wild, just very few people probably even realized they had it. Back in the 2003 timeframe, I made an effort to contact various authors of Geneve software to obtain source code to the programs I thought were very pertinent to the Geneve. I knew I had conversed with Clint, but could not recall what he provided. Fortunately, he provided the source code for everything. I have no way to contact Clint, and since by now he would be in late 70's or early 80's, I really wonder if he is even around and still enjoying retirement, or not. Beery

Hopefully, someone will place this source onto whtech's repository.

OK, here is everything I have from Clint. It was on a MESS image from about 2003 I distributed. I believe the code is the MDOS version, but I can not confirm. it is possible the 4A version could be part of it as a conditional compile. If memory serves me correctly, c99 would compile itself. Code for the libraries I think are also included. Beery C99-V400-SRC.zip

I found the source code from my last contact with Clint. It is on a MESS image, so let me get it moved across to the TIPI so I can zip everything up. Beery

The last contact I seem to have with Clint was back around 2003 from information I could find. I found a note somewhere that indicated he retired in 2004. That's 16 years ago, which would put him like in his late 70's or early 80's. I called the one phone number I had for him and asked for Clint. It wasn't a good number for him, and before I could complete asking a second question, they hung up on me. I could not find him on Linkedin nor Facebook. I'll do a bit more digging, but it is likely the source has been lost.

I have TIDIR on several systems, and apparently that was one PC I had not updated. It is now updated. Either way, what is the difference between a tifiles header, and a tifiles header that TIDIR calls classic99?

I'm using TIDIR V 7.2a. When I list some files I have on a TIPI, I see some files listed as 'tifiles', and others listed as "classic99". What is the difference between the two as they both show a TIFILES header with the hex editor.

Matt, Not sure if you want to consider this an issue or not. Letting you know about it, as there are already work around tools for it. I came across the issue, and after working with Tim, we isolated what is happening as it was not immediately obvious. If there is a native file on a TIPI folder because it was dropped their natively, then it does not have a TIFILES header. I had some GIF and VOC (sound files) from back in the 90's that were playable on the TI that were downloadable from a MS-DOS PC BBS program back in the day. When those files were downloaded, the TI would save them as a DIS/FIX 128 file. However, these files were not downloaded to a TI and never got the TIFILES header as I had them in their original PC format when they made their way to the TIPI. These files were still useable by our programs; they just could not be copied. With DM2K, and the other catalog programs, these programs present as a DIS/FIX 128. However, when you try to copy them to another path, you get an error that TIPI logs report as a Level 2 Error, not TIFILES. I know you indicate these files are readable only as a native file and can not be written. There is no intention on my part to writing back out to the file itself. Not sure how, or if you would allow copying the file to another path. Now, a user using DM2K may not realize these are native files since they present as a DIS/FIX 128 file and may struggle a bit to understand why they can not copy the file. I'm guessing this could include .TXT files as well. Your WebUI and programs like TIDIR solve the issue by converting and adding the TIFILES header, but only if the user realizes the situation. I don't use Force Command, so I don't know how you may (or may not) handle it. Again, just pointing out the observation. From the logs, opening the FILEID of the file, the following error occurred. The lines in Yellow are in the case of the Geneve debug code passing information back out to a terminal with the Pab going in and the Pab that is passed back out for your information. Pab In : 0A00 0001 2000 0000 0000 0000 0000 0013 TIPI.DL1.04DEAD-VOC Pab Out: 0A00 A001 2000 0000 0000 0000 0001 0013 TIPERR: C000 Inspecting the TIPI log shows the following: 2020-12-26 11:46:30,625 LevelTwo : INFO unit: 0, blocks: 0, filename: 04DEAD-VOC, startblock 0 2020-12-26 11:46:30,626 tinames.tinames: INFO TIPI.DL1.04DEAD-VOC -> /home/tipi/tipi_disk/DL1/04DEAD-VOC 2020-12-26 11:46:30,627 LevelTwo : ERROR not TIFILES Anyways, just wanted to alert you to the observation. After I saw what was happening, I converted the files to DIS/FIX 128 TIFILES format and all was well. Beery

Matt, Thanks for this update. I wrote DIR_SORT=FIRST into the PI.CONFIG file, commented some code out, and all is well. From me, thank you for this update. Beery

Love the plan!

Matt, Wasn't sure which topic area to put this, but came across another error at a "safepoint". Log section below. Basically, I went to copy a bunch of files from a floppy drive to a TIPI sub folder with a COPY * command. All files were buffered before the code then tries to start writing them out. The first filename in the list is $MAKE. I've copied that filename multiple times in the past with no issue. Things locked up on the PI. I rebooted the PI, and repeated the procedure, and then things copied fine so I don't know at this point how to duplicate the issue. Just giving you some feedback if you see something there. BTW, found the issue I was trying to chase down above. Let's just say it was buried in some sneaky code. 2020-12-24 19:25:39,764 LevelTwo : INFO set path request 2020-12-24 19:25:39,767 LevelTwo : INFO unit: 0, path: TIPI.DOWN2.AAA. 2020-12-24 19:25:39,767 tinames.tinames: INFO TIPI.DOWN2.AAA. -> /home/tipi/tipi_disk/DOWN2/AAA 2020-12-24 19:25:39,768 tinames.tinames: INFO TIPI.DOWN2.AAA. -> /home/tipi/tipi_disk/DOWN2/AAA 2020-12-24 19:25:39,768 LevelTwo : INFO set unit 0 path to TIPI.DOWN2.AAA. 2020-12-24 19:25:39,769 LevelTwo : INFO direct output 2020-12-24 19:25:40,428 TipiService : ERROR Unhandled exception in main Traceback (most recent call last): File "/home/tipi/tipi/services/tipi/TipiMessage.py", line 22, in receive message = self.ports.readMsg() File "/home/tipi/tipi/services/tipi/TipiPorts.py", line 21, in readMsg return tipiports.readMsg() ValueError: safepoint During handling of the above exception, another exception occurred: Traceback (most recent call last): File "./TipiService.py", line 65, in <module> if levelTwo.handle(msg): File "/home/tipi/tipi/services/LevelTwo.py", line 36, in handle return handler() File "/home/tipi/tipi/services/LevelTwo.py", line 232, in handleDirectOutput bytes = self.tipi_io.receive() File "/home/tipi/tipi/services/tipi/TipiMessage.py", line 24, in receive raise BackOffException('safepoint') tipi.TipiMessage.BackOffException: safepoint 2020-12-24 19:25:40,944 TipiService : INFO physical mode enabled 2020-12-24 19:25:40,945 TipiService : INFO TIPI Ready

There is no request to support the 0xFF filenaming, rather reporting the bug as you described. Don't recall an alternative to the un-implemented TI temporary file mechanism you mentioned, and not something I am seeking/requesting. Just some background on what I am doing as I did not know your timetable or what configuration option(s) you were going to implement. There are two commands in the command line interpreter in MDOS that pull the same routine to catalog a path They are the COPY command, and the DIR command. You are allowed to do a wildcard search for a name. When this GETCATS routine is called, it places a list of up to 114 directory names and 127 filenames into two different buffers that meet the search criteria. So, if you search for "AA*" or "*", you will only get directories and files populated into those two separate lists that meet the criteria. With the HFDC, everything initially comes in as subdirectories first as the master dsr is written, then when the code no longer detects any subdirectories, it switches to populating the files list. Each name as it is pulled is individually searched during the read to see if it matches the search criteria. Now, after the DIR call gets the device cataloged, then it displays the directories first, then it goes on to the list of files that meet the criteria. The GETCATS code that builds these two lists is not smart enough to split files and directories if they come in mixed. So, register usage goes afoul trying to deal with both simultaneously. The code as originally written never envisioned such a scenario which makes it a nightmare to manage the registers and pointers. I tried some code to handle switching back and forth, but there were still pointers somewhere that were being reset. So, what I did was treat the list of everything coming in from the TIPI during the cataloging process as a filename. Mixed in with all that code was some other code that also creates a fake file control block in memory to quicken the display output processing when a DIR is called. After a few code tweaks, and directories in that list are properly display as a directory listing when a TIPI is cataloged in a mixed file listing as it is currently seen. As the COPY routine is only concerned about a path whether it is doing a complete directory, or a "AA*" (ex.), it would pick up a directory name AAA if it existed that would go into the FILES list on the TIPI device. In that fake file control block is a designator that it is a DIR and not a D/F, D/F, I/F, etc file format. So, now the COPY command reads the FILES list, and goes to buffer as many of the files it can in memory dependent upon available memory. There are a host of routines depending upon the type of file, and to whether it is being written out to floppy disk, rs232, pio, hard disk, etc. As the code starts reading through the list of FILE names that are marked as a DIR in the fake file control block, I mark the filename (that is actually a subdirectory) with the first character as >FF so the code will know to avoid the call to the OPEN Pab call and jump over it. Somewhere, there is call I have not isolated that still looked to copy that subdirectory (as file) even though I thought I had code that would have jumped over it. Because it had a filename beginning with >FF, it generated that error. Once I find it, the error should not be generated. If the requests you mentioned have the option of grouping directories, then there will only need to be very minor code changes. As it is now, the code works fine if I tell it to do a COPY AA* and there are no directory names that meet that criteria as well. It is only when I test across the use of the COPY command with directories that get also added to the list. Anyways, that is probably more than you wanted to know.

Matt, Not sure if this is an issue on the PI end or not.... I tried writing a file with the first character in the filename containing the hex byte >FF. I have this information in the TIPI log where it only wants characters below ASCI 128. No issue there, as I understand that. Is the TIPI code not passing some kind of error code response back in this case when it processes an unhandled exception? It looks like my code is waiting for a response (good or bad), and it isn't getting any response back. The hex byte >FF was supposed to be a flag to indicate to skip the file and not write it, so I am chasing that part down myself. Beery 2020-12-24 12:16:59,034 tinames.tinames: INFO TIPI.DOWN2.AAA. -> /home/tipi/tipi_disk/DOWN2/AAA 2020-12-24 12:16:59,034 LevelTwo : INFO set unit 0 path to TIPI.DOWN2.AAA. 2020-12-24 12:16:59,035 LevelTwo : INFO direct output 2020-12-24 12:16:59,038 TipiService : ERROR Unhandled exception in main Traceback (most recent call last): File "./TipiService.py", line 65, in <module> if levelTwo.handle(msg): File "/home/tipi/tipi/services/LevelTwo.py", line 36, in handle return handler() File "/home/tipi/tipi/services/LevelTwo.py", line 231, in handleDirectOutput filename = str(self.tipi_io.receive(), 'ascii').strip() UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) 2020-12-24 12:16:59,480 TipiService : INFO physical mode enabled 2020-12-24 12:16:59,481 TipiService : INFO TIPI Ready

It's Geneve specific.

Well, to stay consistent with the TI-99/4A, cataloging with the Extended Basic program, files come before directories with the SCSI and Myarc HFDC controller cards. That would be how those DSR's present the catalog listing. For that other system I use, directories are presented first. I don't know if there is a setting that could be set in PI.CONFIG (???) that could give the user configuration control like files first, directories first, or alphabetical listing to control the user presentation of the catalog. When I run DM2K on the Myarc HFDC under a TI configuration, files are presented first, then directories. With the TIPI and DM2K, it appears to be the loading order is strictly alphabetical so it can handle either way so it would not break that software. In that respect DM2K is very versatile and covers both scenarios. Off the top of my head, and outside of your program force command and DM2K, I am not sure what other TI-99/4A programs are out there that can do a directory on TIPI with file operations that also contain subdirectories. Really old legacy software that knew nothing about directories would likely default a directory to one of the other filetypes dependent upon what the program defaulted an unknown filetype. My extended basic program I posted earlier, added the TYPE$(6) = "<DIR> " as I knew it. That wasn't thought about during the early TI days. Beery

Wasn't quite sure if the end of that last statement was an indication you were going to make that modification, or it is in reference to the extended basic catalog program. If it is not much of an effort, presenting a catalog listing with directories before files like that would be greatly appreciated. If on the other hand, some kind of string can be written back out to PI.CONFIG(?) that would change that behavior, that would work as well. Beery

The above program was typed in from the TI Disk Controller manual. I pulled the controller manual copy up from the CYC/ page 48. On the Myarc HFDC, the above program does not error out. However, on the TIPI and SCS1, it will error out. I just looked through program listing, and in line 300, B$="<space><space>" should have been B$="<space><space><space>". this avoids the error being generated in line 310 with a neggative SEG$. On the Myarc HFDC and the SCSI, the above program gives files first, then a list of directories, each set in alphabetical order. TIPI provides the listing of all files/dirs in alphabetical order. As far as what is the value of K, I do not know. Beery

Matt, Testing here is in Geneve Rompage mode, so no Geneve DSR in play. Been trying to chase down a catalog issue I having with the TIPI in MDOS/Assembly, so I put together an extended basic program for testing. I am including a copy of the extended basic program I am using below. When I run the program, with my directory listing I get an error after the third line of display. With the Myarc HFDC, if I run the same program substituting WDS1 for TIPI in line 210, I get a listing of all files, then it continues on and I then get a list of directories. If the TIPI was presenting a mixture by alphabetical order, then I think I can deal with that in my other coding efforts. However with the error being generated here in extended basic, I think there may be an issue??? With the TIPI, if I run the extended basic program, I get everything in alphabetical order until it hits the first file after a directory is displayed, then I get an error. I think whatever is happening here is what is confusing my assembly code. Since it does generate an error in extended basic, I wanted to report it. CATALOG

Beery

Tim and I are working on trying to get as much usage as possible from the TIPI with the Geneve. There are still issues, but significant headway is being made. As one thing is solved, we are moving to solve the quirks. Will all DSR features available to 4A users be available in the "master" DSR, likely not. First step is getting File I/O operational on both the 4A and the MDOS side of the Geneve. Many things are done with no issues. The most difficult two functions, we are trying to overcome command line interpreter issues. Will a TIPI version of MDOS boot from Eprom? Unknown and no work is going on in that direction as other efforts look to have priority first. However, once MDOS boots, it will at least have mass file storage capability. Beery

Yeah, it is starting to look like that though I did find some information out there where others have found issues on how the directory list is presented. I think I am going to have to approach the solution from a different angle as it is going to result in too much rewriting of the DIR command with the way the code is currently written. Beery

Yeah, I was just going to post that as I was going to restore that folder from a backup and saw Windows doing something similar. The oddity, is that I can recreate some of that same behavior with the MDOS DIR command. Beery

Matt, I have a folder mapped on my Windows system to the TIPI folder. In it, I have a folder (DL) that has 2800+ files. When I open the DL folder, despite clicking on the NAME field to alphabetize the folder, I still have filenames not in alphabetical order. I should also add in this folder, the filenames in many cases, had filenames that were in the 8.3 architecture before I used an Excel tool to rename the filenames as a maximum 10 character filename. Bytes >10 through >19 in many of the files, do not have filenames in the TIFILES header. As I recall, the use of those bytes for containing the filename was not standardized and various terminal emulators handled things not the same. So, I am a bit perplexed the windows folder mapped to the PI is not alphabetizing the files. With my limited understanding of the operating system, I do not understand why the directory listing is not alphabetized since I thought Windows should have done that. Now, with DM2K and the use of an MDOS program, XDIR, I can get an alphabetical listing or at least until the buffer fills. The MDOS DIR command needs work as it is not getting an alphabetized list, yet! Working on fixing that piece. Is there an explanation? Something that could be changed on the PI to address the ability to click the NAME field and to alphabetize the list? I'm asking here in this area as I do not know if this may be a configuration setting on the PI that may warrant modification. Beery

We need to give Tim a BIG BIG Thanks for his development work. My contributions have been very minor compared to Tim's. And, we both must acknowledge Matt's work on the TIPI and the publishing of the DSR on github that got us to where we are today. I was able to take that source code, and convert it to DIS/VAR 80 files that was able to be assembled byte for byte equal to the original eprom code. We mapped that source code into a new page of MDOS, and Tim has been busy adding the extra hooks to interface things in the Geneve's master DSR for both Geneve and TI-99/4A emulation. That has been a monumental undertaking. Initially, we thought we were going to have some side utilities like John Johnson's XDIR and XCOPY program for file directory listing and file copying, however as of yesterday , modification's to the Command Line Interpreter's (CLI) DIR and COPY routines will likely be possible. Still chasing down a few issues here with those two commands, however it appears Clint Pulley's Directory Manager (DM) allows copying of files to TIPI without issue as it uses a slightly different approach to file copying than the COPY command. However, if you have 3000+ files in a subdirectory like I do for the AfterHours BBS program, there is a limitation on the number of files you can see before the buffer is full. Programs can be launched already from the TIPI from MDOS mode along with making and removing directories. I have also successfully used the TIPI version of MyTerm to download files to the TIPI directly from MDOS. As far as MDOS, it looks like we are going to drop two commands, DISKCOPY and DISKCOMPARE. These two routines consumed around 4K of memory in the memory space allocated, and before removal, we only had 16 bytes of space left. Addition of code to allow the use of TIPI in the DIR and COPY commands necessitated some cleanup and these two commands in today's world with the still existing user base, hard drives, and other mass storage devices, necessitated their removal for future updates. If someone needs to do some disk copying which is less likely these days, then programs like HyperCopy and other disk managers are available. I would have to doublecheck to see if DM2K or DU2K can do a disk copy, or if it is solely for other disk and file functions. As far as the TIPI, only the TIPI device name, called TIP1 that is renamed in the communications with the TIPI to TIPI versus TIP1 is defined. URL and other device names have not been established at this point. First emphasis, get TIP1 100% working in MDOS and in GPL mode without Rompage. I took Tim's PFM split program for PFM modified Geneve's and have modified it to work with the Geneve as it needed to compensate for the addition of an extra 8K page in MDOS. There are still things to do, but things are definitely looking good. There is only one person in the community that could have made this happen. Many thanks to where we are now Tim!!!