• Please review our updated Terms and Rules here

Writing disk images to real disks. This is largely Superbrain related but...

Witchy

Witchy

Experienced Member
Joined
Oct 11, 2015
Messages
376
Location
Flatlands, UK
Hi folks,

First off, happy new year. Cheers!

Today's question is, I have 2 functioning Superbrains and to create disks for them I attach a Tandon TM100 from the SBII to my disk imaging PC and use ImageDisk to write new floppies. This works well.

As a test last night I tried using the usual drive that's installed in the PC. It's a Mitsubishi M4853 from a STM Pied Piper* portable CP/M machine. Both this and the Tandon are 96TPI drives/80 track so both should have the same head size and geometry. However, while I can write disks that will let me read/write on a Superbrain, and run programs, I can't get the disks to boot. I know for example the QD-UTILS image from the Don Maslin archive boots because using a Tandon TM100 I can create a bootable disk. However if I write the same image using the Mitsubishi drive it refuses to boot and I'm baffled.

The same goes for CBOOT which came from Dave Dunfield's repository of excellence. With a Tandon it produces a bootable disk but with the Mitsubishi it's merely readable. All 3 user areas are present and executable, it just won't boot.

Any clues?

*no Pied Pipers were harmed, this drive is from the external drive B enclosure of my prototype.
 
What drive is in the Superbrain?
Can the Superbrain boot off the M4853?
If you re-image image disks created using the two different drive mechanisms are they binary identical?
Some systems have boot tracks that are a different format - perhaps the boot tracks are not being written at all but the Superbrain is reading something left behind on the disk from a previous write.
Are you using new disks with nothing written on the boot tracks?

Happy New Year!
 
As well as the above, it may be worthwhile making sure, with a magnet, that the disks are totally, 100%, thoroughly wiped before writing to them, just in case there's something on the disks from previous use, written with a different drive, which may not be 100% track aligned. Or the disk was used with 48tpi data before?

Use a circular motion with the magnet, and run around the disk, both sides.

Geoff
 
All good suggestions, thanks chaps!

The 'brain's usual boot drive is the Tandon which is why I put that in my imaging PC. Something weird though, because the machine WILL boot off the M4853 but not all programs run and I get a lot of BDOS errors. That's using a disk that was written using the same drive a couple of days ago. With the Tandon it won't boot but programs run. That in itself suggests an alignment problem but the M4853 should surely be happy reading a disk it wrote itself!

The disks I'm using appear new, or rather 'unused', but the box they're in is marked 'blank ADFS disks' so maybe they were formatted in a 48TPI Cumana drive with a BBC Micro, and Cumana used several different manufacturers in their enclosures so it could've been an NEC, Mitsubishi, Chinon, TEAC etc. I've got some neodymiums somewhere so I'll try the magnet trick.

Cheers! :toast:
 
Last edited:
Not sure what is going on here, but just a couple of additional things to check:
Check the rotational drive speed of the drives. These should spin at 300RPM.
When using ImageDisk, make sure you have double stepping enabled or disabled as appropriate. No idea which is appropriate for this machine, but a couple of "QD-UTILS" image files I see out there are 48TPI 40 tracks, not 96TPI 80 tracks, although I might be looking at the wrong thing.
Exactly which model of TM100 drive is this? A TM100-4?
As suggested, try reading the disk back with ImageDisk to see if there were any disk write errors.
 
Aaah, the drives are the same as an IBM PC - TM100-2A so they're double sided 48TPI, which in itself brings the head alignment problem I'm seeing since the M4853 is a 96TPI drive. The images were written with double step on. The head in a 96TPI drive is half the size of a 48TPI drive so while reading will probably work it may not be 100% because of this. I've got a Cumana reference booklet for a Beeb that mentions this very issue. Time to raid my spares to find a working 48TPI drive, I've got plenty of IBM PCs to thieve one from.
 
Yep and as Geoff was getting at the 96TPI drive won't knock out the wider 48TPI track underneath if the floppies aren't new or bulk erased.
 
Aye. I wish I'd read that little note many years ago - Cumana published it in 1982 or thereabouts. Typically yesterday I couldn't find my magnets so that plan has stalled for a while.
 
Radial alignment... I have the same problem with my B: drive on my SB II. It is driving me crazy... I have been trying to get the bugger to work reliably for days.

My advice is to think long and hard before loosening those three bolts that secure the head carriage.
 
JonB said:
My advice is to think long and hard before loosening those three bolts that secure the head carriage.
Click to expand...

That is something I would most definitely do, yes :)

Sun is out and it's nice and bright this morning, time to go box digging in the garage to see if I can dig out a spare 48TPI drive as well as something I can scavenge magnets from...

*edit* it just so happens I had a link to this open on another tab, I assume this is what you're following? https://www.classic-computers.org.nz/blog/2010-06-28-alignment-tandon-m100.htm
 
If anyone has a FluxEngine or GreaseWeazle, it ought to be possible to write a 40-track disk on an 80-track drive by writing every even track and erasing every odd track. I haven't actually tried this, though, because I don't have any 40-track drives to test the result on. If anyone has the hardware and wants to do this, please file an issue at https://github.com/davidgiven/fluxengine/issues/new and I'll see what I can do? I'd love to know if it actually works.

Also, regarding head carriage alignment... I just wrecked a 3.5" laptop drive for an Amstrad NC200 by accidentally undoing the wrong screw. I have no idea if it's possible for me to realign it.
 
hjalfi said:
If anyone has a FluxEngine or GreaseWeazle, it ought to be possible to write a 40-track disk on an 80-track drive by writing every even track and erasing every odd track. I haven't actually tried this, though, because I don't have any 40-track drives to test the result on
Click to expand...

This is my immediate problem too, I have both a GW and FE but can't find a 40 track drive. Well, unless I dismantle either my RML380Z or TRS80 Model 4P. I'm amazed I can't find some old BBC Micro drives like the early Shugarts. I know I've got one, but where... remind me never to move house again!
 
Hmm, my Tiki 100 has 400k drives, this seems to imply 40 tracks (on the Tiki 100 at least). Perhaps I should try the FluxEngine to read some of the floppies I have, and then try writing some if the reading succeeds.
 
There's a possibility they're single-sided, although that would be weird? But if you want to try it on the FluxEngine, that'd be great --- chances are the format will just read automatically using the IBM decoder, which will autodetect most normal FM/MFM formats, but in case it doesn't file a github issue and I'll figure it out. I'll need to do some work to make the 40-track writing code work but that'll need to wait until I know what the format actually is. I'd be really pleased if you could test it for me.
 
Hello hjalfi,

Not really sure what you're doing, but I've got an Amstrad PCW here with a 40t 5.25" drive attached as B:. This works fine with DSDD disks. I have frequently created disks on a PC with an 80t drive, using 22DISK, and they've worked fine on the PCW, but I'm not sure this is relevant.

I've got DU-V86 which allows sector-by-sector reading, this should indicate if my drive is able to access everything. I've got a little utility that turns OFF the system flag that causes the PCW to read the disk xdpb off the disk, this will NOT be there on your disks.

Geoff
 
I've got a 40 track single sided Tandon I picked up as part of lot of 5.25" floppies and I don't plan on ever using it. If anyone is interested, I'll dig it out and get the model # and run a disk through it if I can to see if it reads/writes. Shipping from USA.
 
hjalfi said:
There's a possibility they're single-sided, although that would be weird? But if you want to try it on the FluxEngine, that'd be great --- chances are the format will just read automatically using the IBM decoder, which will autodetect most normal FM/MFM formats, but in case it doesn't file a github issue and I'll figure it out. I'll need to do some work to make the 40-track writing code work but that'll need to wait until I know what the format actually is. I'd be really pleased if you could test it for me.
Click to expand...

ok, the 400k format is double sided:
Code: 
tingo@z30b:~/personal/projects/psoc/fluxengine/tmp$ ../fluxengine read ibm -o 525-tiki_100_400k_tiko_4.01_tikos_2.00_25.img
[..]
Autodetecting output geometry
H.SS Tracks --->
0. 0 ........................................
0. 1 ........................................
0. 2 ........................................
0. 3 ........................................
0. 4 ........................................
0. 5 ........................................
0. 6 ........................................
0. 7 ........................................
0. 8 ........................................
0. 9 ........................................
1. 0 ........................................
1. 1 ........................................
1. 2 ........................................
1. 3 ........................................
1. 4 ........................................
1. 5 ........................................
1. 6 ........................................
1. 7 ........................................
1. 8 ........................................
1. 9 ........................................
Good sectors: 800/800 (100%)
Missing sectors: 0/800 (0%)
Bad sectors: 0/800 (0%)
writing 40 tracks, 2 heads, 10 sectors, 512 bytes per sector, 400 kB total
and autodetects correctly - thanks!
the 200k format is single sided
Code: 
tingo@z30b:~/personal/projects/psoc/fluxengine/tmp$ ../fluxengine read ibm -s:s=0  -o 525-tiki_100_200k_ss_Verdensgeografi.img
[..]
Autodetecting output geometry
H.SS Tracks --->
0. 0 ........................................
0. 1 ........................................
0. 2 ........................................
0. 3 ........................................
0. 4 ........................................
0. 5 ........................................
0. 6 ........................................
0. 7 ........................................
0. 8 ........................................
0. 9 ........................................
Good sectors: 400/400 (100%)
Missing sectors: 0/400 (0%)
Bad sectors: 0/400 (0%)
writing 40 tracks, 1 heads, 10 sectors, 512 bytes per sector, 200 kB total
at least one of those doesn't autodetect correctly, thus the '-s' switch. These are the floppies that came with the machine, so I don't know how they were written.
Update: I have also tested these disks in my Tiki 100, so I know they work, which means I'll be able to test 40-track disks written on a 80-track drive with FluxEngine, when time comes.
 
Last edited:
Re the Tiki 100: that's good --- those look like very boring disks (which I like). Could you file a github issue and attach a flux file, please, assuming there's nothing confidential there? I'm currently involved in other projects but should be able to get onto this in a week or so.
 
You must log in or register to reply here.
Back
Top