On Jun 2, 2016 7:52 PM, "Mark J. Blair" <[email protected]> wrote: > > > > On Jun 2, 2016, at 09:20 , John R. Hogerhuis <[email protected]> wrote: > > No. But I'll remind folks there are two different sector access protocols for the 1 and 2. The sector access protocol for 1 is documented for 2 is not. But the best clue to 2 is the sector access done by BACKUP. > > It shouldn't be that hard to extend tpddtool to be able to at least image and re-create the original TPDD 1 utilities disk, then. The TPDD 2 disk may be a lot harder, depending on how hard it is to reverse-engineer its sector protocol, but snooping TPDD 2 communications while making a copy on original hardware (as has been discussed recently in another thread) can probably help.
I was thinking... IF you DO have the original floppy installed, THEN several sector access programs do function, including backup.ba. So it seems like it should be possible for a backup utility that currently has functional sector access, to create a hex encoded text file, or set of files if needed, which gets around ALL copy problems. Then, once that exists, everyone else can start from scratch purely from downloaded files. download dlplus, use the included teeny to install teeny on the m100, use teeny to pull down the hex text files and a .do-to-.co utility to reconstruct the original flopy2.sy and install it, At that point you have working sector access, and you can use the same method to read other hex .do files to create the utility disk from whole cloth, special boot files and all. I think all those components already exist, or at least the hard parts, needing only some glue. > > > > The old disk utilities are not very good. If someone were to spend time on something I'd recommend someone write an injector program for tsdos RAM version if one doesn't already exist. Big ram hit in using he ram version though. > > I've been toying with the idea of making my own spin of a NADSbox-like emulator, since I gather that the NADSbox is currently out of stock and Ken doesn't expect to make another production run or follow-on product in the near future because of very understandable reasons. One feature I would want to include is a TS-DOS injector, to allow users without one of the various option ROM gadgets to bootstrap TS-DOS from it much like one can bootstrap FLOPPY.CO from an original TPDD with its utility diskette. A command-line injector utility for tethered TPDD emulation could easily spin off from that effort, if I ever actually do it. > > I agree that a ROM based TS-DOS method is preferable, but a RAM injector could still be a good option for anybody who can't use a ROM for whatever reason, such as fluctuations of REX availability. You need the ram option. You can only have one option rom, and what if that's already Multiplan? And the "run com:..." method seems to be the shortest possible for the user with all original hardware/firmware, unless you want to get into connecting to the bus instead of serial. Something trickier might be possible there, I don't know. I was thinking about it, if you're back designing the tppd or a new work-alike now, since it's a serial device, I see no reason the protocol couldn't actually have human readable prompts in it, and include a command or two that are easy/sensible for a human to type, and you install by just going into telcom and responding to prompts, which would download a basic program as a .do, which you could then load and run. Ultimately all that is is way more steps to do the same thing. Even in telcom you'd have to tell the user out of band how to set the right stat: options, which right there is already half of the "run com" command. Also I'm guessing you'd need a special new dos to handle the new junk in the protocol, that all the existing ones would choke on it rather than gracefully/harmlessly ignore it. So back to the standard ipl method. -- bkw
