• Please review our updated Terms and Rules here

Otrona Attache Mega Haul

Oh, and the image is 409,088 bytes, so yes .... a diskette holds 10 x 2 x 40 sectors (512 ea.) minus one (the last sector on the last track). Kind of strange!!!

Roger
 
Roger,
Sure, just install libdsk and build it. After libdsk is built you will need the Floppy definition for the
.libdskrc file. I use the following:

Code: 
# libdsk definition
[otr1]
description = OTR1  Otrona Attache - DSDD 48 tpi 5.25" - 512 x 10
#eagle = out out = rawoo
sides = eagle
cylinders = 80
heads = 2
secsize = 512
sectors = 10
secbase = 1
datarate = DD

# libdsk definition
[otr2]
description = OTR2  Otrona Attache - DSDD 96 tpi 5.25" - 512 x 10
sides = outback
cylinders = 160
heads = 2
secsize = 512
sectors = 10
secbase = 1
datarate = DD

You would have to rebuild cpmtools to include libdsk.

After the definition is added you can use the following switches:
raw = Alternate sides
rawoo = Out Out for both sides
rawob = Out Back, Out Side 0, Back Side 1

Code: 
cpmls -f otr1 -D ATTBT225.RAW
cpmls -f otr1 -Traw,otr1 ATTBT225.RAW
cpmls -f otr1 -Trawoo,otr1 ATTBT225.RAW
cpmls -f otr1 -Trawob,otr1 ATTBT225.RAW

So, let's look at one Otrona Attache image named OATTACH.IMD. If the floppy was written by the
Otrona Attache it was written as out out for both sides. But, it was preserved as an IMD file by some
software, which may or may not write the IMD file as out out. How do you determine the format of
the *.IMD file? libdsk has the utility tools dskscan, dskid, and dskdump.

Code: 
$ dskid -type imd OATTACHE.IMD
OATTACHE.IMD:                                                                 
  Driver:      IMD file driver
  Sidedness:     Alt
  Cylinders:     40
  Heads:          2
  Sectors:       10
  First sector:   1
  Sector size:  512
  Data rate:     SD
  Record mode:  MFM
  Complement:   No
  R/W gap:     0x2a
  Format gap:  0x52

  Drive status:  0x28

Code: 
$ dskscan -type imd -first 1 -last 40 -format otr1 OATTACHE.IMD
Cylinder  1 Head 0:                                                           
    Data rate: 250
    Encoding: mfm
    Cyl 01    Head 0    Sec   1 size  512
    Cyl 01    Head 0    Sec   6 size  512
    Cyl 01    Head 0    Sec   2 size  512
    Cyl 01    Head 0    Sec   7 size  512
    Cyl 01    Head 0    Sec   3 size  512
    Cyl 01    Head 0    Sec   8 size  512
    Cyl 01    Head 0    Sec   4 size  512
    Cyl 01    Head 0    Sec   9 size  512
    Cyl 01    Head 0    Sec   5 size  512
    Cyl 01    Head 0    Sec  10 size  512
Cylinder  1 Head 1:
    Data rate: 250
    Encoding: mfm
    Cyl 01    Head 1    Sec   1 size  512
    Cyl 01    Head 1    Sec   6 size  512
    Cyl 01    Head 1    Sec   2 size  512
    Cyl 01    Head 1    Sec   7 size  512
    Cyl 01    Head 1    Sec   3 size  512
    Cyl 01    Head 1    Sec   8 size  512
    Cyl 01    Head 1    Sec   4 size  512
    Cyl 01    Head 1    Sec   9 size  512
    Cyl 01    Head 1    Sec   5 size  512
    Cyl 01    Head 1    Sec  10 size  512
Cylinder  2 Head 0:
    Data rate: 250
    Encoding: mfm
    Cyl 02    Head 0    Sec   1 size  512
    Cyl 02    Head 0    Sec   6 size  512
    Cyl 02    Head 0    Sec   2 size  512
    Cyl 02    Head 0    Sec   7 size  512
    Cyl 02    Head 0    Sec   3 size  512
    Cyl 02    Head 0    Sec   8 size  512
    Cyl 02    Head 0    Sec   4 size  512
    Cyl 02    Head 0    Sec   9 size  512
    Cyl 02    Head 0    Sec   5 size  512
    Cyl 02    Head 0    Sec  10 size  512

So, it appears that the image was written my Imagedisk as ALT sides versus out out, assuming libdsk's decode
is correct.

libdsk can also write directly to floppy (/dev/fd0 for Linux) and can write as raw = alt = SIDES, rawoo = eagle, and
rawob = CYLINDERS.

Code: 
$ dskconv -itype imd -otype floppy -format otr1 OATTACHE.IMD /dev/fd0


$ dskconv -itype raw -otype floppy -format otr1 OATTACHE.RAW /dev/fd0

$ dskconv -itype rawoo -otype floppy -format otr1 OATTACHE.RAW /dev/fd0

$ dskconv -itype rawob -otype floppy -format otr1 OATTACHE.RAW /dev/fd0

If I had an Otrona Attache it wouldn't take long to see which floppy booted properly.


Larry
 
Most of the *.RAW images I have are 404480 bytes. The last track of 512 bytes
times 10 sectors (5120 bytes) are missing. That total would be 409600 bytes.

Larry
 
Thanks for all the pointers, Larry. I had never heard of libdsk before. I downloaded the tars for it, and the latest version of cpmtools. I'll work on trying to get the whole thing going. I'm running an older version of SuSE, and I've had trouble building things in the past (the repositories for this older version aren't usable). We'll see if this will work.

I can't speak to the floppy images you've worked with, but I'm using a raw (sector by sector) dump created from a *real* floppy that I can run on my Attache. It is truly 409,088 bytes. Just one sector of the last track is missing. I'm also poking around in the BIOS, and I find that the DPH is:

2800 dw 40
4 db 4
F db 15
1 db 1
B500 dw 181
7F00 dw 127
C0 db 0c0h
0 db 0
2000 dw 32
0300 dw 3

which is pretty "vanilla" for a floppy of that geometry with an allocation block size of 2k (but, then again there's that odd DSM which ought to be either 200 or 185 (I think?) depending on whether the system area is reserved, or not).

Roger
 
I miss my old Otrona. I had one in the nineties. I used it work as a programming toy / business machine. Mine had DOS and or CP/M if I remember correctly. I knew CPM but was more proficient in DOS and I had more app selection too.
They are great machines. I don't remember what I ever did with it.
 
No joy, Larry .... cpmtools 2.21 builds great without libdsk, but when I try to build it with libdsk, it failed with a number of undefined references: dg_stdformat, dsk_open, dsk_strerror, dsk_getgeom, dsk_close, dsk_lread, and dsk_lwrite.

This effort is going way beyond what I originally intended. I've been trying out some of my diskettes (copied from a friend's collection), and although they boot OK, I can't use lots of the programs on them. I'm thinking that there is something wrong with them. Maybe I copied them incorrectly?? Don't know.

So, I'm going back to disk images I can find on-line. Maybe I can build a boot diskette from them, or maybe from the Maslin archive? Anyway, thanks for trying to help with this. Good try, but doesn't seem to be getting me anywhere.

Roger
 
Just to close the loop, Larry .... I resorted to taking the Otrona floppy image apart manually, and discovered that the organization is different from what I had seen mentioned elsewhere. It is written 10 sectors per track side 0, tracks 0 through 39, and then side 1, tracks 0 through 39 (although track 39 is incomplete on side 1). I reassembled the image, sector by sector (without the system tracks), and cpmls works great on it. I can copy files from both sides and they look OK. This probably wouldn't be necessary if I could get libdsk to build, but I can't

I had seen it mentioned that the Otrona diskettes have an interleave of 2 (I think that ANADISK even tells me that?), but it is not so.

Here's the diskdef that works with the re-built image:

diskdef otr
seclen 512
tracks 77
sectrk 10
blocksize 2048
maxdir 128
skew 1
boottrk 0
os 2.2
end

Now if I could only get my flash floppy-ed Gotek to work ... sigh.

Roger
 
You must log in or register to reply here.
Back
Top