Jules Richardson wrote: Don't be sure sure; I worked with Dave a few months back getting it running nicely on a stock IBM PC 5150. If it can run on that, surely it can run under DOSEMU, right? I admit I haven't tried it on a PCjr, but then again I wouldn't hold Dave responsible if it didn't work ;-) -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Want to help an ambitious games project? http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/

For the FDC - I talk directly to the hardware, including the DMA chip - but I let the BIOS handle the FDC interrupt (the handler just sets a flag indicating that the current DMA operation if finished). For the video, I talk directly to the video memory for individual character writes, scrolling and for opening/closing text windows, however I use an INT-10h BIOS call to position the cursor. (This is the text windowing library which is supplied with the library for my Micro-C/PC compiler, and I use it for "all kinds of stuff", and have never had a problem running under any version of winblows or DOSemu. The any file access, it's via standard INT-21h DOS services. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

Yeah ... this is a big problem... "I really wish I could get my classic system up and running. I've spend three years and hundreds of dollars on restoring it, and it's ready to go. Hours with the soldering iron, digging up technical details and lengthy hardware debugging sessions and if's finally ready! - but I can't find a boot disk. There is this stuipid ImageDisk thing, but I can't get it to work on my non-standard setup. As far as I can tell, I would have to temporarily move a drive cable and rejumper a drive in order to make the image into a bootable disk. What a bummer to have come so far and be completely stopped by an inconsiderate author who gave us such crappy free software and didn't even care enough to spend more of his money and time in recreating my non-standard setup and maintaining the software to work on it. Oh I wish I could somehow make a boot disk without having to move that cable and jumper - So many years of work have been spent and it looks like I'll never see that system run." Or is there a reason why your 8" and 5.25" 48TPI disks can't be run at the standard PC drive A: and B: positions? Because 4 FDDs on one controller is not a standard PC configuration. Does your controller use the internal drive select register of the 765? Does it have an external hardware register like the 2-drive select register of the PC, and if so what is the layout and will it be the same on different 4-drive controllers. Why does your controller have two connectors (there are four drive selects already on the cable). The primary reason ImageDisk doesn't support this, and dual controllers is because I don't have this setup and would be unable to test it. You are the first to ask for dual controllers (ok, you didn't really ask) - I don't think this is all that common a setup, and most people will find it easier to just hook up the required drive long enough to make the images that you need. (I provide details on my site on how to set up a nice external drive cable). I do apologize for burdening you with this. However the image file format is documented, and you are free to write your own compatible program (or do like Tony suggests and hold me responsible for your "having" to create yet another image file format). I would spend many hours helping people understand it, explaining why it doesn't compile with their favorite compiler or be easily made to run on their favorite system, and helping them implement features I decided not to implement in the first place. Then I would get lots of feedback about what I had done wrong and see posting about how "better" versions are now being maintained at site xxx. And if it goes like some of my earlier projects to which I released source code, I will eventually find other and even commercial tools which are based on my code (This happened in at least two cases with the C compiler). I used to release source code to nearly all of my stuff, but not any more. I just don't need the hassles. I have no commercial goals for Imagedisk, and I will be happy to give out the source code under NDA, however I am not yet ready to make it generally available. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

ImageDisk already has an option to specify the FDC hardware address, however I do not have a system with two controllers, so I have not gone any further toward supporting dual FDCs. What do I need to do to "shut down" the primary FDC - it is just a matter of setting bit 3 in the Digital output register (See description below). If this is the case, you could try poking this bit with a debugger, and then running ImageDisk with an optioh of "IO=372" for the secondary controller address. If this works, let me know and I'll include an option to disable the primary controller. The documents I have describe the "Digital output register" as: 7 = 0 Reserved 6 = 0 Reserved 5 = 1 Enable drive 1 motor 4 = 1 Enable drive 0 motor 3 = 0 Enable diskette interupts and DMA 2 = 0 Controller reset 1 = 0 Reserved 0 = 0 Select drive 0 1 Select drive 1 to this is: 7 = 1 Enable drive 3 motor 6 = 0 Enable drive 2 motor 5 = 1 Enable drive 1 motor 4 = 1 Enable drive 0 motor 3 = 0 Enable diskette interupts and DMA 2 = 0 Controller reset 1 = 0 Select drive 0-1 11 = Drive 3 1 Select drive 2-3 ie: 10 = Drive 2 0 = 0 Select drive 0-2 01 = Drive 1 1 Select drive 1-3 00 = Drive 0 Is this correct? Again - I do not have such a controller, so it would be very hard for me to test and maintain the software - If I make the changes to support this, are you (or anyone) willing to test it? Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

Actually, I was full of excrement - Once I dug back into the guts of the floppy code to look at making these changes, I discovered that I had already put in my own interrupt handler some time ago... So I don't use BIOS of anything! (I did use the BIOS interrupt handler in the early stages) Also from digging into my sources, I discovered that the docs I have describing Bit-3 are wrong as the sense of the bit is inverted to what is shown - this is consistant with your description above. If your PC is fast enough, ImageDisk will read the track in a single revolution, however it will take additional revolutions for re-analysis when the track format changes. Also, for tightly spaced sectors, it may not be able to read them fast enough, which results in one revolution per sector. A useful trick in this case is to read them with a different interleave than the disk is physically formatted - for example, if the disks are formatted 1:1, then reading them 2:1 will allow one extra sector to pass between reads (two revolutions total) - The resulting image will indicate 2:1 interleave (however the sector numbering will be correct for 2:1) and can be used "as is", or you can use IMDU to re-interleave it back to 1:1 - but these steps are only necessary if you are reading a lot of disks and your PC can't keep up at 1:1 interleave. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

Well... that kind of emphasises the kind of misunderstandings that can happen - I do intend to provide reasonable support, bug fixes etc. for the executable program --- it's support of the source code, third party modifications, changes etc. that I do not want to open up yet. When such time arises that I will not or can not support the program, then I will insure that the source code is made available (if it has not already happened by that time) - this btw is in place for all of my commercial products as well. -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

I've been running a mail-order software company selling development tools for embedded systems (of my own creation) for over 20 years. In the early years, I distributed source code, and I would estimate that a full 80% of the technical support revolved around issues relating to people who didn't "know what they are doing" trying to make changes to my tools, and expecting me to show them how, and to fix it when they made horrible messes of it. On top of that, published source to my C compiler was ripped off in at least two instances and used to create competing commercial products by companies which were beyond my ability to persue. So I don't have the same "warm and fuzzy" feeling about releasing source code that you. Well .. after that response, I guess the feeling is mutual. Clearly you have never tried to make a living in the software business. And your earlier crack about "having" to invent your own image format because you don't have access to my source (when the existing format is fully documented) only reinforces this impression. In the case of ImageDisk, it happens to be written with the PC version of my own C development system - It uses video and other libraries which are unique to my tools, and will not compile without changes under GNU C, Turbo-C, Microsoft-C or any windows/linux system ... In short the source code isn't going to be very useful to many people and I am not ready to begin the process of spreadng the program across platforms. If you look back on the early ImageDisk postings, you will find that I stated that I would release the source code when I felt it was mature enough, but I'm not ready to do that yet, as I am still finding things (like 4-drive support) that need to be addressed, and I also want to spend a fair bit of time and effort in bringing what began as a "weekend hack" project to a professional level before general availability (anyone who has looked at any of my other released source code should know that I have fairly high standards in the quality of the material I publish) - For people who just "gotta" have the source, I made the offer today to release it individually - but a general public release will have to wait until it is close enough to "finished" that I feel comfortable in doing so. Until then, I will retain control of the development. You will note however that I have fully documented the image file format, and I have provided tools to move raw binary images to and from .IMD format - this is my attempt to insure that nobody has any "risk" in putting disks in ImageDisk - you will always be free to convert the data to any other format you wish, and I believe I have provided the information necessary to do so. If this isn't good enough the for the classic community, then I guess this has all been a mistake. -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

I would not feel comfortable in releasing the code unsupported until I am confident that it is mature and stable - Imagedisk is not at this point yet (It's getting there, but I'm not ready to screw the cover on yet). Until it is, I will keep it to a single platform and the development under my control. And this is relevant to me how? For the record, in the heyday of my software company, I would spend about 3 hours a day answering tech email - every tech problem would get answered the same day if possible. Even now I service my company mailbox "first thing" each and every day. Here we agree. and here we disagree - this particular branch of the thread was not written about ImageDisk - it was written in response to your statements about the wonderful experiences you have had releasing source code. The intent was to educate you to understand that my experiences have not been so wonderful. You know ... try and see how it looks from the other side and all that. Now this is interesting - your "bitter experience" is justification for your assuming that I have not done a good job at documenting the ImageDisk format and therefore totally dismissing my work, yet my "bitter experiences", and my conservative approach to releasing source code as a result of them are blown off with "you deserve no respect from me" ... Seems to be a bit of a double standard here. For the record, the Imagedisk format is quite simple, and completely documented (It takes only one page to describe). If you want to "investigate it", Image some disks and using the document, take apart the image and see if it lines up. If you still don't take my word for it, you can use IMDU to convert the image to a straight raw sector dump - just the data from all the sectors strung out in a big line - I don't think you can get any simpler or more straightforward that this. And this is relevant to my work how? (a variation of your response above) And I have offered to make them available for "personal reading", so I don't see what the problem is. Definately missing my point - it has nothing to do with worrying about people "ripping off" of my code - It has to do with my wanting to keep a door closed that I am not ready to open yet. Well ... at least thats something. At this point I am unwilling to clutter up the list with what has gotten very far away from anything relevant to it's charter, so I will bow out. -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

AFAIK all HP150 disks are double-density. Certainly the schematics for the 9114 imply that unit can _only_ operate in double density mode, and I think the same is true for the HPIB-interfaced drive units. That makes life a little easier for you, since all PC disk controllers can handle that. The big problem with HP disk units is that there was some intellegence in the drive units (IIRC a 68x09 processor) and they did things like bad track replacement _trnasparently to the user_. If a double-sided disk is 'perfect' (no bad tracks), then phgysical cylinders 0-76 are used for user data, 77 and 78 are unformatted, and 79 contains something that indicates there are no track replacements, the usage counter, etc. From what I can see, this was never documented in any HP manual. When I wrote programs to read 9114 disks on a PC, I have to admit I ignored this, and just imaged cylinders 0 to 76. When dumping back, I assumed a perfect disk that had been formated on the HP drive, and just wrote cylinders 0 to 76. Amazingly nobody seems to have had problems from this. I am not sure how general the 9114 can be -- I've only ever used it to produce disks with 16 256-byte sectors per track. And to do that you can use a command set called 'Modified Filbert Protocol'. This is a superset of the commands to the 82161 tape drive (codenamed Filbert, of course), which are documented in the manual for that product. The best way to find out the extensions is to read the HP71 HPIL IDS volumes, and the HP75C ROM source and comentary. I spent many a long night doing just that... system and sent arbitrarly DDT and DDL commands (which is what you need to do). Just don;t do it on any disk you expect to be using from MS-DOS... If you think you might find useful stuff in my 9114 disk reading programs, feel free to take a look, They're on hpcc.org somewhere, they're GPLed C sources. If you can't find them, I'll mail you a tar archive or something. -tony

From: "Miller, Keven" <kevenm at reeltapetransfer.com> Cc: <cctalk at classiccmp.org> Sent: Saturday, December 24, 2005 12:25 PM Subject: PDP-11 9-track tapes I am not familiar with PDP, so I can only answer based on my experience. 7-track tapes went out of fashion around 1970 or so. In my first job I encountered an IBM drive for 7 AND 9 track, and that was in 1969. 800 bpi would be more like it, but you didnt give the make/model of the drive used, so that's only a guess. It could very well be a case of too large blocklength; many drives (or operating systems!) I've seen cannot read blocks larger then 32K. This is especially a problem for tapes from the oil and geophysical industries. If nobody else can be of help, you're welcome to send me a tape, so I can have a look at it Cheers Nico (located in Denmark)

Keven Miller wrote: When 7 track went out of fashion was somewhat dependent on the vendor. In the CDC 60-bit world, 7 track tapes hung on until at least the late 70s at many installations. But that only makes sense, as the 6000/7000/Cyber series before the 180 was all 60 bit words and 6 bit characters. OTOH, on the 64-bit Cyber 200 series, it was all 9 track tapes. 200, 556 and 800 bpi. Cheers, Chuck

(Dave wrote) (Tony Duell wrote) The logic of this, coming from an adult, is astounding. Dave can and is defending himself, but as a happy "customer" of his free tools, I can't let this slide by. I often use an analogy with my six year olds: imagine we are going to the ice cream store (which in our case is not often), and you really want strawberry ice cream. We get there only to find out they are all out of strawberry, but how about chocolate instead? Are you going to cry and whine that you want strawberry, or are you going to be happy that you are still getting a nifty chocolate one? That makes a lot more sense to them than the adage, "Don't look a gift horse in the mouth." Dave has worked selflessly to produce a professionally done, well documented program for the benefit of us all. It is peerless; there have been similar programs in the past, e.g. teledisk, but they are not actively developed and the resulting disk image format is not documented. Imagedisk works, it is free and is unencumbered by questions of the right to use. OK, we are not in utopia. Dave isn't comfortable releasing the source code ... yet. And yet you complain about it. You say judgementally that if *you* had written the program, the you'd certainly release the source code. That is great except you *haven't* spent the time to write the program. So until you go and do it, you are just posturing.

(I, Jim Battle, wrote this concerning complaints about free software): der Mouse wrote: First, I should say that I meant to reply to Tony directly. After my post showed up on the list, I realized my mistake and sent an email to Tony saying such, but I didn't post it to this list because I didn't want to needlessly spam it again. der Mouse, there are too many pronouns and not enough attribution for me to answer with confidence as I'm not sure what you mean. If you are saying that I've just lost stock with you because of my disagreement with Tony, then so be it. But what that has to do with you writing software is a nonsequiter. Since it is such a nonsequiter, maybe you thought you were replying to Dave. If so, I still don't follow your reasoning. The complaint has nothing to do with what Tony has done for the world (or in your hypothetical, what you have done). Dave wrote a program and gave it away for free. If you don't like it, don't use it and go write your own. Talking about what you would do if you had written it is posturing, yes. Do it yourself or stop complaining. Dave, for his own reasons, decided the time isn't right for him to release the source code. Would we be better off if he just sat on it until that time?

der Mouse wrote: But Dave has said that he will be releasing source, just not until he's happy that it's in a fit state to be released. That doesn't seem unreasonable to me; it's preferable to releasing something that isn't considered finished. I think this was my fault as I originally posted saying that source wasn't available - but Dave's responded since about it being available under some form of NDA-like agreement in the shorter term, and (as I read it) is hinting at a more flexible source release in the longer term when he's satisfied with the state of the code. Given that, I can't see why anyone has grounds for complaint? cheers Jules

On Fri, 16 Dec 2005 12:01:51 +0000 Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: You can configure DOSEMU (at least last time I tried, which was the kernel 1.2 era) to tunnel through and give deep direct access to the hardware where necessary. Particularly on something like the floppy interface that Linux doesn't integrate and use that much in the first place. You can even compile out the floppy disk interface in the linux kernel entirely to give the 'whole thing' to DOSEMU if you like. I've run my ISA-card EPROM programmer under DOSEMU on a Linux box.