Hard drive formatting

[+FarmerPotato]

1 hour ago, Brufnus said:

By the way... is piping somehow possible with MDOS? I was thinking about creating a batch file, which reads the contents of my directories and then pipes it to SFBACKUP, which in turn saves the compressed output files to 1.44 MB floppies or a smaller hard drive. I don't know if that's possible, though...

No pipelining, and if I recall > can only redirect output to the console or printer.

 

I've been thinking about how to add pipelining . Some ideas, purely imaginary:

 

• Assuming the shell/CLI can be modified to parse a pipeline, special characters |  <  >
• Pipelining assumes multitasking, buffered I/O and blocking on read/write. Or does it?
• Assume that programs/builtins use the MDOS  API to read keys and write to console.
• Assume you're willing to rewrite programs to understand stdin/stdout/stderr
• In CamelForth, for the MORE utility, @TheBF had a neat idea to switch I/O mode between DV80 and DF128, essentially text and raw mode.
• New programs that parse the | < or > on their command line, adjust their behavior, and tell MDOS to parse everything after |

 

 

Imaginary examples:

DIR /W > LISTING

LS /R  | TAR DSK1.BKUP_TAR

 

Baby steps. Assuming these existed already:

TAR C:\MYDIR  HDS1.OUT_TAR
ZIP HDS1.OUT_TAR DSK3.OUT_Z

 

If the CLI saw this cmd line:

TAR C:\MYDIR  | ZIP > DSK1.OUT_Z

 

It would execute:

 

TAR C:\MYDIR  HDS1.PIPES.PIPE1
ZIP HDS1.PIPES.PIPE1 DSK1.OUT_Z

that is, append a temporary output file to the arguments, or insert a temporary input file as 1st argument (after switches).

 

of course you just write your batch file to do that...

 

There could be a multi-floppy option for ZIP. It would then prompt the user to change the floppy.

 

Bigger example:

 

CAT NAMES | SORT /A | TAIL

becomes
 

COPY NAMES HDS1.PIPES.PIPE1
SORT /A HDS1.PIPES.PIPE1 HDS1.PIPES.PIPE2
TAIL HDS1.PIPES.PIPE2

again, it's just like rewriting the command line into a batch file.

 

Another:

 

FIND /A HDS1.MYDIR | GREP GIF | ZIP H:\BKUP_Z

where FIND /A outputs pathnames that don't have the archive bit set

GREP looks through its 1st input arg file for lines containing "GIF" and writes to its 2nd file arg
 

Resulting batch file:
 

FIND HDS1.MYDIR /A HDS1.PIPES.PIPE1
GREP HDS1.PIPES.PIPE1 HDS1.PIPES.PIPE2  GIF
ZIP /F HDS1.PIPES.PIPE2 H:\BKUP_Z

Here assume that ZIP /F reads the names of files from a file (instead of zipping the one file)

 

Essentially, each cmd needs to recognize one input file and one output file - no console I/O intended. Perhaps if they were written from scratch, a convention would be that the CLI inserts arguments to mark input  with < and output with >. Position independent, so that implied /F option to ZIP is unnecessary.

 

 

FIND HDS1.MYDIR /A >HDS1.PIPES.PIPE1
GREP <HDS1.PIPES.PIPE1 >HDS1.PIPES.PIPE2  GIF
ZIP <HDS1.PIPES.PIPE2 H:\BKUP_Z

Position independent, so this is equivalent:

FIND >HDS1.PIPES.PIPE1 HDS1.MYDIR /A 
GREP GIF >HDS1.PIPES.PIPE2  <HDS1.PIPES.PIPE1 
ZIP H:\BKUP_Z <HDS1.PIPES.PIPE2  

 

 

Conclusion

 

The idea of pipelining is that small programs can be really good at implementing one idea.

 

LS is good at listing directories or expanding globs like H:\USERS\*\DOCUMENTS\*

FIND can be good at picking files that match a bunch of user criteria like date modified, name pattern matching.

GREP is good at pattern matching

ZIP can be good at adding files to a zip, and not support a bunch of fancy options like testing the date modified (that's usually the "freshen" option in ZIP btw)

 

 

 

 

 

[+FarmerPotato]

25 minutes ago, Brufnus said:

Anyway, my first priority at the moment is to get a backup made of all our club archives from the 80's and 90's, which are stored on a quite large number of 5 1/4" floppies right now. It may not be needed, but I've always preferred to have too much rather than too little. I think that's a good principle when it comes to (old) computers. c".)

I found a couple of functional 5 1/4" drives upstairs some time ago, so one of them is now installed in a Pentium III PC with a floppy controller, which works fine with TI disk formats on both 5 1/4" and 3.5" drives (running Win98). So once I'm ready I'm going to make DSK images of a couple of hundred floppies; perhaps I'll discover something in between, which may be of use to the community today, who knows? I do have both a web and an FTP server available, so if I find anything worth sharing, I'll let you know.

 

Best of luck preserving this archive!

 

I preserved 200+ floppies from the Milwaukee (Wisconsin USA) area TI users group. I bought a Kryoflux board, then connected it to a floppy drive from the Corcomp MPES.

A bit of scripting and I could process the floppies from my laptop. About 30 seconds for each.

 

[+9640News]

24 minutes ago, FarmerPotato said:

No pipelining, and if I recall > can only redirect output to the console or printer.

 

I've been thinking about how to add pipelining . Some ideas, purely imaginary:

 

• Assuming the shell/CLI can be modified to parse a pipeline, special characters |  <  >
• Pipelining assumes multitasking, buffered I/O and blocking on read/write. Or does it?
• Assume that programs/builtins use the MDOS  API to read keys and write to console.
• Assume you're willing to rewrite programs to understand stdin/stdout/stderr
• In CamelForth, for the MORE utility, @TheBF had a neat idea to switch I/O mode between DV80 and DF128, essentially text and raw mode.
• New programs that parse the | < or > on their command line, adjust their behavior, and tell MDOS to parse everything after |

 

OK, MDOS can do multitasking, and it is something that has been documented and the source code is available should anyone desire the code.  The RS232 based version of MyTerm has code that puts to sleep the calling program (MyTerm) when it calls up another program (editor) if the option is selected.

 

The MDOS CLI behaves in a similar manner as it "sleeps" when another program is running, and is reawakened when the program exits.

 

As far as the 80 character limit I mentioned earlier, that is a limit I believe imposed by it being a DIS/VAR 80 batch file.

 

There might be a bit more flexibility by writing one's own program and creating a script file for commands to process in a larger record size, and then using the MDOS LOAD TASK XOP option to launch the SFXBACKUP program from another Shell style program.  I don't know what the command strength maximum length might be under that option, but it should exceed the length a DIS/VAR 80 batch file would offer.

 

 

[+9640News]

@FarmerPotato

 

If @Brufnus is trying to keep his hardware costs to near zero, the Kryoflux is not likely to be an option either.  If he went with the most minimal PI Zero/TIPI option, he would be somewhere around $150-$160.  I suspect the Kryoflux is a bit more?

 

One option that may not have been considered, and this depends upon what hardware Brufnus may have, may be using Ralph Nabet's (??) MS-DOS program, TI99-PC.  He could then read the floppies on a MS-DOS system if he has a Windows 2000 or earlier computer and suitable floppy drive, store the images on the computer, then transfer either with a serial interface, TIDIR, USB, network share, or some other fashion. 

 

There are several options depending upon what he has available to him. 

 

 

[Brufnus]

45 minutes ago, FarmerPotato said:

 

Best of luck preserving this archive!

 

I preserved 200+ floppies from the Milwaukee (Wisconsin USA) area TI users group. I bought a Kryoflux board, then connected it to a floppy drive from the Corcomp MPES.

A bit of scripting and I could process the floppies from my laptop. About 30 seconds for each.

 

Thanks! That sounds like an awesome way to do it... I don't even know what a Kryoflux board is... but I do know what a flux capacitor is; I've done some research on the science behind Back to the Future.

 

Indeed, River Patroller, I have a Win 98 PC with a 5 1/4", a 3.5" floppy drive and TI99-PC standing by, waiting for me to feed it with all our floppies.

Unfortunately for the time being, the only connection to the surrounding world I have on my Geneves, is floppy and serial connection. I am considering though, how to improve on that situation in the best way possible - be it a DREM, TIPI, SCSI controller or whatever. I think the TIPI sounds like the most promising option.

[+9640News]

4 minutes ago, Brufnus said:

Indeed, River Patroller, I have a Win 98 PC with a 5 1/4", a 3.5" floppy drive and TI99-PC standing by, waiting for me to feed it with all our floppies.

Unfortunately for the time being, the only connection to the surrounding world I have on my Geneves, is floppy and serial connection. I am considering though, how to improve on that situation in the best way possible - be it a DREM, TIPI, SCSI controller or whatever. I think the TIPI sounds like the most promising option.

In today's world, the TIPI is your best option.  If the hardware fails, you can order a new one.  If a HFDC or SCSI controller fail, you can only hope someone can repair it.  The DREM is only as good as the HFDC until the HFDC fails.  The TIPI was not around when I bought 2 DREM's to replace hard drives for both HFDC's I have.  Now, if I was doing it, I would have likely just gotten the TIPI and a HRD 4000+ for everything I do.

 

I have stuff on the HFDC/DREM, but I predominantly use my HRD 4000+ and the TIPI for my Geneve work.  And backups on the HRD 4000+ go to the TIPI, and then I copy the files on the TIPI to a Windows shared folder.

 

Does your Win98 PC have a USB port?  If so, can you attach an USB stick and copy the resultant DSK files to it?  Then, you could take that set of files and upload to Whtech and at least make that library available to everyone.  For your use, I am not sure if you are wanting to have the whole library available to yourself on a hard drive, or just a few of the files where downloading them individually is needed, etc.  

[Brufnus]

9 hours ago, 9640News said:

In today's world, the TIPI is your best option.  If the hardware fails, you can order a new one.  If a HFDC or SCSI controller fail, you can only hope someone can repair it.  The DREM is only as good as the HFDC until the HFDC fails.  The TIPI was not around when I bought 2 DREM's to replace hard drives for both HFDC's I have.  Now, if I was doing it, I would have likely just gotten the TIPI and a HRD 4000+ for everything I do.

 

I have stuff on the HFDC/DREM, but I predominantly use my HRD 4000+ and the TIPI for my Geneve work.  And backups on the HRD 4000+ go to the TIPI, and then I copy the files on the TIPI to a Windows shared folder.

 

Does your Win98 PC have a USB port?  If so, can you attach an USB stick and copy the resultant DSK files to it?  Then, you could take that set of files and upload to Whtech and at least make that library available to everyone.  For your use, I am not sure if you are wanting to have the whole library available to yourself on a hard drive, or just a few of the files where downloading them individually is needed, etc.  

Good points, Beery. However solid the HFDC's may be, they won't last forever. And going back to floppy only is not an option.

Yes, I do have USB ports on that PC. It's a Pentium III motherboard, so it's relatively new. I just need to find the drivers for one of my USB sticks, but that should be possible, too. I had some issues with it tonight after having connected the last few cables - I had some problems gaining access to my Samba domain controller, but in the end I got the configuration right (hard to remember, since I haven't used Win 98 on my domain for a couple of decades...) Anyway, now I can back up whatever I copy to the local drive to one of my servers as well.

I'd be happy to upload the resulting library to Whtech. I'll need some time of course, but I'll let you know when I'm ready. Perhaps that's the best solution - to include everything; then people can select for themselves if they have any interest in it. c",)

 

Where can I purchase the TIPI? I'll be needing a Raspberry PI as well, correct?

Edited October 8, 2021 by Brufnus

[+InsaneMultitasker]

 

10 hours ago, Brufnus said:

Unfortunately for the time being, the only connection to the surrounding world I have on my Geneves, is floppy and serial connection.

Before TIPI, I used Fred's HDX software to transfer files between my TI and the PC. (and I still use HDX with my nanoPEB).  

The HDX server runs on the PC host, and the disk manager runs on the TI.  A serial cable connects the TI to the PC.  I do not recall whether Fred's ( @F.G. Kaal )  HDX version of DM2K works on the Geneve though if it does, this could be a nice and simple way for you to start transferring files.  The backed up files could later be used with the TIPI if you decide to obtain one. 

 

Like @9640News, I use my Horizon Ramdisks for development and back up the files via TIPI.  I also back up to my MFM and/or SCSI drive, so that I have a native copy and to preserve timestamps, so that I have the original creation/modify dates for my development files.  I do use the TIPI for more than backup purposes but there is nothing faster than assembling code on the ramdisks  

 

10 hours ago, 9640News said:

If a HFDC or SCSI controller fail, you can only hope someone can repair it. 

Between @Swim and I, HFDC repairs are still possible, though chips are scarce.  The SCSI card can be repaired if the common logic chips fail but it seems that Competition Computer has not made any of the specialty parts available since obtaining the remaining inventory of parts/updates.  

 

[+9640News]

5 hours ago, Brufnus said:

Good points, Beery. However solid the HFDC's may be, they won't last forever. And going back to floppy only is not an option.

Yes, I do have USB ports on that PC. It's a Pentium III motherboard, so it's relatively new. I just need to find the drivers for one of my USB sticks, but that should be possible, too. I had some issues with it tonight after having connected the last few cables - I had some problems gaining access to my Samba domain controller, but in the end I got the configuration right (hard to remember, since I haven't used Win 98 on my domain for a couple of decades...) Anyway, now I can back up whatever I copy to the local drive to one of my servers as well.

I'd be happy to upload the resulting library to Whtech. I'll need some time of course, but I'll let you know when I'm ready. Perhaps that's the best solution - to include everything; then people can select for themselves if they have any interest in it. c",)

 

Where can I purchase the TIPI? I'll be needing a Raspberry PI as well, correct?

Greg at arcadeshopper.com has the tipi’s, and yes, you will need a pi.  While you can get away with a pi zero, if you have the funds, get the pi 3 plus.  

[Brufnus]

Yes, the HDX also sounds like a good option, it's pretty much like the one I recently discovered for my Amiga CDTV, the "Amiga Explorer", albeit this one goes the other way around and lets one browse through the contents of the Amiga from a PC, also via a serial connection. I did run into some other problems before I could test HDX however, so I had to address that first.

Anyway, I'll soon continue with HDX and also see if I can make use of that DM2K version.

 

It's good to hear that HFDC repairs may still be possible; I know I have to take good care of them - more than once I've had some issues which made me think they had gone bad, but until now it's always been false alarm. I haven't used the TI's or Geneve's much for a long time, but that may be subject to change.

[Brufnus]

1 hour ago, 9640News said:

Greg at arcadeshopper.com has the tipi’s, and yes, you will need a pi.  While you can get away with a pi zero, if you have the funds, get the pi 3 plus.  

Okay, thanks... I'll take a look at that. c",)

[HOME AUTOMATION]

2 hours ago, 9640News said:

While you can get away with a pi zero,

NOT...

 

"Pi Zero W"

 

That "W" makes all the difference!