Model III Emulators
Rick Massey
III disk images.
First, the functional details. I have several files that I either created in
basic a while back or created as text files in Excaliber's program Edit.
I've been trying to get these files off the images created by Readdisk, but
I have been unable to find an emulator that works well enough to run
programs on an XP system, has the capability to print files or copy data to
the clipboard, and reads things in a native enough format that a screen
reader can parse the output. (I lost my sight almost six years ago and have
been unable to locate it in the intervening time)
So, I either need to find an emulator that will print or copy to the
clipboard on a Windows XP system while letting my screen reader access the
info, or I need to find a kind soul that will will help me out with getting
these files translated to txt documents. Edit is quite intuitive once you
use Clear+O to access the help menu, plus it's a plain text format so it
should probably open up in any text editor or word processor. I've tried
pulling data from the raw disk images, and I get some success with it, but
things are rather hashed. I spent five hours recently cleaning up one file
this way, and even then some of the text of the file was junked so that I
had to get a sighted person to look at the file in an emulator )that I can't
access and won't print) to get the missing text out.
Any assistance/advice would be greatly appreciated.
Grinder
I would be willing to help. There appears to be quite a bit of good
information about those disk image format online, so I might be able to
write a small program to rip some files out.
Can you send me one of the images to:
grinder2112 (a) gmail.com
tur...@gmail.com
If you can post either and READDISK image or the file image to a place
where we all can take a poke at it I'll bet you'll find many people
who'd be interested in seeing if they can hack something quickly
together and share their techniques after the fact.
It's probably easier to just take a stab at it than to guess how to do
it.
Knut
Have you got it all transferred to disk images? It shouldn't be too
difficult to extract the data.
Text files are slightly different for TRS-80 as compared to a pc so most
(but not all) pc editors/viewers don't understand them.
Basic can be de-tokenized back to text in several ways, there are
separate tools or you could save from an emulator and use PlayCas to
save a textfile.
I'm not familiar with Excaliber's program Edit but if it was a straight
text editor the files are easy to translate (CR needs to be CR LF on a
pc and any ctrl-z must be removed).
Other than that the best way might be to print to a file and translate
that. I'm actually working on a program that can print captured MX-80
Graftrax commands on a windows printer, a Graftrax80 emulator.
I could have a look at those disk images too if you want, reply to my
email or 'reply to sender' on this message just note that my email here
is mangled you need to remove 'nogarbage.'.
Knut
Grinder
Rick sent me an example, and it appears to be a DMK disk image. I'm an
interested novice, so if someone knows of an "out of the box" solution
you can probably get him a quick answer.
More later...
Grinder
but I can't get tools that purport to read to do so. (Specifically, Tim
Mann's dmk2jv3, and Phil Ereaut's Emulator File Read and Copy 3.1.)
Picking the file apart with a hex editor suggests that it is a DMK, at
least down to the level of the IDAM pointers. Can anyone direct me to a
discussion of what those sectors are supposed to look like? (Which
would also presumably cover directory details.)
Any guidance, or just random blathering, will be appreciated.
Grinder
> I've been having a fairly non-stop headache getting my files off some Model
> III disk images.
>
> First, the functional details. I have several files that I either created in
> basic a while back or created as text files in Excaliber's program Edit.
> I've been trying to get these files off the images created by Readdisk, but
> I have been unable to find an emulator that works well enough to run
> programs on an XP system, has the capability to print files or copy data to
> the clipboard, and reads things in a native enough format that a screen
> reader can parse the output. (I lost my sight almost six years ago and have
> been unable to locate it in the intervening time)
Have found any program that can read your disk images well enough to
clearly view the contents of the files on that disk?
I'm getting a better idea of the format now, but it seems to be
non-standard enough that general DMK readers are having a problem.
Knut
Thay are created with TRSDOS1.3 which is very incompatible with almost anything else... 4 of the
disk I got are OK so I extracted 4 files for him. They are indeed DMK type images.
I'm not sure if export tools work for TRSDOS1.3 so I used LDOS' CONV command to get the files over
to LDOS and then exported them 'CONV :1 :0 (VIS)' then Y for it to convert the file. I also use
XVI32, a pc hexeditor, to substitute CR to CRLF so the files can be read by a pc editor. I sent both
the straight file and the pc readable one.
The bad disk images didn't read even with TRSDOS1.3
Knut
Grinder
Rick, if you're watching, send me the images that Knut couldn't get
read. Knut: was one of the bad images named SWORDS.DSK?
Knut
No I didn't get that. I read PSICHART, PSICLASS, SKILL1 and SKILL5 and those that failed were
SKILL2, SKILL3 and SKILL4.
TRSDOS1.3 gave error 04 on them while LDOS' CONV said unable to read sector. I guess those images
weren't properly created or "taken out" before all writing was done. So probably not a problem with
the file in itself, I think.
My method wouldn't have any problem with images with lots of files.
I did also try an old virtual-disk tool I had but it couldn't read TRSDOS1.3 disks. TRSDOS1.3 has no
sector 0, numbering the sectors from 1 to 18 rather than 0 to 17. This thwarts almost any tool I
have, even zap type tools.
Knut
Grinder
I was able to get 16K worth of text out of SWORDS.DSK just by reading
the sectors in order (de-interleaving them, that is) and jamming it all
into a text file. There really was only one file on the disk, so that
worked about. The file appears truncated, though.
The image header indicated that there are 40 tracks of 0x1900 bytes.
Every other track was zero-filled, though. Maybe that's the way images
of single-sided disks are made?
Grinder
> those that failed were SKILL2, SKILL3 and SKILL4.
Would you mind sending those along to me? I'd like to pick apart some
that are proper as well as those that can't be converted.
grinder2112 (at) gmail.com
Thanks.
Rick Massey
"Knut" <kr-...@nogarbage.online.no> wrote in message
news:CaudnY1t-PP...@telenor.com...
I have the original disk images for the files as well, so tht might be a
better place. After all, spliiting out each file for a disk image might
have been rough on the file headers.
I have, in total, about 22 disks of things. What would be great is a program
that would handle the conversion without having to go into a TRSDOS based
environment. I know that Tandy had one like this for converting data files
back when they were phasing out the TRS-80 lines that would drop data files
into an IBM image. I didn't pick it up then because i couldn't spare the $80
and because it wouldn't convert any basic programs, just data, and I do have
some programs written in basic that I'd like to convert at some point.
Unfortunately I don't have a centralized place where I can upload a file or
group of files for people to look at and work with, so it'll have to be
individual sends.
Rick Massey
news:ZrXWl.732644$yE1.453581@attbi_s21...
> Rick, if you're watching, send me the images that Knut couldn't get read.
> Knut: was one of the bad images named SWORDS.DSK?
Nope. And I'll send you the ones he couldn't read to see what you get from
them. Also, the swords file seems mostly good, only missing a few characters
at the end.
Ira
email if you need anything further.
Grinder
Can you outline the process you used? I noticed that the "Emulator File
Read and Copy 2006 v3.1.exe" application wasn't really able to
interpret the DISKx.DSK images.
Knut
If you send some of these unsplit images to me I'll try my way of doing it and see if it works
better. My email can take really large emails (I have received large pdf's by email) so there should
be no problem.
Supercross is a tool that writes PC floppies on a TRS-80. Is that what you are thinking of? It works
for 5.25" floppies only as it is.
I have been using both DOSPLUS and LDOS before and they have an annoying difference on how the file
length is specified in the directory so that a sector would be lost or added depending on which way
the file was copied. I had to be very specific that floppies were used only with one of the DOS's
and not the other. Are there other versions of TRSDOS that use the same sector numbering that 1.3
uses or is it specific for this model III DOS only?
I'll probably make a CR to CR LF tool too as using a hexeditor it too tedious. One file had
something that looked like a printer command (which I left in there).
Knut
Ira
others which are, and they will be discussed.
While there are a decent number of programs which will extract, I use
TRSREAD which is part of the registered version of Matthew Reed's TRS-80
DOS emulator package. I believe that there are other utilities which
are free, but I have gotten used to that one. It is not part of MR's
windows emulator, but I believe he once told me that he would make it
available to any registered user of his Windows emulator who asks.
(Matthew - If I am wrong, I apologize).
What I used to use before Matthew wrote TRSREAD, however, is VREAD and
VWRITE from Jeff Vavasour's Model I DOS emulator. That IS free and is
inside an archive (inside his emulator archive) called vutils.zip. It
is limited to SS/SD DSK images but that is not an issue because you can
use an emulator to copy the files from whatever format they are (in this
case, TRSDOS v1.3) to a SS/SD virtual blank DSK (not DMK) image. This
will work just as well as TRSREAD (albeit on that one format) and can be
controlled as part of a command line DOS utility as well. I find that
one should use virtual 80 track disks to somewhat get close to holding
the data of the source disk image. VREAD can go up to 80 tracks (if I
recall).
I believe Knut, who is reading this thread, wrote a few utilities (such
as X.EXE in 2001 and Emulator File Copy more recently) to extract. I
believe that Tim Mann's linux emulator also has a utility that can
read/write. I know that one person is currently working on a PC level
extractor and another person has indicated a desire to start working on
one. Both of these two people, however, may be stymied by the myriad
different disk formats. Even TRSREAD can only handle so many DOS's. I
recently got a bunch of DoubleDOS disks to extract, and no available
program (to my knowledge) can extract those. For those, I used
Newdos/80 with a PDRIVE of TI=CK, TD=E and copied the files using CBF,
NFMT to a single sided, single density disk, for extraction. For harder
disks (those with directory errors, etc), I used SuperUtility to copy to
a SS/SD after learning that DoubleDOS is "B1R" in SuperUtility disk
configuration-speak. It would be WONDERFUL if someone would/could
develop an extractor for the PC which could handle all the different
DOS's and handle DMK's (TRSREAD cannot handle DMK's and one must convert
DMK to DSK first, using Tim Mann's catweasel utility DMK2JV3).
Of course, as more utilities are written, I will add them to the
relevant web page:
http://www.trs-80.com/wordpress/disk-and-tape-conversion-utilities/
Regardless of the extractor program you choose, I simply made a batch
file which made a directory which was the same name as the image, ran
the extraction program into that directory, and ran a batch file I
created which removes boot/sys, dir/sys, SYS?/SYS and the standard files
"xfersys, lpc, basic, etc). Zipped up what was left and sent them along
to Rick. If you want to use VREAD and VWRITE (free), you would need to
do the interim step of copying the files to a SS/SD DSK image, but then
everything else would work just fine.
However, Rick also needed them in ASCII. I long ago wrote a little
utility which I called LOADSAVE which examines the contents of X.ZIP and
writes out a JCL file which alternatively does a LOAD, SAVE, and NEW for
each file on the disk; and adds a CRLF to each line of the JCL. I did
this because slack appears at the end of many files, and I would have a
million different copies of the same exact file if I did not load and
save them to clear the slack. In this case, I ran LOADSAVE but edited
the resulting JCL file from:
LOAD "menu"
SAVE "menu"
NEW
to
LOAD "menu"
SAVE "MENU/ASC:2",a
NEW
then I imported the files (with the JCL file) into an emulator and let
it do its business. When done, I extracted the files and sent those to
Rick as well.
I lament that no Windows emulator can run full speed (Keil's DOS
emulator can, but there are SEVERE compatibility issues with Keil's DOS
emulator and XP, and with Keil's DOS emulator and LCD monitors), so the
ASCII conversion was in real time. There are a few tasks which are very
time consuming (such as ASCII conversion, file copying, and
superscripsit to ASCII conversion), and a full-tilt emulator would be
useful for such tasks.
I hope all this helps and that I didn't miss anything. I seem to read
people's disks at a rate of at least 1 set a week, so this is pretty
rote for me at this point. I apologize if I didn't describe a step.
Ira
Grinder
[snip]
> ... It would be WONDERFUL if someone would/could
> develop an extractor for the PC which could handle all the different
> DOS's and handle DMK's (TRSREAD cannot handle DMK's and one must convert
> DMK to DSK first, using Tim Mann's catweasel utility DMK2JV3).
It's an interesting project, I wish I had the time to devote to it.
Thanks for the run-down, it's interesting stuff.
Miguel Dutra
In fact I am working on such project for a few months now. It's
development is going kind of slowly, but I think the first release is
already able to fulfill the needs you presented here. Please, take a
look at http://www.mdutra.com/asm/vdisk. I intend to release a new
version in the weeks.
Miguel.
tur...@gmail.com
Ira, and all,
Thanks for taking the time to break down your conversion and archiving
processes. I hope that some of the emulator authors can see the
specific issues you run into doing batch conversions and might improve
the emulators with build in 'macro' tools that would speed your
conversion. For instance, I know Tim Mann has done work already with
Scripsit conversion, perhaps a stand alone utlity or even a utility
attached to a menu in xtrs that would convert these files would be
helpful.
Also I can see from some of the challenges mentioned here that a nice
emulator feature would be a way to take all screen output text and
pipe that into a text file... sort of a "save screen output as text"
option. This would be clever to implement in a way that would be
generally useful and predictable but when it was working it could be
very useful. Also, I've wondered if the emulators could emulate
typing but take the input from a file. I suppose both of these are
similar to Unix stdin or stdout.
Miguel and other utility developers... please read carefully Kim
Watt's Super Utility Plus manual to implement support for the widest
range of DOS structures! Kim has done so much work on deciphering
different DOS behavior already. Also since apparently he is still
around, if you ask him nicely he may remember some details on the odd
DOSes and their behavior. And if there isn't time to reverse engineer
DOS behavior by creating dummy disks in the emulators with the various
OS's then it might be quicker to reproduce similar actions using Super
Utility Plus.
(The DOSPLUS vs. LDOS differing sector count is a very interesting
observation.) Can the general audience here do anything collectively
as a research project to help document how each DOS structures it's
directory? How about creating a wiki page somewhere where we can all
contribute something about each DOS -?
On Jul 9, 6:23 pm, Miguel Dutra <magdu...@gmail.com> wrote:
> On Jun 9, 4:06 am, Grinder <grin...@no.spam.maam.com> wrote:
>
> > Ira wrote:
>
> > [snip]
>
> > > ... It would be WONDERFUL if someone would/could
> > > develop an extractor for the PC which could handle all the different
> > > DOS's and handle DMK's (TRSREAD cannot handle DMK's and one must convert
> > > DMK to DSK first, using Tim Mann's catweasel utility DMK2JV3).
>
> > It's an interesting project, I wish I had the time to devote to it.
> > Thanks for the run-down, it's interesting stuff.
>
> In fact I am working on such project for a few months now. It's
> development is going kind of slowly, but I think the first release is
> already able to fulfill the needs you presented here. Please, take a
> look athttp://www.mdutra.com/asm/vdisk. I intend to release a new