27 Jan
2012
27 Jan
'12
4:18 p.m.
Hi everybody,
I've had delivery turned off for a long time - seems I'm no longer
subscribed as my password does not work ... hopefully this will make
it to the list, however I will not receive replies sent to the list
except by checking the archives (which I don't do very often).
I checked the archives today to see if a chap I had directed to the
list got help with SuperBrain disks. I see several comments that I
"should have them".
I've never been able to read the diskettes from my original SuperBrain.
I can read the first two tracks, then errors on every track - missing
address marks. I cannot read them with ImageDisk nor TeleDisk. I've
tried multiple different drives and types of drives - I simply cannot
read the SuperBrain disks on anything except the SuperBrain.
Every so often this comes up, and several people say "but SuperBrain
disks are bog standard and easy to read" - so apparently I am the only
one on the planet who can't read them. After explaining the above (that
I simply cannot read them, and that I have in fact tried really hard) - I
always get several offers to send me images or disks that can be read
... but nobody has every followed through, which is why I do not have
SuperBrain disks on my site.
I do have another system called a "CompuStar" which is a rebadged
SuperBrain - and most of the disk from that system ARE readable on a
PC ... BUT... the guy who owned it really liked APL, and created his
own character generator ROM and custom BIOS to support APL characters
on the machine ... All of his disks are "hand made" (not originals) and
although his disks boot, they display incomprehensible garbage on a
normal SuperBrain. Therefore I see little point in posting them as
SuperBrain disks. I've only found one disk from his collection which
boots and displays on the normal Brain - and it has the missing address
mark problem.
I've tried booting the Compustar disks on the SuperBrain and blind-
formatting a disk --- but the created disk is still unreadable. I am
assuming that the Z80 based disk controller in my SuperBrain makes
disks which are not readable on a PC (the SB reads them fine). It can
boot and read the CompuStar disks, however it does not appear to be
able to format a readable disk.
Unfortunately the Compustar is not currently working, and will need
significant work to repair - so I cannot try formatting disks on it.
And I am unable to create anything on the SuperBrain which I can read
on the PC.
Which is why I cannot provide disk images for the SuperBrain. I've
tried - I simply cannot make it happen.
Dave
--
dave12 (at) Dave Dunfield
dunfield Firmware development services & tools: www.dunfield.com
(dot) com Classic computers: http://www.classiccmp.org/dunfield/
28 Jan
28 Jan
5:52 a.m.
Hi Guys,
After reading recent comments (including my own), and thinking
about it for a bit - I came up with a way to make images of my
SuperBrain disks.
Seems like the "smart" disk controller in my SuperBrain always
formats with non-standard address marks.... but since it can read
and write the CompuStar disks, it does not seem to have trouble
accessing disks with standard address marks.
So.. I used ImageDisk to create some blank formatted disks (with
standard address marks), then PIP'd all the files from my original
disks to these new ones - then I read them into images, and used
ImageDisk to replace the blank system tracks with the system
tracks from the original disks (fortunately the system tracks have
standard address marks).
I tested the resulting images by writing them back to some fresh
disks and booting them in my SuperBrain - and everything seems
to work!
I've posted these "slightly modified" images of my original CP/M
and ZCPR disks for the SuperBrain to my site - look for "Intertec
SuperBrain" under "System disks".
Dave
--
dave12 (at) Dave Dunfield
dunfield Firmware development services & tools: www.dunfield.com
(dot) com Classic computers: http://www.classiccmp.org/dunfield/
2:27 p.m.
On Sat, 28 Jan 2012, Dave Dunfield wrote:
After reading recent comments (including my own), and
thinking
about it for a bit - I came up with a way to make images of my
SuperBrain disks.
Seems like the "smart" disk controller in my SuperBrain always
formats with non-standard address marks.... but since it can read
and write the CompuStar disks, it does not seem to have trouble
accessing disks with standard address marks.
That technique works for MOST formats with address mark issues.
Unfortunately not some of the TRS-DOS address mark issues.
There are several formats in XenoCopy, where it is necessary to
generate a formatted disk for the alien format using the PC,
copy the files on the alien machine to the "pseudo" disk,
and then bring the "psuedo" disk back to the PC for conversion.
That is also applicable for quite a few formats, such as double
sided Kaypro, where the computer writes sector headers with invalid
side numbers, but doesn't object to reading nor writing sectors that
happen to have correct sector headers.
In addition to address marks, disks with 10 * 512 have a crowded track,
and may take liberties with tht length of the index gap and inter-sector
gaps.
The very visible inverted data is merely a trivial inconvenience in
comparison.
I've posted these "slightly modified"
images of my original CP/M
and ZCPR disks for the SuperBrain to my site - look for "Intertec
SuperBrain" under "System disks".
THANK YOU!!
That should help a lot of people.
--
Grumpy Ol' Fred cisin at xenosoft.com
2:45 p.m.
On 28 Jan 2012 at 14:27, Fred Cisin wrote:
Didn't I say the same thing TWO DAYS ago? I even offered to ship a
copy of the modified image to the OP and got no response.
Or is it that people don't know what "DAM" stands for?
Give me a clue, folks.
--Chuck
I've
posted these "slightly modified" images of my original CP/M and
ZCPR disks for the SuperBrain to my site - look for "Intertec
SuperBrain" under "System disks".
THANK YOU!!
3:07 p.m.
On Sat, 28 Jan 2012, Chuck Guzis wrote:
Didn't I say the same thing TWO DAYS ago? I even
offered to ship a
copy of the modified image to the OP and got no response.
Or is it that people don't know what "DAM" stands for?
Give me a clue, folks.
MOST don't know what it stands for, nor the issues involved in
non-standard ones. Remember how the discussion got side-tracked
into an assumption that the inverted data was the problem?
Sometimes, you just have to give step-by-step procedures. REPEATEDLY.
3:40 p.m.
On 28 Jan 2012 at 15:07, Fred Cisin wrote:
MOST don't know what it stands for, nor the issues
involved in
non-standard ones. Remember how the discussion got side-tracked
into an assumption that the inverted data was the problem?
Sometimes, you just have to give step-by-step procedures. REPEATEDLY.
I guess you're right. I'll start by explaining which side of a
floppy is up--not so easy with users of early Altos boxes...
While it's true that the data on Superbrain floppies is
inverted/complemented, the remainder of the floppy is normal (i.e.
address marks, sector ID information, etc. is in the "normal" state.
Off the top of my head, the Columbia, Comupustar, M&K (Michels and
Kleberhoff), the Sharp MZ-80, and the Shelton systems also did it.
Actually, the Sharp MZ-80B also "inverted" the data in the sense that
side 0 is the top side of the floppy and side 1 the "bottom" side.
As far as "why?", I haven't a clue.
Sigh,
Chuck
5:32 p.m.
________________________________
From: Chuck Guzis <cclist at sydex.com>
I guess you're right.? I'll start by explaining which side of a
floppy is up--not so easy with users of early Altos boxes...
C: There is no "up" w/double sided disks on a Commie 64 either. You nibble notch
that bad boy, then flip it over and keep recording. I still have my original nibble
notcher too. Suncom I think.
29 Jan
29 Jan
8:44 a.m.
Chris M wrote:
________________________________ From: Chuck Guzis <cclist at sydex.com>
I guess you're right. I'll start by explaining which side of a floppy
is up--not so easy with users of early Altos boxes...
C: There is no "up" w/double sided disks on a Commie 64 either. You
nibble notch that bad boy, then flip it over and keep recording. I still
have my original nibble notcher too. Suncom I think.
... unlike Acorn, where the DFS firmware would treat separate disk surfaces
as completely different logical drives:
logical drive 0 = physical drive 1, top surface
logical drive 1 = physical drive 2, top surface
logical drive 2 = physical drive 1, bottom surface
logical drive 3 = physical drive 2, bottom surface
Access to logical drives 1 and 3 would give an error in a single-drive system.
It'd be interesting to know how common that kind of setup was. Most floppy
image formats seem to expect there to just be one 'thing' on a disc (i.e.
the floppy is either single-sided, or double-sided with the filesystem
spanning the whole disk), and metadata can only be attached to the image as
a whole.
cheers
Jules
11:37 a.m.
[Treating the 2 sides of a DS floppy as separate 'drives']
It'd be interesting to know how common that kind
of setup was. Most floppy
It wasn;'t uncommon at one time. The RML380Z did it IIRC (I think C: and
D: were the flip sides of A: and B: respectively). I've seen other
machines that do it too, but the neames don't instantly spring to mind).
When I added a double-sided 3" (not 3.5") drive to my CoCo (all those
years ago...), I added a lit little bit of hardware (a couple of TTL ICs)
to allow the drive to appearr either as a sdouble-sided drive 1 (using
the Side Select line in the normal way) or a a pair of single-sided
drives 1 and 2. The ROM-based OS used iwth BASIC could onlt handle the
latter, OS-9 could work with either (but woe betide me if I set the
switch wrongkly, I would end up wit ha corrupted filesystem on the disk).
image formats seem to expect there to just be one
'thing' on a disc (i.e.
the floppy is either single-sided, or double-sided with the filesystem
spanning the whole disk), and metadata can only be attached to the image as
a whole.
Isn't the solution to image the 2 sides sparately as single-sided disks?
-tony
3:10 p.m.
Jules Richardson wrote:
... unlike Acorn, where the DFS firmware would treat
separate disk
surfaces as completely different logical drives:
logical drive 0 = physical drive 1, top surface
logical drive 1 = physical drive 2, top surface
logical drive 2 = physical drive 1, bottom surface
logical drive 3 = physical drive 2, bottom surface
Access to logical drives 1 and 3 would give an error in a single-drive
system.
Not quite right, because upside down.
logical drive 0 = physical drive 1, bottom surface
logical drive 1 = physical drive 2, bottom surface
logical drive 2 = physical drive 1, top surface
logical drive 3 = physical drive 2, top surface
Remember a single-sided drive has the lower head but not the upper.
--
Pete Peter Turnbull
Network Manager
University of York
30 Jan
30 Jan
10:39 a.m.
Pete Turnbull wrote:
Jules Richardson wrote:
I thought when writing that I might have that backwards! :-)
Re. Tony's mention of the 380Z, yes I think it did treat surfaces of the
media as different drives too, just with the surface designations iterating
"drive first" rather than Acorn's "surface first".
I expect that most machines of the era came with either single or
double-sided drives and the OS/firmware was coded to treat the entire disk
as a single entity.
cheers
Jules
... unlike Acorn, where the DFS firmware would
treat separate disk
surfaces as completely different logical drives:
logical drive 0 = physical drive 1, top surface
logical drive 1 = physical drive 2, top surface
logical drive 2 = physical drive 1, bottom surface
logical drive 3 = physical drive 2, bottom surface
Access to logical drives 1 and 3 would give an error in a single-drive
system.
Not quite right, because upside down.
11:26 a.m.
On 30 Jan 2012 at 12:39, Jules Richardson wrote:
I expect that most machines of the era came with
either single or
double-sided drives and the OS/firmware was coded to treat the entire
disk as a single entity.
Exactly HOW the second side of a floppy was used by various
manufacturers was wildly variable--even the order of sectors was
subject to variation.
For example:
MS-DOS (and many other formats) start at the outermost cylinder and
use the lower side sectors, then the upper side sectors, then move to
the next cylinder.
Many CP/M formats use all of the sectors starting with cylinder 0 on
the lower side, then go back to cylinder 0 and use all of the sectors
on the bottom side.
Other CP/M formats use all of the sectors starting with cylinder 0 on
the lower side, then turn around on the upper side and work backwards
from the highest cylinder to cylinder 0.
The National Semi BLC 86 systems start at the middle cylinder (39 on
an 80-cylinder drive) to hold the directory, then allocate top and
bottom sides, alternately working up to cylinder 79 and down to
cylinder 0.
Some, such as the Cifer, add a logical "skew" to heads as well as
tracks, so that the first sector on each track and side is different.
And at least one (I'd have to go to my notes), interleaves the
sectors on the top and bottom side before moving to the next
cylinder.
I suppose arguments can be made for any of these.
--Chuck
11:42 a.m.
On 30 Jan 2012 at 11:26, Chuck Guzis wrote:
> Many CP/M formats use all of the sectors starting
with cylinder 0
on
the lower side, then go back to cylinder 0 and use all
of the sectors
on the bottom side.
Make that "go back to cylinder 0 and use all of the sectors on the
top side".
--Chuck
29 Jan
29 Jan
9:01 a.m.
On 28 Jan 2012 at 17:32, Chris M wrote:
I guess you're right.? I'll start by
explaining which side of a
floppy is up--not so easy with users of early Altos boxes...
C: There is no "up" w/double sided disks on a Commie 64 either. You
nibble notch that bad boy, then flip it over and keep recording. I
still have my original nibble notcher too. Suncom I think.
Factory "flippies" weren't uncommon in the 8" format at all. Most
of mine simple have the brand "Diskette" (at one time it was a
proprietary trademark).
--Chuck
10:27 a.m.
> I guess you're right.? I'll start by
explaining which side of a
> floppy is up--not so easy with users of early Altos boxes...
> C: There is no "up" w/double sided disks on a Commie 64 either. You
> nibble notch that bad boy, then flip it over and keep recording. I
> still have my original nibble notcher too. Suncom I think.
On Sun, 29 Jan
2012, Chuck Guzis wrote:
Factory "flippies" weren't uncommon in
the 8" format at all. Most
of mine simple have the brand "Diskette" (at one time it was a
proprietary trademark).
Are there ANY 3" (NOT 3.5") that are NOT double-sided?
Some are double sided with two-head drives, some are flippies.
10:38 a.m.
New subject: Flippy (Was: SuperBrain Disks
On Sat, 28 Jan 2012, Chris M wrote: C: There is no "up" w/double sided
disks on a Commie 64 either. You nibble notch that bad boy, then flip it
over and keep recording. I still have my original nibble notcher too.
Suncom I think.
There's a little more to deal with if you want to make flippies out of
disks for machines that are aware of the index pulse. The Berkeley
Microcomputer Flip-Jig (tm) was by far the best jig for marking the disks.
11:21 a.m.
On 28 Jan 2012 at 15:07, Fred Cisin wrote:
And then do it for owners of a real RX50 drive... (For the uninitiated --
I almost wrote unitialised :-) -- the RX50 is a double 5.25" drive where
one disk goes in lable-up, the other lable down. Yes, the 2 spindles do
rotate in oppsite directions inside. It makes mechancial sense when you
see how the drive is put togehter, but it's confusing to the user.
MOST don't know what it stands for, nor the
issues involved in
non-standard ones. Remember how the discussion got side-tracked
into an assumption that the inverted data was the problem?
Sometimes, you just have to give step-by-step procedures. REPEATEDLY.
I guess you're right. I'll start by explaining which side of a
floppy is up--not so easy with users of early Altos boxes...
While it's true that the data on Superbrain
floppies is
inverted/complemented, the remainder of the floppy is normal (i.e.
address marks, sector ID information, etc. is in the "normal" state.
Off the top of my head, the Columbia, Comupustar, M&K (Michels and
Kleberhoff), the Sharp MZ-80, and the Shelton systems also did it.
Actually, the Sharp MZ-80B also "inverted" the data in the sense that
side 0 is the top side of the floppy and side 1 the "bottom" side.
As far as "why?", I haven't a clue.
Well, for inverting the data : I seem to eemember that Western Digital
disk controlelr ICs were avaialbe with both normal and iverted data
buses. If you used the 'wrong' one and cpoied data from ememory to the
disk cotnrolelr chip using either DMA or a tight software l;oop, you
woudl end up wit hinverted data patterns of the disk, but of course the
DAMs, etc, would be normal. Perhaps the inverted-bus version was easier
to get, or cheaper, or something
Of course an inverting buffer chip would solve the problem, but then as
now, far too many companies reduce the parts count as far as possible.
-tony
12:12 p.m.
On 01/29/2012 02:21 PM, Tony Duell wrote:
And then do it for owners of a real RX50 drive... (For
the uninitiated --
I almost wrote unitialised :-) -- the RX50 is a double 5.25" drive where
one disk goes in lable-up, the other lable down. Yes, the 2 spindles do
rotate in oppsite directions inside. It makes mechancial sense when you
see how the drive is put togehter, but it's confusing to the user.
It seems less confusing, if only a bit, when the drive is mounted
vertically, as is the case of a Pro325/350/380, Rainbow, or BA23 mounted
in their floor-standing shrouds, or a BA123 in the vertical bay.
-Dave
--
Dave McGuire
New Kensington, PA
1:02 p.m.
> Or is it that people don't know what
"DAM" stands for?
MOST don't know what it stands for, [...]
For what it may be worth, I saw "DAM" and wondered what it meant. If I
cared about SuperBrains (I got out of such machines a while ago) I
would have asked.
Not that my reasons are very relevant to anyone else's reactions.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1:39 p.m.
Or is it that people don't know what
"DAM" stands for?
MOST don't know what it stands for, [...]
30 Jan
30 Jan
12:24 p.m.
> Or is it that people don't know what
"DAM" stands for?
MOST don't know what it stands for, [...]
For what it may be worth, I saw "DAM" and wondered what it meant. If I cared about SuperBrains (I got out of such machines a
while ago) I
would have asked.
It's not specific to Superbrains. I think all soft-sectored FM and MFM
floppies use them.
-tony
3:11 p.m.
On Mon, 30 Jan 2012, Tony Duell wrote:
'Data Address Mark'. Basically am
'illegal' pattern of pulses on the disk
(one that can't occur elsewhere in a sector) the indicates the start of a
new sector or soemthing like lat.
But, not all MIS-use them on the scale of Superbrain and TRSDOS
cared about SuperBrains (I got out of such
machines a while ago) I
would have asked.
It's not specific to Superbrains. I think all soft-sectored
FM and MFM
floppies use them.
3:56 p.m.
On 30 Jan 2012 at 15:11, Fred Cisin wrote:
But, not all MIS-use them on the scale of Superbrain
and TRSDOS
Only in the sense of "misuse" being that used by common commonity
disk controllers. In fact, the possibilities for their use are
probably close to 255. For example, the Intel MDS800 "double
density" MMFM format uses 0B with a clock of 70 for a DAM or 08/72
for a DDAM (deleted DAM).
Most controllers can support DDAMs but few operating systems actually
use them. Most often, you see them used on the cylinder 0/track 0
volume header used by IBM 3740-compatible formats.
--Chuck
4:19 p.m.
New subject: DAMs (Was: SuperBrain Disks
On Mon, 30 Jan 2012, Chuck Guzis wrote:
Only in the sense of "misuse" being that
used by common commonity
disk controllers. In fact, the possibilities for their use are
probably close to 255. For example, the Intel MDS800 "double
density" MMFM format uses 0B with a clock of 70 for a DAM or 08/72
for a DDAM (deleted DAM).
Most controllers can support DDAMs but few operating systems actually
use them. Most often, you see them used on the cylinder 0/track 0
volume header used by IBM 3740-compatible formats.
Yes, there are plenty of valid uses for them.
But, I'll stick with calling Superbrain a MIS-use.
What did it accomplish?
In the case of TRSDOS, I think that I get what Randy Cook had in
mind, but he never completed code for that use to actually do any good.
TRSDOS3 and VTOS showed that he was capable of starting incredible
projects with little hope of finishing them.
4:47 p.m.
New subject: DAMs (Was: SuperBrain Disks
On 30 Jan 2012 at 16:19, Fred Cisin wrote:
But, I'll stick with calling Superbrain a
MIS-use.
What did it accomplish?
I'm sure their goal was "lock-in". When looking at the pre-PC world,
many people fail to understand that "lock-in" was a common product
concern. Keeping technical details secret was normal business
practice.
As in "How do I take all of my B5500 code and run it on my 7090?"
Of course, we have evolved past such nonsense dropped the idea of
secrecy ensuring lock-in. We now depend on actual reliability,
economy and usefulness of products to be the determining criteria
for product selection.
--Chuck
5 p.m.
New subject: DAMs (Was: SuperBrain Disks
On Jan 30, 2012, at 7:47 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
Of course, we have evolved past such nonsense dropped
the idea of
secrecy ensuring lock-in. We now depend on actual reliability,
economy and usefulness of products to be the determining criteria
for product selection.
[head explodes]
--
Dave McGuire
New Kensington, PA
5:29 p.m.
New subject: DAMs (Was: SuperBrain Disks
On Jan 30, 2012, at 7:47 PM, "Chuck Guzis"
<cclist at sydex.com> wrote:
> Of course, we have evolved past such nonsense dropped the idea of
> secrecy ensuring lock-in. We now depend on actual reliability,
> economy and usefulness of products to be the determining criteria
> for product selection.
On Mon, 30 Jan 2012, Dave McGuire wrote:
[head explodes]
Yeah!
Chuck isn't generally given to sarcasm.
Chuck,
If you are being held against your will, top-post a "Me Two", add a
political and religious rant, and explain why fiberglass tubas sound
better than brass.
5:55 p.m.
New subject: DAMs (Was: SuperBrain Disks
On 30 Jan 2012 at 17:29, Fred Cisin wrote:
(Glances over shoulder) Oh no, I'm serious. I also agree with the
findings of this study:
http://bit.ly/zjwbOV
(Glances over shoulder again) Okay?
--Chuck
(It's the season for exploding heads, dontcha know.)
Chuck,
If you are being held against your will, top-post a "Me Two", add a
political and religious rant, and explain why fiberglass tubas sound
better than brass. 
5:12 p.m.
New subject: DAMs (Was: SuperBrain Disks
On Jan 30, 2012, at 7:47 PM, Chuck Guzis wrote:
Of course, we have evolved past such nonsense dropped
the idea of
secrecy ensuring lock-in. We now depend on actual reliability,
economy and usefulness of products to be the determining criteria
for product selection.
Ha! Had me there for a minute.
Though I suppose that does hold true depending on the "we" in question.
- Dave
5:15 p.m.
New subject: DAMs (Was: SuperBrain Disks
> But, I'll stick with calling Superbrain a
MIS-use.
> What did it accomplish?
On Mon, 30 Jan 2012, Chuck Guzis wrote:
I'm sure their goal was "lock-in". When
looking at the pre-PC world,
many people fail to understand that "lock-in" was a common product
concern. Keeping technical details secret was normal business
practice.
As in "How do I take all of my B5500 code and run it on my 7090?"
Yes, that was certainly the mindset that I encountered with the Intertec
booth-suits at NCC Anaheim. I don't think that it actually accomplished
any of their objectives.
Perhaps it's just my political orientation, but I will still persist in
calling that a MIS-use.
Of course, we have evolved past such nonsense dropped
the idea of
secrecy ensuring lock-in.
We HAVE??!?
The descendents of the B Ark??!?
We now depend on actual reliability, economy and
usefulness of products
to be the determining criteria for product selection.
We DO??!?
I want to emigrate THERE!
Around here, they're using XP and OutHouse. ("actual reliability,
economy and usefulness"??!?)
31 Jan
31 Jan
7:53 a.m.
New subject: DAMs (Was: SuperBrain Disks
Chuck Guzis wrote:
Of course, we have evolved past such nonsense dropped
the idea of
secrecy ensuring lock-in. We now depend on actual reliability,
economy and usefulness of products to be the determining criteria
for product selection.
Coffee just came out of my nose - and I wasn't even drinking coffee at the
time!
3:38 p.m.
On Mon, Jan 30, 2012 at 6:12 PM, Fred Cisin <cisin at xenosoft.com> wrote:
FM and MFM CAN be done without them, particularly if
it reads track at a
time.
What does tyhe Amiga do?
The Amiga does an entire track of raw data to and from GCR in memory
(via logical terms applied by the custom chipset) and slurps in or
spews out an entire track of GCR-encoded data via an
8000-plus-bit-long shift register (in the Paula/sound chip). On
reads, the shift register pulls in about 1.1 revolutions worth of data
and lets the logical terms do the GCR decoding on the entire buffer.
For writes, I think it writes nulls for a portion of a revolution, to
clear out old data, then it emits the GCR-encoded data as one write,
overlapping an unknown number of nulls (and by "null", I don't know if
it's binary 00000000; it could be a GCR-encoded "null" - I haven't had
to do that level of disk reads myself so I'm a little fuzzy at that
layer).
Unlike sector-at-a-time formats, the sector-to-sector gap on Amigas is
fixed and only as many bytes as required to wrap up one sector and
start another. The real "gap" is at the end of the track and is of
variable length depending on how many millimeters long the specific
track is and how many bits it holds.
The hardware is not *required* to do it that way, since Amigas can
read IBM-formatted floppies (DD or HD, if your Amiga is equipped with
a drive that rotates at half-speed for HD disks (since the shift
register can only go so fast)), but "Amiga Format" is always done with
the sectors jammed up against each other a track at a time.
Phrased differently (and perhaps more succinctly), Amigas do the
sector separation in software with a hardware assist from the graphics
chips to do it in fewer machine cycles (it's why floppy buffers have
to allocated in CHIP RAM that can slow the machine down due to
contention when elaborate screen modes are being displayed)
The whole ugly mess is largely documented in the Rom Kernel Modules,
but in practice, unless you happen to be writing GCR disk utilities,
most Amiga programmers don't do more than allocate buffers and call
system library routines to invoke hidden magic.
-ethan
10:42 a.m.
New subject: DAM it (Was: SuperBrain Disks
On Mon, 30 Jan 2012, Ethan Dicks wrote:
On Tue, 31 Jan 2012, Christian Corti wrote:
The Amiga does an entire track of raw data to and
from GCR in memory
[...] s/GCR/MFM/g
GCR was almost never used on the Amiga.
Thus supporting my contention of an instance of MFM without DAMs.
(FM/MFM and DAMs are both essential components of the "IBM"/WD track
format "standard", but are largely independent of each other - Amiga being
an example of MFM without the IBM/WD track structure.)
Although rightfully called "IBM standard" track format, use of that term
results in clueless lusers who think that computers started with 5150
thinking that we are talking about the PC.
Depending on how you define GCR, it can easily be argued that MFM
IS A TYPE OF GCR. Ethan is therefore not WRONG.
--
Grumpy Ol' Fred cisin at xenosoft.com
11:43 a.m.
New subject: DAM it (Was: SuperBrain Disks
On Tue, Jan 31, 2012 at 1:42 PM, Fred Cisin <cisin at xenosoft.com> wrote:
Doh! Too many years since I was grubbing around at that level
(following too many years of deep grubbing on 4040s and 1541s).
On Mon, 30 Jan
2012, Ethan Dicks wrote:
On Tue, 31 Jan 2012, Christian Corti wrote:
> s/GCR/MFM/g
> GCR was almost never used on the Amiga. The Amiga does an entire track of raw data to and
from GCR in memory
[...] Thus supporting my contention of an instance of MFM
without DAMs.
(FM/MFM and DAMs are both essential components of the "IBM"/WD track
format "standard", but are largely independent of each other - Amiga being
an example of MFM without the IBM/WD track structure.)
Yes. If you were to magnaflux an IBM/WD diskette, it would look
radically different (pun intended) from an Amiga diskette, the biggest
visible difference being individual sectors with variable gaps vs
jammed-together sectors with a variable-length tail. The consequence
of such is that the Amiga doesn't have to look for the start of a
sector when reading - it just opens the gates, slurps up slightly more
than one turn of the medium and figures out what's what in software.
Depending on how you define GCR, it can easily be
argued that MFM
IS A TYPE OF GCR. ?Ethan is therefore not WRONG.
Thanks for defending me, but I mis-remembered. CBM disks use a
recognizable GCR, and Amiga floppies use an MFM scheme. The rest
should be accurate (sectors are adjacent without variable intersector
gaps, and the blitter engine is used to convert to/from binary buffers
in CHIPMEM)
-ethan
1 Feb
1 Feb
1:43 a.m.
On Tue, 31 Jan 2012, Tony Duell wrote:
Isn't MFM just a special case of GCR?
In that case, GCR is a RLL code in the sense of limiting the run length of
successive zeroes. So at the end, everything's the same and we just have
invented all those acronyms to make life more complicated ;-)
Christian
10:54 a.m.
> Isn't MFM just a special case of GCR?
On Wed, 1 Feb 2012, Christian Corti wrote:
In that case, GCR is a RLL code in the sense of
limiting the run length of
successive zeroes.
That is correct.
So at the end, everything's the same and we just
have
invented all those acronyms to make life more complicated ;-)
That is correct.
11:26 a.m.
> Isn't MFM just a special case of GCR?
On Wed, 1 Feb 2012, Christian Corti wrote:
In that case, GCR is a RLL code in the sense of
limiting the run length of
successive zeroes.
MFM being a "special case" (one of many possible instances) of GCR, and
MFM being a "special case" (one of many possible instances) of RLL,
does NOT NECESSARILY imply logically that GCR and RLL are the same.
(Want a Venn diagram how that could work as an intersection of the two?)
The relationship between GCR and RLL is going to depend on how you define
GCR (and, to a lesser extent, RLL). Both limit the number of consecutive
0 bits. However, GCR generally is table driven, based on only using
bit patterns that can be written without adding any clock pulses, while
RLL manipulates added clock bits placed between the existing bits to
achieve the goal. Our definitions could be used to
differentiate the two, OR to demonstrate the equality.
11:44 a.m.
On Feb 1, 2012, at 2:26 PM, Fred Cisin wrote:
Or, in short, "Yes, but the TLAs carry important semantics". :-)
- Dave
> Isn't
MFM just a special case of GCR?
On Wed, 1 Feb 2012, Christian Corti wrote:
In that case, GCR is a RLL code in the sense of
limiting the run length of
successive zeroes.
MFM being a "special case" (one of many possible instances) of GCR, and
MFM being a "special case" (one of many possible instances) of RLL,
does NOT NECESSARILY imply logically that GCR and RLL are the same.
(Want a Venn diagram how that could work as an intersection of the two?)
The relationship between GCR and RLL is going to depend on how you define
GCR (and, to a lesser extent, RLL). Both limit the number of consecutive
0 bits. However, GCR generally is table driven, based on only using
bit patterns that can be written without adding any clock pulses, while
RLL manipulates added clock bits placed between the existing bits to
achieve the goal. Our definitions could be used to
differentiate the two, OR to demonstrate the equality.
8:13 a.m.
(Want a Venn
diagram how that could work as an intersection of the two?)
In ASCII? That's
madness! :-)
11:06 a.m.
On Feb 3, 2012, at 11:13 AM, Mouse wrote:
I'm sure it could be done equally well in EBCDIC if you prefer.
Sixbit only, please. On punch cards. Or paper tape, if you really must.
- Dave
(Want a Venn diagram how that could work as an
intersection of the two?)
In ASCII? That's madness! :-)
28 Jan
28 Jan
9:35 a.m.
On 27 Jan 2012 at 19:18, Dave Dunfield wrote:
Unfortunately the Compustar is not currently working,
and will need
significant work to repair - so I cannot try formatting disks on it.
And I am unable to create anything on the SuperBrain which I can read
on the PC.
Which is why I cannot provide disk images for the SuperBrain. I've
tried - I simply cannot make it happen.
What I said--the Superbrain tends (evidently, not all revisions do)
to use FA as a DAM. Either edit the raw track to use FBs or use a WD
17xx controller to get the data and rewrite your disk using FBs on a
NEC 765-type controller.
The Superbrain doesn't care which are used.
It's not rocket science.
--Chuck
2:59 p.m.
On Sat, 28 Jan 2012, Chuck Guzis wrote:
What I said--the Superbrain tends (evidently, not all
revisions do)
to use FA as a DAM. Either edit the raw track to use FBs or use a WD
17xx controller to get the data and rewrite your disk using FBs on a
NEC 765-type controller.
The Superbrain doesn't care which are used.
It's not rocket science.
"rocket science" is a lot easier than Superbrain!
4:26 p.m.
What I
said--the Superbrain tends (evidently, not all revisions do)
to use FA as a DAM. Either edit the raw track to use FBs or use a WD
17xx controller to get the data and rewrite your disk using FBs on a
NEC 765-type controller.
The Superbrain doesn't care which are used.
It's not rocket science.
"rocket science" is a lot easier than Superbrain! > Didn't I say the same thing TWO DAYS ago? I
even offered to ship
> a copy of the modified image to the OP and got no response.
> Or is it that people don't know what "DAM" stands for?
> Give me a clue, folks.
I wasn't subscribed to the list two days ago (I got resubscribed in
less than a day - Kudos to Jay and helpers for getting this working
so smoothly) - but I happened to see Chucks comments about address
marks, and that along with a recent conversation with the guy who
donated the Compustar where he mentioned that he had no trouble reading
the disks with linux DD got me thinking, so I did some tests with the
Compustar disks which led to a solution (thanks Chuck).
MOST don't know what it stands for, nor the issues
involved in
non-standard ones. Remember how the discussion got side-tracked
into an assumption that the inverted data was the problem?
That came from my original email to the guy who asked for disk images.
I hadn't visited SuperBrain for a LONG time (at least 5 years), and
didn't remember what exactly was non-standard, only that I had not
been able to read them - I did recall that the data was inverted, and
had the thought that *everything* was inverted (including header data)
... obviously with only the data field inverted, data is data ... so
any pattern would be perfectly valid.
Anyway, FWIW .. some more good came from this. Got me back into
fooling with the Brains, so today I took the time to repair my
Compustar. It's good to have them both going again.
--
dave12 (at) Dave Dunfield
dunfield Firmware development services & tools: www.dunfield.com
(dot) com Classic computers: http://www.classiccmp.org/dunfield/
4:51 p.m.
New subject: TRS-80 Model 2/Model 16 ROMs
Okay, now here's one where I need some help, having nothing to
compare with.
I have a TRS-80 model 16 here that boots Aton CP/M (CP/M 2.2 and CP/M
68K) just fine. In theory, I should also be able to boot any TRS-80
Model 2 or 12 system also, at least from what I gathered.
But I can't boot a Pickles and Trout floppy--the boot sector is read
and the select light on the drive goes out. Nothing more.
Similarly, a friend with a Model 2 can't boot the Aton CP/M floppy
that boots on mine.
Are there different ROMs for the P&T and the Aton? What am I
missing?
--Chuck
8:19 p.m.
New subject: TRS-80 Model 2/Model 16 ROMs
On 28 Jan 2012 at 16:51, Chuck Guzis wrote:
I have a TRS-80 model 16 here that boots Aton CP/M
(CP/M 2.2 and CP/M
68K) just fine. In theory, I should also be able to boot any TRS-80
Model 2 or 12 system also, at least from what I gathered.
As Emily Latella said, "Never mind". I went back on my Model 16,
reseated all the cards and cleaned the drive heads and both disks
(TRS-DOS and P&T CP/M) boot fine. The system hasn't been used in a
couple of years, so something got cranky.
Should have thought of it sooner...
Thanks anyway,
Chuck
9:14 p.m.
New subject: TRS-80 Model 2/Model 16 ROMs
My model 16 when I had it could boot p&t cp/m and cp/m 68k fine and it had
the standard roms.
Can you boot trsdos on it?
On 1/28/12 4:51 PM, "Chuck Guzis" <cclist at sydex.com> wrote:
Okay, now here's one where I need some help,
having nothing to
compare with.
I have a TRS-80 model 16 here that boots Aton CP/M (CP/M 2.2 and CP/M
68K) just fine. In theory, I should also be able to boot any TRS-80
Model 2 or 12 system also, at least from what I gathered.
But I can't boot a Pickles and Trout floppy--the boot sector is read
and the select light on the drive goes out. Nothing more.
Similarly, a friend with a Model 2 can't boot the Aton CP/M floppy
that boots on mine.
Are there different ROMs for the P&T and the Aton? What am I
missing?
--Chuck
9:51 p.m.
New subject: TRS-80 Model 2/Model 16 ROMs
On 28 Jan 2012 at 21:14, Geoffrey Reed wrote:
My model 16 when I had it could boot p&t cp/m and
cp/m 68k fine and it
had the standard roms.
Can you boot trsdos on it?
Yup--and yup. See my later message. Looks to be the usual issues
with the silly PCB cage retention on these machines.. Works now.
--Chuck
29 Jan
29 Jan
1:33 a.m.
New subject: TRS-80 Model 2/Model 16 ROMs
Chuck Guzis wrote:
Are there different ROMs for the P&T and the Aton?
What am I missing?
--Chuck
There are several different ROM revisions for the Model
2/16/16B/12/6000, but I think those mainly have to do with adding
support for new models of floppy drives, and shouldn't affect what kind
of software you can boot (except perhaps if you're trying to boot old
software on new drives).
Archiving images of the ROMs in my machines is on my todo list. I'll
try to get around to it soon.
I'm definitely interested in disk images of various versions of CP/M for
the M2 etc., and especially CP/M-68K.
Eric
4658
days inactive
4664
days old
53 comments
14 participants
participants (14)
-
ard＠p850ug1.demon.co.uk -
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
chrism3667＠yahoo.com -
cisin＠xenosoft.com -
dave12＠dunfield.com -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
geoffr＠zipcon.net -
jules.richardson99＠gmail.com -
mcguire＠neurotica.com -
mouse＠Rodents-Montreal.ORG -
pete＠dunnington.plus.com