26 Apr
2011
26 Apr
'11
6:41 p.m.
Hi guys,
Here's a screenshot of the analysis side of the current DiscFerret
software build:
http://i162.photobucket.com/albums/t242/philpem/Screenshot-1.png
At the moment, I've got it reading IMG files (the format of some disc
images Chuck Guzis sent me a while back). CWI files are next on the hit
list (another one of Chuck's file formats) and then DFI files (the
DiscFerret native raw image format).
The GUI was built with wxWidgets, and in theory the code is completely
cross-platform compatible. I'm aware of wxWidgets backends for GTK, Mac
Cocoa/Carbon and Windows, so that covers all the major *nixes, OS X and
Windows. As long as you have a half-way decent C++ compiler, that is
(*cough* GCC). However: I will openly admit that the code has only been
tested on Linux.
It slows down to an absolute crawl (~60 seconds refresh time) if you
turn anti-aliasing on... though I suppose that's to be expected when you
ask it to plot 30-odd thousand data points on a scatter chart...
The raw-reader app is working too -- I can specify the various
parameters of a disc drive, and do a full track-by-track read of an
entire disc, and dump the data into a file. Next on the 'add list' is
DFI support (so the analyser can read it, of course!) then disc-format
script support.
Effectively, I want a tool which can be told what type of drive is in
use, what disc format, and will automatically figure out whether
double-stepping is needed, and what read parameters to use. Even to the
point where it'll warn you if you specify a 100tpi format and a 96 or
48tpi drive... Built in sanity checking :)
Which now brings us onto naming -- the reader app currently calls itself
"discferret-read", and the analyser "Merlin". Can anyone think of
better
names for these, or should I be lazy leave them as-is?
(Suggestions on an email to the usual address please!)
At this point the reader app is close to releasable (involving maybe a
few more weeks of work assuming I find a ready supply of Round Tuits),
but the analyser needs a lot more work. Mainly because I seem to be
spending a lot of time chasing mismatched-free bugs in the algorithms.
Thank $DEITY for Valgrind (and a great big sarcastic "gee, *thanks
guys*" to the GTK developers who have obviously never heard of it, much
less used it on their own code...)
Cheers,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
29 Apr
29 Apr
12:12 p.m.
Philip Pemberton <classiccmp at philpem.me.uk> writes:
Mainly because I seem to be spending a lot of time
chasing
mismatched-free bugs in the algorithms. Thank $DEITY for Valgrind (and
a great big sarcastic "gee, *thanks guys*" to the GTK developers who
have obviously never heard of it, much less used it on their own
code...)
Have you read the glib documentation, specifically the "Running and
debugging GLib Applications"[1] section? Check what they have to say
about the G_SLICE and G_DEBUG environment variables and you frustration
with the GTK developers will probably decrease :)
Running with G_SLICE=always-malloc and G_DEBUG=gc-friendly will remove
most valgrind warnings from inside GTK. Remember that glib and GTk does
not free (at termination) structures and configuration data that are
useful during the full lifetime of the process so you'll probably want
to write a valgrind suppression file for
that. http://live.gnome.org/Valgrind contains more information about GTK
and valgrind.
Regards,
--Frej
[1] http://developer.gnome.org/glib/2.28/glib-running.html
2:37 p.m.
... And now it does Speedgraph analysis and peak display too:
http://i162.photobucket.com/albums/t242/philpem/Screenshot-1-2.png
That's a partial image of a TRS-80/4 floppy. The logarithmic histogram
shows that there's a good separation between the various timing 'zones',
which means it should be fairly easy to get a good read from this disc.
The scatter plot shows similar gaps between the timing lines, further
emphasising this point.
The three peaks on the histogram suggest MFM coding, with a base time
period of around a microsecond. This gives a data rate of ~250kbps.
Moving onto the scatter plot, you can see what appears to be nine
distinct sectors. The first three are apparently blank (0xFF), with data
in the remaining six.
From the speed graph, the 'cut points' (inter-sector gaps) between the
sectors are even more obvious as fuzzy 'blobs' with large spikes at the
transition points.
So there you have it :)
I'm going to add a few more file formats to the image loader, give the
read tool the ability to actually *write* something, then you can all
have a play with these lovely little toys :)
Cheers,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
4:56 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On Fri, 29 Apr 2011, Philip Pemberton wrote:
That's a partial image of a TRS-80/4 floppy. The
logarithmic histogram
. . .
The three peaks on the histogram suggest MFM coding, with a base time
period of around a microsecond. This gives a data rate of ~250kbps.
. . .
Moving onto the scatter plot, you can see what appears to be nine
distinct sectors. The first three are apparently blank (0xFF), with data
in the remaining six.
Are you SURE that that disk is from a TRS80?
TRS-DOS and its derivatives normally had 256 bytes per sector (18 sectors
per track)
5:09 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On 30/04/11 00:56, Fred Cisin wrote:
Are you SURE that that disk is from a TRS80?
TRS-DOS and its derivatives normally had 256 bytes per sector (18 sectors
per track)
Hmm. I've got it listed as "TRS-80 Model 4P" in my catalogue. Maybe I
need to feed it through one of the decoders and see what happens...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
6:24 p.m.
New subject: [Discferret] Latest DiscFerret beta software
> Are you SURE that that disk is from a TRS80?
> TRS-DOS and its derivatives normally had 256 bytes per sector (18 sectors
> per track)
On Sat, 30 Apr 2011, Philip Pemberton wrote:
Hmm. I've got it listed as "TRS-80 Model
4P" in my catalogue. Maybe I
need to feed it through one of the decoders and see what happens...
I don't remember for sure, but the CP/M 3.0 that was also available for
the model 4 might have been 9 x 512
--
Grumpy Ol' Fred cisin at xenosoft.com
6:29 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On 30 Apr 2011 at 1:09, Philip Pemberton wrote:
Hmm. I've got it listed as "TRS-80 Model
4P" in my catalogue. Maybe I
need to feed it through one of the decoders and see what happens...
Well, there *was* a Mod 4 CP/M format that was 8 sectors of 512
bytes, but no 9 AFAIK.
--Chuck
7:52 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On 30/04/11 02:29, Chuck Guzis wrote:
On 30 Apr 2011 at 1:09, Philip Pemberton wrote:
18/256 looks more likely.
The head-zero tracks all have far more than 9 sectors on them. With so
many sectors it's hard to tell, but 18 seems plausible based on the
inter-sector gaps.
Those 9/512 sectors look suspiciously like DOS 360K tracks... though
what I don't get is why every track is formatted like that. DOS 360K is
only 40 tracks. Unless it was read in a 40-track drive..?
What a cock-up. My face is red! (though probably more because my desk
fan's packed in, and it's like an oven in here!)
At least it's not as "strange and unusual" as the Durango F-85 format.
GCR, 12 sectors (or it *looks* like 12 sectors at least)... Without a
GCR code table, I probably won't get far with that one...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
Hmm. I've got it listed as "TRS-80 Model
4P" in my catalogue. Maybe I
need to feed it through one of the decoders and see what happens...
Well, there *was* a Mod 4 CP/M format that was 8 sectors of 512
bytes, but no 9 AFAIK.
8 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On 30 Apr 2011 at 3:52, Philip Pemberton wrote:
The head-zero tracks all have far more than 9 sectors
on them. With so
many sectors it's hard to tell, but 18 seems plausible based on the
inter-sector gaps.
Well, yes, there were 18-sector, 256 byte/sector single-sided formats
for the model 4--MT CP/M comes to mind as one. Doubtless there was
also a similar TRSDOS format.
--Chuck
8:03 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On 30 Apr 2011 at 3:52, Philip Pemberton wrote:
At least it's not as "strange and
unusual" as the Durango F-85 format.
GCR, 12 sectors (or it *looks* like 12 sectors at least)... Without a
GCR code table, I probably won't get far with that one...
12 sectors is correct, and they're 512 bytes. Consider looking at
the sector ID fields--those are of a known structure ( C H R N+crc)
and follow a logical sequence.
That's how I figured out a couple of word processor formats, as well
as a Future Data development system.
--Chuck
8:25 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On Sat, 30 Apr 2011, Philip Pemberton wrote:
18/256 looks more likely.
The head-zero tracks all have far more than 9 sectors on them. With so
many sectors it's hard to tell, but 18 seems plausible based on the
inter-sector gaps.
Those 9/512 sectors look suspiciously like DOS 360K tracks... though
what I don't get is why every track is formatted like that. DOS 360K is
only 40 tracks. Unless it was read in a 40-track drive..?
40 track Single sided drives were standard in TRS80. If a disk was
formatted PC360K, and then RE-formatted on TRS80, then you would have 18 x
256 on side 0 and 9 x 412 on side B
Model 1 was sssd 35 cylinder 10 x 256 (cf. Osborne SD)
aftermarket DD
Model 3 SSDD 40 cylinder 18 x 256
aftermarket CP/M and other mods, DS, 80 cylinder, etc.
some of the aftermarket CP/M mods used a variety of different disk formats
Model 4
same as model 3, but 80 x 24 video, memory mappable to 64K contiguous
CP/M 3.0 available from Radio Shack (8? x 512), but didn't catch on
Model 4P
same as model 4, in a Compaq like luggable case
Never expect a TRS80 disk to be adequately labeled as to what it is.
LOTS of "EVERYBODY uses Dos-Plus", "NOBODY uses TRS-DOS", etc.
--
Grumpy Ol' Fred cisin at xenosoft.com
30 Apr
30 Apr
11:49 a.m.
New subject: [Discferret] Latest DiscFerret beta software
Model 4
same as model 3, but 80 x 24 video, memory mappable to 64K contiguous
The logic voard of a M4 could accept 128K of RAM. Yes, you could only
have 64K in the CPU memory map at a time, and AFIAK very little
application software made use of the 'extra' memory. It was commonly used
fo a RAMdisk or print spooler.
CP/M 3.0 available from Radio Shack (8? x 512), but
didn't catch on
Unless you wanted to run CP/M software (which is, I agree, a pretty big
reason), TRS-DOS (LS-DOS) was a much micer OS that CP/M. I have M4 CP/M
somewhere, I think I booted it once, but that was it. I still use my H4,
but under TRS-DOS.
Model 4P
same as model 4, in a Compaq like luggable case
Same disk format and OS, sure, but there are a few hardware differences.
The main one is that the 4P only existed as a disk system (the plain M4
could exist without disks, running ROM BASIC and using a cassette tape
for storage), and as such it didn't have the BASIC ROMs, only a simnple
bootstrap ROM. There was a file on the TRS-DOS master disk that would
effectively load a ROM image into the bottom part of RAM so as to be able
to run softeware that expected said ROM.
-tony
3:47 p.m.
New subject: [Discferret] Latest DiscFerret beta software
On Sat, 30 Apr 2011, Tony Duell wrote:
I didn't know about the lack of the BASIC ROMs.
'course, I can always fall back on, "I was only talking about the disk
format"
--
Grumpy Ol' Fred cisin at xenosoft.com
The logic voard of a M4 could accept 128K of RAM. Yes,
you could only
have 64K in the CPU memory map at a time, and AFIAK very little
application software made use of the 'extra' memory. It was commonly used
fo a RAMdisk or print spooler.
Many CP/M machines with 128K used it to be able to expand the TPA from
about 53K up to about 63K.
Model 4P
same as model 4, in a Compaq like luggable case
Same disk format and OS, sure, but there are a few hardware differences.
The main one is that the 4P only existed as a disk system (the plain M4
could exist without disks, running ROM BASIC and using a cassette tape
for storage), and as such it didn't have the BASIC ROMs, only a simnple
bootstrap ROM. There was a file on the TRS-DOS master disk that would
effectively load a ROM image into the bottom part of RAM so as to be able
to run softeware that expected said ROM.
11:43 a.m.
New subject: [Discferret] Latest DiscFerret beta software
On 30/04/11 02:29, Chuck Guzis wrote:
The original TRS-80 5.25" drives (even as late as the M4) were, by
default, single-sided, and formated to 35 tracks only. Needless to say
everybody formatted them to 40 traceks to get a bit more storage capactiy
(I've yet to fidn a M3 or M4 fitted with drives that couldn't handle 40
tracks).
My guess is that what you have is a pre-formatted PC disk which was
reformatted for use on the TRS-80. This would expalin why side 1 has a
PC-like format.
The M4 version of TRS-DOS (which is LS-DOS, really), and the disk
contorller hardware, can easily hadnle 80 cylinder drives and
double-sided operation. Many TRS-80s had such drives added to them
(although keeping a 40 cylinder drive as :0 (the boot drive) was also
common for compatibility).
-tony
On 30 Apr 2011 at 1:09, Philip Pemberton wrote:
18/256 looks more likely.
The head-zero tracks all have far more than 9 sectors on them. With so
many sectors it's hard to tell, but 18 seems plausible based on the
inter-sector gaps.
Those 9/512 sectors look suspiciously like DOS 360K tracks... though
what I don't get is why every track is formatted like that. DOS 360K is
only 40 tracks. Unless it was read in a 40-track drive..? Hmm. I've got it listed as "TRS-80 Model
4P" in my catalogue. Maybe I
need to feed it through one of the decoders and see what happens...
Well, there *was* a Mod 4 CP/M format that was 8 sectors of 512
bytes, but no 9 AFAIK. 
5 May
5 May
4:08 p.m.
New subject: IBM 5100 power supply available
Hi,
Pierre de Globe, at pierrebeau at globetrotter.net , wrote me, saying:
I have for sale a power supply unit for an early 1975 IBM 5100
the model one with a cassette drive.
If interested, contact me.
I wasn't interested, and after exchanging an email or two, I
volunteered to post the above here in case anyone wants a power supply.
If you're interested, email Pierre.
Don't email me :) (I have no other information about the power supply or Pierre.)
thanks,
Stan
4746
days inactive
4754
days old
14 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
frej.drejhammar＠gmail.com -
ss＠allegro.com