From garlangr at verizon.net Wed Sep 1 01:06:13 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Wed, 1 Sep 2004 01:06:13 -0500 Subject: [sebhc] h17 and h8d disk images References: Message-ID: <01e001c48fe9$c96cd000$6501010a@BUSTER> Yes, that is what I saw, these just upload h17 files are the exact same size as the h8d files. Also, has the file/directory naming convention been decided upon? I have a little script that will mirror the site (but also keep all existing files), I've noticed alot of changes with capitalization, dashes vs. underscores, periods vs. dashes, and other changes. It would be nice to have it stablized ;-). I've also notice that at least one file seemed to have been removed: This is on my computer I have: -rw-r--r-- 1 garlangr garlangr 102400 May 26 12:23 HDOS_1.0_Issue_#50.05.00_890-1-5.h8d But is no-longer on the site (but I know with the new uploads we now have -rw-rw-r-- 1 7002 sebhc 102400 Aug 30 21:13 hdos10.h17 ). Was there a problem with the file from May, or did it get accidently removed? Should we have a master catalog file that has a longer description of the file than just the file name? Also, does any one have some of the graphic games like Y-Wing, Space Odyssey, Gravitron, Gravitron 2, Munchman, snake, Space Pirates, etc? I saw adventure, but I also remember an adventure game call 'Remark' and another one that had a space theme. I also had the Zork series (I, II, & III), and Enchanter). There was 12 Scott Adams text adventure . Mark ----- Original Message ----- From: "Steven Parker" To: Sent: Tuesday, August 31, 2004 11:51 PM Subject: RE: [sebhc] h17 and h8d disk images > Mark asked: >>So is the new h17 format the same as the h8d? > > Then Jack said: >>The .h17 format preceded the .h8d - these images are "verbose" hex >>dumps... > > Except the recent downloads are actually binary images, so the answer to > Mark's question in this case is "yes". The h17 extension is what they > were uploaded with .. I suppose we may want to rename them to h8d for > consistency. They could use individual descriptions also. I'll try to do > this soon but first I wanted to make the files accessible for download. > > - Steven (spelled with a "v") :) > > _________________________________________________________________ > Don't just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 01:47:37 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 02:47:37 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409010647.CAA05623@ss10.danlan.com> "Mark Garlanger" wrote: |Yes, that is what I saw, these just upload h17 files are the exact same size |as the h8d files. I've been calling my binary image files .h17. |Also, does any one have some of the graphic games like Y-Wing, Space |Odyssey, |Gravitron, Gravitron 2, Munchman, snake, Space Pirates, etc? I have (at least) Space Odyssey 1. |I saw adventure, but I also remember an adventure game call 'Remark' and |another one that |had a space theme. I have "A Remarkable Experience"; not a great adventure if I recall correctly. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed Sep 1 02:58:54 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 01 Sep 2004 07:58:54 +0000 Subject: [sebhc] h17 and h8d disk images Message-ID: >Also, has the file/directory naming convention been decided upon? Mostly. Underscores between words, only one period followed by a 3-letter (max) descriptive extension, other periods converted to hyphens. I don't recall any spedific decision around capitalization. >It would be nice to have it stablized ;-). Yea, if you plan on mirroring I can see how name changes could be a real paiin. I think there are sttill a few old things that need renaming to conform, so be prepared for that. Plus I moved the recent submissions to make them available, but they still need more descriptive names. I'll try to remember to post notice of any name changes. How about in future, we move new uploads to an 'incoming' directory until we give them their more permanent location and name. Just don't mirror the 'incoming' directory. >I've also notice that at least one file seemed to have been removed: >HDOS_1.0_Issue_#50.05.00_890-1-5.h8d >But is no-longer on the site It was renamed to HDOS_1-6_Issue_#50-05-00_890-1-5.h8d I had placed the original name on it based on what was printed on the label, Jack renamed it based on what it printed out when you boot it. And at the same time we were considering the hyphens vs. periods thing. Cheers, - Steven _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 04:20:43 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 05:20:43 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040901092042.MFBR26191.orval.sprint.ca@smtp.sprint.ca> >The .h17 format preceded the .h8d - these images are "verbose" hex dumps >of various disks using Dave Wallace's algorithm. This is also the format >that Eric Rothfus uses with his SVD device. > >The .h8d format was developed by Dave Dunfield for his H8 emulator; >Stephen Parker transformed many .h17 disks into .h8d images by stripping >the track and sector info (and converting to binary?). At least for the >HUG material, the same disks should be available in both formats. > >Jack Hi Guys, I haven't checked into the archive in a long time - been tied up with other things... must do so, sounds like good things are happening. If it would be useful, I would be happy to write up a little utility to convert .H17 to and from .H8D (by removing or adding the track/sector informaion) - just point me at a good description of the .H17 format. Then we don't have to maintain two copies of everything. Also, I've got it in my mind to modify the emulator so that it can boot CP/M ... Presumably I need to add the "RAM at 0" option ... anything else needed? I don't have any technical info on this - can someone give me a pointer? Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 11:16:31 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 09:16:31 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409011616.JAA16874@clulw009.amd.com> >From: "Steven Parker" ---snip--- > >>I've also notice that at least one file seemed to have been removed: > >>HDOS_1.0_Issue_#50.05.00_890-1-5.h8d >>But is no-longer on the site > >It was renamed to HDOS_1-6_Issue_#50-05-00_890-1-5.h8d > Hi I believe is was originally a 1.0 but was later patched to 1.6 level. The HDOS10 that Dan just posted seems to be #50-03-00. I don't see any indication that this had any patches applied so it is probably closer to original. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 12:11:13 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 10:11:13 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409011711.KAA16889@clulw009.amd.com> Hi Dave & Dan Although I generate the h8d format ( mostly being lazy ) I think your h17 format is more robust and contains more information than the smaller format. What both formats seem to lack is information about interleaving. Dan Lanciani mentioned that it didn't make any difference for pure images. In a sense, this is correct but this make the two methods of handling these images incompatible for images with interleaving. The problem is that if you take an image and just create a sequential binary of the data like the h8d directly from the disk image, you'll lose the sector headers that contain the interleaving information. The problem exist if one takes a disk with interleaving and reads it as a physical image, that has interleaving, and tries to use it using either your format or the current h8d format. Both your and my methods read the sectors through the information of the sector headers that exist on the disk. These may not be in the physical order and loses any interleaving information. I don't know if Dan is extracting the sector header information and using that to determine the order of the sector blocks or just reading the disk order. It is true that all original HDOS distribution disk have the natural order. This may not always be the case. Dan mentions in a previous mail that the only staggering he knew of was skewing but it was quite common to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that my transfer program even has this option for creating disk ). This was done quite often for BASIC programs because of BASICs slow method of accessing the disk that would cause it to skip looking at the next sector. Interleaving made about a 8 to one speedup in the program loading time. This isn't a big deal for small programs but any with large DATA statements can be painfully slow. The CP/M disk should be OK since CP/M had a feature of doing interleaving within the OS to avoid having altered disk. There is no reason to resort to physical interleaving. If one were to take one of the disk that was created with my program, using the interleave option, and later read it with Dan's system, I'd suspect it would take some time to rebuild it, since the sectors would not be in the natural physical order. As for only having the one format I'd not like to to see this. I would prefer to see a simple utility to translate your format to the simpler h8d format and back to the h17 format than see your format go away. I've written a simple h17 to h8d converter program myself but it would need a little friendlier interface before I could hand it out. Converting back to h17 from h8d would take a little more effort since your format contains more robust information about the disk structure as well as comments. I guess the question for Dan is, do you assume that the physical sector order matches the logical sector order when creating your image files or do you map the logical sector order into the order used in the images? We should change the names that Dan has sent to keep things consistent as soon as we can and post that so that anyone mirroring can make the changes. Dwight >From: "Dave Dunfield" > >>The .h17 format preceded the .h8d - these images are "verbose" hex dumps >>of various disks using Dave Wallace's algorithm. This is also the format >>that Eric Rothfus uses with his SVD device. >> >>The .h8d format was developed by Dave Dunfield for his H8 emulator; >>Stephen Parker transformed many .h17 disks into .h8d images by stripping >>the track and sector info (and converting to binary?). At least for the >>HUG material, the same disks should be available in both formats. >> >>Jack > >Hi Guys, > >I haven't checked into the archive in a long time - been tied up with >other things... must do so, sounds like good things are happening. > >If it would be useful, I would be happy to write up a little utility >to convert .H17 to and from .H8D (by removing or adding the track/sector >informaion) - just point me at a good description of the .H17 format. >Then we don't have to maintain two copies of everything. > >Also, I've got it in my mind to modify the emulator so that it can boot >CP/M ... Presumably I need to add the "RAM at 0" option ... anything else >needed? I don't have any technical info on this - can someone give me a >pointer? > >Regards, >Dave >-- >dave04a (at) Dave Dunfield >dunfield (dot) Firmware development services & tools: www.dunfield.com >com Vintage computing equipment collector. > http://www.parse.com/~ddunfield/museum/index.html > > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 12:19:52 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 10:19:52 -0700 (PDT) Subject: [sebhc] Access to the SEBHC archive Message-ID: <200409011719.KAA16893@clulw009.amd.com> Hi Dan See my reply to Dave's message. I address issues of interleaving that you may not be aware of. I don't think any of your images have issues but it can be a problem. You'll note that my transfer program actually has the option to create interleaved disk. This was done quite often and I know of at least one disk that I'd gotten from a friend that had this interleaving done to speed up BASICs load. You do need to look out for them. As you note, none of the realise disk had any form of interleaving, either track skewing or sector. Dwight >From: "Dan Lanciani" > >"Dwight K. Elvey" wrote: > >|Hi Mark >| It appears to be the same. At most, it might include >|different interleaving. I expect to look at it tonight >|to check it out. I don't think the sectors of HDOS were >|physically interleaved > >They were not interleaved; however, some versions of the driver did >offset sector 0 on each successive track so that spiral reads did not >miss a rotation each time. As with any physical sector manipulation, >none of this matters to images. It's only logical interleave (where the >driver knows a mapping between real sector numbers and those in the >headers) that causes problems. As far as I know, this was never done >on H17-style disks. > >I've now uploaded the three CP/M distributions and my collection of HUG >disks (some of which probably duplicate what is alread there). > > Dan Lanciani > ddl at danlan.*com >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed Sep 1 13:07:12 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 01 Sep 2004 18:07:12 +0000 Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: I said: > >>HDOS_1.0_Issue_#50.05.00_890-1-5.h8d > >It was renamed to HDOS_1-6_Issue_#50-05-00_890-1-5.h8d Dwight said: > I believe is was originally a 1.0 but was later patched to 1.6 >level. The HDOS10 that Dan just posted seems to be #50-03-00. >I don't see any indication that this had any patches applied >so it is probably closer to original. No, I created the 50.05.00 image from an original distribution disk with write-protect tab still in place. The printed label on the disk actually says HDOS 1.0 but when you boot it it displays 1.6 on the screen. This makes sense now that we have 1.5, and it's issue 50.04.00. I'm assuming the new submissions are also unpatched original distributions just like the 50.05.00 is. Cheers, - Steven P.S. I renamed the HDOS and HUG submissions to conform with the other archives and be more descriptive. All the duplicates of the HUG disks matched byte-for-byte except one of them, which I have set aside and may look into more thoroghly later. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 13:45:38 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 14:45:38 -0400 Subject: [sebhc] Archive question In-Reply-To: Message-ID: <200409011845.i81IjZIa005125@ms-smtp-04-eri0.ohiordc.rr.com> Does anyone have a problem with material (documents, primarily) from the archive being cross posted on Howard Harte's site: http://www.hartetechnologies.com/manuals/ It's my opinion that as web sites come and go, and as, unfortunately, we ourselves "go", the only way to insure the long-term survival of this material is to get it as widely distributed in as many forms and places as possible. But I won't cross-post it if people object. Barry Watzman Watzman at neo.rr.com -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 13:58:57 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 14:58:57 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040901185854.JAVQ13092.berlinr.sprint.ca@smtp.sprint.ca> At 10:11 01/09/2004 -0700, you wrote: >Hi Dave & Dan > Although I generate the h8d format ( mostly being lazy ) I think >your h17 format is more robust and contains more information >than the smaller format. What both formats seem to lack is >information about interleaving. Dan Lanciani mentioned that >it didn't make any difference for pure images. In a sense, this >is correct but this make the two methods of handling these >images incompatible for images with interleaving. The problem >is that if you take an image and just create a sequential >binary of the data like the h8d directly from the disk image, >you'll lose the sector headers that contain the interleaving >information. >... Dwight, The H8D format is very simple/just data for a few reasons: 1) I had not-to-long ago just done the Altair simulator which has the NorthStar hard sectored single-density disk system in it - this system DOES NOT use headers, and sector numbering HAS TO BE the physical ordering on the disk - so I just "did the same thing" for the H8, having not had experience with hard-sector disk and sector headers before (It really just seemed like a nusiance). 2) The H8 simulator caches the disk a track at a time, so interleave factor makes absolutely no difference, except for the fact that I artifically wait for sector pulses - however due to the way it is designed, the virtual disk system should be able to read/write in sequential fashion at full speed, so interleaved disks would actually be slower - H8D files are by definition non-interleaved. 3) I was really only concerned about being able to access the data and the controller register level, not it doing a bit-by-bit detailed simulation right down to the sector layout level. 4) My layout simplifies the simulation, because a given sector can be located by simple seek within a track - otherwise I would have to scan each track as I cache it and build a sector map table (do you recall how quickly my emulator came into being ... I didn't want to do any work that was not necessary). In retrospect, this format is great for preserving the data, and also great for virtual disks in my emulator, however it cannot completely reconstruct the original disk, which makes it less great for physically rebuilding exact copies of archived disks. I actually has been assuming that the .H17 format always placed the sectors in sequential order in the file (I guess I assumed that when transferring, he just starts with the first logical sector and keeps reading the next one till the end of the disk - but now I realise that he may be reading and transferring entire tracks, including the header information, so at least he COULD be preserving the interleave). Anyway, the way I would address this in the utility that I write (if anyone wants me to) to translate back and forth between .H8D and .H17 would be to allow you to specify an interleave factor (has anyone verified that a .H17 disk image with other than 1:1 interleave does work correctly). I would package this unility with the simulator, which means that anyone who gets my simulator will have the utility - then you can store all disks as .H17, preserving the sector ordering, and anyone using my simulator will have the ability to translate them into .H8D. But... .H17 is bigger than .H8D, so if it does NOT work with other than 1:1 interleave, it would make sense to use the smaller format. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 13:40:39 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 11:40:39 -0700 (PDT) Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: <200409011840.LAA16961@clulw009.amd.com> >From: "Steven Parker" > >I said: >> >>HDOS_1.0_Issue_#50.05.00_890-1-5.h8d >> >It was renamed to HDOS_1-6_Issue_#50-05-00_890-1-5.h8d > >Dwight said: >> I believe is was originally a 1.0 but was later patched to 1.6 >>level. The HDOS10 that Dan just posted seems to be #50-03-00. >>I don't see any indication that this had any patches applied >>so it is probably closer to original. > >No, I created the 50.05.00 image from an original distribution disk with >write-protect tab still in place. The printed label on the disk actually >says HDOS 1.0 but when you boot it it displays 1.6 on the screen. This >makes sense now that we have 1.5, and it's issue 50.04.00. I'm assuming the >new submissions are also unpatched original distributions just like the >50.05.00 is. Hi Steven This makes more sense. I just assumed it was patched because the label said 1.0. I guess they where just saving cost of printing labels. I don't have it right in front of me but it seems like the 50.05.00 was hand stamped on the label as well. > >Cheers, > >- Steven > >P.S. I renamed the HDOS and HUG submissions to conform with the other >archives and be more descriptive. All the duplicates of the HUG disks >matched byte-for-byte except one of them, which I have set aside and may >look into more thoroghly later. > > It is good to get a nice cross compare. I believe the originals were all converted from the h17 format. I see that you renamed them already. You are really fast ;) For others, I should note that there appear to be 11 new images so for those trying to keep things up to date, one should download what is new( thanks Dan and Steve ). I just have to finish making my sector hole punch. Then I can have enough disks to use for all of this great stuff. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed Sep 1 14:15:49 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 01 Sep 2004 19:15:49 +0000 Subject: [sebhc] h17 and h8d disk images Message-ID: Dave says: >Then we don't have to maintain two copies of everything. We don't .. all the new submissions are in the .h8d format. And we have 'disktool' to do conversions. >Also, I've got it in my mind to modify the emulator so that it can boot >CP/M ... Presumably I need to add the "RAM at 0" option ... anything else >needed? I don't have any technical info on this - can someone give me a >pointer? I did already! Here's an excerpt from the previous message: >From: "Steven Parker" >To: sebhc at sebhc.org >Subject: Re: [sebhc] Emulator fixes / additions >Date: Wed, 26 May 2004 23:52:17 +0000 > >Even with XCON, on reset you need to switch the rom(s) back on. After the >I/O port, the only other thing you'd need for XCON is a way to set the boot >control switch positions that it reads (cmd line parms?). I attached a >mtr.acm excerpt to the end of this mail with the port and bit definitions. (rest of message omitted here) >========================================================== > >** I/O Ports >* >IP.CON EQU 362Q H-88/H-89/HA-8-8 Configuration >OP2.CTL EQU 362Q H-88/H-89/HA-8-8 Control Port > >** Front Panel Control Bits >* >* CB2.* set in OP2.CTL >* >CB2.SSI EQU 00000001B Single Step Interrupt >CB2.CLI EQU 00000010B Clock Interrupt Enable >CB2.ORG EQU 00100000B ORG 0 Select >CB2.SID EQU 01000000B Side 1 Select > >** Configuration Flags >* >* These bits are read in IP.CON >* >CN.174M EQU 00000011B Port 174Q Device-Type Mask >CN.170M EQU 00001100B Port 170Q Device-Type Mask >CN.PRI EQU 00010000B Primary/Secondary: 1=>primary == 170Q >CN.MEM EQU 00100000B Memory Test/Normal Switch: 0=>Test; >1=>Normal >CN.BAU EQU 01000000B Baud Rate: 0=>9600; 1=>19,200 >CN.ABO EQU 10000000B Auto-Boot: 1=>Auto-Boot > >CND.H17 EQU 00B H-17 Disk, Valid only in CN.174M >CND.NDI EQU 00B No Device Installed, Valid only in CN.170M >CND.H47 EQU 01B H-47 Disk > >========================================================== _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 14:36:54 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 12:36:54 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409011936.MAA16986@clulw009.amd.com> >From: "Dave Dunfield" ---snip--- > >1) I had not-to-long ago just done the Altair simulator which has the > NorthStar hard sectored single-density disk system in it - this system > DOES NOT use headers, and sector numbering HAS TO BE the physical Hi Dave Actually, single-density and double-density both use headers, you just don't, usually, have as direct access to them as Dan's methods would have. Both can also have different physical and logical interleaving. I used to play with the physical sector interleaving on an original IBM PC to speed up transfers. ---snip--- > >2) The H8 simulator caches the disk a track at a time, so interleave > factor makes absolutely no difference, except for the fact that I This makes perfect sense Dave. I'm not criticizing, only making the point to Dan that both of the formats we are using now do not account for interleaving. We both have good reasons for ignoring it. You have no need for it in the simulator and I gather the data through H17 calls so don't see it. I'm only aware of it when I format the disk. Even then, once format is done, the software ignores it. It is only a timing issue if such a disk is used for real systems. ---snip--- > >I actually has been assuming that the .H17 format always placed the >sectors in sequential order in the file (I guess I assumed that when >transferring, he just starts with the first logical sector and keeps >reading the next one till the end of the disk - but now I realise that >he may be reading and transferring entire tracks, including the header >information, so at least he COULD be preserving the interleave). > ---snip--- All of the .H8D files that I and others have creates have all been in logical sector order. It looks like so far, the ones that Dan has created all have logical order, even though created by physical order. As long as the images for H8D are kept in logical order, we don't have any issues. The potential problem is that Dan's method drops the sector headers and could potentially have scrambled sectors. I think we should always assume that the order for the H8D files are in logical sector order. Anything else would not make sense since there is no additional information to determine the physical order of the original. Your format has the potential by using the comments at the beginning of each sector. I see this a more of a problem for Dan since he has assumed that all disk are created with matching physical and logical order. Recreating the exact interleaving is not essential for image transfer. It is more of an issue of convenience of use once one creates the new disk. I was even reluctant to add the feature to my transfer program except I remember the enormous increase in the loading of BASIC programs when used. Dwight -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 15:08:32 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 16:08:32 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012008.QAA24555@ss10.danlan.com> "Dwight K. Elvey" wrote: | I believe is was originally a 1.0 but was later patched to 1.6 |level. The HDOS10 that Dan just posted seems to be #50-03-00. |I don't see any indication that this had any patches applied |so it is probably closer to original. All the images I provided are from original, always-write-protected disks. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 15:31:35 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 16:31:35 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012031.QAA25131@ss10.danlan.com> "Dwight K. Elvey" wrote: | I don't know if Dan is extracting the sector header information |and using that to determine the order of the sector blocks |or just reading the disk order. I'm using the headers. Doing it any other way would make retries very difficult. More specifically, I read an entire track (actually a track and a half), separate the data bits from the clock bits, and begin hunting for sectors which I scatter into a track image buffer. For each sector that I validate I set a bit in a mask. When I finish with the raw track I check the mask to see if I have found all 10 sectors. If I have not I re-read the track and repeat. |It is true that all original |HDOS distribution disk have the natural order. This may not |always be the case. Dan mentions in a previous mail that the |only staggering he knew of was skewing but it was quite common |to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that |my transfer program even has this option for creating disk ). Which H17 driver supported creating interleaved formats? | I guess the question for Dan is, do you assume that the physical |sector order matches the logical sector order when creating |your image files or do you map the logical sector order into |the order used in the images? I take the sectors as I find them but then (unless a special switch is given to the image command) I require that the next sector header found in the raw track image is for the current sector + 1 (mod 10) and that it is located less than 64 bytes from the end of the previous data area. This is a reliability measure since it is possible with these old disks for big chunks of data to be missed as the VCO wanders out of sync. In theory you could drop a data area and the next sector header (or more) leaving you with the wrong data area for a given header. (When the controller gets out of sync it usually generates long runs of 0 and I compress out anything less than 85 before I do the FM decoding since such bytes cannot contain valid FM data.) So if a disk were actually interleaved I would know about as the imaging process would fail. None of the disks I read used a physical interleave. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 15:42:30 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 16:42:30 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012042.QAA25350@ss10.danlan.com> |"Dwight K. Elvey" wrote: | | All of the .H8D files that I and others have creates have all been |in logical sector order. It looks like so far, the ones that |Dan has created all have logical order, even though created by |physical order. As long as the images for H8D are kept in logical |order, we don't have any issues. The potential problem is that |Dan's method drops the sector headers and could potentially have |scrambled sectors. No, really, it couldn't. Trust me. :) | I see this a more of a problem for Dan since he has assumed that |all disk are created with matching physical and logical order. I don't assume it; I assert it. If the assertion fails the program will tell me about it. The I can either disable the assertion with an option switch (sacrificing some reliability) or add support for interleaving to the next sector header prediction code. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 15:33:46 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 16:33:46 -0400 (EDT) Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: <200409012033.QAA25178@ss10.danlan.com> "Steven Parker" wrote: |P.S. I renamed the HDOS and HUG submissions to conform with the other |archives and be more descriptive. All the duplicates of the HUG disks |matched byte-for-byte except one of them, which I have set aside and may |look into more thoroghly later. Which one failed to match? Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed Sep 1 16:08:18 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 1 Sep 2004 16:08:18 -0500 Subject: [sebhc] Archive question regarding cross-posting In-Reply-To: <200409011845.i81IjZIa005125@ms-smtp-04-eri0.ohiordc.rr.com> Message-ID: <000001c49067$ce801bf0$1f6fa8c0@eths.k12.il.us> I encourage cross-posting material in the public domain but some items may be released specifically to SEBHC. This may be the case with Peter Shkabara's software and documentation. The HUG material and HDOS itself have been released to the public domain. As for Heath documentation, nobody, including those at the current Heathkit organization, seem to know who owns the copyright. You (Barry) might be in the best position of any of us to answer that question! I also lack explicit permission to republish the Magnolia material. Concern about copyright - both protection and liability - was the driving force behind creating a closed archive in the first place. Let me also remind list members to only upload material that is known to be in the public domain. And, as always, thank you all for your interest and contributions. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Barry Watzman > Sent: Wednesday, September 01, 2004 1:46 PM > To: sebhc at sebhc.org > Subject: [sebhc] Archive question > > > Does anyone have a problem with material (documents, > primarily) from the archive being cross posted on Howard Harte's site: > > http://www.hartetechnologies.com/manuals/ > > It's my opinion that as web sites come and go, and as, > unfortunately, we ourselves "go", the only way to insure the > long-term survival of this material is to get it as widely > distributed in as many forms and places as possible. But I > won't cross-post it if people object. > > Barry Watzman > Watzman at neo.rr.com > > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 16:12:14 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 14:12:14 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012112.OAA17034@clulw009.amd.com> >From: "Dan Lanciani" > >"Dwight K. Elvey" wrote: > >| I don't know if Dan is extracting the sector header information >|and using that to determine the order of the sector blocks >|or just reading the disk order. > >I'm using the headers. Doing it any other way would make retries very >difficult. More specifically, I read an entire track (actually a track >and a half), separate the data bits from the clock bits, and begin hunting >for sectors which I scatter into a track image buffer. For each sector that >I validate I set a bit in a mask. When I finish with the raw track I check >the mask to see if I have found all 10 sectors. If I have not I re-read the >track and repeat. Hi Dan This sounds good. It will keep us from getting things mixed up. As long as you use the headers as part of your process, there should be no issue. > >|It is true that all original >|HDOS distribution disk have the natural order. This may not >|always be the case. Dan mentions in a previous mail that the >|only staggering he knew of was skewing but it was quite common >|to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that >|my transfer program even has this option for creating disk ). > >Which H17 driver supported creating interleaved formats? I use many of the calls from the H17. I have lifted the format code from the H17 code and patched in the interleaving. Once the disk is formatted, the H17 doesn't care if it is interleaved or not since it only looks at the headers to find sectors. You can see my code in the H89LDR9.ZIP file, source file H89LDR2.ASM. The idea of interleaving was done by many others before me. I just added it to my code for those that want it. As long as I'm reading and writing through H17 routines, it makes no difference other than time. HDOS it self has an OS level interleaving like CP/M but it is not easily modified at the OS level as CP/M is. There was an article in one of the magazines, way back then, about doing the physical interleaving for HDOS disk. I've long since lost that but remember reading it. I know of a least one other user that had most of their disks interleaved. I don't expect these to show up here since it was a customer data base he used it with. > >| I guess the question for Dan is, do you assume that the physical >|sector order matches the logical sector order when creating >|your image files or do you map the logical sector order into >|the order used in the images? > >I take the sectors as I find them but then (unless a special switch is ---snip--- It sounds like we are still in good shape. You'll just have to watch out for any disk created with my transfer code that someone chose to take advantage of the interleaving option. It sounds like your code will bomb out on them. Also, should you come on disk that fails in this way in the future, don't assume that the disk is bad. It might just be one of the few that are out there someplace that have had this done to them by someone else. I do believe that you are OK in assuming that all release disk were done without interleaving. There would be no reason for them to do otherwise. Dwight -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 16:34:26 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 17:34:26 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040901213425.NHBZ13092.berlinr.sprint.ca@smtp.sprint.ca> At 19:15 01/09/2004 +0000, you wrote: >Dave says: >>Then we don't have to maintain two copies of everything. > >We don't .. all the new submissions are in the .h8d format. And we have >'disktool' to do conversions. Ok - my point is that if people are concerned that the header information is lost with my format, then perhaps it should be stored as .H17 and use "disktool" to convert it to H8D as required. >>Also, I've got it in my mind to modify the emulator so that it can boot >>CP/M ... Presumably I need to add the "RAM at 0" option ... anything else >>needed? I don't have any technical info on this - can someone give me a >>pointer? > >I did already! Here's an excerpt from the previous message: Ok ---- Now... Is there a copy of CP/M which will boot on an H8 using this feature, and still use the standard H5 serial board for the console - IIRC, this features was on an enhanced console board ... I don't want to have to implement new "virtual unarts" - just add the RAM at 0 option - is there software which supports this configuration? Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 16:36:13 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 17:36:13 -0400 Subject: [sebhc] Archive question regarding cross-posting In-Reply-To: <000001c49067$ce801bf0$1f6fa8c0@eths.k12.il.us> Message-ID: <200409012136.i81LaAnb011547@ms-smtp-02-eri0.ohiordc.rr.com> I'm inclined to take the view, with regard to copyright, to "just do it", and if anyone complains, take it down after the fact. Some of this material has Intel, Motorola, National Semiconductor and AMD material in it -- datasheets for CPUs, math coprocessors, UARTs, video chips, etc. -- and it's been up for years already, and no one has complained. I can't imagine anyone "pressing" a copyright action for damages providing, that if asked, the material in question was removed. As to the Heath stuff, what a mess. Heath and Zenith Data Systems were separate legal corporate entities, both owned by ZEC (Zenith Electronics)(and VEC was yet a 3rd legal entity). Then ZDS was sold to Group Bull, a French company, without Heath, while ZEC went bankrupt and their assets were mostly bought by LG (Lucky Goldstar, Korea), Group Bull sold ZDS to Packard Bell, which was then acquired by NEC, and somehow Heathkit survived, although not as the company that we knew, and I have no idea what the legal ownership or structure of today's Heathkit looks like. As to the copyrights, as late as 1980 or so, some Heathkit stuff was not copyrighted at all (which I actually worked to correct -- wish I hadn't !!), and Heath, ZDS, ZEC and VEC all had various copyright interests (often joint and overlapping) in these documents, but at this point, trying to sort all of that out would be a real mess, and I seriously doubt if anyone, anywhere has any interest in, for example, the H-8 assembly manual (or even the Z-100 manuals). There's tons of "copyrighted" material on the web, including much stuff from companies that no longer exist (Altair, Imsai, Processor Tech, etc.), but also lots of stuff from firms that do, including (as mentioned) antique documents from Intel, AMD, Western Digital, National Semiconductor, Cromemco (which does still exist), Motorola and even, occasionally Microsoft. I'm not aware of any cases at all, not even one, in which anyone has gone after anyone for posting old but nominally copyrighted documentation. However, there's no way I'd post Microsoft CODE (or even documentation), but even then, I suspect that all that would happen (for 20-year old CP/M software) would be a letter from their attorneys demanding that it be removed. Which, of course, anyone would be a fool not to comply with. Barry Watzman Watzman at neo.rr.com -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Jack Rubin Sent: Wednesday, September 01, 2004 5:08 PM To: sebhc at sebhc.org Subject: RE: [sebhc] Archive question regarding cross-posting I encourage cross-posting material in the public domain but some items may be released specifically to SEBHC. This may be the case with Peter Shkabara's software and documentation. The HUG material and HDOS itself have been released to the public domain. As for Heath documentation, nobody, including those at the current Heathkit organization, seem to know who owns the copyright. You (Barry) might be in the best position of any of us to answer that question! I also lack explicit permission to republish the Magnolia material. Concern about copyright - both protection and liability - was the driving force behind creating a closed archive in the first place. Let me also remind list members to only upload material that is known to be in the public domain. And, as always, thank you all for your interest and contributions. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Barry Watzman > Sent: Wednesday, September 01, 2004 1:46 PM > To: sebhc at sebhc.org > Subject: [sebhc] Archive question > > > Does anyone have a problem with material (documents, > primarily) from the archive being cross posted on Howard Harte's site: > > http://www.hartetechnologies.com/manuals/ > > It's my opinion that as web sites come and go, and as, > unfortunately, we ourselves "go", the only way to insure the > long-term survival of this material is to get it as widely > distributed in as many forms and places as possible. But I > won't cross-post it if people object. > > Barry Watzman > Watzman at neo.rr.com > > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 16:34:30 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 17:34:30 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040901213429.NHCZ13092.berlinr.sprint.ca@smtp.sprint.ca> >>1) I had not-to-long ago just done the Altair simulator which has the >> NorthStar hard sectored single-density disk system in it - this system >> DOES NOT use headers, and sector numbering HAS TO BE the physical > >Hi Dave > Actually, single-density and double-density both use headers, >you just don't, usually, have as direct access to them as Dan's >methods would have. Both can also have different physical and >logical interleaving. I used to play with the physical sector >interleaving on an original IBM PC to speed up transfers. I guess I wasn't clear - NOT EVERY hard-sectored system in the world uses headers - H8 uses headers, but NorthStar (which is the only HardSectored system I had worked on before the H8) DOES NOT ** (I know because I ported my own OS to it and wrote the low level disk system drivers) - that is what 1) is trying to explain - I made the decision NOT to use physical headers in part because that is what I was used to at the time, and I saw no need for them other than to satisfy the H8 disk drivers (which my "on the fly" generated headers do) - this is an explaination of history, not an argument. ** The N* system has a register in the controller which tells you the current sector number - it does this by detecting the track index hole (shorter timing than sector holes) and then maintaining a hardware counter for each sector index pulse - As long as the drive remains selected this counter is accurate - that is why N* systems keep the drive selected for a fairly long period after the last access. When you deselect/select (including switch drives), you have to wait for the next track index to resync - this is all done with hardware timers and counters! - At least that is the way the Single Density system which which I am famier works - there are only 256 bytes of readable data recorded between the sector index pulses. [This also means that you CANNOT HAVE INTERLEAVE on a N* controller, which is why the "Raw binary" dump of sequential sectors seemed natural to me] Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed Sep 1 16:33:46 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 01 Sep 2004 21:33:46 +0000 Subject: [sebhc] HUG disk mismatch Message-ID: >Which one failed to match? 885-1020. Download the one from the archives and compare it to yours. It's possible the differences might only be due to a change in the manufacturing process and appear only in unused sectors, but I haven't confirmed that yet. Anybody find "chaseleds" or the TMI package yet? _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 16:55:10 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 14:55:10 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012155.OAA17056@clulw009.amd.com> >From: "Dave Dunfield" > >At 19:15 01/09/2004 +0000, you wrote: >>Dave says: >>>Then we don't have to maintain two copies of everything. >> >>We don't .. all the new submissions are in the .h8d format. And we have >>'disktool' to do conversions. > >Ok - my point is that if people are concerned that the header information >is lost with my format, then perhaps it should be stored as .H17 and use >"disktool" to convert it to H8D as required. > >>>Also, I've got it in my mind to modify the emulator so that it can boot >>>CP/M ... Presumably I need to add the "RAM at 0" option ... anything else >>>needed? I don't have any technical info on this - can someone give me a >>>pointer? >> >>I did already! Here's an excerpt from the previous message: > >Ok ---- Now... Is there a copy of CP/M which will boot on an H8 using this >feature, and still use the standard H5 serial board for the console - IIRC, >this features was on an enhanced console board ... I don't want to have to >implement new "virtual unarts" - just add the RAM at 0 option - is there >software which supports this configuration? Hi Dan The Z80 board didn't require the enhanced board. The older 8080 machines required the extra board. I'm not sure if the CP/M boots to both the H8-4 and H8-5 boards. I'll try to check this out. I most likely won't get to it before the weekend. I have both boards so I can try it. HDOS will boot to either board. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 17:03:19 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 15:03:19 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012203.PAA17060@clulw009.amd.com> >From: "Dave Dunfield" > >At 19:15 01/09/2004 +0000, you wrote: >>Dave says: >>>Then we don't have to maintain two copies of everything. >> >>We don't .. all the new submissions are in the .h8d format. And we have >>'disktool' to do conversions. > >Ok - my point is that if people are concerned that the header information >is lost with my format, then perhaps it should be stored as .H17 and use >"disktool" to convert it to H8D as required. > ---snip--- Hi Dave The only issue with headers ( other than exact replica of the interleaving ) is the volume number. As you know, HDOS places this number in a convenient place on track 0 so that isn't an issue. My transfer program is HDOS friendly and will look at this info as a default. At least to this point, all of the CP/M disk seem to work with the volume number set to 0. I'll know more when I get a chance to download a bunch of the images that Dan has posted. For those using my transfer program, ( you should of course read this in my documents ) it allows you to set the volume number. To my knowledge at this point, the volume number for the CP/M disk should be 0. Like I said, I'll be checking this out and let those know if I find anything different. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 16:49:24 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 14:49:24 -0700 (PDT) Subject: [sebhc] HUG disk mismatch Message-ID: <200409012149.OAA17049@clulw009.amd.com> >From: "Steven Parker" > >>Which one failed to match? > >885-1020. Download the one from the archives and compare it to yours. It's >possible the differences might only be due to a change in the manufacturing >process and appear only in unused sectors, but I haven't confirmed that yet. > Hi Steve It might be better to load them both to a real disk. One could then compare the files that exist. This could be done, either through Dan's emulator or my transfer program to a real machine. It may be that even something like the directory is in a different location. Different versions of the init program placed the directories in different places. I've seen this a number of times when doing a quick check to see what is on a disk. I often just use xtree to scan for the directory. Dwight >Anybody find "chaseleds" or the TMI package yet? > I've not seen it. Dwight -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed Sep 1 17:33:44 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 1 Sep 2004 17:33:44 -0500 Subject: [sebhc] Archive question regarding cross-posting In-Reply-To: <200409012136.i81LaAnb011547@ms-smtp-02-eri0.ohiordc.rr.com> Message-ID: <000001c49073$bf281390$1f6fa8c0@eths.k12.il.us> > I'm inclined to take the view, with regard to copyright, to > "just do it", and if anyone complains, take it down after the > fact. Some of this material has Intel, Motorola, National > Semiconductor and AMD material in it -- datasheets for CPUs, > math coprocessors, UARTs, video chips, etc. -- and it's been > up for years already, and no one has complained. I can't > imagine anyone "pressing" a copyright action for damages > providing, that if asked, the material in question was removed. This was also the consensus reached among SEBHC members at the time the archive was established and is reiterated in the ftp login screen, though I guess we should make sure it appears for html users as well. The only material for which we have definitely failed to get permission is software from Hoyle and Hoyle. I am still in discussion with Jim Giloogly about his Software Toolworks material and until I get approval from him, none of his software should be uploaded. Jack -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 17:41:05 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 18:41:05 -0400 (EDT) Subject: [sebhc] HUG disk mismatch Message-ID: <200409012241.SAA29031@ss10.danlan.com> "Steven Parker" wrote: |>Which one failed to match? | |885-1020. Download the one from the archives and compare it to yours. It's |possible the differences might only be due to a change in the manufacturing |process and appear only in unused sectors, but I haven't confirmed that yet. I don't have 885-1020, so I'm going to assume you mean 1120. I checked this and while the disk differs, the files are identical. By the way, there is no need to load the images on a real or virtual disk. I wrote this little utility to verify an HDOS disk and (optionally with the -e switch) extract the files: #include unsigned char buf[2560], z[256], gl[256], grt[256], buf2[2048]; int diag, extract; main(argc, argv) char **argv; { register int i, j; int t = 0, dirsec, grtsec, spg, n; char nbuf[16]; register char *p; again: if(argc > 1 && !strcmp(argv[1], "-d")) { diag = 1; argc--; argv++; goto again; } if(argc > 1 && !strcmp(argv[1], "-e")) { extract = 1; argc--; argv++; goto again; } for(i = 0; i < 256; i += 2) { gl[i] = 'G'; gl[i+1] = 'L'; } while(read(0, buf, sizeof(buf)) == sizeof(buf)) { if(t == 0) { printf("ver = %x, spg = %d, type = %d, size = %d, ssize = %d, dir = %d, grt = %d\n", buf[9*256+9], spg = buf[9*256+7], buf[9*256+8], buf[9*256+12] + 256*buf[9*256+13], buf[9*256+14] + 256*buf[9*256+15], dirsec = buf[9*256+3] + 256*buf[9*256+4], grtsec = buf[9*256+5] + 256*buf[9*256+6]); } if(diag) { for(i = 0; i < 10; i++) if(!memcmp(buf + 256*i, z, 256)) printf("track %d sector %d is zero\n", t, i); for(i = 0; i < 9; i++) for(j = i + 1; j < 10; j++) if(!memcmp(buf + 256*i, buf + 256*j, 256) && memcmp(buf + 256*i, z, 256) && memcmp(buf + 256*i, gl, 256)) printf("track %d sector %d=%d %c %c\n", t, i, j, buf[256*i], buf[256*i+1]); } t++; } lseek(0, 256L*grtsec, 0); read(0, grt, 256); while(dirsec) { printf("Directory sector = %d\n", dirsec); lseek(0, 256L*dirsec, 0); if(read(0, buf, 512) != 512) { perror("directory read"); exit(1); } if(dirsec != (i = buf[508] + 256*buf[509])) { fprintf(stderr, "Bad directory self ptr = %d\n", i); exit(1); } for(i = 0; i < 22; i++) { if(buf[23*i] == 0377 || buf[23*i] == 0376) continue; p = nbuf; for(j = 0; j < 8; j++) { printf("%c", *p = buf[23*i+j]); if(*p > ' ') p++; } *p++ = '.'; printf("."); for(j = 8; j < 11; j++) { printf("%c", *p = buf[23*i+j]); if(*p > ' ') p++; } *p = 0; printf(" first=%d last=%d tail=%d ", j=buf[23*i+16], buf[23*i+17], buf[23*i+18]); if(buf[23*i+18] > spg) { fprintf(stderr, "\nTail too big\n"); exit(1); } if(extract) { if((n = creat(nbuf, 0666)) < 0) { fprintf(stderr, "\n"); perror(nbuf); exit(1); } } while(j != buf[23*i+17]) { printf("[%d] ", j); lseek(0, j*256L*spg, 0); if(read(0, buf2, 256*spg) != 256*spg) { perror("file read"); exit(1); } if(extract) write(n, buf2, 256*spg); j = grt[j]; } printf("[%d]\n", j); if(grt[j]) fprintf(stderr, "Non-zero grt on last group\n"); lseek(0, j*256L*spg, 0); if(read(0, buf2, 256*buf[23*i+18]) != 256*buf[23*i+18]){ perror("file tail read"); exit(1); } if(extract) { write(n, buf2, 256*buf[23*i+18]); close(n); } } dirsec = buf[510] + 256*buf[511]; } } -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 17:44:30 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 15:44:30 -0700 (PDT) Subject: [sebhc] Archive question regarding cross-posting Message-ID: <200409012244.PAA17086@clulw009.amd.com> ---snip--- >The only material for which we have definitely failed to get permission >is software from Hoyle and Hoyle. I am still in discussion with Jim >Giloogly about his Software Toolworks material and until I get approval >from him, none of his software should be uploaded. > >Jack Hi I'm also sitting on a Chess program written by one of the major Chess program writers. He lives in Mobile, Alabama. I was hoping that someone that lived in that area, on this list, could contact him about a copyright release. It is a shame to keep sitting on it. It is just burning away where it is. If no one volunteers, I may have to resort to snail mail. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 17:36:59 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 15:36:59 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012236.PAA17082@clulw009.amd.com> Hi There is one thing I've thought would be good to add to the h8d format. I think we could add one byte to the end that would be the volume number. This could be optional since HDOS disk already include this in the first track data. Adding one more byte would cause allocation of another disk block on most files systems ( like DOS or Windoze ). That is a reasonable waste of space to always use. This information could be determined by any program as simply checking the file size. One byte longer than the 100K bytes and it must have a volume number attached. If exactly 100K bytes, the first track information could be used. I believe that most current programs would just ignore this last byte. I'm relatively sure my program would. I currently buffer a track at a time. This should keep it backwards compatible. What do others think? Dwight -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 17:36:49 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 18:36:49 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012236.SAA28979@ss10.danlan.com> "Dwight K. Elvey" wrote: |>|It is true that all original |>|HDOS distribution disk have the natural order. This may not |>|always be the case. Dan mentions in a previous mail that the |>|only staggering he knew of was skewing but it was quite common |>|to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that |>|my transfer program even has this option for creating disk ). |> |>Which H17 driver supported creating interleaved formats? | | I use many of the calls from the H17. I have lifted the format |code from the H17 code and patched in the interleaving. Once |the disk is formatted, the H17 doesn't care if it is interleaved |or not since it only looks at the headers to find sectors. |You can see my code in the H89LDR9.ZIP file, source |file H89LDR2.ASM. The idea of interleaving was done by many |others before me. I just added it to my code for those that |want it. As long as I'm reading and writing through H17 |routines, it makes no difference other than time. I know what interleaving is. I'm asking which real-world H17 driver supported the creation of interleaved disks. At the time I was really into this (I had my own heavily modified SY: driver) and I had never come across such a thing. |HDOS it |self has an OS level interleaving like CP/M but it is not easily |modified at the OS level as CP/M is. Not really. HDOS interleaved the directory sectors, but not with a fixed mapping, i.e., it didn't care if they weren't set up that way. CP/M BIOS- based interleaving was typically a direct mapping done "transparently" on each track. | It sounds like we are still in good shape. You'll just |have to watch out for any disk created with my transfer |code that someone chose to take advantage of the interleaving |option. It sounds like your code will bomb out on them. "fail gracefully" Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 17:53:11 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 18:53:11 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040901213425.NHBZ13092.berlinr.sprint.ca@smtp.sprint.ca> Message-ID: <200409012253.i81Mr8Ia013262@ms-smtp-04-eri0.ohiordc.rr.com> I agree -- save the version with the header, and use the conversion utility to convert to the version without the header, if necessary. There were two versions of CP/M used on the H8. The "Lifeboat" version was "org'd" at 4200H, I think (my recollection is fuzzy), but the real Heath version was standard "org 0" and required RAM at zero. Does this list server have a "digest" mode? -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 17:55:39 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 18:55:39 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040901213429.NHCZ13092.berlinr.sprint.ca@smtp.sprint.ca> Message-ID: <200409012255.i81MtZnb017497@ms-smtp-02-eri0.ohiordc.rr.com> I believe that NorthStar DOS (the original single density one) did use headers. I disassembled that OS, and my source code, fully commented, from 1978, is on Howard's site. -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 18:34:15 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 16:34:15 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409012334.QAA17107@clulw009.amd.com> >From: "Dan Lanciani" > >"Dwight K. Elvey" wrote: > >|>|It is true that all original >|>|HDOS distribution disk have the natural order. This may not >|>|always be the case. Dan mentions in a previous mail that the >|>|only staggering he knew of was skewing but it was quite common >|>|to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that >|>|my transfer program even has this option for creating disk ). >|> >|>Which H17 driver supported creating interleaved formats? >| >| I use many of the calls from the H17. I have lifted the format >|code from the H17 code and patched in the interleaving. Once >|the disk is formatted, the H17 doesn't care if it is interleaved >|or not since it only looks at the headers to find sectors. >|You can see my code in the H89LDR9.ZIP file, source >|file H89LDR2.ASM. The idea of interleaving was done by many >|others before me. I just added it to my code for those that >|want it. As long as I'm reading and writing through H17 >|routines, it makes no difference other than time. > >I know what interleaving is. I'm asking which real-world H17 driver >supported the creation of interleaved disks. At the time I was really >into this (I had my own heavily modified SY: driver) and I had never >come across such a thing. Hi Dan As far as I know, no Heathkit driver ever did this. I know it was done by others because I learned the trick while looking at other's disks that were formatted this way. I was in the process of writing my Forth to run on the H89, at the time ( the one that is available from the ftp ). How they did it I'm not sure. They may have had special SY: files. I do remember reading an article about doing this on the H89. So, like I've said, I was not the first one. Like I said, HDOS could care less, once it is formatted. It just needs valid headers. You only need to know about the disk's interleave while formatting. All the regular software works fine with it after that. No special drivers are needed. I remember writng my own code to interleave, the first time using the Forth that I'd implemented. I used this for a friend that needed it for his BASIC so it wasn't so slow at loading. He asked me to specifically do this for him so he must have known about it. > >|HDOS it >|self has an OS level interleaving like CP/M but it is not easily >|modified at the OS level as CP/M is. > >Not really. HDOS interleaved the directory sectors, but not with a fixed >mapping, i.e., it didn't care if they weren't set up that way. CP/M BIOS- >based interleaving was typically a direct mapping done "transparently" on >each track. I just meant that CP/M has a nice table that one can replace. I'm not sure if I've ever seen anything like that in HDOS, although it might be there. > >| It sounds like we are still in good shape. You'll just >|have to watch out for any disk created with my transfer >|code that someone chose to take advantage of the interleaving >|option. It sounds like your code will bomb out on them. > >"fail gracefully" Yes, fails gracefully. :) Dwight > > Dan Lanciani > ddl at danlan.*com >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 18:45:48 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 19:45:48 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409012334.QAA17107@clulw009.amd.com> Message-ID: <200409012345.i81NjjIa020992@ms-smtp-04-eri0.ohiordc.rr.com> There are two ways to interleave. In the 1st method, used by CP/M, you have an interleave table in the operating system itself. The sectors are in physical order on the diskette, but are not used in physical sequence. That is, CP/M (on an 8" disk) uses sector 1 then 7 then 13, then 19, etc. The other way is to have the OS use the sectors sequentially (1,2,3 etc.) but to do the interleaving when the disk is formatted. So the OS will ask for sector 1, 2, 3 ...., but on the disk the sector after sector 1 is not 2 but rather something else. There is no requirement that the sectors on the disk be in sequential order. In fact, there is no requirement that they be contiguous, or that they be "positive" numbers (if one wants to interpret them as signed numbers). They are more like labels than actual numbers, they can be in any sequence, and there can be gaps (a fact on which may copy protection schemes rely). -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 19:07:24 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 17:07:24 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020007.RAA17123@clulw009.amd.com> >From: "Barry Watzman" > > >There are two ways to interleave. > >In the 1st method, used by CP/M, you have an interleave table in the >operating system itself. The sectors are in physical order on the diskette, >but are not used in physical sequence. That is, CP/M (on an 8" disk) uses >sector 1 then 7 then 13, then 19, etc. > >The other way is to have the OS use the sectors sequentially (1,2,3 etc.) >but to do the interleaving when the disk is formatted. So the OS will ask >for sector 1, 2, 3 ...., but on the disk the sector after sector 1 is not 2 >but rather something else. There is no requirement that the sectors on the >disk be in sequential order. In fact, there is no requirement that they be >contiguous, or that they be "positive" numbers (if one wants to interpret >them as signed numbers). They are more like labels than actual numbers, >they can be in any sequence, and there can be gaps (a fact on which may copy >protection schemes rely). Hi Barry On the HDOS hard sectored disk, the headers do have to have sector numbers that need to match those that are requested. The order on the disk doesn't matter for the H17 ROM. They can even be random order. How we got here was that I was concerned that if Dan's code read the physical sectors and placed them sequentially in the image file, any interleaving might cause loss of order of the sectors because the headers are not saved. He assures me that his code looks both at the sector order and the sector header for a match. As long as he is not reading interleaved disk, there is no issue. He states that he'd never seen this on HDOS. I believe him. I state that I'd seen it before I'd ever done it myself ( I believe myself ). Dwight -- Delivered by the SEBHC Mailing List From melamy at earthlink.net Wed Sep 1 19:25:32 2004 From: melamy at earthlink.net (Steve Thatcher) Date: Wed, 01 Sep 2004 20:25:32 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409012345.i81NjjIa020992@ms-smtp-04-eri0.ohiordc.rr.com > References: <200409012334.QAA17107@clulw009.amd.com> Message-ID: <5.1.0.14.2.20040901202353.00bbbad0@mail.earthlink.net> make that three ways because I have had cp/m systems that interleaved the sector on the disk on the physical media. The floppy controller could care less when the track is formatted as to which sector was which on a soft sector disk. best regards, Steve Thatcher At 07:45 PM 09/01/2004 -0400, Barry Watzman wrote: >There are two ways to interleave. > >In the 1st method, used by CP/M, you have an interleave table in the >operating system itself. The sectors are in physical order on the diskette, >but are not used in physical sequence. That is, CP/M (on an 8" disk) uses >sector 1 then 7 then 13, then 19, etc. > >The other way is to have the OS use the sectors sequentially (1,2,3 etc.) >but to do the interleaving when the disk is formatted. So the OS will ask >for sector 1, 2, 3 ...., but on the disk the sector after sector 1 is not 2 >but rather something else. There is no requirement that the sectors on the >disk be in sequential order. In fact, there is no requirement that they be >contiguous, or that they be "positive" numbers (if one wants to interpret >them as signed numbers). They are more like labels than actual numbers, >they can be in any sequence, and there can be gaps (a fact on which may copy >protection schemes rely). > > > >-- >Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 19:27:34 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 20:27:34 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409020007.RAA17123@clulw009.amd.com> Message-ID: <200409020027.i820RVIa021612@ms-smtp-04-eri0.ohiordc.rr.com> Of course the headers always have to match what is requested. But that's the whole point. A copy protection scheme can request sector 218, which won't exist on any normal disk (or be capable of being created with any normal format program). Similarly, if it requests sector 1 and then sector 2, it doesn't matter that sector 2 doesn't immediately follow sector 1. Personally, if I was writing an image program, I'd record each track's sectors in the order in which they physically occurred on the track AND I'd also record, in each sector's data contents, the track and sector number recorded in that sector's header. Only by recording BOTH of these -- they physical layout AND the logical layout (the numbers in the header) would it be possible to physically reproduce a physically correct image of the diskette. [by the way, this applies to tracks also. You could have a track number in a header that was different from the physical track number. For example, all (or just some or just one) of the sectors on the 20th track could have a header that said it was track 169.] -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dwight K. Elvey Sent: Wednesday, September 01, 2004 8:07 PM To: sebhc at sebhc.org Subject: RE: [sebhc] h17 and h8d disk images >From: "Barry Watzman" > > >There are two ways to interleave. > >In the 1st method, used by CP/M, you have an interleave table in the >operating system itself. The sectors are in physical order on the diskette, >but are not used in physical sequence. That is, CP/M (on an 8" disk) uses >sector 1 then 7 then 13, then 19, etc. > >The other way is to have the OS use the sectors sequentially (1,2,3 etc.) >but to do the interleaving when the disk is formatted. So the OS will ask >for sector 1, 2, 3 ...., but on the disk the sector after sector 1 is not 2 >but rather something else. There is no requirement that the sectors on the >disk be in sequential order. In fact, there is no requirement that they be >contiguous, or that they be "positive" numbers (if one wants to interpret >them as signed numbers). They are more like labels than actual numbers, >they can be in any sequence, and there can be gaps (a fact on which may copy >protection schemes rely). Hi Barry On the HDOS hard sectored disk, the headers do have to have sector numbers that need to match those that are requested. The order on the disk doesn't matter for the H17 ROM. They can even be random order. How we got here was that I was concerned that if Dan's code read the physical sectors and placed them sequentially in the image file, any interleaving might cause loss of order of the sectors because the headers are not saved. He assures me that his code looks both at the sector order and the sector header for a match. As long as he is not reading interleaved disk, there is no issue. He states that he'd never seen this on HDOS. I believe him. I state that I'd seen it before I'd ever done it myself ( I believe myself ). Dwight -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 19:38:26 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 20:38:26 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040902003824.RXZU13092.berlinr.sprint.ca@smtp.sprint.ca> At 18:55 01/09/2004 -0400, you wrote: >I believe that NorthStar DOS (the original single density one) did use >headers. I disassembled that OS, and my source code, fully commented, from >1978, is on Howard's site. Hi Barry, I beg to differ - NS 'SD' dos actually calls the controller ROM for disk operations, (which redirects write and verify back to the DOS code) Here is the relavent snippet for the controller ROM code for a READ operation: (Note that the "wait for the right sector" function occurs BEFORE it vectors back to DOS, so this code does apply to ALL disk operations. ... Entry/motor on etc. code snipped ... E934 CD 64 E9 CALL $E964 ; Step to track E937 C1 POP B ; <[210A] Sector/function Here we wait for the sector to "come around" we do this by reading the hardware register at $EB30, which is the 'B' status, and reflects a hardware counter in the controller which counts index pulses. There are NO data transfers ($EB50) while waiting for the right sector (hence no header information written on the disk). E938 CD CE E9 CALL $E9CE ; Wait one sector time E93B 3A 30 EB LDA $EB30 ; Read B status E93E E6 0F ANI $0F ; Save only sector number E940 B8 CMP B ; Are we at sector E941 C2 38 E9 JNZ $E938 ; No, wait for it E944 E1 POP H ; <[210C] Ram address E945 0D DCR C ; Test function E946 FA 0A 20 JM $200A ; 00=Write \_ Redirect back to DOS E949 C2 07 20 JNZ $2007 ; !01=Verify / ; Read block of data from drive Here we wait for the "body" indicator which means that data is available - still no actual data transfer from the drive E94C 06 8C MVI B,$8C ; Timeout count E94E 11 50 EB LXI D,$EB50 ; Read data <= Data register address E951 0E 00 MVI C,$00 ; Read 256 bytes <= Sector size E953 3A 10 EB LDA $EB10 ; Get status E956 E6 04 ANI $04 ; Wait for Body E958 C2 AE E9 JNZ $E9AE ; Body - ready for data E95B 05 DCR B ; Reduce timeout E95C C2 53 E9 JNZ $E953 ; Wait for it E95F 3E 01 MVI A,$01 ; Report TIMEOUT error E961 C3 AB E9 JMP $E9AB ; And exit ... intervening code snipped ... Here is the FIRST time we read the data register, and we read it exactly 256 times while stuffing the data in memory (one sectors worth), and one more time to get the check value - we never read any other data (header) from the disk (Search the entire disassembly, and the only reference to the data register is the LXI D which occurs above. ; ; Read data sector from disk ; E9AE 41 MOV B,C ; Zero checkval E9AF 1A LDAX D ; Read data byte E9B0 77 MOV M,A ; Write to RAM E9B1 A8 XRA B ; Compute E9B2 07 RLC ; Check E9B3 47 MOV B,A ; Resave check E9B4 23 INX H ; Next RAM address E9B5 0D DCR C ; Reduce count E9B6 C2 AF E9 JNZ $E9AF ; Read them all E9B9 1A LDAX D ; Read check value E9BA A8 XRA B ; Does it match? E9BB CA C4 E9 JZ $E9C4 ; Yes, it's OK I have the N* sd controller documentation, including theory of operation and schematics on my site, you can read through to see how the system works. A couple of points to note: Page 13 "Data Format" Zeros 16 bytes Sync Char(FB) 1 byte Data 256 bytes Check Char 1 byte --- 274 bytes No sector header is mentioned at all. Page 9 "Counter 1G is the sector position counter" (admittedly a bit vague, however on schematic page 3, we see counter 1G is reset by the "index" hole signal, and clocked by the "new sector" signal (follow these back to see how they are generated) - it's outputs are labled "Sector Counter to 8080 via MPXR" - MPXR is IC 4E, a multiplexor which controls Status A or B selected, which is the register read at $EB30 above. I wrote my DMF OS originally on this system - since the controller ROM vectors back to stubs at $2000, and DMF loads a 256 byte stub at $0000, and the rest at the highest 4K block in the system (in my case $F000), I could not use the controller ROM once the system booted - therefore I wrote my own complete set of low-level disk access functions for the NorthStar single-density controller. I also simulated this controller right down to the hardware register level with correct timing in my Altair/NorthStar simulator... In other words - I know this controller AND system software VERY WELL - there is NO sector header information written on the diskette. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 19:38:30 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 20:38:30 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040902003829.RYBC13092.berlinr.sprint.ca@smtp.sprint.ca> > There is one thing I've thought would be good to >add to the h8d format. I think we could add one byte >to the end that would be the volume number. >This could be optional since HDOS disk already include >this in the first track data. Adding one more byte >would cause allocation of another disk block on >most files systems ( like DOS or Windoze ). That >is a reasonable waste of space to always use. > This information could be determined by any program as >simply checking the file size. One byte longer than the >100K bytes and it must have a volume number attached. >If exactly 100K bytes, the first track information could >be used. > I believe that most current programs would just ignore >this last byte. I'm relatively sure my program would. >I currently buffer a track at a time. This should keep >it backwards compatible. > What do others think? I don't actually read the file size (I just open it), however I could just attempt a seek to the "extra byte" and if it fails, assume HDOS and use the volume id from block 9 (IIRC), otherwise use the volume ID in the "extra byte" (essentually a feature to allow for non-HDOS disks?) Sounds reasonable. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 19:40:03 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 20:40:03 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <5.1.0.14.2.20040901202353.00bbbad0@mail.earthlink.net> Message-ID: <200409020040.i820dxIa001011@ms-smtp-04-eri0.ohiordc.rr.com> That's the 2nd way ("but to do the interleaving when the disk is formatted") It's possible, also, to do both (use the sectors out-of-sequence, and also format them (put them on the disk) out of sequence). -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Steve Thatcher Sent: Wednesday, September 01, 2004 8:26 PM To: sebhc at sebhc.org; sebhc at sebhc.org Subject: RE: [sebhc] h17 and h8d disk images make that three ways because I have had cp/m systems that interleaved the sector on the disk on the physical media. The floppy controller could care less when the track is formatted as to which sector was which on a soft sector disk. best regards, Steve Thatcher At 07:45 PM 09/01/2004 -0400, Barry Watzman wrote: >There are two ways to interleave. > >In the 1st method, used by CP/M, you have an interleave table in the >operating system itself. The sectors are in physical order on the diskette, >but are not used in physical sequence. That is, CP/M (on an 8" disk) uses >sector 1 then 7 then 13, then 19, etc. > >The other way is to have the OS use the sectors sequentially (1,2,3 etc.) >but to do the interleaving when the disk is formatted. So the OS will ask >for sector 1, 2, 3 ...., but on the disk the sector after sector 1 is not 2 >but rather something else. There is no requirement that the sectors on the >disk be in sequential order. In fact, there is no requirement that they be >contiguous, or that they be "positive" numbers (if one wants to interpret >them as signed numbers). They are more like labels than actual numbers, >they can be in any sequence, and there can be gaps (a fact on which may copy >protection schemes rely). > > > >-- >Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 19:38:35 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 20:38:35 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040902003835.RYCS13092.berlinr.sprint.ca@smtp.sprint.ca> > The Z80 board didn't require the enhanced board. The older >8080 machines required the extra board. I'm not >sure if the CP/M boots to both the H8-4 and H8-5 boards. >I'll try to check this out. I most likely won't get to >it before the weekend. I have both boards so I can try it. >HDOS will boot to either board. Barry mentioned that there might be a Lifeboat version orged higher in memory - possibly it will work with the H5 and standard CPU board (no RAM at zero) - if so, I would love to get a copy. Still - CP/M isn't really CP/M if it can't run programs at $100 - so ideally, I would like to find a version which is configured for H5 console I/O, and works with the RAM at zero feature, but basically requires no other "special" features... Does such an animal exist? Does anyone know if CP/M just switches to RAM once, or does it toggle between ROM and RAM (say to access ROM functions)? My address space is a single 64K 8086 segment - to handle a "real" switch, I would have to rewrite and slow down the accesses to main memory in the CPU emulator (and there are a fair number). If it only does it infrequently, I could get away with just copying the RAM/ROM content in and out of the address space, and updating my write protect table... Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 19:38:33 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 20:38:33 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040902003832.RYBV13092.berlinr.sprint.ca@smtp.sprint.ca> At 18:53 01/09/2004 -0400, you wrote: >I agree -- save the version with the header, and use the conversion utility >to convert to the version without the header, if necessary. > >There were two versions of CP/M used on the H8. The "Lifeboat" version was >"org'd" at 4200H, I think (my recollection is fuzzy), but the real Heath >version was standard "org 0" and required RAM at zero. So is there a version of CP/M which will boot on a system with the H17 controller, the standard H5 I/O card, and RAM from $2000 to top of memory (IE: the configuration of my emulator) - if so, where can I get an image of it, because I would love to try it out. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 19:55:58 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 20:55:58 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040902003835.RYCS13092.berlinr.sprint.ca@smtp.sprint.ca> Message-ID: <200409020055.i820ttIa013390@ms-smtp-04-eri0.ohiordc.rr.com> I'm absolutely certain that there was a Lifeboat version org'd with a higher TPA and ROM at zero. It was, in that regard, the same version of CP/M used on the original Radio Shack TRS-80, which also had ROM (Microsoft ROM Basic) at zero, and I worked for months with Larry Alcoff (of Lifeboat) to write that non-standard version for the H-8 and H-89 (with, at that time, only the H-17 disk system). What I'm not sure of with certainty is where the RAM base and TPA began, I think it was 4200 hex but my recollection is fuzzy on that. [You are right, in a sense, "it wasn't really CP/M", although in another sense it was. Lifeboat had versions of virtually everything assembled for the alternate TPA beginning address.] The Heath version switched to an all-ram environment sometime during the boot process and never went backwards unless the entire computer was reset. Larry Plummer was the primary person responsible for working out the hardware details of converting both the H-8 and H-89 to be able to have 64k of RAM. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield Sent: Wednesday, September 01, 2004 8:39 PM To: sebhc at sebhc.org Subject: Re: [sebhc] h17 and h8d disk images > The Z80 board didn't require the enhanced board. The older >8080 machines required the extra board. I'm not >sure if the CP/M boots to both the H8-4 and H8-5 boards. >I'll try to check this out. I most likely won't get to >it before the weekend. I have both boards so I can try it. >HDOS will boot to either board. Barry mentioned that there might be a Lifeboat version orged higher in memory - possibly it will work with the H5 and standard CPU board (no RAM at zero) - if so, I would love to get a copy. Still - CP/M isn't really CP/M if it can't run programs at $100 - so ideally, I would like to find a version which is configured for H5 console I/O, and works with the RAM at zero feature, but basically requires no other "special" features... Does such an animal exist? Does anyone know if CP/M just switches to RAM once, or does it toggle between ROM and RAM (say to access ROM functions)? My address space is a single 64K 8086 segment - to handle a "real" switch, I would have to rewrite and slow down the accesses to main memory in the CPU emulator (and there are a fair number). If it only does it infrequently, I could get away with just copying the RAM/ROM content in and out of the address space, and updating my write protect table... Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 19:49:02 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 20:49:02 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040902003824.RXZU13092.berlinr.sprint.ca@smtp.sprint.ca> Message-ID: <200409020049.i820mwJX010314@ms-smtp-01-eri0.ohiordc.rr.com> It wasn't my recollection, but ok, I think you are right. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield Sent: Wednesday, September 01, 2004 8:38 PM To: sebhc at sebhc.org Subject: RE: [sebhc] h17 and h8d disk images At 18:55 01/09/2004 -0400, you wrote: >I believe that NorthStar DOS (the original single density one) did use >headers. I disassembled that OS, and my source code, fully commented, from >1978, is on Howard's site. Hi Barry, I beg to differ - NS 'SD' dos actually calls the controller ROM for disk operations, (which redirects write and verify back to the DOS code) Here is the relavent snippet for the controller ROM code for a READ operation: (Note that the "wait for the right sector" function occurs BEFORE it vectors back to DOS, so this code does apply to ALL disk operations. ... Entry/motor on etc. code snipped ... E934 CD 64 E9 CALL $E964 ; Step to track E937 C1 POP B ; <[210A] Sector/function Here we wait for the sector to "come around" we do this by reading the hardware register at $EB30, which is the 'B' status, and reflects a hardware counter in the controller which counts index pulses. There are NO data transfers ($EB50) while waiting for the right sector (hence no header information written on the disk). E938 CD CE E9 CALL $E9CE ; Wait one sector time E93B 3A 30 EB LDA $EB30 ; Read B status E93E E6 0F ANI $0F ; Save only sector number E940 B8 CMP B ; Are we at sector E941 C2 38 E9 JNZ $E938 ; No, wait for it E944 E1 POP H ; <[210C] Ram address E945 0D DCR C ; Test function E946 FA 0A 20 JM $200A ; 00=Write \_ Redirect back to DOS E949 C2 07 20 JNZ $2007 ; !01=Verify / ; Read block of data from drive Here we wait for the "body" indicator which means that data is available - still no actual data transfer from the drive E94C 06 8C MVI B,$8C ; Timeout count E94E 11 50 EB LXI D,$EB50 ; Read data <= Data register address E951 0E 00 MVI C,$00 ; Read 256 bytes <= Sector size E953 3A 10 EB LDA $EB10 ; Get status E956 E6 04 ANI $04 ; Wait for Body E958 C2 AE E9 JNZ $E9AE ; Body - ready for data E95B 05 DCR B ; Reduce timeout E95C C2 53 E9 JNZ $E953 ; Wait for it E95F 3E 01 MVI A,$01 ; Report TIMEOUT error E961 C3 AB E9 JMP $E9AB ; And exit ... intervening code snipped ... Here is the FIRST time we read the data register, and we read it exactly 256 times while stuffing the data in memory (one sectors worth), and one more time to get the check value - we never read any other data (header) from the disk (Search the entire disassembly, and the only reference to the data register is the LXI D which occurs above. ; ; Read data sector from disk ; E9AE 41 MOV B,C ; Zero checkval E9AF 1A LDAX D ; Read data byte E9B0 77 MOV M,A ; Write to RAM E9B1 A8 XRA B ; Compute E9B2 07 RLC ; Check E9B3 47 MOV B,A ; Resave check E9B4 23 INX H ; Next RAM address E9B5 0D DCR C ; Reduce count E9B6 C2 AF E9 JNZ $E9AF ; Read them all E9B9 1A LDAX D ; Read check value E9BA A8 XRA B ; Does it match? E9BB CA C4 E9 JZ $E9C4 ; Yes, it's OK I have the N* sd controller documentation, including theory of operation and schematics on my site, you can read through to see how the system works. A couple of points to note: Page 13 "Data Format" Zeros 16 bytes Sync Char(FB) 1 byte Data 256 bytes Check Char 1 byte --- 274 bytes No sector header is mentioned at all. Page 9 "Counter 1G is the sector position counter" (admittedly a bit vague, however on schematic page 3, we see counter 1G is reset by the "index" hole signal, and clocked by the "new sector" signal (follow these back to see how they are generated) - it's outputs are labled "Sector Counter to 8080 via MPXR" - MPXR is IC 4E, a multiplexor which controls Status A or B selected, which is the register read at $EB30 above. I wrote my DMF OS originally on this system - since the controller ROM vectors back to stubs at $2000, and DMF loads a 256 byte stub at $0000, and the rest at the highest 4K block in the system (in my case $F000), I could not use the controller ROM once the system booted - therefore I wrote my own complete set of low-level disk access functions for the NorthStar single-density controller. I also simulated this controller right down to the hardware register level with correct timing in my Altair/NorthStar simulator... In other words - I know this controller AND system software VERY WELL - there is NO sector header information written on the diskette. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 19:58:51 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 20:58:51 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040902003832.RYBV13092.berlinr.sprint.ca@smtp.sprint.ca> Message-ID: <200409020058.i820wlIa015838@ms-smtp-04-eri0.ohiordc.rr.com> I think that the RAM base was much higher even than 2000H, but yes, such a version of CP/M did exist. Getting a copy will be very, very hard, because it fell into extreme disfavor after the version came out that supported a "normal" CP/M memory configuration. [In case anyone is wondering, I have almost no H8/H89 software at all, I don't even have a copy of the software that I myself wrote.] -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield Sent: Wednesday, September 01, 2004 8:39 PM To: sebhc at sebhc.org Subject: RE: [sebhc] h17 and h8d disk images At 18:53 01/09/2004 -0400, you wrote: >I agree -- save the version with the header, and use the conversion utility >to convert to the version without the header, if necessary. > >There were two versions of CP/M used on the H8. The "Lifeboat" version was >"org'd" at 4200H, I think (my recollection is fuzzy), but the real Heath >version was standard "org 0" and required RAM at zero. So is there a version of CP/M which will boot on a system with the H17 controller, the standard H5 I/O card, and RAM from $2000 to top of memory (IE: the configuration of my emulator) - if so, where can I get an image of it, because I would love to try it out. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 19:57:38 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 17:57:38 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020057.RAA17174@clulw009.amd.com> >From: "Dave Dunfield" > > >> There is one thing I've thought would be good to >>add to the h8d format. I think we could add one byte >>to the end that would be the volume number. >>This could be optional since HDOS disk already include >>this in the first track data. Adding one more byte >>would cause allocation of another disk block on >>most files systems ( like DOS or Windoze ). That >>is a reasonable waste of space to always use. >> This information could be determined by any program as >>simply checking the file size. One byte longer than the >>100K bytes and it must have a volume number attached. >>If exactly 100K bytes, the first track information could >>be used. >> I believe that most current programs would just ignore >>this last byte. I'm relatively sure my program would. >>I currently buffer a track at a time. This should keep >>it backwards compatible. >> What do others think? > >I don't actually read the file size (I just open it), however >I could just attempt a seek to the "extra byte" and if it fails, >assume HDOS and use the volume id from block 9 (IIRC), otherwise >use the volume ID in the "extra byte" (essentually a feature to >allow for non-HDOS disks?) Hi Dave That is right. This would be for non-HDOS disk. So far I only know of the CP/M disk and my Forth disk. My Forth disks all use volume 0 and I believe that all of the CP/M are volume 0 as well but I thought it would be good if we deal with this early on to avoid future issues. Backwards compatibility is always a good idea. I don't want to break old code if not needed. Dwight > >Sounds reasonable. > >Regards, >Dave >-- >dave04a (at) Dave Dunfield >dunfield (dot) Firmware development services & tools: www.dunfield.com >com Vintage computing equipment collector. > http://www.parse.com/~ddunfield/museum/index.html > > -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 20:13:54 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 21:13:54 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020113.VAA03342@ss10.danlan.com> "Dwight K. Elvey" wrote: | I just meant that CP/M has a nice table that one can replace. I don't think it's nice at all. It was yet another piece of meta data that you needed to correctly read a foreign disk. Combined with vendors' tendencies to use other than DRI's recommended allocation parameters it made interchange of anything other than SS/SD 8" disks a nightmare. Which reminds me... Somewhere on one of the disks I just finished imaging is a program I wrote to dynamically patch the BIOS in memory with parameters for various foreign disks (as stored in little parameter files). This was primarily for soft-sectored disks, of course. |I'm |not sure if I've ever seen anything like that in HDOS, although |it might be there. Happily it is not. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From jwt at OnJapan.net Wed Sep 1 20:10:02 2004 From: jwt at OnJapan.net (Jim Tittsler) Date: Thu, 2 Sep 2004 10:10:02 +0900 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409020055.i820ttIa013390@ms-smtp-04-eri0.ohiordc.rr.com> References: <20040902003835.RYCS13092.berlinr.sprint.ca@smtp.sprint.ca> <200409020055.i820ttIa013390@ms-smtp-04-eri0.ohiordc.rr.com> Message-ID: <20040902011002.GB3513@server.onjapan.net> On Wed, Sep 01, 2004 at 08:55:58PM -0400, Barry Watzman wrote: > I'm absolutely certain that there was a Lifeboat version org'd with a higher > TPA and ROM at zero. It was, in that regard, the same version of CP/M used > on the original Radio Shack TRS-80, which also had ROM (Microsoft ROM Basic) > at zero, and I worked for months with Larry Alcoff (of Lifeboat) to write > that non-standard version for the H-8 and H-89 (with, at that time, only the > H-17 disk system). What I'm not sure of with certainty is where the RAM > base and TPA began, I think it was 4200 hex but my recollection is fuzzy on > that. Yes, I mentioned it here a couple of months back. It was indeed 4200h. What I can't remember for sure is if it would work with the H8-5. I'm pretty sure it did... but I think you'd have to try it to find out. -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 20:30:54 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 21:30:54 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040902011002.GB3513@server.onjapan.net> Message-ID: <200409020130.i821UoIa012512@ms-smtp-04-eri0.ohiordc.rr.com> Unreal. Steve Parker, Jim Tittsler, Barry Watzman. It's like old times. Now if we can find Gregg Chandler, Bill Zurney, Mike Hakeem, Ron Kasik, Babu. Oh, wait, this is the 8-bit group. Better get "what's a Z-80" Neil Beneditz and Tom Yeager; and I think that Jack Crenshaw is floating around somewhere as well. Who'd I leave out? -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Jim Tittsler Sent: Wednesday, September 01, 2004 9:10 PM To: sebhc at sebhc.org Subject: Re: [sebhc] h17 and h8d disk images On Wed, Sep 01, 2004 at 08:55:58PM -0400, Barry Watzman wrote: > I'm absolutely certain that there was a Lifeboat version org'd with a higher > TPA and ROM at zero. It was, in that regard, the same version of CP/M used > on the original Radio Shack TRS-80, which also had ROM (Microsoft ROM Basic) > at zero, and I worked for months with Larry Alcoff (of Lifeboat) to write > that non-standard version for the H-8 and H-89 (with, at that time, only the > H-17 disk system). What I'm not sure of with certainty is where the RAM > base and TPA began, I think it was 4200 hex but my recollection is fuzzy on > that. Yes, I mentioned it here a couple of months back. It was indeed 4200h. What I can't remember for sure is if it would work with the H8-5. I'm pretty sure it did... but I think you'd have to try it to find out. -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 20:27:36 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 21:27:36 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020127.VAA03670@ss10.danlan.com> "Barry Watzman" wrote: |Personally, if I was writing an image program, I'd record each track's |sectors in the order in which they physically occurred on the track AND I'd |also record, in each sector's data contents, the track and sector number |recorded in that sector's header. That's easier said than done. Unless you are lucky enough to get an entire track to read correctly each time you have to do some fancy matching to keep the physical information. And it just isn't necessary in this application since there were neither copy protected disks nor interleave schemes in general use. |Only by recording BOTH of these -- they physical layout AND the logical |layout (the numbers in the header) would it be possible to physically |reproduce a physically correct image of the diskette. If you *do* have to worry about non-standard formats used in copy protection schemes then merely recording that information is far from sufficient to reproduce the disk. Using funny sector/track numbers and positions got old within months of its introduction. To be able to make an accurate copy you need to record both the data and the *clock* bits in the FM or MFM stream along with the timing relationship to the index hole. This is because people learned to embed headers within data areas and play games with non-standard address marks. Even with the data and clock bits recorded you might not be able to make a reliable copy if you don't know how to recompute the correct precomp shifts. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Wed Sep 1 20:30:39 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Wed, 1 Sep 2004 21:30:39 -0400 (EDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020130.VAA03679@ss10.danlan.com> Dave Dunfield wrote: |Does anyone know if CP/M just switches to RAM once, or does |it toggle between ROM and RAM (say to access ROM functions)? The operating system proper just switches to RAM; however, various CP/M applications sold by Heath were buggered to work only on Heath hardware. They did this by switching the ROM back in and checking for some known bytes. I have a vague memory that something that came with the OS did this as well. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 20:44:11 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 21:44:11 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409020130.VAA03679@ss10.danlan.com> Message-ID: <200409020144.i821i7Ia023541@ms-smtp-04-eri0.ohiordc.rr.com> I may be having a "bad memory day" -- it's been 20 years, after all --, but that's not my recollection. The Microsoft stuff for HDOS, of course, only worked under HDOS. For CP/M there was a "vendor" byte in the CP/M serial number that an applications program could check, and all of the Microsoft software for CP/M (sold by Heath) did check that and wouldn't run unless it had one of {I think} 3 values, the values assigned to Lifeboat (which sold CP/M for Heath systems, for a while), Heathkit and Zenith Data Systems. But I don't believe that we played any games with the memory mapping in any of the software that I was responsible for (which was all of the systems software under CP/M for the H-8 and H-89). -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dan Lanciani Sent: Wednesday, September 01, 2004 9:31 PM To: sebhc at sebhc.org Subject: Re: [sebhc] h17 and h8d disk images Dave Dunfield wrote: |Does anyone know if CP/M just switches to RAM once, or does |it toggle between ROM and RAM (say to access ROM functions)? The operating system proper just switches to RAM; however, various CP/M applications sold by Heath were buggered to work only on Heath hardware. They did this by switching the ROM back in and checking for some known bytes. I have a vague memory that something that came with the OS did this as well. Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 20:42:54 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 18:42:54 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020142.SAA17191@clulw009.amd.com> Hi H17 puts RAM variables just above 2000H. The boot code loads the boot sector at 2280H. I would think that a Heath compatable CP/M would just have to keep above 2300H. ( 430000 Heath split octal ) Dwight >From: "Barry Watzman" > >I think that the RAM base was much higher even than 2000H, but yes, such a >version of CP/M did exist. Getting a copy will be very, very hard, because >it fell into extreme disfavor after the version came out that supported a >"normal" CP/M memory configuration. > >[In case anyone is wondering, I have almost no H8/H89 software at all, I >don't even have a copy of the software that I myself wrote.] > > > >-----Original Message----- >From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield >Sent: Wednesday, September 01, 2004 8:39 PM >To: sebhc at sebhc.org >Subject: RE: [sebhc] h17 and h8d disk images > >At 18:53 01/09/2004 -0400, you wrote: >>I agree -- save the version with the header, and use the conversion utility >>to convert to the version without the header, if necessary. >> >>There were two versions of CP/M used on the H8. The "Lifeboat" version was >>"org'd" at 4200H, I think (my recollection is fuzzy), but the real Heath >>version was standard "org 0" and required RAM at zero. > >So is there a version of CP/M which will boot on a system with the H17 >controller, the standard H5 I/O card, and RAM from $2000 to top of memory >(IE: the configuration of my emulator) - if so, where can I get an image >of it, because I would love to try it out. > >Regards, >Dave >-- >dave04a (at) Dave Dunfield >dunfield (dot) Firmware development services & tools: www.dunfield.com >com Vintage computing equipment collector. > http://www.parse.com/~ddunfield/museum/index.html > > >-- >Delivered by the SEBHC Mailing List > > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 20:54:42 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 21:54:42 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409020142.SAA17191@clulw009.amd.com> Message-ID: <200409020154.i821scnb009983@ms-smtp-02-eri0.ohiordc.rr.com> 4200 Hex wasn't chosen for any of those reasons. It was chosen because it was already in use on the TRS-80, which had 16k of ROM at zero for Microsoft Basic (in ROM). It was bad enough that there had to be a "non-standard" CP/M system, but Heath [meaning, at the time, me] and Lifeboat were not going to have multiple non-standard CP/M's it was tough enough to get Microsoft, Micropro, Digital Research, Sorcim, etc. to create one non-standard object code version of everything let alone two (or more) for different vendors. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dwight K. Elvey Sent: Wednesday, September 01, 2004 9:43 PM To: sebhc at sebhc.org Subject: RE: [sebhc] h17 and h8d disk images Hi H17 puts RAM variables just above 2000H. The boot code loads the boot sector at 2280H. I would think that a Heath compatable CP/M would just have to keep above 2300H. ( 430000 Heath split octal ) Dwight >From: "Barry Watzman" > >I think that the RAM base was much higher even than 2000H, but yes, such a >version of CP/M did exist. Getting a copy will be very, very hard, because >it fell into extreme disfavor after the version came out that supported a >"normal" CP/M memory configuration. > >[In case anyone is wondering, I have almost no H8/H89 software at all, I >don't even have a copy of the software that I myself wrote.] > > > >-----Original Message----- >From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield >Sent: Wednesday, September 01, 2004 8:39 PM >To: sebhc at sebhc.org >Subject: RE: [sebhc] h17 and h8d disk images > >At 18:53 01/09/2004 -0400, you wrote: >>I agree -- save the version with the header, and use the conversion utility >>to convert to the version without the header, if necessary. >> >>There were two versions of CP/M used on the H8. The "Lifeboat" version was >>"org'd" at 4200H, I think (my recollection is fuzzy), but the real Heath >>version was standard "org 0" and required RAM at zero. > >So is there a version of CP/M which will boot on a system with the H17 >controller, the standard H5 I/O card, and RAM from $2000 to top of memory >(IE: the configuration of my emulator) - if so, where can I get an image >of it, because I would love to try it out. > >Regards, >Dave >-- >dave04a (at) Dave Dunfield >dunfield (dot) Firmware development services & tools: www.dunfield.com >com Vintage computing equipment collector. > http://www.parse.com/~ddunfield/museum/index.html > > >-- >Delivered by the SEBHC Mailing List > > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Wed Sep 1 21:01:03 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Wed, 1 Sep 2004 21:01:03 -0500 Subject: [sebhc] h17 and h8d disk images References: <200409020127.VAA03670@ss10.danlan.com> Message-ID: <026901c49090$b3c26b50$6501010a@BUSTER> "Dan Lanciani" wrote: > "Barry Watzman" wrote: > > > |Only by recording BOTH of these -- they physical layout AND the logical > |layout (the numbers in the header) would it be possible to physically > |reproduce a physically correct image of the diskette. > > If you *do* have to worry about non-standard formats used in copy > protection > schemes then merely recording that information is far from sufficient to > reproduce the disk. Using funny sector/track numbers and positions got > old > within months of its introduction. To be able to make an accurate copy > you > need to record both the data and the *clock* bits in the FM or MFM stream > along > with the timing relationship to the index hole. This is because people > learned > to embed headers within data areas and play games with non-standard > address > marks. Even with the data and clock bits recorded you might not be able > to > make a reliable copy if you don't know how to recompute the correct > precomp > shifts. > Did anyone exactly make copy-protected software for the H89 in either HDOS or CP/M? I had quite a bit of software for the H89, but don't remember one title that used copy-protection. (I do remember Apple II games having it and alot of IBM PC software had it.) Mark -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 21:17:14 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 19:17:14 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020217.TAA17203@clulw009.amd.com> >From: "Barry Watzman" > ---snip--- > >Personally, if I was writing an image program, I'd record each track's >sectors in the order in which they physically occurred on the track AND I'd >also record, in each sector's data contents, the track and sector number >recorded in that sector's header. ---snip--- Hi Although, it is possible to acquire this information through the current H17 disk controller, my primary purpose was to move standard disk from machine to machine when I wrote the image transfer program. I realize that there could be all kinds of protection methods used. Trying to predict them all was not my intent. There are some that without knowing how it was done might not be reliably read with a one size-fits-all type program. If I was doing it over, I suspect that I might today have it a little more robust. Dwight -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 21:11:54 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 22:11:54 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <026901c49090$b3c26b50$6501010a@BUSTER> Message-ID: <200409020211.i822BpIa015693@ms-smtp-04-eri0.ohiordc.rr.com> I don't think so, but all I can say is I'm not aware of it. ********** Did anyone exactly make copy-protected software for the H89 in either HDOS or CP/M? I had quite a bit of software for the H89, but don't remember one title that used copy-protection. (I do remember Apple II games having it and alot of IBM PC software had it.) Mark -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed Sep 1 21:20:54 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 1 Sep 2004 19:20:54 -0700 (PDT) Subject: [sebhc] h17 and h8d disk images Message-ID: <200409020220.TAA17209@clulw009.amd.com> >From: "Dan Lanciani" > >"Dwight K. Elvey" wrote: > >| I just meant that CP/M has a nice table that one can replace. > >I don't think it's nice at all. It was yet another piece of meta data >that you needed to correctly read a foreign disk. Combined with vendors' >tendencies to use other than DRI's recommended allocation parameters it >made interchange of anything other than SS/SD 8" disks a nightmare. Which >reminds me... Somewhere on one of the disks I just finished imaging is a >program I wrote to dynamically patch the BIOS in memory with parameters >for various foreign disks (as stored in little parameter files). This >was primarily for soft-sectored disks, of course. > >|I'm >|not sure if I've ever seen anything like that in HDOS, although >|it might be there. > >Happily it is not. Hi Dan I see your point from this perspective as well. I think that CP/M chose this route because at the time some disk controllers were not able to generate interleaved disk. In order to improve perfomance, they chose to deal with it this way. ( I have just such a controller on my IMSAI ). Dwight > > Dan Lanciani > ddl at danlan.*com >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 21:29:21 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 22:29:21 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040902022919.ULVP13092.berlinr.sprint.ca@smtp.sprint.ca> At 19:17 01/09/2004 -0700, you wrote: >>From: "Barry Watzman" >> >---snip--- >> >>Personally, if I was writing an image program, I'd record each track's >>sectors in the order in which they physically occurred on the track AND I'd >>also record, in each sector's data contents, the track and sector number >>recorded in that sector's header. > >---snip--- > >Hi > Although, it is possible to acquire this information through >the current H17 disk controller, my primary purpose was >to move standard disk from machine to machine when I wrote >the image transfer program. I realize that there could be >all kinds of protection methods used. Trying to predict >them all was not my intent. There are some that without >knowing how it was done might not be reliably read with >a one size-fits-all type program. > If I was doing it over, I suspect that I might today have >it a little more robust. >Dwight >From my point of view, the MOST important thing is that we preserve the content of the disks - I'm not quite so concerned about interleave and such, for two reasons: 1) Applicable to non-copy protected disks only (which appears to be the vast majority) - The data is the part that cannot be easily replaced - We can move things around, make our own disks, experiement with interleave etc. and make disks from the images in pretty much any way we like, however we HAVE TO HAVE the original data to do so. 2) I don't even HAVE a disk controller for my H8 (I'd REALLY like to find one if anyone happens to stumble on it) - As noted in a previous message, the emulator really doesn't care. Even with the simple H8D format - just having that (and knowing that it boots/runs fine on the emulator) provides me with the assurance I need that this software will not be lost. A slightly more complex format which includes the header information (basically, record the positions of the sector pulses and ALL data which occurs between them) would be a little more complete, and is probably not a bad idea (I confess to not having looked in detail at the .H17 format to see exactly what it records). But as long as we have enough information to boot/run the software, I am happy. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 21:29:29 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 22:29:29 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409020220.TAA17209@clulw009.amd.com> Message-ID: <200409020229.i822TPVe019983@ms-smtp-03-eri0.ohiordc.rr.com> Which IMSAI disk system? The old dual Calcomp, with the IFM/FIB, or the later one with the DIO/PDS? -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dwight K. Elvey Sent: Wednesday, September 01, 2004 10:21 PM To: sebhc at sebhc.org Subject: Re: [sebhc] h17 and h8d disk images >From: "Dan Lanciani" > >"Dwight K. Elvey" wrote: > >| I just meant that CP/M has a nice table that one can replace. > >I don't think it's nice at all. It was yet another piece of meta data >that you needed to correctly read a foreign disk. Combined with vendors' >tendencies to use other than DRI's recommended allocation parameters it >made interchange of anything other than SS/SD 8" disks a nightmare. Which >reminds me... Somewhere on one of the disks I just finished imaging is a >program I wrote to dynamically patch the BIOS in memory with parameters >for various foreign disks (as stored in little parameter files). This >was primarily for soft-sectored disks, of course. > >|I'm >|not sure if I've ever seen anything like that in HDOS, although >|it might be there. > >Happily it is not. Hi Dan I see your point from this perspective as well. I think that CP/M chose this route because at the time some disk controllers were not able to generate interleaved disk. In order to improve perfomance, they chose to deal with it this way. ( I have just such a controller on my IMSAI ). Dwight > > Dan Lanciani > ddl at danlan.*com >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed Sep 1 21:35:22 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 1 Sep 2004 22:35:22 -0400 Subject: [sebhc] h17 and h8d disk images Message-ID: <20040902023521.UOWD13092.berlinr.sprint.ca@smtp.sprint.ca> > I see your point from this perspective as well. I think that >CP/M chose this route because at the time some disk controllers >were not able to generate interleaved disk. In order to improve >perfomance, they chose to deal with it this way. ( I have just >such a controller on my IMSAI ). >Dwight Thats exactly it - any soft sectored system, and any hard sectored system which records the sector number in a "soft" header (like the H17) can do "physical interleaving" - which I far prefer above "logical interleaving" because it avoids an extra translation level. Although it would be technically possible to enforce sequential sector numbering in a soft system, I have never seen it done - the controller just waits until the right header comes along (otherwise soft read errors on headers before the one you wanted would cause a retry). Unfortunately, systems like the NorthStar SD one I described in an earlier message which physicallt tie the sector numbering to the physical sector index holes cannot do this, and would require a translation if you wanted to be able to do interleave. Given a controller like the H17 which is capable of "physical" interleave, I would prefer to do it that way, and leave the CP/M sector translation table at 1:1 - this makes more sense to me, and moves the entire interleave issue into strictly a formatting concern (where it should be) - once formatted, no special action has to be taken, no matter what the interleave factor of the diskette is. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Wed Sep 1 21:39:40 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Wed, 1 Sep 2004 22:39:40 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <20040902022919.ULVP13092.berlinr.sprint.ca@smtp.sprint.ca> Message-ID: <200409020239.i822daJX023994@ms-smtp-01-eri0.ohiordc.rr.com> You know, the H-8 disk controller was really simple. It would not be that hard to wire-wrap one. The schematics are in the manual, which we have. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield Sent: Wednesday, September 01, 2004 10:29 PM To: sebhc at sebhc.org Subject: RE: [sebhc] h17 and h8d disk images At 19:17 01/09/2004 -0700, you wrote: >>From: "Barry Watzman" >> >---snip--- >> >>Personally, if I was writing an image program, I'd record each track's >>sectors in the order in which they physically occurred on the track AND I'd >>also record, in each sector's data contents, the track and sector number >>recorded in that sector's header. > >---snip--- > >Hi > Although, it is possible to acquire this information through >the current H17 disk controller, my primary purpose was >to move standard disk from machine to machine when I wrote >the image transfer program. I realize that there could be >all kinds of protection methods used. Trying to predict >them all was not my intent. There are some that without >knowing how it was done might not be reliably read with >a one size-fits-all type program. > If I was doing it over, I suspect that I might today have >it a little more robust. >Dwight >From my point of view, the MOST important thing is that we preserve the content of the disks - I'm not quite so concerned about interleave and such, for two reasons: 1) Applicable to non-copy protected disks only (which appears to be the vast majority) - The data is the part that cannot be easily replaced - We can move things around, make our own disks, experiement with interleave etc. and make disks from the images in pretty much any way we like, however we HAVE TO HAVE the original data to do so. 2) I don't even HAVE a disk controller for my H8 (I'd REALLY like to find one if anyone happens to stumble on it) - As noted in a previous message, the emulator really doesn't care. Even with the simple H8D format - just having that (and knowing that it boots/runs fine on the emulator) provides me with the assurance I need that this software will not be lost. A slightly more complex format which includes the header information (basically, record the positions of the sector pulses and ALL data which occurs between them) would be a little more complete, and is probably not a bad idea (I confess to not having looked in detail at the .H17 format to see exactly what it records). But as long as we have enough information to boot/run the software, I am happy. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed Sep 1 22:58:32 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 1 Sep 2004 22:58:32 -0500 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409012253.i81Mr8Ia013262@ms-smtp-04-eri0.ohiordc.rr.com> Message-ID: <000101c490a1$1d750840$1f6fa8c0@eths.k12.il.us> > > Does this list server have a "digest" mode? > we never needed it until tonight ;>) Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Thu Sep 2 04:27:08 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 02 Sep 2004 09:27:08 +0000 Subject: [sebhc] h17 and h8d disk images Message-ID: >I think that the RAM base was much higher even than 2000H, but yes, such a >version of CP/M did exist. Getting a copy will be very, very hard, ... I think I have one .. somewhere ... still haven't found all my stuff. I did find a few more of my diskettes today tho .. and I just posted these: 885-1066_Disk_X_Misc.h8d 885-1031X_Music_8.h8d I tacked on an "X" to the product number of the latter as I believe it was originally issued on 2 bootable disks but this is a single non-bootable one. The comments also say "enhanced by AIWZ" (that's me) but I don't remember exactly what I did to it besides combining the disks. This is the "H8 speaker music" stuff that requires you to lift a leg of one of the front panel chips (unless you want the music modulated by a 1khz tone :-) ). Cheers, - Steven _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu Sep 2 07:22:06 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 2 Sep 2004 07:22:06 -0500 Subject: music mods? - was RE: [sebhc] h17 and h8d disk images In-Reply-To: Message-ID: <000001c490e7$766ebb30$1f6fa8c0@eths.k12.il.us> > This is the "H8 speaker music" stuff that requires you to > lift a leg of one > of the front panel chips (unless you want the music modulated > by a 1khz tone > :-) ). > Aha! Was this mod also done for the NDOS sound boards? I've got a couple systems with a slide switch that cuts out the normal "horn" - thought it was just to stop the machine from making noise during those late night coding sessions! Jack -- Delivered by the SEBHC Mailing List From me at patswayne.com Thu Sep 2 08:24:28 2004 From: me at patswayne.com (Pat Swayne) Date: Thu, 02 Sep 2004 09:24:28 -0400 Subject: [sebhc] h17 and h8d disk images In-Reply-To: <200409020130.i821UoIa012512@ms-smtp-04-eri0.ohiordc.rr.com > References: <20040902011002.GB3513@server.onjapan.net> <200409020130.i821UoIa012512@ms-smtp-04-eri0.ohiordc.rr.com> Message-ID: <6.1.2.0.2.20040902092404.032e4890@mail.patswayne.com> Barry wrote: >Unreal. Steve Parker, Jim Tittsler, Barry Watzman. Sometimes, even Pat Swayne! -- Pat -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Thu Sep 2 16:47:13 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 02 Sep 2004 21:47:13 +0000 Subject: [sebhc] music-8 Message-ID: Jack says: >Was this mod also done for the NDOS sound boards? If you mean NOGDS, no, those were 2-channel D/A convertor units, and totally unrelated to the panel speaker music. They were capable of much higher quality sounds, but required entirely different software. Speaking of which, I recently stuck my breadbord (which still has the original 2-channel D/A prototype set up on it) in my scanner and will post the pictures soon. >I've got a couple >systems with a slide switch that cuts out the normal "horn" - I'd bet if you check, those switches don't turn off the speaker, but disconnect the 1khz signal from the speaker gate and allow the gate control signal to drive the speaker directly. This was a common mod among music-8 users. I also have some software somewhere that makes the H8 "talk" using this mod via 1-bit PCM encoded speech sounds. Cheers, - Steven _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu Sep 2 16:59:43 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 2 Sep 2004 16:59:43 -0500 Subject: [sebhc] music-8 In-Reply-To: Message-ID: <000301c49138$27c82240$1f6fa8c0@eths.k12.il.us> thanks! > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Steven Parker > Sent: Thursday, September 02, 2004 4:47 PM > To: sebhc at sebhc.org > Subject: [sebhc] music-8 > > > Jack says: > >Was this mod also done for the NDOS sound boards? > > If you mean NOGDS, no, those were 2-channel D/A convertor > units, and totally > unrelated to the panel speaker music. They were capable of > much higher > quality sounds, but required entirely different software. > > Speaking of which, I recently stuck my breadbord (which still has the > original 2-channel D/A prototype set up on it) in my scanner > and will post > the pictures soon. > > >I've got a couple > >systems with a slide switch that cuts out the normal "horn" - > > I'd bet if you check, those switches don't turn off the speaker, but > disconnect the 1khz signal from the speaker gate and allow > the gate control > signal to drive the speaker directly. This was a common mod > among music-8 > users. I also have some software somewhere that makes the > H8 "talk" using > this mod via 1-bit PCM encoded speech sounds. > > Cheers, > > - Steven > > _________________________________________________________________ > Check out Election 2004 for up-to-date election news, plus > voter tools and > more! http://special.msn.com/msn/election2004.armx > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Thu Sep 2 18:11:31 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Thu, 2 Sep 2004 18:11:31 -0500 Subject: [sebhc] h17 and h8d disk images References: <200409020211.i822BpIa015693@ms-smtp-04-eri0.ohiordc.rr.com> Message-ID: <035c01c49142$3131c1b0$6501010a@BUSTER> I'm thinking that if there is any software that is copy-protected, it would be easier to just patch the program to remove it than support any of the sector stuff. Mark ----- Original Message ----- From: "Barry Watzman" To: Sent: Wednesday, September 01, 2004 9:11 PM Subject: RE: [sebhc] h17 and h8d disk images >I don't think so, but all I can say is I'm not aware of it. > > ********** > > Did anyone exactly make copy-protected software for the H89 in either HDOS > or > CP/M? I had quite a bit of software for the H89, but don't remember one > title > that used copy-protection. (I do remember Apple II games having it and > alot > of IBM PC software had it.) > > Mark > > -- > Delivered by the SEBHC Mailing List > > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Thu Sep 2 19:46:51 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Thu, 2 Sep 2004 19:46:51 -0500 Subject: [sebhc] HDOS Issue #50.05.00 References: <200409011840.LAA16961@clulw009.amd.com> Message-ID: <03bf01c4914f$80754730$6501010a@BUSTER> Hi Dwight, How close are you to creating a sector hole punch? At the current price that the group of offered, I thought having some type of punch would be a lot cheaper. I would love to have more hard-sectored disks, even if it meant punching through the sleeve. Mark ----- Original Message ----- From: "Dwight K. Elvey" To: Sent: Wednesday, September 01, 2004 1:40 PM Subject: Re: [sebhc] HDOS Issue #50.05.00 > > It is good to get a nice cross compare. I believe the originals were > all converted from the h17 format. I see that you renamed them already. > You are really fast ;) > For others, I should note that there appear to be 11 new images > so for those trying to keep things up to date, one should download > what is new( thanks Dan and Steve ). I just have to finish making > my sector hole punch. Then I can have enough disks to use for > all of this great stuff. > Dwight > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu Sep 2 20:00:43 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 2 Sep 2004 20:00:43 -0500 Subject: [sebhc] Hard sector disks and alternatives In-Reply-To: <03bf01c4914f$80754730$6501010a@BUSTER> Message-ID: <000001c49151$70d62f40$1f6fa8c0@eths.k12.il.us> Even better (certainly from an archival viewpoint) would be the elusive IDE drive or a PC-based virtual disk. Meanwhile, I'm eagerly waiting for version 2.0 of Eric's SVD which will allow write as well as read access (the chip is in the mail). Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Mark Garlanger > Sent: Thursday, September 02, 2004 7:47 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] HDOS Issue #50.05.00 > > > Hi Dwight, > > How close are you to creating a sector hole punch? At the > current price > that the group of offered, I thought having some type of > punch would be a > lot cheaper. I would love to have more hard-sectored disks, > even if it meant > punching through the sleeve. > > Mark > > ----- Original Message ----- > From: "Dwight K. Elvey" > To: > Sent: Wednesday, September 01, 2004 1:40 PM > Subject: Re: [sebhc] HDOS Issue #50.05.00 > > > > > It is good to get a nice cross compare. I believe the > originals were > > all converted from the h17 format. I see that you renamed them > > already. You are really fast ;) For others, I should note > that there > > appear to be 11 new images so for those trying to keep things up to > > date, one should download what is new( thanks Dan and Steve > ). I just > > have to finish making my sector hole punch. Then I can have enough > > disks to use for all of this great stuff. > > Dwight > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu Sep 2 20:02:45 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 2 Sep 2004 18:02:45 -0700 (PDT) Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: <200409030102.SAA18071@clulw009.amd.com> Hi It is a day or so of work. I'm using a frame from an old SA400. I just have to mill the blocks to hold the punch shaft ( I think I selected a #93 drill for the punch shaft). These old frames were quite strong. The idea is that you put the disk into the drive and center the index hole with the punch. The pulley on the back has some detents drilled in it that a spring loaded ball bearing rides in ( or maybe a tapered setscrew ). Once aligned and clamped, one would rotate the pulley and stop at each detent. The location under the punch should be correct for each hole so one doesn't need to punch extra holes in the envelope. It is just a side project so hasn't got high priority. I have a long weekend coming up so I might actually work on it some. I have a request from Barry Watzman to copy some manuals and another fellow that is interested in some of my Poly 88 manuals( the 8813 uses hard sectored as well ). It won't be a production speed operation but I'm sure I'll be able to punch disk faster than I can find data to put on them ;) When I get it working, I'm sure that I'll loan it out to people. Maybe a hefty deposit will make sure that it returns. Dwight >From: "Mark Garlanger" > >Hi Dwight, > > How close are you to creating a sector hole punch? At the current price >that the group of offered, I thought having some type of punch would be a >lot cheaper. I would love to have more hard-sectored disks, even if it meant >punching through the sleeve. > > Mark > >----- Original Message ----- >From: "Dwight K. Elvey" >To: >Sent: Wednesday, September 01, 2004 1:40 PM >Subject: Re: [sebhc] HDOS Issue #50.05.00 > >> >> It is good to get a nice cross compare. I believe the originals were >> all converted from the h17 format. I see that you renamed them already. >> You are really fast ;) >> For others, I should note that there appear to be 11 new images >> so for those trying to keep things up to date, one should download >> what is new( thanks Dan and Steve ). I just have to finish making >> my sector hole punch. Then I can have enough disks to use for >> all of this great stuff. >> Dwight >> >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Thu Sep 2 20:37:21 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Thu, 2 Sep 2004 21:37:21 -0400 Subject: [sebhc] HDOS Issue #50.05.00 In-Reply-To: <03bf01c4914f$80754730$6501010a@BUSTER> Message-ID: <200409030137.i831bGVe017105@ms-smtp-03-eri0.ohiordc.rr.com> While you are at it, I want USB 8" and 5.25" drives. [Hey, don't laugh, I'm serious !!] -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Mark Garlanger Sent: Thursday, September 02, 2004 8:47 PM To: sebhc at sebhc.org Subject: Re: [sebhc] HDOS Issue #50.05.00 Hi Dwight, How close are you to creating a sector hole punch? At the current price that the group of offered, I thought having some type of punch would be a lot cheaper. I would love to have more hard-sectored disks, even if it meant punching through the sleeve. Mark ----- Original Message ----- From: "Dwight K. Elvey" To: Sent: Wednesday, September 01, 2004 1:40 PM Subject: Re: [sebhc] HDOS Issue #50.05.00 > > It is good to get a nice cross compare. I believe the originals were > all converted from the h17 format. I see that you renamed them already. > You are really fast ;) > For others, I should note that there appear to be 11 new images > so for those trying to keep things up to date, one should download > what is new( thanks Dan and Steve ). I just have to finish making > my sector hole punch. Then I can have enough disks to use for > all of this great stuff. > Dwight > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Thu Sep 2 20:41:47 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Thu, 2 Sep 2004 21:41:47 -0400 (EDT) Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: <200409030141.VAA05258@ss10.danlan.com> "Mark Garlanger" wrote: | How close are you to creating a sector hole punch? At the current price |that the group of offered, I thought having some type of punch would be a |lot cheaper. I would love to have more hard-sectored disks, even if it meant |punching through the sleeve. It might be easier to generate the extra pulses on the index line with a little hardware add-on. Then you could use readily available soft-sectored disks... Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu Sep 2 20:49:22 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 2 Sep 2004 18:49:22 -0700 (PDT) Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: <200409030149.SAA18108@clulw009.amd.com> Hi This has been talked about. From others experiments, it was determined that the belt drive 5-1/4 drives did not hold speed well enough. I think we are stuck with punching holes. Dwight >From: "Dan Lanciani" > >"Mark Garlanger" wrote: > >| How close are you to creating a sector hole punch? At the current price >|that the group of offered, I thought having some type of punch would be a >|lot cheaper. I would love to have more hard-sectored disks, even if it meant >|punching through the sleeve. > >It might be easier to generate the extra pulses on the index line with a >little hardware add-on. Then you could use readily available soft-sectored >disks... > > Dan Lanciani > ddl at danlan.*com >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Thu Sep 2 20:56:05 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Thu, 2 Sep 2004 21:56:05 -0400 (EDT) Subject: [sebhc] HDOS Issue #50.05.00 Message-ID: <200409030156.VAA05474@ss10.danlan.com> "Dwight K. Elvey" wrote: | This has been talked about. From others experiments, it was |determined that the belt drive 5-1/4 drives did not hold |speed well enough. Over what time scale? You can phase-lock to the single real index pulse, adjusting every revolution. Is variation really that bad over a single revolution? Dan Lanciani ddl at danlan.*com -- Delivered by the SEBHC Mailing List From melamy at earthlink.net Thu Sep 2 21:05:47 2004 From: melamy at earthlink.net (Steve Thatcher) Date: Thu, 02 Sep 2004 22:05:47 -0400 Subject: [sebhc] HDOS Issue #50.05.00 In-Reply-To: <200409030156.VAA05474@ss10.danlan.com> Message-ID: <5.1.0.14.2.20040902220348.00bbbc38@mail.earthlink.net> actually, the sector hole hardware was one person's work done a while back. I was proposing a circuit to do the very thing that has just been suggested again. I see no issue with speed variation being a problem. I just don't have time to pursue it at the moment. best regards, Steve Thatcher At 09:56 PM 09/02/2004 -0400, you wrote: >"Dwight K. Elvey" wrote: > >| This has been talked about. From others experiments, it was >|determined that the belt drive 5-1/4 drives did not hold >|speed well enough. > >Over what time scale? You can phase-lock to the single real index pulse, >adjusting every revolution. Is variation really that bad over a single >revolution? > > Dan Lanciani > ddl at danlan.*com >-- >Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Thu Sep 2 23:49:36 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Thu, 2 Sep 2004 23:49:36 -0500 Subject: [sebhc] HDOS Issue #50.05.00 References: <200409030141.VAA05258@ss10.danlan.com> Message-ID: <03f401c49171$699e98f0$6501010a@BUSTER> I would like to keep the hardware untouched - I just got my H89 (I had one back in the '80s) and it currently only has the 1 100K internal drive, but I should be getting a soft-sectored controller shortly ;-), so I'm just looking for some more media until that comes through. I currently have an H77 external case and an 3.5" 720K floppy drive awaiting the soft-sectored controller. Also an H87 with one H17-1 & one H17-4 drive should be on route, Since this should arrive much sooner than the soft-sectored controller, I'll be able to connect this to the hard-sectored controller (have the BIOS-80 software that supports the H17-4 at 400K). I also have a lead on two additional 96tpi drives, unfortunately this are full-height so I'll only be able to use one in the H77 with the soft-sectored controller. This should give me enough flexibility once everything gets delivered. If everything goes as planned: H17 controller - 2 x 100K, 1 x 400K H37 controller - 1 x 3.5" 720K, 1 x 5.25" 640K and one open 1/2 height bay. Mark ----- Original Message ----- From: "Dan Lanciani" To: Sent: Thursday, September 02, 2004 8:41 PM Subject: Re: [sebhc] HDOS Issue #50.05.00 > "Mark Garlanger" wrote: > > | How close are you to creating a sector hole punch? At the current price > |that the group of offered, I thought having some type of punch would be a > |lot cheaper. I would love to have more hard-sectored disks, even if it > meant > |punching through the sleeve. > > It might be easier to generate the extra pulses on the index line with a > little hardware add-on. Then you could use readily available > soft-sectored > disks... > > Dan Lanciani > ddl at danlan.*com > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri Sep 3 08:42:52 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 03 Sep 2004 09:42:52 -0400 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <000001c48088$c3750430$f300a8c0@berkeley.evocative.com> References: <000001c48088$c3750430$f300a8c0@berkeley.evocative.com> Message-ID: <413874DC.6050407@sc.rr.com> Patrick/VCM SysOp wrote: >Gents, > >After a long wait, a mixup with the vendor, and another long wait, the hard >and soft-sectored media (and a cache of jackets) has arrived. > >More to follow as I get everything unpacked... > >Patrick > >-- >Delivered by the SEBHC Mailing List > > > Haven't heard yet, but how many disks (hard sector) do you have and how much are they? I'm interested in about 50. Carroll -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Fri Sep 3 11:48:30 2004 From: patrick at vintagecomputermarketplace.com (Patrick) Date: Fri, 3 Sep 2004 09:48:30 -0700 Subject: [sebhc] At long last... Media has arrived! References: <000001c48088$c3750430$f300a8c0@berkeley.evocative.com> <413874DC.6050407@sc.rr.com> Message-ID: <003301c491d5$d82a9f30$f702a20c@berkeley.evocative.com> Carroll, I'm away on vacation, back in the office Tuesday and I'll be able to get that ball rolling. I have 1,000 hard and 500 soft. Patrick ----- Original Message ----- From: "Carroll Waddell" To: Sent: Friday, September 03, 2004 6:42 AM Subject: Re: [sebhc] At long last... Media has arrived! > Patrick/VCM SysOp wrote: > > >Gents, > > > >After a long wait, a mixup with the vendor, and another long wait, the hard > >and soft-sectored media (and a cache of jackets) has arrived. > > > >More to follow as I get everything unpacked... > > > >Patrick > > > >-- > >Delivered by the SEBHC Mailing List > > > > > > > Haven't heard yet, but how many disks (hard sector) do you have and how > much are they? I'm interested in about 50. > Carroll > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri Sep 3 18:02:46 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 3 Sep 2004 16:02:46 -0700 (PDT) Subject: [sebhc] Hard sector disks and alternatives Message-ID: <200409032302.QAA18911@clulw009.amd.com> >From: "Jack Rubin" > >Even better (certainly from an archival viewpoint) would be the elusive >IDE drive or a PC-based virtual disk. Meanwhile, I'm eagerly waiting for >version 2.0 of Eric's SVD which will allow write as well as read access >(the chip is in the mail). > >Jack > Hi I looked into the IDE hard drive a number of years ago. It wouldn't be hard to do at all. One needs to expand the 8 bit bus to 16 bits with some latches and buffers. As I recall, the commands were the same or similar to the standard MFM hard drive controllers, used on PC's, with a few extensions. I've written code for a MFM controller driver in the past so the code part wouldn't be hard. I don't know what the commands for the CD ROM drives are or how similar they are to the hard drives. I could easily make some code for a PC-based virtual disk through the serial( in DOS ). This is not too difficult. All I need is time to deal with all my projects. Dwight -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Fri Sep 3 15:35:11 2004 From: leeahart at earthlink.net (Lee Hart) Date: Fri, 03 Sep 2004 13:35:11 -0700 Subject: [sebhc] music-8 References: Message-ID: <4138D57F.51CF@earthlink.net> Steven Parker wrote: > If you mean NOGDS, no, those were 2-channel D/A convertor units, > and totally unrelated to the panel speaker music. This reminds me of the ARTRA "Housemaster" boards. They were cards for the H8 and H89 that added sound and music synthesis, voice recognition, real-time clock, and X-10 home control. I have one for my H89. Wow, was *that* ever impressive in 1980! -- "Never doubt that the work of a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has!" -- Margaret Mead -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat Sep 4 10:45:04 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 04 Sep 2004 11:45:04 -0400 Subject: [sebhc] CoStar Printer Message-ID: <4139E300.2040503@sc.rr.com> This might not be the right place to ask, but does anyone know anything about a CoStar Model SE250 label printer. It has a 6 conductor, RJ11 phone jack for the serial interface connection. I don't know which pins are which. The power on self test works and shows the baud rate set at 9600 with software flow control. I need to know how to connect a serial interface to the RJ11 jack. Carroll -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Sat Sep 4 11:31:47 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Sat, 4 Sep 2004 12:31:47 -0400 Subject: [sebhc] CoStar Printer In-Reply-To: <4139E300.2040503@sc.rr.com> Message-ID: <200409041631.i84GVfIa004447@ms-smtp-04-eri0.ohiordc.rr.com> This was offered by Dymo. Although I can't find any information on the SE250, the manual for the SE300 is available online: http://download.dymo.com/media/UserGuides/se300.pdf It appears to have the exact same interface, and it's fully documented in the above manual. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll Waddell Sent: Saturday, September 04, 2004 11:45 AM To: sebhc Subject: [sebhc] CoStar Printer This might not be the right place to ask, but does anyone know anything about a CoStar Model SE250 label printer. It has a 6 conductor, RJ11 phone jack for the serial interface connection. I don't know which pins are which. The power on self test works and shows the baud rate set at 9600 with software flow control. I need to know how to connect a serial interface to the RJ11 jack. Carroll -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat Sep 4 13:04:51 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 04 Sep 2004 14:04:51 -0400 Subject: [sebhc] CoStar Printer In-Reply-To: <200409041631.i84GVfIa004447@ms-smtp-04-eri0.ohiordc.rr.com> References: <200409041631.i84GVfIa004447@ms-smtp-04-eri0.ohiordc.rr.com> Message-ID: <413A03C3.1040604@sc.rr.com> Barry Watzman wrote: >This was offered by Dymo. Although I can't find any information on the >SE250, the manual for the SE300 is available online: > >http://download.dymo.com/media/UserGuides/se300.pdf > >It appears to have the exact same interface, and it's fully documented in >the above manual. > > >-----Original Message----- >From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll Waddell >Sent: Saturday, September 04, 2004 11:45 AM >To: sebhc >Subject: [sebhc] CoStar Printer > >This might not be the right place to ask, but does anyone know anything >about a CoStar Model SE250 label printer. >It has a 6 conductor, RJ11 phone jack for the serial interface >connection. I don't know which pins are which. The power on self test >works and shows the baud rate set at 9600 with software flow control. I >need to know how to connect a serial interface to the RJ11 jack. >Carroll >-- >Delivered by the SEBHC Mailing List > > >-- >Delivered by the SEBHC Mailing List > > > Thanks! That's what I was looking for. CEW -- Delivered by the SEBHC Mailing List From ddl-cctech at danlan.com Sun Sep 5 22:51:25 2004 From: ddl-cctech at danlan.com (Dan Lanciani) Date: Sun, 5 Sep 2004 23:51:25 -0400 (EDT) Subject: [sebhc] CP/M image disk names Message-ID: <200409060351.XAA09633@ss10.danlan.com> are approximately as follows: cpm{1,2}.h17 -> DISTRIBUTION DISK {I,II} DIGITAL RESEARCH INC. CP/M MODEL NO. HOS-817-2 cpm{a,b,c}.h17 -> DISK {1,2,3} MODEL NO. HOS-817-2 cpm22u{1,2,3}.h17 -> DISTRIBUTION DISK {I,II,III} DIGITAL RESEARCH INC. CP/M "R" 2.2 UPDATE-2 MODEL NO. HOS-817-2 cpm22us.h17 -> SETUP DISK DIGITAL RESEARCH INC. CP/M "R" 2.2 UPDATE-2 MODEL NO. HOS-817-2 -- Delivered by the SEBHC Mailing List From paulpenn at knology.net Tue Sep 7 06:59:13 2004 From: paulpenn at knology.net (Paul A. Pennington) Date: Tue, 7 Sep 2004 07:59:13 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 References: <005801c445bb$02183bc0$0700a8c0@walterp4> Message-ID: <00a901c494d2$17b7c8e0$6401a8c0@ibm6go1addn6c0> Walter Moore wrote: >I guess I'm missing that important document also! I'm also missing the > schematic for the ETA-3400, so I cannot guarantee what I'm about to tell > you > is 100% accurate. It would be nice to see if the wires in 3 & 4 are > correct. Walt (and anyone else interested); I recently picked up an ETA-3400 on eBay, and it came with the schematic and operation manual, 595-2271, copyright 1979. If you still need the schematic, let me know and I'll get one run off at Kinkos. Have you found a manual yet for the modifications to the ET-3400? I'm going to start a bibliography for all these manuals and put it on my web page. There seem to be a lot of versions -- you noted three. Paul Pennington Augusta, Georgia -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Tue Sep 7 08:49:29 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Tue, 7 Sep 2004 09:49:29 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 In-Reply-To: <00a901c494d2$17b7c8e0$6401a8c0@ibm6go1addn6c0> Message-ID: <200409071349.i87DnSJX005721@ms-smtp-01-eri0.ohiordc.rr.com> If you will get this documentation converted to a PDF file, I'll add it to the classic computer DVD that I'm offering and submit it to the Harte web site. If the material is "loose", I'll do the scanning and create the PDF file for you if you will loan me the originals (which I will return). I use a scanner with an automatic document feeder, so it's difficult to handle bound material, or material larger than 8.5" x 11" efficiently. I'm interested in other classic computer documentation that we don't have as well. I'll do the scanning if the material is loose (and, sometimes, even if it's not). I will return the originals, and if you supply something that I don't have, I'll give you a free copy of the DVD. Please contact me before sending me any material, or if you are not sure if I already have what you are considering to make available. The primary interest is in S-100 cards and systems, and their peripherals, but other items from the 1975 to 1983 era are also wanted. Barry Watzman Watzman at neo.rr.com -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Paul A. Pennington Sent: Tuesday, September 07, 2004 7:59 AM To: sebhc at sebhc.org Subject: Re: [sebhc] The 8-bit Runt of the Litter: ET-3400 Walter Moore wrote: >I guess I'm missing that important document also! I'm also missing the > schematic for the ETA-3400, so I cannot guarantee what I'm about to tell > you > is 100% accurate. It would be nice to see if the wires in 3 & 4 are > correct. Walt (and anyone else interested); I recently picked up an ETA-3400 on eBay, and it came with the schematic and operation manual, 595-2271, copyright 1979. If you still need the schematic, let me know and I'll get one run off at Kinkos. Have you found a manual yet for the modifications to the ET-3400? I'm going to start a bibliography for all these manuals and put it on my web page. There seem to be a lot of versions -- you noted three. Paul Pennington Augusta, Georgia -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Tue Sep 7 13:13:32 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 7 Sep 2004 11:13:32 -0700 (PDT) Subject: [sebhc] punching hard sectored disk Message-ID: <200409071813.LAA20715@clulw009.amd.com> Hi I worked on my disk punch this weekend. I was able to make a few disk. It works reasonably well but I'm not yet happy with my locating method. I'm using an old SA400 frame. These are nice heavy cast frames. I milled some blocks of aluminum to make the punch and used a #38 drill bit as the punch. I did this machine work on my tinky-lathe ( Shearline ). I used a 100 tooth gear to index the locations for the punch marks but somehow got the index location off a little. I manually offset this and it seems to work. I'll fix this before the final version. Right now, I have no mechanical detent for locating the hole positions but expect to make a detent using a ball bearing ball as soon as I locate a ball about 1/4" diameter. I currently use a pointer ( attached with hot glue ) and a magnifier to locate where to punch. I've made 9 disk that seem to work well but had 4 failures ( see note above about index location ). The disk I'm using are known to have a bunch of bad ones so the failures are not all caused by my punching. Most times the punch works well but just like Florida, I get the occational hanging chad. I just take a pair of needle nose and twist these off. It isn't the fasted punch system. You need to do each hole independently but does seem to work. It'll be faster once I get the detent working to locate the hole positions. Once done, if someone has a web page that can host pictures, I'll take some and send them. Dwight -- Delivered by the SEBHC Mailing List From eric at rothfus.com Tue Sep 7 14:32:15 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Tue, 7 Sep 2004 14:32:15 Subject: [sebhc] Disk Formats - where'd we end up? References: <200409060351.XAA09633@ss10.danlan.com> Message-ID: <1094580165@rothfus.com> I've been out, and missed the frenzy of disk format postings...which is one of my favorite subjects! Can someone tell me were we ended up? What is the "official" SEBHC format going to be? Eric -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Tue Sep 7 14:10:55 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 7 Sep 2004 12:10:55 -0700 (PDT) Subject: [sebhc] Disk Formats - where'd we end up? Message-ID: <200409071910.MAA20781@clulw009.amd.com> >From: "Eric J. Rothfus" > >I've been out, and missed the frenzy of disk format >postings...which is one of my favorite subjects! > >Can someone tell me were we ended up? What is the >"official" SEBHC format going to be? > >Eric > > Hi Eric I think for now, we are keeping both the H8D and the H17 ( SVD ). We have added that for the H8D, there can be one optional byte added. This would be to have the volume number for non-HDOS disk. We believe that this should be backwards compatable with most of the code so far but allows one to state the volume number when it is not part of the normal data. The additional byte would be the last byte of the file so that the H8D file would otherwise seem the same to a program that only transfered the first 100K. So far, all of the non-HDOS have been volume number zero but that could always change. I used the volume number zero this weekend for the CP/M stuff and it worked fine ( after I read my own instructions ). I forgot that one needs to run the disk boot with the drive empty to setup the drive parameters. I even noted in my readme that one needs to follow the steps exactly of it wouldn't work. I proved this to my self several times before I actually did a step by step. Dwight -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Tue Sep 7 14:44:39 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Tue, 7 Sep 2004 15:44:39 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 References: <005801c445bb$02183bc0$0700a8c0@walterp4> <00a901c494d2$17b7c8e0$6401a8c0@ibm6go1addn6c0> Message-ID: <003e01c49513$1e571fc0$02a8a8c0@IBMD9HY10WBGXB> Paul/Jack, I've just posted a scan of a more recent iteration of the ET-3400[A] modification kit documentation. It includes sections for both the original ET-3400 (Part 1 of the document) and the ET-3400A (Part 2 of the document). Also included (and just acquired 2 weeks ago) is the ellusive pictorial fold-out ...but only for Part 1 (the original ET-3400). I do not have the pictorial fold-out for Part 2 (ET-3400A). To determine which ET-3400 you have, simply look at the number of RAM chips installed. If you have 4, then you have the earlier ET-3400. Everthing you need is included in the document posted. If you have 2 RAM chips ...you have the newer ET-3400A (and you will need to find the missing pictorial fold-out somewhere else). As interesting ...if anyone can determine a suitable replacement for the GD510 diode required to modify the ET-3400, then I would sure like to hear about it. I can't find any info or cross-reference data on it. The modification for the newer ET-3400A doesn't require any parts (other than a ribbon cable, and a homemade foil RF shield). Enjoy ... Scott -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Tue Sep 7 15:46:26 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Tue, 7 Sep 2004 16:46:26 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 In-Reply-To: <003e01c49513$1e571fc0$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <200409072046.i87KkOJX015942@ms-smtp-01-eri0.ohiordc.rr.com> Re: " I've just posted a scan ...." Posted where? Unless the application is "exotic", most diodes with sufficient PIV and current ratings can replace other diodes (I'm assuming it's not a special diode, e.g. Zener, Varactor, etc.) -- Delivered by the SEBHC Mailing List From RONALD.S.WEST at saic.com Tue Sep 7 15:32:51 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Tue, 7 Sep 2004 16:32:51 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9EA4@mcl-its-exs03.mail.saic.com> Scott, This is what I found on the GD510 diode so far. Found on the following web site. http://www.d8apro.com/heath3.htm Heath P/N Generic P/N Alternate 1 Alternate 2 Description 56-89 GD510 25 PIV 100mA Germanium That might help. Ron -snip- > As interesting ...if anyone can determine a suitable > replacement for the GD510 diode required to modify the > ET-3400, then I would sure like to hear about it. I can't > find any info or cross-reference data on it. The modification > for the newer ET-3400A doesn't require any parts (other than > a ribbon cable, and a homemade foil RF shield). > -snip- -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Tue Sep 7 16:16:10 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Tue, 7 Sep 2004 16:16:10 -0500 Subject: [sebhc] punching hard sectored disk References: <200409071813.LAA20715@clulw009.amd.com> Message-ID: <002d01c4951f$e613ab30$6501010a@BUSTER> Hi Dwight, I have a ton of space available at http://heath.garlanger.com/ . Not much there yet, but planning to add more stuff. If anyone else has stuff that can be publically available, just let me know, and I can post it. Mark > Once done, if someone has a web page that can host pictures, > I'll take some and send them. > Dwight > -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Tue Sep 7 19:27:13 2004 From: leeahart at earthlink.net (Lee Hart) Date: Tue, 07 Sep 2004 17:27:13 -0700 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 References: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9EA4@mcl-its-exs03.mail.saic.com> Message-ID: <413E51E1.79A2@earthlink.net> >> As interesting ...if anyone can determine a suitable >> replacement for the GD510 diode required to modify the >> ET-3400, then I would sure like to hear about it. West, Ronald S. wrote: > Heath P/N Generic P/N Description > 56-89 GD510 25 PIV 100mA Germanium This can be replaced by a 1N270 (80piv, 200ma), which is pretty common. Jameco has them for $0.75. -- "Never doubt that the work of a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has!" -- Margaret Mead -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Tue Sep 7 17:03:12 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Tue, 7 Sep 2004 18:03:12 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 References: <200409072046.i87KkOJX015942@ms-smtp-01-eri0.ohiordc.rr.com> Message-ID: <005a01c49526$780780b0$02a8a8c0@IBMD9HY10WBGXB> Hi Barry, > Posted where? To the sebhc ftp archive. > Unless the application is "exotic", most diodes with sufficient PIV and > current ratings can replace other diodes (I'm assuming it's not a special > diode, e.g. Zener, Varactor, etc.) How about a germanium diode (which is what the GD510 is)? Thx .. Scott -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue Sep 7 18:13:31 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 7 Sep 2004 18:13:31 -0500 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 - Manual posted In-Reply-To: <003e01c49513$1e571fc0$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <000201c49530$4afb79a0$1f6fa8c0@eths.k12.il.us> Thanks Scott - It's in the documents/hardware/ET340x directory as ET3400-Mod-597-1954-02.pdf Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Scott LaBombard > Sent: Tuesday, September 07, 2004 2:45 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] The 8-bit Runt of the Litter: ET-3400 > > > Paul/Jack, > > I've just posted a scan of a more recent iteration of the > ET-3400[A] modification kit documentation. It includes > sections for both the original ET-3400 (Part 1 of the > document) and the ET-3400A (Part 2 of the document). Also > included (and just acquired 2 weeks ago) is the ellusive > pictorial fold-out ...but only for Part 1 (the original > ET-3400). I do not have the pictorial fold-out for Part 2 (ET-3400A). > > To determine which ET-3400 you have, simply look at the > number of RAM chips installed. If you have 4, then you have > the earlier ET-3400. Everthing you need is included in the > document posted. If you have 2 RAM chips ...you have the > newer ET-3400A (and you will need to find the missing > pictorial fold-out somewhere else). > > As interesting ...if anyone can determine a suitable > replacement for the GD510 diode required to modify the > ET-3400, then I would sure like to hear about it. I can't > find any info or cross-reference data on it. The modification > for the newer ET-3400A doesn't require any parts (other than > a ribbon cable, and a homemade foil RF shield). > > Enjoy ... > > > Scott > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Tue Sep 7 19:52:13 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Tue, 7 Sep 2004 20:52:13 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 In-Reply-To: <005a01c49526$780780b0$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <200409080052.i880qBVe020294@ms-smtp-03-eri0.ohiordc.rr.com> It may be important that you replace it with the same general type of diode, silicon with silicon, germanium with germanium. But that's not an issue, there are hundreds if not thousands of diodes of each type (why???). So, within that context, and PIV and current capacity, almost anything should work unless it's a very unusual and critical application. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Scott LaBombard Sent: Tuesday, September 07, 2004 6:03 PM To: sebhc at sebhc.org Subject: Re: [sebhc] The 8-bit Runt of the Litter: ET-3400 Hi Barry, > Posted where? To the sebhc ftp archive. > Unless the application is "exotic", most diodes with sufficient PIV and > current ratings can replace other diodes (I'm assuming it's not a special > diode, e.g. Zener, Varactor, etc.) How about a germanium diode (which is what the GD510 is)? Thx .. Scott -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Tue Sep 7 20:08:33 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 7 Sep 2004 18:08:33 -0700 (PDT) Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 Message-ID: <200409080108.SAA21055@clulw009.amd.com> >From: "Barry Watzman" > >It may be important that you replace it with the same general type of diode, >silicon with silicon, germanium with germanium. But that's not an issue, >there are hundreds if not thousands of diodes of each type (why???). So, Hi I'd often wondered why myself. A 1N4148 is spec by spec identical with a 1N914. I looked into this and found that the difference was in the process used to create the diode. Both have the same PIV, max current, reverse biased capacitance and what ever. I suspect that I'd been just as happy if they sold the newer part under the old number but maybe there is something like life expectancy or something that I missed. It does make it fun for the engineer that has to choose which one to put in the next circuit. Under a microscope, you'd see they were made differently. In a circuit, you'd never know. Dwight >within that context, and PIV and current capacity, almost anything should >work unless it's a very unusual and critical application. > ---snip--- -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Tue Sep 7 21:24:17 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Tue, 7 Sep 2004 22:24:17 -0400 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 In-Reply-To: <200409080108.SAA21055@clulw009.amd.com> Message-ID: <200409080224.i882OGJX017950@ms-smtp-01-eri0.ohiordc.rr.com> There are really subtle things like on-off switching times, reverse leakage current, that matter only in very rare, very critical applications. But for most applications, all that matters is type (Si or Ge), PIV and current, plus case style. Probably more than 95% of diode applications can be filled with less than 50 part numbers, when there are, I think, thousands and thousands of them. -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dwight K. Elvey Sent: Tuesday, September 07, 2004 9:09 PM To: sebhc at sebhc.org Subject: RE: [sebhc] The 8-bit Runt of the Litter: ET-3400 >From: "Barry Watzman" > >It may be important that you replace it with the same general type of diode, >silicon with silicon, germanium with germanium. But that's not an issue, >there are hundreds if not thousands of diodes of each type (why???). So, Hi I'd often wondered why myself. A 1N4148 is spec by spec identical with a 1N914. I looked into this and found that the difference was in the process used to create the diode. Both have the same PIV, max current, reverse biased capacitance and what ever. I suspect that I'd been just as happy if they sold the newer part under the old number but maybe there is something like life expectancy or something that I missed. It does make it fun for the engineer that has to choose which one to put in the next circuit. Under a microscope, you'd see they were made differently. In a circuit, you'd never know. Dwight >within that context, and PIV and current capacity, almost anything should >work unless it's a very unusual and critical application. > ---snip--- -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Wed Sep 8 02:40:58 2004 From: leeahart at earthlink.net (Lee Hart) Date: Wed, 08 Sep 2004 00:40:58 -0700 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 References: <200409080108.SAA21055@clulw009.amd.com> Message-ID: <413EB78A.4794@earthlink.net> Dwight K. Elvey wrote: > I'd often wondered why myself. A 1N4148 is spec by spec > identical with a 1N914. I looked into this and found that > the difference was in the process used to create the diode. The 1N914 was a gold-doped "very fast" switching diode. But optimizing switching speed makes its forward voltage drop vs. current higher; their forward voltage drop rises over 100mv per decade current increase. Time passed, and semiconductor technology improved. The 1N4148 was an improved, more expensive version of the 1N914, with more standard doping and thus less forward voltage drop. More time passed. As 1N4148 sales volume became higher, its price dropped. The 1N914 sales dropped, until its price was higher than the better 1N4148. At this point, manufacturers just dropped production of the "real" 1N914 and used the same 1N4148 die in both parts. So today, both parts are really the same. This behaviour has continued. Huge numbers of today's diodes and transistors are in fact all the same few chip; just marked, packaged, and sorted differently. Once in a while, you will run across a high-performance circuit that really *does* care what you use in it. But design engineers know that their Purchasing dept. will buy whatever is cheap from whatever manufacturer promises fast delivery. So, they don't design their circuit to depend on parts that truly meet their specs. -- "Never doubt that the work of a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has!" -- Margaret Mead -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu Sep 9 14:35:34 2004 From: patrick at vintagecomputermarketplace.com (Patrick/VCM SysOp) Date: Thu, 9 Sep 2004 12:35:34 -0700 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <000001c48088$c3750430$f300a8c0@berkeley.evocative.com> Message-ID: <002701c496a4$2cda3f40$f300a8c0@berkeley.evocative.com> Gentlemen, Thanks for your patience, I know it has been a long wait. Those of you who had previously requested media (hard or soft sector), and those of you who didn't but want some anyway, please reply to me privately/off-list with your final quantities ($1.85 each), and I'll give you a total with shipping (and tax if applicable--California residents). If you use PayPal (which I prefer), please remember to include your PayPal email address if you're not already replying to me from it. Oh, for sanity's sake, please keep your quantities to multiples of 10. Thanks! Thanks! Patrick > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Patrick/VCM SysOp > Sent: Thursday, August 12, 2004 9:24 AM > To: sebhc at sebhc.org > Subject: [sebhc] At long last... Media has arrived! > > > Gents, > > After a long wait, a mixup with the vendor, and another long > wait, the hard and soft-sectored media (and a cache of > jackets) has arrived. > > More to follow as I get everything unpacked... > > Patrick > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Thu Sep 9 15:21:15 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Thu, 9 Sep 2004 16:21:15 -0400 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <002701c496a4$2cda3f40$f300a8c0@berkeley.evocative.com> Message-ID: <200409092021.i89KLAnb010090@ms-smtp-02-eri0.ohiordc.rr.com> $1.85 per what? Per disk? -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu Sep 9 16:33:03 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 9 Sep 2004 14:33:03 -0700 (PDT) Subject: [sebhc] At long last... Media has arrived! Message-ID: <200409092133.OAA22845@clulw009.amd.com> >From: "Barry Watzman" > >$1.85 per what? Per disk? > Hi I'm sure that is what he means. With my punch, it is economical for me to do them for myself but I couldn't produce them at my time rate for $1.85. I'd been giving some thought to how to automate the process. One could connect the haft to a stepper motor ( just happen to have one from the drive Dwight -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu Sep 9 16:12:25 2004 From: patrick at vintagecomputermarketplace.com (Patrick/VCM SysOp) Date: Thu, 9 Sep 2004 14:12:25 -0700 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <200409092021.i89KLAnb010090@ms-smtp-02-eri0.ohiordc.rr.com> Message-ID: <003101c496b1$b49778a0$f300a8c0@berkeley.evocative.com> Correct. > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Barry Watzman > Sent: Thursday, September 09, 2004 1:21 PM > To: sebhc at sebhc.org > Subject: [sebhc] At long last... Media has arrived! > > > $1.85 per what? Per disk? > > > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Thu Sep 9 16:27:35 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Thu, 9 Sep 2004 17:27:35 -0400 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <003101c496b1$b49778a0$f300a8c0@berkeley.evocative.com> Message-ID: <200409092127.i89LRUVe000376@ms-smtp-03-eri0.ohiordc.rr.com> Well, I've got hundreds, maybe even a couple of thousand 5.25" disks, "brand new" (if very "Old" stock) left over from my "Perks" and "Addresselope" days, and I'd sell them for a LOT less than that. All soft-sector, 360k type, however. Now, as for the hard-sector ones, anyone know where I can get a hole-punch? :-) Barry Watzman Watzman at neo.rr.com -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Patrick/VCM SysOp Sent: Thursday, September 09, 2004 5:12 PM To: sebhc at sebhc.org Subject: RE: [sebhc] At long last... Media has arrived! Correct. > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Barry Watzman > Sent: Thursday, September 09, 2004 1:21 PM > To: sebhc at sebhc.org > Subject: [sebhc] At long last... Media has arrived! > > > $1.85 per what? Per disk? > > > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu Sep 9 16:52:40 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 9 Sep 2004 14:52:40 -0700 (PDT) Subject: [sebhc] At long last... Media has arrived! Message-ID: <200409092152.OAA22856@clulw009.amd.com> >From: "Dwight K. Elvey" > >>From: "Barry Watzman" >> >>$1.85 per what? Per disk? >> > >Hi > I'm sure that is what he means. With my punch, it >is economical for me to do them for myself but I >couldn't produce them at my time rate for $1.85. > I'd been giving some thought to how to automate >the process. One could connect the haft to a >stepper motor ( just happen to have one from the >drive Darn mail tool. Sent before I finished. Anyway. I have a stepper and I figure I could connect the punch to one of those power stapler to actuate the punch. Then, I could automate the process. Dwight >Dwight > -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu Sep 9 17:33:17 2004 From: patrick at vintagecomputermarketplace.com (Patrick/VCM SysOp) Date: Thu, 9 Sep 2004 15:33:17 -0700 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <200409092127.i89LRUVe000376@ms-smtp-03-eri0.ohiordc.rr.com> Message-ID: <000001c496bd$007290b0$f300a8c0@berkeley.evocative.com> Barry, Sure. You can also buy them by the box on eBay for $20 per 10 or less. Maybe they're OK, maybe not, but I agree it's worth the savings to at least try. My price was previously announced on this list. The media is new stock, not new old, and manufactured to order by a reputable supplier. If I could get them for less, I'd sell them for less. I'm not in this to make money, I'm just trying to help out. Patrick > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Barry Watzman > Sent: Thursday, September 09, 2004 2:28 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] At long last... Media has arrived! > > > Well, I've got hundreds, maybe even a couple of thousand > 5.25" disks, "brand new" (if very "Old" stock) left over from > my "Perks" and "Addresselope" days, and I'd sell them for a > LOT less than that. All soft-sector, 360k type, however. > > Now, as for the hard-sector ones, anyone know where I can get > a hole-punch? > > :-) > > Barry Watzman > Watzman at neo.rr.com > > > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Patrick/VCM SysOp > Sent: Thursday, September 09, 2004 5:12 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] At long last... Media has arrived! > > Correct. > > > -----Original Message----- > > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > > Barry Watzman > > Sent: Thursday, September 09, 2004 1:21 PM > > To: sebhc at sebhc.org > > Subject: [sebhc] At long last... Media has arrived! > > > > > > $1.85 per what? Per disk? > > > > > > > > > > -- > > Delivered by the SEBHC Mailing List > sebhc-request at sebhc.org. > > > > -- > Delivered by the SEBHC Mailing List > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From Watzman at neo.rr.com Thu Sep 9 18:04:32 2004 From: Watzman at neo.rr.com (Barry Watzman) Date: Thu, 9 Sep 2004 19:04:32 -0400 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <000001c496bd$007290b0$f300a8c0@berkeley.evocative.com> Message-ID: <200409092304.i89N4RJX016287@ms-smtp-01-eri0.ohiordc.rr.com> I understand, but it seems like -- it is -- a lot of money. Barry -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Patrick/VCM SysOp Sent: Thursday, September 09, 2004 6:33 PM To: sebhc at sebhc.org Subject: RE: [sebhc] At long last... Media has arrived! Barry, Sure. You can also buy them by the box on eBay for $20 per 10 or less. Maybe they're OK, maybe not, but I agree it's worth the savings to at least try. My price was previously announced on this list. The media is new stock, not new old, and manufactured to order by a reputable supplier. If I could get them for less, I'd sell them for less. I'm not in this to make money, I'm just trying to help out. Patrick > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Barry Watzman > Sent: Thursday, September 09, 2004 2:28 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] At long last... Media has arrived! > > > Well, I've got hundreds, maybe even a couple of thousand > 5.25" disks, "brand new" (if very "Old" stock) left over from > my "Perks" and "Addresselope" days, and I'd sell them for a > LOT less than that. All soft-sector, 360k type, however. > > Now, as for the hard-sector ones, anyone know where I can get > a hole-punch? > > :-) > > Barry Watzman > Watzman at neo.rr.com > > > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Patrick/VCM SysOp > Sent: Thursday, September 09, 2004 5:12 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] At long last... Media has arrived! > > Correct. > > > -----Original Message----- > > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > > Barry Watzman > > Sent: Thursday, September 09, 2004 1:21 PM > > To: sebhc at sebhc.org > > Subject: [sebhc] At long last... Media has arrived! > > > > > > $1.85 per what? Per disk? > > > > > > > > > > -- > > Delivered by the SEBHC Mailing List > sebhc-request at sebhc.org. > > > > -- > Delivered by the SEBHC Mailing List > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu Sep 9 18:49:56 2004 From: patrick at vintagecomputermarketplace.com (Patrick/VCM SysOp) Date: Thu, 9 Sep 2004 16:49:56 -0700 Subject: [sebhc] At long last... Media has arrived! In-Reply-To: <200409092304.i89N4RJX016287@ms-smtp-01-eri0.ohiordc.rr.com> Message-ID: <000201c496c7$b5925160$f300a8c0@berkeley.evocative.com> > I understand, but it seems like -- it is -- a lot of money. > > Barry > Well, I can't disagree. I sure would like it to be less, considering I just bought 1500 of them! :-) That's a bit of a discount, too. You have to buy ridiculous numbers to get a real meaningful discount. When I first tried to find them two years ago, I was hoping to get 'em for 25-30 cents each, and I got my expectations adjusted very quickly. Still, at $1.85 each today, that's about $8.25 in 1980 dollars per box of ten. Doesn't seem so bad when you look at it that way. I remember paying $15-$20 per box plus tax back then (no cracks about my allowance please, Jack :) ). Patrick :-) http://minneapolisfed.org/Research/data/us/calc/index.cfm -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Fri Sep 10 01:05:49 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Fri, 10 Sep 2004 01:05:49 -0500 Subject: [sebhc] At long last... Media has arrived! References: <000201c496c7$b5925160$f300a8c0@berkeley.evocative.com> Message-ID: <00d001c496fc$389e25f0$6501010a@BUSTER> That's one way to look at it, the other way, is that you can usually find a 50 pack of CD-RW for less than $10, so that would be about $0.20 each for 650M, to get that much space on the hard-sectored disks, it would cost 6500 * $1.85, or about $12,000 and would take up alot more space. For the H89, I hope to be getting a soft-sectored controller shortly and I already have a 3.5" 720K drive to connect to it. I was able to get 100 of those disks for about $22, (so 72M total), but to get the same space in hard-sectored disks, it would be 720 * 1.85 or about $1300. Much to rich for me. Mark ----- Original Message ----- From: "Patrick/VCM SysOp" To: Sent: Thursday, September 09, 2004 6:49 PM Subject: RE: [sebhc] At long last... Media has arrived! >> I understand, but it seems like -- it is -- a lot of money. >> >> Barry >> > > Well, I can't disagree. I sure would like it to be less, considering I > just > bought 1500 of them! :-) That's a bit of a discount, too. You have to > buy > ridiculous numbers to get a real meaningful discount. When I first tried > to > find them two years ago, I was hoping to get 'em for 25-30 cents each, and > I > got my expectations adjusted very quickly. > > Still, at $1.85 each today, that's about $8.25 in 1980 dollars per box of > ten. Doesn't seem so bad when you look at it that way. I remember paying > $15-$20 per box plus tax back then (no cracks about my allowance please, > Jack :) ). > > Patrick :-) > > http://minneapolisfed.org/Research/data/us/calc/index.cfm > > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Fri Sep 10 12:29:07 2004 From: leeahart at earthlink.net (Lee Hart) Date: Fri, 10 Sep 2004 10:29:07 -0700 Subject: [sebhc] At long last... Media has arrived! References: <000201c496c7$b5925160$f300a8c0@berkeley.evocative.com> <00d001c496fc$389e25f0$6501010a@BUSTER> Message-ID: <4141E463.55CC@earthlink.net> Mark Garlanger wrote: > That's one way to look at it. The other way, is that you can usually > find a 50 pack of CD-RW for less than $10, so that would be about > $0.20 each for 650M, to get that much space on the hard-sectored > disks, it would cost 6500 * $1.85, or about $12,000 and would take > up a lot more space. Except that you can't use CD-RW disks in your H89. So the comparison is logical, but useless. The true value of these new $1.85 H17 disks lies in what you can do with them. What do they let you do that you can't do now? And, what is that worth to you? You have to remember that the H17 is a *very* simple hardware and software design -- this allowed it to be designed very quickly. That's why it was the first one out. The trade-off is a higher cost per bit (more expensive disks, and low storage capacity per disk). The CD-ROM is the opposite extreme. Very expensive hardware and software, that took a tremendous amount of time and money to invent -- in return for which it yields a very low cost per bit and very cheap media. To me, it is important to note that the 25-year-old H17 system still works today, with zero adjustments and repairs. Out of a dozen H89s, I've never had to fix or replace any H17 controller. In contrast, the Heath H37 (soft-sector) controller was the *last* one to come out, has the *most* complicated PC board, and needs the *largest* software driver to work. I've found it to be the least reliable controller board, and very difficult to fix (I've been struggling for months to get one working for Mark Garlanger, in fact)! Quite frankly, I have just about zero confidence that a modern PC with its CD-RW will work in 25 years. While I can just about guarantee that an H89 with those new H17 disks will still work. After all, we already *know* these disks hold data for 25+ years! -- "Never doubt that the work of a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has!" -- Margaret Mead -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri Sep 17 17:20:48 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 17 Sep 2004 18:20:48 -0400 Subject: [sebhc] PC Fab Message-ID: <414B6340.2090308@sc.rr.com> I'm looking for recommendations for a CHEAP PCB fab house. Who does the best work for the lowest price? CEW -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Fri Sep 17 20:10:06 2004 From: leeahart at earthlink.net (Lee Hart) Date: Fri, 17 Sep 2004 18:10:06 -0700 Subject: [sebhc] PC Fab References: <414B6340.2090308@sc.rr.com> Message-ID: <414B8AEE.814@earthlink.net> Carroll Waddell wrote: > > I'm looking for recommendations for a CHEAP PCB fab house. Who does the > best work for the lowest price? As usual, "cheap" and "best" tend to be mutually exclusive. The real questions to ask yourself are, "What are you willing to pay?" and "How good is good enough?" I've bought cheap punched phenolic PC boards for under 5 cents/sq.inch. But they are single-sided, you have to buy a minimum of 1000+ boards, the solder pads lift off easily from excess soldering heat, and the board material is rather weak and brittle. I've also paid over 50 cents/sq.inch for precision multilayer boards, where we had very tight tolerances and were depending on certain physical properties to get stable repeatable performance. There is a huge range of possibilities in between. Your typical glass-epoxy double-sided PCB with plated-thru holes is a commodity item, with dozens of companies competing for your business. They have all sorts of marketing tricks, which may or may not lower your price. "Use our free layout software program (but it won't let you take the board to anyone else). "Buy now, get fast delivery for free" (because half our plant is currently idle). "Order today and get two for the price of one" (if you can wait 6 weeks, and order some minimum quantity). Frankly, I don't shop for lowest price. One little screw-up, and a PC board is nearly worthless. Your time is worth far more than the cost of the board. -- "Never doubt that the work of a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has!" -- Margaret Mead -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From rgroh at swbell.net Fri Sep 17 23:27:55 2004 From: rgroh at swbell.net (Bob And Bettina Groh) Date: Fri, 17 Sep 2004 23:27:55 -0500 Subject: [sebhc] PC Fab References: <414B6340.2090308@sc.rr.com> Message-ID: <414BB94B.6080807@swbell.net> Carroll, Don't know what you mean by 'cheap' but I know there are several PC houses that advertise in the back of EE Times that advertise double sided pc boards with plated through holes, 4x5" or thereabouts, qty of 3 or 4 for about $50 each. I have never used any of them but they look decent. SOme even have somewhat primitive but 'FREE" cad packages for schematic and board layout. If interested I could dig up more info for you. Bob Groh Carroll Waddell wrote: > I'm looking for recommendations for a CHEAP PCB fab house. Who does > the best work for the lowest price? > CEW > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From eric at rothfus.com Sat Sep 18 07:31:57 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Sat, 18 Sep 2004 08:31:57 -0400 Subject: [sebhc] PC Fab In-Reply-To: <414B6340.2090308@sc.rr.com> (message from Carroll Waddell on Fri, 17 Sep 2004 18:20:48 -0400) References: <414B6340.2090308@sc.rr.com> Message-ID: <1095453385@rothfus.com> Hi Carroll, I use PCBExpress (www.pcbexpress.com) myself. I don't quite remember why I went with them, however. When I was shopping, most of the different on-line services appeared to have roughly the same prices. This one required that you use your own software to generate the files they need to produce the PCBs. I use the Eagle development software. I looked at Express PCB (www.expresspcb.com) as well. They have free down-loadable development software which is MUCH easier than Eagle...though not as powerful. All in all, I think that their solution will be easier for simpler boards. There are really three variables for small runs of PCBs at these places: - board size - the smaller, the cheaper :-) (obviously) - number of boards - the more, the cheaper per board :-) (obviously) - silk-screen & solder mask - when you add these, the price starts to go up quickly. They're NOT necessary...really. When I did my runs, I did the first few boards without silk-screen and solder mask and they worked great. When I started to produce boards that others would be using, that's when I added the silk-screen and solder mask. Here's a quick example, my boards were 3" X 3.75": Without silk-screen & solder-mask - 4 boards PCB Express - $115 Express PCB - $105 With silk-screen & solder-mask - 4 boards PCB Express - $238 Express PCB - $229 (fixed price for 5 boards) Hope this helps. Eric -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sat Sep 18 23:55:00 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sat, 18 Sep 2004 23:55:00 -0500 Subject: [sebhc] Flash memory interfaces Message-ID: <001701c49e04$d1fc57d0$6501010a@BUSTER> I was just looking at the prices of the little USB Flash memory devices and was wondering if anyone has investigated the feasibility of adding a USB interface to the H89? Or maybe one of the other Flash memory interfaces (compact flash, SD, memory stick, etc.)? It seems like it would be possible to model it like a harddrive, and have much more than the H67 provided for less than $50 + cost of the interface card. Mark From leeahart at earthlink.net Mon Sep 20 15:58:51 2004 From: leeahart at earthlink.net (Lee Hart) Date: Mon, 20 Sep 2004 13:58:51 -0700 Subject: [sebhc] Flash memory interfaces References: <001701c49e04$d1fc57d0$6501010a@BUSTER> Message-ID: <414F448B.7E1C@earthlink.net> Mark Garlanger wrote: > I was just looking at the prices of the little USB Flash memory > devices and was wondering if anyone has investigated the > feasibility of adding a USB interface to the H89? Or maybe one > of the ther Flash memory interfaces (compact flash, SD, memory > stick, etc.)? > It seems like it would be possible to model it like a harddrive, > and have much more than the H67 provided for less than $50 + > cost of he interface card. It's a great idea, but the practical difficulties abound. Most of these modern cheap-mass-memory devices are tailored strongly toward high-end PCs. They use complex protocols and specialized parts that make them very difficult to be used by hobbyists. So, while it is possible, no one is willing to spend the time and effort to figure it all out and get it to work. I think a "low tech" solution is far more likely to succeed. You can readily buy very large conventional EPROM, EEPROM, flash ROM, and RAM chips in normal DIP packages. The pinouts are highly standardized. The protocols for talking to them are simple and well-documented. For example, years ago when the 32k EPROMs became cheap, I plugged one into the ROM socket of my H89, and wired the extra address lines to the spare output bits of the 8250 UART. I wrote software to bank-switch the EPROM. The extra ROM space was used by my "Superset" software to drastically enhance the H19 and H89's terminal capabilities. Now that 512k EPROMs are $6-7, you could expand the concept. Plug it into one of the CPU board's 2k ROM sockets, and add an 8-bit latch to control the EPROM's extra address lines. This gives you 256 x 2k = 512k bytes of non-volatile read-only memory. Add a RAM disk drive to the CP/M BIOS to access this memory as a read-only disk drive. (I already have such software written for the H-1000, which would work on the H8 and H89 with only minor modifications). Half a meg is enough to hold virtually all the programs that one could ever want on an H89. You could even boot from this ROM disk! If this isn't enough memory, the concept could be expanded. If it was a RAM chip and a little battery, it would be non-volatile and work like a real disk (but drastically faster). You could put multiple ROM/RAM sockets on a little board, which plugs into the bus or ROM socket as an adapter. The advantage of this approach is that it is so straightforward and simple that it has a good chance of actually getting built. All the approaches with interfacing USB or CompactFlash sound great, but will never get done. -- "Never doubt that the work of a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has!" -- Margaret Mead -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun Sep 26 13:19:37 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 26 Sep 2004 13:19:37 -0500 Subject: [sebhc] New ET3400 docs Message-ID: <000001c4a3f5$622121b0$1f6fa8c0@eths.k12.il.us> James Cosper has contributed scans of several manuals related to the ET-3400 and ETA-3400. They are in the /documents/hardware/ section of the archive. Microprocessor Trainer ET-3400 part number 595-2021-06, copyright date 1977 113 Pages + 3 set Foldout + "price list 10/20/80". Heathkit_3400_595-2021-06.pdf - 9991k Memory Input/Output Accessory ETA-3400 (Assembly) part number 595-2170-03, copyright date 1979 57 Pages. + 1 set Foldout. Heathkit_3400_595-2170-03.pdf - 5463k Memory and Input/Output Accessory for the ET-3400 (Software Reference) part number 595-2271-01, copyright date 1979 95 pages. Heathkit_3400_595-2271-01.2 - 7524k Thanks James! Jack -- Delivered by the SEBHC Mailing List