IMD on floppy

[William Hicks]

Hi All

I have been using Dave Dunfield's IMD for a year on an older 286 computer and recently I wanted to try and run it direct from floppy instead of hard drive. The configuration is A 1.4mb 3 1/2", B 360kb 5 1/4" and C 20mb HD. I am run it on HD all is good, but when I boot from floppy (3.31 and 5.0) I get error reading from drive A (not ready error reading drive A) and it crashes right after the title screen. I have tried multiple floppies and the write protect is off. Will it not run from floppy?

Bill

[dxf...@gmail.com]

Perhaps not. Both DOS and IMD will be sharing the
same controller. If IMD is reconfiguring the
controller, DOS won't necessarily know about it.
Any mention in the IMD docs?

[William Hicks]

No mention for or against in the docs but that does make sense. If so that sucks

Bill

[William Hicks]

Is there a way of converting an IMD to a teledisk image or an image that I can use dcopy to create a new floppy?

Bill

[Udo Munk]

On Monday, January 8, 2018 at 2:57:20 PM UTC+1, William Hicks wrote:

> Is there a way of converting an IMD to a teledisk image or an image
> that I can use dcopy to create a new floppy?

IMD can be converted to raw, either with one of the IMD tools,
or with imd2raw, source is here:

http://www.autometer.de/unix4fun/z80pack/ftp/tools/

[John Elliott]

On Monday, January 8, 2018 at 1:57:20 PM UTC, William Hicks wrote:
>
> Is there a way of converting an IMD to a teledisk image or an image that I can use dcopy to create a new floppy?

Libdsk 1.5.5 should be able to: dskconv -otype td0 filename.imd filename.td0

[William Hicks]

Where would I find dskconv?

Bill

[Larry Kraemer]

Bill,
Libdsk is at:
http://www.seasip.info/Unix/LibDsk/

and dskconv is a utility John has supplied with it.

If you want I can try making a .TD0 from the .IMD or .RAW image.
I've got libdsk 1.5.4 installed.

Larry

[William Hicks]

I just gave it a go but for some reason it sets the TD0 image as a 3 1/2 disk and I get an error when I try to use it in teledisk

Bill

[John Elliott]

<http://www.seasip.info/Unix/LibDsk/> -- dskconv is one of the utilities in
the package.

--
John Elliott

Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show

[William Hicks]

I am still stuck with it creating images that are targeted for a 3 1/2" drive. I am running the utilities on my Windows 7 machine with a 3 1/2" drive attached but the images are handled on a floppy based 286 machine.

[John Elliott]

Looking at the code, that's because the 'drive type' field in a TD0 file
is exclusive to TeleDisk and so, when converting a non-TD0 file to TD0,
LibDsk just gives it a default value. Possibly a better solution would be
to try and guess a likely drive type based on the geometry of the disc
image.

[William Hicks]

Can this be changed? Is it just a byte or something? If it is I would have no problem writing a program to modify the TDO file as long as I know what needs to be changed.

Bill

[William Hicks]

On Tuesday, January 23, 2018 at 3:08:03 PM UTC-5, John Elliott wrote:

I found out how to change it but now I get a CRC error so I am assuming the checksum has to be recalculated :(

Bill

[dxf...@gmail.com]

The IMD sources (a separate zip) has info on the
TD0 format. This (and possibly TD02IMD.C) may
contain the details you need to recalculate the
checksum.

[dxf...@gmail.com]

The following is a DX-FORTH script that can be
used to calculate the crc. Just plug in the
header values you wish to use.

\ TD0CRC.F
\ TD0 CRC header checksum calculator
\ Use: dx - include td0crc.f bye

empty forth definitions decimal application

hex

\ TD0 header data - 10 bytes
here
54 c, 44 c, 00 c, 5B c, 15 c, 80 c, 01 c, 80 c, 00 c, 02 c,
here over - 2constant HDR-DATA ( -- adr len )

\ TD0 header crc - 2 bytes lo|hi
create HDR-CRC ( -- adr )
0F c, 75 c,

decimal

\ Hex formatted numeric output
: (DH.N) ( ud n -- )
base @ >r hex <# 0 do # loop #> r> base ! ;
: (HW.) ( u -- a u ) 0 4 (dh.n) ;
: HW. ( u -- ) (hw.) type space ;

: TD0-CRC ( crc byt -- crc' )
>< xor 8 0 do dup 0< if 2* $A097 xor else 2* then loop ;

: get16 ( adr -- 16b )
dup c@ ( lo) swap 1+ c@ ( hi) 8 lshift + ;

: calc ( -- )
hdr-crc get16 cr ." CRC existing " hw.
0 hdr-data bounds do i c@ td0-crc loop ( crc)
cr ." CRC calculated " hw. ;

calc

\ end

[John Elliott]

William Hicks <bill...@gmail.com> wrote:
>
> Can this be changed? Is it just a byte or something? If it is I would have
> no problem writing a program to modify the TDO file as long as I know what
> needs to be changed.

I've tried updating LibDsk to guess a correct value for this byte when
converting to TD0 format -- the new release (1.5.6) can now be found at
<http://www.seasip.info/Unix/LibDsk/>

[Larry Kraemer]

John,
There appears to be a problem with the type of floppy drive that was used to write the image when using dskconv. I've copied sections of both headers
so you can see what I am getting.

using libdsk Ver 1.5.6 (Debian 8.x - 32 Bit):

$dskconv -format zor1 -otype TD0 ZORBA1.IMD ZORBA1.TD0

00000000 54 44 00 C6 15 00 04 80 00 02 C2 6C B4 F1 94 00 TD.........l....
00000010 76 00 1B 0A 0A 39 5A 6F 72 62 61 20 50 65 72 73 v....9Zorba Pers
00000020 6F 6E 61 6C 20 43 6F 6D 70 75 74 65 72 00 00 53 onal Computer..S
00000030 79 73 74 65 6D 20 44 69 73 6B 20 28 42 49 4F 53 ystem Disk (BIOS
00000040 20 76 65 72 73 69 6F 6E 20 31 2E 37 29 41 00 00 version 1.7)A..
00000050 43 50 2F 4D 20 32 2E 32 20 43 50 32 2D 38 36 35 CP/M 2.2 CP2-865
00000060 2D 30 34 35 35 33 00 00 43 42 41 53 49 43 20 20 -04553..CBASIC
00000070 20 43 42 41 2D 38 36 35 2D 30 34 35 35 33 00 00 CBA-865-04553..
00000080 43 6F 70 79 72 69 67 68 74 20 31 39 38 31 20 62 Copyright 1981 b
00000090 79 20 44 69 67 69 74 61 6C 20 52 65 73 65 61 72 y Digital Resear
000000A0 63 68 2C 20 49 6E 63 2E 00 00 0A 00 00 88 00 00 ch, Inc.........
000000B0 01 02 00 97 B7 01 02 00 08 C3 5C CF C3 58 CF 7F ..........\..X..
000000C0 00 01 08 20 20 00 26 43 4F 50 59 52 49 47 48 54 ... .&COPYRIGHT
000000D0 20 28 43 29 20 31 39 37 39 2C 20 44 49 47 49 54 (C) 1979, DIGIT
000000E0 41 4C 20 52 45 53 45 41 52 43 48 20 20 01 25 00 AL RESEARCH .%.
000000F0 00 00 FF 08 CC 00 00 5F 0E 02 C3 05 00 C5 CD 8C ......._........


00 Source Density, 1 byte. Recording density of source drive;
0 = 250K bps, 1 = 300K bps, 2 = 500K bps. If this was a
single-density FM diskette, this number is biased by 128.

04 Drive Type, 1 byte. Type of source drive. 1 = 360K, 2 =
1.2M, 3 = 720K, 4 = 1.44M. Note that the actual media size
is not recorded; thus type 3 may be either 5.25" or 3.5"
media.


Used IMD to write ZORBA1.IMD to a 360K Floppy, then read the floppy with Teledisk (Ver 2.23) and created ZORBA1.TD0

00000000 54 44 00 5B 15 00 01 80 00 02 4C D0 79 CD 14 00 TD.[......L.y...
00000010 76 00 1C 0D 20 25 5A 6F 72 62 61 20 44 69 73 6B v... %Zorba Disk
00000020 20 31 00 00 00 00 00 00 00 00 0A 00 00 88 00 00 1..............
00000030 01 02 00 97 B7 01 02 00 08 C3 5C CF C3 58 CF 7F ..........\..X..
00000040 00 01 08 20 20 00 26 43 4F 50 59 52 49 47 48 54 ... .&COPYRIGHT
00000050 20 28 43 29 20 31 39 37 39 2C 20 44 49 47 49 54 (C) 1979, DIGIT
00000060 41 4C 20 52 45 53 45 41 52 43 48 20 20 01 25 00 AL RESEARCH .%.
00000070 00 00 FF 08 CC 00 00 5F 0E 02 C3 05 00 C5 CD 8C ......._........
00000080 CC C1 C9 3E 0D CD 92 CC 3E 0A C3 92 CC 3E 20 C3 ...>....>....> .
00000090 92 CC C5 CD 98 CC E1 7E B7 C8 23 E5 CD 8C CC E1 .......~..#.....
000000A0 C3 AC CC 0E 0D C3 05 00 5F 0E 0E C3 05 00 CD 05 ........_.......
000000B0 00 32 EE D3 3C C9 0E 0F C3 C3 CC AF 32 ED D3 11 .2..<.......2...
000000C0 CD D3 C3 CB CC 0E 10 C3 C3 CC 0E 11 C3 C3 CC 0E ................
000000D0 12 C3 C3 CC 11 CD D3 C3 DF CC 0E 13 C3 05 00 CD ................
000000E0 05 00 B7 C9 0E 14 C3 F4 CC 11 CD D3 C3 F9 CC 0E ................
000000F0 15 C3 F4 CC 0E 16 C3 C3 CC 0E 17 C3 05 00 1E FF ................


00 Source Density, 1 byte. Recording density of source drive;
0 = 250K bps, 1 = 300K bps, 2 = 500K bps. If this was a
single-density FM diskette, this number is biased by 128.

01 Drive Type, 1 byte. Type of source drive. 1 = 360K, 2 =
1.2M, 3 = 720K, 4 = 1.44M. Note that the actual media size
is not recorded; thus type 3 may be either 5.25" or 3.5"
media.


Thanks.

Larry

[John Elliott]

Larry Kraemer <ldkr...@gmail.com> wrote:
> John,
> There appears to be a problem with the type of floppy drive that was used
> to write the image when using dskconv. I've copied sections of both headers
> so you can see what I am getting.

Can you send me the IMD file you were using? It's quite possible that my
guesswork isn't working for disc images that don't have 512-byte sectors.

[John Elliott]

Larry Kraemer <ldkr...@gmail.com> wrote:
> John,
> There appears to be a problem with the type of floppy drive that was used
> to write the image when using dskconv. I've copied sections of both headers
> so you can see what I am getting.

OK, I've uploaded version 1.5.7 that has a rewritten drive type guesser;
see if that works any better for you. (It remains only a guess, of course).

[Larry Kraemer]

John,
The latest change to libdsk 1.5.7 does create a proper header for a 5.25" 360K
48 TPI floppy.

Thanks.

Larry

[retrosys...@gmail.com]

HI Many months ago I posted this thread for help in using IMD on a floppy based system. In the end I had to reinstall the HD to use it. I wanted to revisit this topic and let you know that you can run this on a floppy based PC:

I have the Compaq 286 mentioned in the original post and I also have a Compaq portable XT clone with 2 DSDD 360kb floppies. I discovered that if I boot MSDOS on both systems, connect them with a null modem cable, and run intersvr.exe on the 286 system and interlnk.exe on the floppy only XT system so that I can access the 286's HD via the XT I can indeed run the IMD on the XT with only 2 floppy drives. IMD, though it changes things so you can't run from floppy directly you can get around it. As far as IMD cares I am accessing a HD called "E:" on the XT system.

Ok I know this is overkill but it has bugged me for 8 months and now I know it can be done.

Bill

[Steve Nickolas]

On Tue, 6 Nov 2018, retrosys...@gmail.com wrote:

> HI Many months ago I posted this thread for help in using IMD on a
> floppy based system. In the end I had to reinstall the HD to use it. I
> wanted to revisit this topic and let you know that you can run this on a
> floppy based PC:
>
> I have the Compaq 286 mentioned in the original post and I also have a
> Compaq portable XT clone with 2 DSDD 360kb floppies. I discovered that
> if I boot MSDOS on both systems, connect them with a null modem cable,
> and run intersvr.exe on the 286 system and interlnk.exe on the floppy
> only XT system so that I can access the 286's HD via the XT I can indeed
> run the IMD on the XT with only 2 floppy drives. IMD, though it changes
> things so you can't run from floppy directly you can get around it. As
> far as IMD cares I am accessing a HD called "E:" on the XT system.
>
> Ok I know this is overkill but it has bugged me for 8 months and now I
> know it can be done.

What about vdisk.sys / ramdrive.sys to hold the program?

-uso.

[retrosys...@gmail.com]

I only have 640k on both systems so a ramdisk is out.

Bill

[Steven Hirsch]

Cannot resist: "...640k ought to be enough for anybody.." (W. Gates)

[Udo Munk]

On Thursday, November 8, 2018 at 9:02:10 PM UTC+1, Steven Hirsch wrote:
> Cannot resist: "...640k ought to be enough for anybody.." (W. Gates)

Yup, is, if you are not using software from W. Gates ;-)

[dxf...@gmail.com]

Fake news apparently. Gates didn't design the machine/processor and hence
no reason to make excuses for it. He denies ever making the statement.

https://www.computerworld.com/article/2534312/operating-systems/the--640k--quote-won-t-go-away----but-did-gates-really-say-it-.html

[dott.Piergiorgio]

On 11/12/18 9:55 PM, Jim H wrote:


> At the link above Gates is reorted as saying he had nothing to do with
> the **PROCESSOR** design, yet the 640K limit had little to do with the
> processor. It had to do with the memory map of the original IBM PC,
> which placed ROM at 640K. MSDOS, when booted, looked for either end of
> RAM or first ROM, whichever came first, and that was the memory limit
> for that machine (ignoring extended memory programming techniques that
> came a bit later). Some of it was used for video RAM and DOS basically
> got the rest.
>
> At work I had a DEC Rainbow 100 containing 1 meg of RAM running MSDOS
> (or CP/M) and my best recollection was that resulted in 896K of RAM
> with DOS getting whatever wasn't allocated to video RAM. This was
> possible because DEC placed their ROMs and video memory higher in the
> machine's memory map than IBM did on the original IBM PC.
>
> The basic DEC 100 contained 64K RAM. Add-on memory was VERY expensive
> if bought from DEC, but the company I worked for used large quantities
> of semiconductors in some of their products so it was easy to buy the
> chips for "next to nothing" and just plug them in. Vague memory says
> we saved over $600 via that approach.

600 mid-80s $ for a single machine or overall ? the former is indeed a
great saving for a small/medium company with a 10-20 machine fleet of
DEC 100s

Best regards from Italy,
dott. Piergiorgio.