From jack.rubin at ameritech.net Sat May 1 00:03:51 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 1 May 2004 00:03:51 -0500 Subject: [sebhc] New Archive postings In-Reply-To: <002401c42f37$0a41aec0$6501010a@gr390> Message-ID: <000501c42f39$b25f06f0$1f6fa8c0@eths.k12.il.us> Mark, I've got at least some H29 docs that I will try to locate over the weekend. Is the terminal function integral to the virtual 8H or is a serial connection part of the emulation - the hope, of course, being that one could use the "terminals" as stand-alone emulations by themselves for communication with "real" hardware. The HUG software images in the sebhc archives follow Dave's dump format - have you tried to load any of them? It would seem that a bit of editing to the header should allow the images to be loaded like a tape. Wouldn't H17/H37 support simply mean reading and loading various header types? Would you please upload the recompiled module when you get a chance? Thanks, Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Mark Garlanger > Sent: Friday, April 30, 2004 11:45 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] New Archive postings > > > Yes it appears to work fine. Although with both the > 'official' binary, and my compile program, loading either of > the 'benchmark' tapes don't appear to do anything (but it > could just be user error). But the console_echo tape seems to > function as expected. > > Anyone interested in adding an option for the H9 terminal > instead of only the H19? It shouldn't be too hard with the H9 > Operational Manual that I uploaded to the archives. If done > right, it would then be easy (if we have the manual) to also > add in an H29 option. Maybe we can generate some interest and > work on H17 support in the emulator. Another thing I would > be interested in doing is to get this also working under > Linux. Although that would be a much bigger undertaking due > to all the GUI changes required. > > Mark > > > ----- Original Message ----- > From: "Jack Rubin" > To: > Sent: Friday, April 30, 2004 11:20 PM > Subject: RE: [sebhc] New Archive postings > > > > were you successful running the emulator with these changes to the > > source? > > > > > -----Original Message----- > > > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Mark > > > Garlanger > > > Sent: Friday, April 30, 2004 10:51 PM > > > To: sebhc at sebhc.org > > > Subject: Re: [sebhc] New Archive postings > > > > > > > > > It's great that the ROMs for the H8 are now available... > > > > > > > > > I have recompiled the virtual_h8 project, and based on some > > > warnings, it appears to have a few bugs in the processor > emulation. > > > In the file processor.cpp, the following code is in four > places: S = > > > (A & 0x0080 != 0); > > > > > > And the compiler provides the following warning: > > > c:\H8\code\virtual_h8\processor.cpp(2452) : warning C4554: '&' : > > > check operator precedence for possible error; use parentheses to > > > clarify precedence > > > > > > In looking at operator precedence, it does appear to be a problem > > > since the precedence makes it equivelent to: S = (A & > (0x0080 != 0 > > > )); > > > > > > Which doesn't make any sense. It should be: > > > S = ((A & 0x0080) != 0 ); > > > > > > I've sent email to the author (David Wallace) so it can > be addressed > > > in the next release. > > > > > > Mark > > > > > > > > > ----- Original Message ----- > > > From: "Jack Rubin" > > > To: "SEBHC" > > > Sent: Friday, April 30, 2004 8:16 AM > > > Subject: [sebhc] New Archive postings > > > > > > > > > > Steve Parker, author of the original PAM37 ROM, has > > > prepared the two > > > > ROM files needed to make Dave Wallace's Virtual H8 emulator > > > > operational. These are in the H8 ROMs folder - note that > > > these are not > > > > straight binary dumps but rather dumps formatted especially for > > > > the emulator. > > > > > > > > I've also posted the Cassette SRM (Software Reference > Manual, P/N > > > > 595-2048-01). Included in the same folder is the update > > > document for > > > > Extended BH Basic 10.02.00 (HC8-13). When the original > > > owner of this > > > > machine received the EBHB update, he discarded the > > > superceded sections > > > > from the original BASIC section of the manual. I will replace > > > > these sections as soon as I locate them (in my physical archive) > > > and update > > > > the .pdf file at that time. > > > > > > > > I also uploaded several "real" ROM binaries and manuals > for the H8 > > > > H37/67 and H47 disk controllers. > > > > > > > > Jack > > > > > > > > -- > > > > 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 Sat May 1 00:55:25 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sat, 1 May 2004 00:55:25 -0500 Subject: [sebhc] New Archive postings References: <000501c42f39$b25f06f0$1f6fa8c0@eths.k12.il.us> Message-ID: <002c01c42f40$e63a0130$6501010a@gr390> Hi Jack, I doubt we will need the H29 docs anytime soon ;-). It looks like the H19 is tied closely to the H8 emulator. Although today is the first day I've looked at the code, so I may be way off. I haven't tried to load the HUG .h17 files, I doubt changing the header will work. Those disk images support multiple files, with a directory, etc. The tape images appear to be a single executable program. I just now tried to run the .PID files in the DAP-H8-tapes directory after renaming to .tape with the following results: H8DEMO - works, see the message on the H8's LED panel. HANGMAN - stops emulator with: "I/O write attempted to unimplemented port" TED8 - stops emulator with: "I/O write attempted to unimplemented port" BHBASIC - stops emulator with: "I/O write attempted to unimplemented port" BUG8 - stops emulator with: "I/O write attempted to unimplemented port" EXBASIC - stops emulator with: "I/O write attempted to unimplemented port" HASL8 - stops emulator with: "I/O write attempted to unimplemented port" I tried HANGMAN on David's release emulator and received the same "I/O write" error message. I assume they all will give that same error. Tomorrow I will try to enable some logging to see which port is causing the problem. Supporting the H17 and H37 would require loading in the OS (CP/M or HDOS) and providing all the hardware support those OSs use. I don't think it's as simple as supporting a new header. Before uploading a new version of the emulator, I would like to hear back from David to verify that it is a problem, and see if he wants to be the provide the 'official' versions. Mark ----- Original Message ----- From: "Jack Rubin" To: Sent: Saturday, May 01, 2004 12:03 AM Subject: RE: [sebhc] New Archive postings > Mark, > > I've got at least some H29 docs that I will try to locate over the > weekend. > > Is the terminal function integral to the virtual 8H or is a serial > connection part of the emulation - the hope, of course, being that one > could use the "terminals" as stand-alone emulations by themselves for > communication with "real" hardware. > > The HUG software images in the sebhc archives follow Dave's dump format > - have you tried to load any of them? It would seem that a bit of > editing to the header should allow the images to be loaded like a tape. > Wouldn't H17/H37 support simply mean reading and loading various header > types? > > Would you please upload the recompiled module when you get a chance? > > Thanks, > Jack > -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sat May 1 12:27:05 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sat, 1 May 2004 12:27:05 -0500 Subject: [sebhc] New Archive postings References: <000501c42f39$b25f06f0$1f6fa8c0@eths.k12.il.us> <002c01c42f40$e63a0130$6501010a@gr390> Message-ID: <003601c42fa1$85ec6a00$6501010a@gr390> I found the port address that is causing the problem. According to the log file, it's I/O address 0373 (251 or 0xFB), the code says it's related to the console being connected via the H8-5 card: Log File: "***Port 373 is not implemented.***" Code: // Ports 372 and 373 were the console USART ports if the console was connected // via the H8-5's serial I/O port. Not used. case 0372: // (fall through) case 0373: bNotImplemented = TRUE; break; Anyone have any ideas on what we can do so that the majority of the Tapes will run on the emulator? Simply commenting out the bNotImplemented Line so that the output goes no where didn't seem to help. Mark ----- Original Message ----- From: "Mark Garlanger" To: Sent: Saturday, May 01, 2004 12:55 AM Subject: Re: [sebhc] New Archive postings > Hi Jack, > > I doubt we will need the H29 docs anytime soon ;-). It looks like the > H19 is tied closely to the H8 emulator. Although today is the first day I've > looked at the code, so I may be way off. > > I haven't tried to load the HUG .h17 files, I doubt changing the header will > work. Those disk images support multiple files, with a directory, etc. The > tape images appear to be a single executable program. > > I just now tried to run the .PID files in the DAP-H8-tapes directory after > renaming to .tape with the following results: > > H8DEMO - works, see the message on the H8's LED panel. > HANGMAN - stops emulator with: "I/O write attempted to unimplemented port" > TED8 - stops emulator with: "I/O write attempted to unimplemented port" > BHBASIC - stops emulator with: "I/O write attempted to unimplemented port" > BUG8 - stops emulator with: "I/O write attempted to unimplemented port" > EXBASIC - stops emulator with: "I/O write attempted to unimplemented port" > HASL8 - stops emulator with: "I/O write attempted to unimplemented port" > > I tried HANGMAN on David's release emulator and received the same "I/O > write" error message. I assume they all will give that same error. > > Tomorrow I will try to enable some logging to see which port is causing the > problem. > > Supporting the H17 and H37 would require loading in the OS (CP/M or HDOS) > and providing all the hardware support those OSs use. I don't think it's as > simple as supporting a new header. > > Before uploading a new version of the emulator, I would like to hear back > from David to verify that it is a problem, and see if he wants to be the > provide the 'official' versions. > > Mark > > > ----- Original Message ----- > From: "Jack Rubin" > To: > Sent: Saturday, May 01, 2004 12:03 AM > Subject: RE: [sebhc] New Archive postings > > > > Mark, > > > > I've got at least some H29 docs that I will try to locate over the > > weekend. > > > > Is the terminal function integral to the virtual 8H or is a serial > > connection part of the emulation - the hope, of course, being that one > > could use the "terminals" as stand-alone emulations by themselves for > > communication with "real" hardware. > > > > The HUG software images in the sebhc archives follow Dave's dump format > > - have you tried to load any of them? It would seem that a bit of > > editing to the header should allow the images to be loaded like a tape. > > Wouldn't H17/H37 support simply mean reading and loading various header > > types? > > > > Would you please upload the recompiled module when you get a chance? > > > > Thanks, > > Jack > > > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sat May 1 18:16:56 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 01 May 2004 23:16:56 +0000 Subject: [sebhc] Emulator fix Message-ID: >I found the port address that is causing the problem. According to the log >file, it's I/O address 0373 (251 or 0xFB), the code says it's related to >the console being connected via the H8-5 card: > >Log File: "***Port 373 is not implemented.***" I'm guessing the tape s/w is polling ports to find the terminal. It's been a while since I played with any tape s/w but I seem to recall it waits for you to hit a key, right? So the fix would be to simulate the port by returning a value that would look like the usart has empty buffers and an un-asserted DSR ("nobody home"). Ideally, the emulator should do this (simulate idle or unconnected device) for all ports that might be associated with common devices. And perhaps accesses to any other port could simply be logged but not stop execution (as it would not stop a real CPU). Just return a fixed value (like zero). >Simply commenting out the bNotImplemented Line so >that the output goes no where didn't seem to help. I would have expected it to keep the CPU going, at least - did it? But returning an unitialized value may have confused the polling routine. Try this: // Ports 372 and 373 were the console USART ports if the console was connected // via the H8-5's serial I/O port. Not used. // 2004.05.01.sp - Checked by tape software, so simulate in idle status. case 0372: nData = 0; break; case 0373: nData = USART_STATUS_TXE | USART_STATUS_TXRDY; break; Then, down at the end of the routine, to keep it from halting on unimplemented inputs entirely (but still log them and display the status window): // 2004.05.01.sp - Continue execution anyway (as a real CPU would) nData = 0; // Sleep(5000); // SetEvent(theApp.m_IPC.hShutdown); Let me know if that fixes it! Cheers, - Steven _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 1 18:42:32 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 01 May 2004 19:42:32 -0400 Subject: [sebhc] Emulator fix In-Reply-To: References: Message-ID: <409435E8.5010801@sc.rr.com> For the tape software that I've used on H8, when you hit GO on the keypad, it will output to the H8-5 if present and present you with some options for Lower case characters, etc, then write an updated copy of that program to the output tape recorder. CEW Steven Parker wrote: >> I found the port address that is causing the problem. According to >> the log >> file, it's I/O address 0373 (251 or 0xFB), the code says it's related to >> the console being connected via the H8-5 card: >> >> Log File: "***Port 373 is not implemented.***" > > > I'm guessing the tape s/w is polling ports to find the terminal. It's > been a while since I played with any tape s/w but I seem to recall it > waits for you to hit a key, right? So the fix would be to simulate the > port by returning a value that would look like the usart has empty > buffers and an un-asserted DSR ("nobody home"). > > Ideally, the emulator should do this (simulate idle or unconnected > device) for all ports that might be associated with common devices. > And perhaps accesses to any other port could simply be logged but not > stop execution (as it would not stop a real CPU). Just return a fixed > value (like zero). > >> Simply commenting out the bNotImplemented Line so >> that the output goes no where didn't seem to help. > > > I would have expected it to keep the CPU going, at least - did it? But > returning an unitialized value may have confused the polling routine. > Try this: > > > // Ports 372 and 373 were the console USART ports if the console was > connected > // via the H8-5's serial I/O port. Not used. > // 2004.05.01.sp - Checked by tape software, so simulate in idle status. > > case 0372: > nData = 0; > break; > case 0373: > nData = USART_STATUS_TXE | USART_STATUS_TXRDY; > break; > > > Then, down at the end of the routine, to keep it from halting on > unimplemented inputs entirely (but still log them and display the > status window): > > > // 2004.05.01.sp - Continue execution anyway (as a real CPU would) > nData = 0; > // Sleep(5000); > // SetEvent(theApp.m_IPC.hShutdown); > > > Let me know if that fixes it! > > Cheers, > > - Steven > > _________________________________________________________________ > MSN Toolbar provides one-click access to Hotmail from any Web page ? > FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sat May 1 19:08:13 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 02 May 2004 00:08:13 +0000 Subject: [sebhc] Emulator fix Message-ID: >For the tape software that I've used on H8, when you hit GO on the keypad, >it will output to the H8-5 if present and present you with some options for >Lower case characters, etc, then write an updated copy of that program to >the output tape recorder. CEW If the tape software doesn't know how to use the 8250 ports at all, then it might be worthwhile to modify the integral H19 in the emulator so it can work via the 8251 also. Until then, my fix won't make that particular software useful, but it should still keep the CPU from halting. I might consider doing this myself when I get set up so I can rebuild the emulator. I'm not currently set up to compile for windows. Anybody got a "copyleft" Linux -> Windows cross-development kit? _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sat May 1 20:26:55 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sat, 1 May 2004 20:26:55 -0500 Subject: [sebhc] Emulator fix References: Message-ID: <005001c42fe4$8e5fd2b0$6501010a@gr390> Hi Steven, The emulator was first complaining about write attempts to that address. The change I had made before just let that write drop those bits. In the read codeI had commented out the setting of bNotImplemented line, and reading both addresses would just return 0. With those changes it didn't halt it but it didn't seem to do anything after that. Making the changes you proposed below to the port read code didn't seem to change the end result - still not doing anything after that (at least that I could tell). Part of the problem could be that I don't know what I'm doing with the H8. I never had an H8, I did have an H89 but only used disks - CP/M and HDOS. And the last time I used the H89 was probably in 1989 or 1990... The emulator seems to continue processing (the MON led stays off), but the H19 doesn't provide anything and I don't see anything that implies something is being accomplished. The only thing I know to do is hit reset and load another program. I would really like to get the H17 supported, so I can try with disk images instead of tapes. Mark ----- Original Message ----- From: "Steven Parker" To: Sent: Saturday, May 01, 2004 6:16 PM Subject: [sebhc] Emulator fix > >I found the port address that is causing the problem. According to the log > >file, it's I/O address 0373 (251 or 0xFB), the code says it's related to > >the console being connected via the H8-5 card: > > > >Log File: "***Port 373 is not implemented.***" > > I'm guessing the tape s/w is polling ports to find the terminal. It's been > a while since I played with any tape s/w but I seem to recall it waits for > you to hit a key, right? So the fix would be to simulate the port by > returning a value that would look like the usart has empty buffers and an > un-asserted DSR ("nobody home"). > > Ideally, the emulator should do this (simulate idle or unconnected device) > for all ports that might be associated with common devices. And perhaps > accesses to any other port could simply be logged but not stop execution (as > it would not stop a real CPU). Just return a fixed value (like zero). > > >Simply commenting out the bNotImplemented Line so > >that the output goes no where didn't seem to help. > > I would have expected it to keep the CPU going, at least - did it? But > returning an unitialized value may have confused the polling routine. Try > this: > > > // Ports 372 and 373 were the console USART ports if the console was > connected > // via the H8-5's serial I/O port. Not used. > // 2004.05.01.sp - Checked by tape software, so simulate in idle status. > > case 0372: > nData = 0; > break; > case 0373: > nData = USART_STATUS_TXE | USART_STATUS_TXRDY; > break; > > > Then, down at the end of the routine, to keep it from halting on > unimplemented inputs entirely (but still log them and display the status > window): > > > // 2004.05.01.sp - Continue execution anyway (as a real CPU would) > nData = 0; > // Sleep(5000); > // SetEvent(theApp.m_IPC.hShutdown); > > > Let me know if that fixes it! > > Cheers, > > - Steven > > _________________________________________________________________ > MSN Toolbar provides one-click access to Hotmail from any Web page - FREE > download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 2 05:22:39 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 2 May 2004 05:22:39 -0500 Subject: [sebhc] Trionyx Message-ID: <000001c4302f$661317e0$1f6fa8c0@eths.k12.il.us> I've just posted a file of Trionyx product marketing info to the document folder in the sebhc archive. Trionyx tried valiantly to support and develop the H8 after the Heath/Zenith merger and the emergence of the IBM PC left it orphaned. I'd like to put together a short history of Trionyx. If anyone has any more info, documentation or hardware, please let me know. I'm also interested in acquiring any Trionyx items that might be available. Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 2 05:31:20 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 02 May 2004 10:31:20 +0000 Subject: [sebhc] Emulator fix Message-ID: Mark says: >The emulator was first complaining about write attempts to that address. It was probably setting up the word size, parity, etc. on the status port. >In the read code...both addresses would just return 0. The status port should probably always return TxRDY to prevent hanging in an output routine. My mod returns that and TxE together to simulate an empty buffer. >it didn't halt it but it didn't seem to do anything after that. I'm guessing this tape software does not support the 4-port serial card (with the 8250's), which is apparently how the emulator handles the H19 connection. That's what I meant by adding code to support simulation of the terminal connected on the H8-5 serial port as well. This particular tape software probably won't do anything interesting until that is set up. >Making the changes you proposed >below to the port read code didn't seem to change the end result It was only intended to keep the CPU from halting on input attempts from other unsimulated ports. >I would really like to get the H17 supported, so I can try with disk images >instead of tapes. That would be really cool. I might also consider working on that too, once I can do a build. Looks like Dave Wallace was intending to add that - has anyone been in touch with him recently? He hasn't answered email I sent him weeks ago. - Steven _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sun May 2 06:59:40 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sun, 02 May 2004 07:59:40 -0400 Subject: [sebhc] Trionyx In-Reply-To: <000001c4302f$661317e0$1f6fa8c0@eths.k12.il.us> References: <000001c4302f$661317e0$1f6fa8c0@eths.k12.il.us> Message-ID: <4094E2AC.80500@sc.rr.com> I have a Trionyx 64K memory board, but it doesn't work anymore. I still have the Trionyx drawings for that board. Carroll Jack Rubin wrote: >I've just posted a file of Trionyx product marketing info to the >document folder in the sebhc archive. > >Trionyx tried valiantly to support and develop the H8 after the >Heath/Zenith merger and the emergence of the IBM PC left it orphaned. > >I'd like to put together a short history of Trionyx. If anyone has any >more info, documentation or hardware, please let me know. I'm also >interested in acquiring any Trionyx items that might be available. > >Jack > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Sun May 2 11:01:29 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Sun, 2 May 2004 12:01:29 -0400 Subject: [sebhc] Trying to get NetPC 3.4 running ... Message-ID: <004c01c4305e$bb5f2390$02a8a8c0@IBMD9HY10WBGXB> Hi folks, As the subject indicates ... I've been attempting to get NetPC 3.4 up and running on a recently restored Swtp S/09 system. NetPC starts up and displays the 'NetPC driver version 3.4' banner ... and then it sits for a minute or so (presumably trying to connect) and then times out with 'Can't sync serial transfer!'. Here are the system specifics (intentionally verbose): * The S/09 has an MP-09A that is configured for extended addressing and SBUG 1.8. The system is currently configured to run at 1mhz. * Installed boards include the MP-ID board, an MP-S2 with only a single port installed on IO port 0 (console), an MP-S2 with both ports installed on IO port 1, and two MP-L2 dual port parallel boards installed on IO ports 2 and 3. In addition, there is a DMAF2 disk controller, connected to the Swtp dual 8" drive cabinet. For memory, it has the Swtp SMS3509 memory system (with the SMS3509C controller card, and one SMS3509A 128k memory array card). * The operating system is Swtp's flavor of Flex, version 2.7:3. * The PC side is a Thinkpad laptop with DOS 6.3 installed. I use this system as a 'console' (running term emulation) for most all of my vintage systems. I'm using a standard DB9-DB25 serial cable. I'm connecting the PC to the dual MP-S2 at IO port 1. I've modified acia.txt to use port A on the MP-S2: aciac equ $E010 aciad equ $E011 I've also tried $E014,$E015 with the PC connected to port B. I've also tried adding the 6850 uart initialization code to acia.txt (even though it is in netdrv.txt already). Last, I also tried just using a three wire connection (pins 2,3, and 7) ...all with no luck. The dual MP-S2 has been verified functional installed at IO slot 0 and connected to a console. The config.txt file on the PC side is set for 9600 baud, the MP-S2 is configured for 9600 baud (strapped). Debug is on in config.txt... no messages are generated when I run netdrv.bin on the S/09. I've tried both 'slow' and 'fast' configurations. NetPC initializes just fine on the PC. Also, netdrv.txt was assembled on the S/09 itself using asmb.cmd. No assembly errors were generated. I imagine that I'm missing something simple here ... any suggestions would be most welcome. Thanks ... Regards, Scott -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Sun May 2 11:37:16 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Sun, 2 May 2004 12:37:16 -0400 Subject: [sebhc] Trying to get NetPC 3.4 running ... References: <004c01c4305e$bb5f2390$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <008101c43063$baa704e0$02a8a8c0@IBMD9HY10WBGXB> Too many mailing lists ... too little time ... sorry folks. I posted this to the wrong list ... Jack asked me to leave it for a couple of reasons ...read on: I've been giving some thought as to the possibility of having an equivalent to NetPC for the H8. For those of you who may not know what NetPC is ... it essentially allows access from a Swtp system to disk images that reside on a PC. The access is done in such a way so as to make the images appear as real disks to the Swtp (running Flex as the operating system). The approach is implemented over a serial port ...a piece of code runs on both ends of the connection. It would seem that there would be a way to take advantage of the H8 simulation work that has been available for some time to implement a NetPC capability for H8. Specifically, we should be able to use a stripped down iteration of the simulator to handle the disk image IO. Instead of having a full simulator that accepts disk related commands from the console (and that has a full GUI), it would accept disk related commands via the serial port (sent from the H8 while booted in HDOS, or perhaps even CP/M). I know that Dwight and others have done some work in this area ... any comments? Scott ----- Original Message ----- From: "Scott LaBombard" To: Sent: Sunday, May 02, 2004 12:01 PM Subject: [sebhc] Trying to get NetPC 3.4 running ... > Hi folks, > > As the subject indicates ... I've been attempting to get NetPC 3.4 up > and running on a recently restored Swtp S/09 system. NetPC starts > up and displays the 'NetPC driver version 3.4' banner ... and then it > sits for a minute or so (presumably trying to connect) and then times > out with 'Can't sync serial transfer!'. > > Here are the system specifics (intentionally verbose): > > * The S/09 has an MP-09A that is configured for extended addressing > and SBUG 1.8. The system is currently configured to run at 1mhz. > > * Installed boards include the MP-ID board, an MP-S2 with only a > single port installed on IO port 0 (console), an MP-S2 with both ports > installed on IO port 1, and two MP-L2 dual port parallel boards > installed on IO ports 2 and 3. In addition, there is a DMAF2 disk > controller, connected to the Swtp dual 8" drive cabinet. For memory, > it has the Swtp SMS3509 memory system (with the SMS3509C > controller card, and one SMS3509A 128k memory array card). > > * The operating system is Swtp's flavor of Flex, version 2.7:3. > > * The PC side is a Thinkpad laptop with DOS 6.3 installed. I use > this system as a 'console' (running term emulation) for most all of > my vintage systems. I'm using a standard DB9-DB25 serial cable. > > I'm connecting the PC to the dual MP-S2 at IO port 1. I've > modified acia.txt to use port A on the MP-S2: > > aciac equ $E010 > aciad equ $E011 > > I've also tried $E014,$E015 with the PC connected to port B. I've > also tried adding the 6850 uart initialization code to acia.txt (even > though it is in netdrv.txt already). Last, I also tried just using a three > wire connection (pins 2,3, and 7) ...all with no luck. > > The dual MP-S2 has been verified functional installed at IO slot 0 > and connected to a console. > > The config.txt file on the PC side is set for 9600 baud, the MP-S2 > is configured for 9600 baud (strapped). Debug is on in config.txt... > no messages are generated when I run netdrv.bin on the S/09. I've > tried both 'slow' and 'fast' configurations. NetPC initializes just fine > on the PC. > > Also, netdrv.txt was assembled on the S/09 itself using asmb.cmd. > No assembly errors were generated. > > I imagine that I'm missing something simple here ... any suggestions > would be most welcome. Thanks ... > > > Regards, > > Scott > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sun May 2 13:06:36 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sun, 2 May 2004 13:06:36 -0500 Subject: [sebhc] Emulator fix References: Message-ID: <001601c43070$360f4fa0$a301010a@gr390> Steven writes: > Mark says: > >The emulator was first complaining about write attempts to that address. > > It was probably setting up the word size, parity, etc. on the status port. > > >In the read code...both addresses would just return 0. > > The status port should probably always return TxRDY to prevent hanging in an > output routine. My mod returns that and TxE together to simulate an empty > buffer. > > >it didn't halt it but it didn't seem to do anything after that. > > I'm guessing this tape software does not support the 4-port serial card > (with the 8250's), which is apparently how the emulator handles the H19 > connection. That's what I meant by adding code to support simulation of the > terminal connected on the H8-5 serial port as well. This particular tape > software probably won't do anything interesting until that is set up. > Any chance the 8250 is a superset of the 8251 or close enough to pretend to be a 8250? It appears the current 8250, for the console, has 8 port (350-357), since the 8251 only has two address, 372 & 373. Can I create a second UART object and map the first port to 372 and the second port to 373? If I remember correctly the first port on the 8250 is the data port and the second is the status, and that appears to be what 372 and 373 is looking for. > >Making the changes you proposed > >below to the port read code didn't seem to change the end result > > It was only intended to keep the CPU from halting on input attempts from > other unsimulated ports. > > >I would really like to get the H17 supported, so I can try with disk images > >instead of tapes. > > That would be really cool. I might also consider working on that too, once > I can do a build. Looks like Dave Wallace was intending to add that - has > anyone been in touch with him recently? He hasn't answered email I sent him > weeks ago. > I just sent him email on Friday, and haven't heard anything yet. -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sun May 2 17:23:14 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sun, 2 May 2004 17:23:14 -0500 Subject: [sebhc] Emulator fix References: <001601c43070$360f4fa0$a301010a@gr390> Message-ID: <002601c43094$0ffbcdb0$a301010a@gr390> Latest update: I've tried several things: 1) defining a new UART. Duplicated almost all the code/places that the existing ' m_ConsoleUART' class has. Result -> I get output that has dropped many characters. I can still somewhat make out the words, but it appears the computer is writing the next charater before the UART sends out the first one. It doesn't seem to accept any characters. 2) Using the existing UART. I.e. mapping the addresses 372 ->350 and 373 -> 351. Result: First attempt didn't have the dropped characters on the output, but now is showing dropped characters like above. Not sure if it's a code change I made (I tried to get back to the original, but it's still dropping the characters). On pressing a key, the emulator makes a continuous repeating beep. Doesn't respond to the reset button or even the 'X' Windows close button. I have to get Windows task manager up and kill the task (and get the 'Application not responding' error dialog). This seems to be directly related to the Bus::SetInterruptRequests method. If the original ConsoleUART or my new 'CassConsoleUART' is initialized for a interrupt: m_bINT30 = m_ConsoleUART.InterruptSignal(); They both will cause the emulator to just beep and not respond to any other inputs. (Some text did continue to be displayed to the H19 but I couldn't decipher what it was writing.) And if I comment out that line using the original ConsoleUART all input appears to be ignored ( just like it behaved with using a new UART). I'll try some other combinations and see if I can get any more hints by using the Logic Analyzer. Mark ----- Original Message ----- From: "Mark Garlanger" To: Sent: Sunday, May 02, 2004 1:06 PM Subject: Re: [sebhc] Emulator fix > > Steven writes: > > > > Mark says: > > >The emulator was first complaining about write attempts to that address. > > > > It was probably setting up the word size, parity, etc. on the status port. > > > > >In the read code...both addresses would just return 0. > > > > The status port should probably always return TxRDY to prevent hanging in > an > > output routine. My mod returns that and TxE together to simulate an empty > > buffer. > > > > >it didn't halt it but it didn't seem to do anything after that. > > > > I'm guessing this tape software does not support the 4-port serial card > > (with the 8250's), which is apparently how the emulator handles the H19 > > connection. That's what I meant by adding code to support simulation of > the > > terminal connected on the H8-5 serial port as well. This particular tape > > software probably won't do anything interesting until that is set up. > > > > Any chance the 8250 is a superset of the 8251 or close enough to > pretend to be a 8250? > It appears the current 8250, for the console, has 8 port (350-357), > since the 8251 only has two address, 372 & 373. Can I create a second > UART object and map the first port to 372 and the second port to 373? > If I remember correctly the first port on the 8250 is the data port and the > second is the status, and that appears to be what 372 and 373 is looking > for. > > > > >Making the changes you proposed > > >below to the port read code didn't seem to change the end result > > > > It was only intended to keep the CPU from halting on input attempts from > > other unsimulated ports. > > > > >I would really like to get the H17 supported, so I can try with disk > images > > >instead of tapes. > > > > That would be really cool. I might also consider working on that too, > once > > I can do a build. Looks like Dave Wallace was intending to add that - has > > anyone been in touch with him recently? He hasn't answered email I sent > him > > weeks ago. > > > > I just sent him email on Friday, and haven't heard anything yet. > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Sun May 2 17:57:45 2004 From: patrick at vintagecomputermarketplace.com (Patrick) Date: Sun, 2 May 2004 15:57:45 -0700 Subject: [sebhc] Trying to get NetPC 3.4 running ... In-Reply-To: <008101c43063$baa704e0$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <000001c43098$e1d59650$200fa8c0@berkeley.evocative.com> > It would seem that there would be a way to take advantage of > the H8 simulation work that has been available for some time > to implement a NetPC capability for H8. Specifically, we should > be able to use a stripped down iteration of the simulator to handle > the disk image IO. Instead of having a full simulator that accepts > disk related commands from the console (and that has a full GUI), > it would accept disk related commands via the serial port (sent > from the H8 while booted in HDOS, or perhaps even CP/M). > > I know that Dwight and others have done some work in this > area ... any comments? Scott, I've been working on a parallel port version of this for my North Star Horizon (running CP/M 2.2) for some time. I haven't done anything with it for a couple of months, though... many other projects have distracted me. --Patrick -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 2 18:44:10 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 02 May 2004 23:44:10 +0000 Subject: [sebhc] Emulator Enhancements Message-ID: Is everyone enjoying this? Or should Mark and I take it offline? >1) defining a new UART. Duplicated almost all the code/places that >the existing ' m_ConsoleUART' class has. >Result -> I get output that has dropped many characters. I can still >....it appears the computer is writing >the next charater before the UART sends out the first one. Well, getting anything is a good sign. :-) But you'll need different code to simulate the 8251 of the H8-5. The 8250's currently being simulated for console I/O have different status values and initialization sequences. The tape uses an 8251 also, so looking at how that's handled might help, although it will be different enough that it can't just be copied. >2) Using the existing UART. I.e. mapping the addresses 372 ->350 >and 373 -> 351. >Result: ...now is showing dropped characters like above. Same problem: simulating the wrong type of chip. No telling what states are being unintentionally set up in the emulator by the tape s/w sending it setup params for a 8251. Although the emulator could certainly be "hardened" a bit so it could withstand simulated port abuse without itself crashing. >If the original ConsoleUART or my new 'CassConsoleUART' is >initialized for a interrupt:... >They both will cause the emulator to just beep and not respond to any >other inputs. Well, you certainly don't want to enable interrupts unless there's a functional interrupt service routine already installed. :-) Do we even know that this software uses interrupts? Maybe it just polls the port. >I'll try some other combinations and see if I can get any more hints by >using the Logic Analyzer. Oh yea? How do you use a logic analyzer on simulated virtual hardware? :-) Cheers, - Steven _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 2 22:04:26 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 2 May 2004 22:04:26 -0500 Subject: [sebhc] Emulator fix - 8251 data sheet In-Reply-To: <001601c43070$360f4fa0$a301010a@gr390> Message-ID: <000001c430bb$5853a1b0$1f6fa8c0@eths.k12.il.us> I just uploaded the 8251 data sheet to the archive in a documentation subdirectory called "8251". Versions of the Heath/Wintek software prior to xx.03.xx didn't know about the 4-port serial card so if the tape images you're trying to read were made or configured early enough, they will lack the ability to talk to an 8250 since the console driver routines for this chip were non-existant. Jack -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sun May 2 23:44:45 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sun, 2 May 2004 23:44:45 -0500 Subject: [sebhc] Emulator fix - 8251 data sheet References: <000001c430bb$5853a1b0$1f6fa8c0@eths.k12.il.us> Message-ID: <004f01c430c9$685299a0$a301010a@gr390> Thanks, I'll look it over tomorrow, btw, we have taken the conversion off the list to not flood the list. Also the file: Magnolia-CPM-Guide.pdf has wrong permissions. Does anyone have newer tape images that know how to talk to the 8250 UART? Mark ----- Original Message ----- From: "Jack Rubin" To: Sent: Sunday, May 02, 2004 10:04 PM Subject: RE: [sebhc] Emulator fix - 8251 data sheet > I just uploaded the 8251 data sheet to the archive in a documentation > subdirectory called "8251". > > Versions of the Heath/Wintek software prior to xx.03.xx didn't know > about the 4-port serial card so if the tape images you're trying to read > were made or configured early enough, they will lack the ability to talk > to an 8250 since the console driver routines for this chip were > non-existant. > > Jack > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 3 00:49:35 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 03 May 2004 05:49:35 +0000 Subject: [sebhc] RE: 8251 data sheet Message-ID: >I just uploaded the 8251 data sheet to the archive in a documentation >subdirectory called "8251". Cool. Plus we have the info in the H8-5 manual. Do you also happen to have a data sheet for the 8250? Maybe put it in the same place and rename the directory to "datasheets". >Versions of the Heath/Wintek software prior to xx.03.xx didn't know >about the 4-port serial card Yea, we pretty much figured that out. :-) Thus the project to add H8-5 style console I/O. _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 3 06:43:07 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 3 May 2004 06:43:07 -0500 Subject: [sebhc] Emulator fix - 8251 data sheet - definitely 'on topic' In-Reply-To: <004f01c430c9$685299a0$a301010a@gr390> Message-ID: <002401c43103$cdf78470$1f6fa8c0@eths.k12.il.us> Mark and Steve - This is definitely the sort of conversation that is of interest to many others. Dave's emulator is well known, but perhaps because of the lack of ROM images, I've never known of anyone actually running it. "Everyone" has used his documentation; it would be great if the emulator was available as well. I would recommend judicious trimming of traffic, but emulators, UARTs and USARTs are definitely of interest, as is the trouble-shooting process. Come on back! Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Mark Garlanger > Sent: Sunday, May 02, 2004 11:45 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] Emulator fix - 8251 data sheet > > > Thanks, I'll look it over tomorrow, btw, we have taken the > conversion off the list to not flood the list. Also the file: > Magnolia-CPM-Guide.pdf has wrong permissions. > > Does anyone have newer tape images that know how to talk to > the 8250 UART? > > Mark > > > ----- Original Message ----- > From: "Jack Rubin" > To: > Sent: Sunday, May 02, 2004 10:04 PM > Subject: RE: [sebhc] Emulator fix - 8251 data sheet > > > > I just uploaded the 8251 data sheet to the archive in a > documentation > > subdirectory called "8251". > > > > Versions of the Heath/Wintek software prior to xx.03.xx didn't know > > about the 4-port serial card so if the tape images you're trying to > > read were made or configured early enough, they will lack > the ability > > to talk to an 8250 since the console driver routines for this chip > > were non-existant. > > > > Jack > > > > -- > > Delivered by the SEBHC Mailing List > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 3 06:46:47 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 3 May 2004 06:46:47 -0500 Subject: [sebhc] RE: 8251 data sheet In-Reply-To: Message-ID: <002501c43104$50e21300$1f6fa8c0@eths.k12.il.us> the data sheet is from the H8-5 manual ;>) I'll scan the relevant 8250 info (from the H8-4 docs) and eventually get both manuals up there as well. > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Steven Parker > Sent: Monday, May 03, 2004 12:50 AM > To: sebhc at sebhc.org > Subject: [sebhc] RE: 8251 data sheet > > > >I just uploaded the 8251 data sheet to the archive in a > documentation > >subdirectory called "8251". > > Cool. Plus we have the info in the H8-5 manual. Do you also > happen to have > a data sheet for the 8250? Maybe put it in the same place > and rename the > directory to "datasheets". > > >Versions of the Heath/Wintek software prior to xx.03.xx didn't know > >about the 4-port serial card > > Yea, we pretty much figured that out. :-) Thus the project > to add H8-5 > style console I/O. > > _________________________________________________________________ > Stop worrying about overloading your inbox - get MSN Hotmail > Extra Storage! > http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/o nm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 3 11:18:13 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 3 May 2004 09:18:13 -0700 (PDT) Subject: [sebhc] Trying to get NetPC 3.4 running ... Message-ID: <200405031618.JAA22863@clulw009.amd.com> >From: "Scott LaBombard" > >Too many mailing lists ... too little time ... sorry folks. I posted >this to the wrong list ... Jack asked me to leave it for a couple >of reasons ...read on: > >I've been giving some thought as to the possibility of having >an equivalent to NetPC for the H8. For those of you who may >not know what NetPC is ... it essentially allows access from >a Swtp system to disk images that reside on a PC. The access >is done in such a way so as to make the images appear as real >disks to the Swtp (running Flex as the operating system). The >approach is implemented over a serial port ...a piece of code >runs on both ends of the connection. > >It would seem that there would be a way to take advantage of >the H8 simulation work that has been available for some time >to implement a NetPC capability for H8. Specifically, we should >be able to use a stripped down iteration of the simulator to handle >the disk image IO. Instead of having a full simulator that accepts >disk related commands from the console (and that has a full GUI), >it would accept disk related commands via the serial port (sent >from the H8 while booted in HDOS, or perhaps even CP/M). > >I know that Dwight and others have done some work in this >area ... any comments? > > >Scott > Hi I'm not at all familiar with the NetPC 3.4 methods. I do understand the concepts. For the most part, access to disk routines is through the jump tables but some software also look at some of the system variables to understand various disk status. The stuff I wrote was just specifically to transfer images and to allow one to bootstrap a machine without having anything other than a serial cable, blank disk and a PC. Still I don't believe that any of the applications talk directly to the 8250 or 179? chips used for disk interface. This means that almost any kind of software emulation could be done. Using the parallel port is always possible. I made my own parallel printer port for my H89 and added my own driver. The serial port is still the most common port used. It may not be the fastest but it is the most universally available. As for returning values from unknown ports, the value 0 it the least likely. For machines with Z80's one would expect one of two values to be returned. It would either be an echo of the port address for an unterminated bus or $0FF for most terminated or with standard TTL type receivers. Dwight >----- Original Message ----- >From: "Scott LaBombard" >To: >Sent: Sunday, May 02, 2004 12:01 PM >Subject: [sebhc] Trying to get NetPC 3.4 running ... > > >> Hi folks, >> >> As the subject indicates ... I've been attempting to get NetPC 3.4 up >> and running on a recently restored Swtp S/09 system. NetPC starts >> up and displays the 'NetPC driver version 3.4' banner ... and then it >> sits for a minute or so (presumably trying to connect) and then times >> out with 'Can't sync serial transfer!'. >> >> Here are the system specifics (intentionally verbose): >> >> * The S/09 has an MP-09A that is configured for extended addressing >> and SBUG 1.8. The system is currently configured to run at 1mhz. >> >> * Installed boards include the MP-ID board, an MP-S2 with only a >> single port installed on IO port 0 (console), an MP-S2 with both ports >> installed on IO port 1, and two MP-L2 dual port parallel boards >> installed on IO ports 2 and 3. In addition, there is a DMAF2 disk >> controller, connected to the Swtp dual 8" drive cabinet. For memory, >> it has the Swtp SMS3509 memory system (with the SMS3509C >> controller card, and one SMS3509A 128k memory array card). >> >> * The operating system is Swtp's flavor of Flex, version 2.7:3. >> >> * The PC side is a Thinkpad laptop with DOS 6.3 installed. I use >> this system as a 'console' (running term emulation) for most all of >> my vintage systems. I'm using a standard DB9-DB25 serial cable. >> >> I'm connecting the PC to the dual MP-S2 at IO port 1. I've >> modified acia.txt to use port A on the MP-S2: >> >> aciac equ $E010 >> aciad equ $E011 >> >> I've also tried $E014,$E015 with the PC connected to port B. I've >> also tried adding the 6850 uart initialization code to acia.txt (even >> though it is in netdrv.txt already). Last, I also tried just using a three >> wire connection (pins 2,3, and 7) ...all with no luck. >> >> The dual MP-S2 has been verified functional installed at IO slot 0 >> and connected to a console. >> >> The config.txt file on the PC side is set for 9600 baud, the MP-S2 >> is configured for 9600 baud (strapped). Debug is on in config.txt... >> no messages are generated when I run netdrv.bin on the S/09. I've >> tried both 'slow' and 'fast' configurations. NetPC initializes just fine >> on the PC. >> >> Also, netdrv.txt was assembled on the S/09 itself using asmb.cmd. >> No assembly errors were generated. >> >> I imagine that I'm missing something simple here ... any suggestions >> would be most welcome. Thanks ... >> >> >> Regards, >> >> Scott >> -- >> Delivered by the SEBHC Mailing List >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 3 22:37:55 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 3 May 2004 22:37:55 -0500 Subject: [sebhc] RE: 8251 data sheet In-Reply-To: Message-ID: <000101c43189$30680320$1f6fa8c0@eths.k12.il.us> Data sheets for the 8250 are included in the H8-4 serial card manual already in the archive. > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Steven Parker > Sent: Monday, May 03, 2004 12:50 AM > To: sebhc at sebhc.org > Subject: [sebhc] RE: 8251 data sheet > > > >I just uploaded the 8251 data sheet to the archive in a > documentation > >subdirectory called "8251". > > Cool. Plus we have the info in the H8-5 manual. Do you also > happen to have > a data sheet for the 8250? Maybe put it in the same place > and rename the > directory to "datasheets". > > >Versions of the Heath/Wintek software prior to xx.03.xx didn't know > >about the 4-port serial card > > Yea, we pretty much figured that out. :-) Thus the project > to add H8-5 > style console I/O. > > _________________________________________________________________ > Stop worrying about overloading your inbox - get MSN Hotmail > Extra Storage! > http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/o nm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 3 22:15:45 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 3 May 2004 22:15:45 -0500 Subject: [sebhc] new docs Message-ID: <000001c43186$1737ad40$1f6fa8c0@eths.k12.il.us> Manuals for H8-7 Breadboard (thanks to Wayne and Eric) and for GamePak #1 (8 games on cassette, including Hangman, Craps, NIM, Hexapawn, Tic-Tac-Toe, Orbit, Hamrabi and Derby. Carroll, do you have images for the rest of these? Jack -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Mon May 3 23:35:31 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Mon, 3 May 2004 23:35:31 -0500 Subject: [sebhc] new docs References: <000001c43186$1737ad40$1f6fa8c0@eths.k12.il.us> Message-ID: <007c01c43191$3e0e73d0$a301010a@gr390> Thanks for posting the new docs, but it appears the the Magnolia-CPM-Guide.pdf still has the wrong permissions (you may have not noticed this comment in the previous email). I also have found following PDFs: a.. h8_sio.pdf that is the manual for the H8-5, b.. h8_4k.pdf which is for the H8-1 - 4K Static Memory c.. h8_asm - H8 Assembly and d.. h8_opr.pdf - H8 Operation I'm not sure where I downloaded these from, thought it was your site, but it doesn't look like it. Let me know if you want me to upload them and what naming convention you would like or if you want to rename them. Mark ----- Original Message ----- From: "Jack Rubin" To: "SEBHC" Sent: Monday, May 03, 2004 10:15 PM Subject: [sebhc] new docs > Manuals for H8-7 Breadboard (thanks to Wayne and Eric) and for GamePak > #1 (8 games on cassette, including Hangman, Craps, NIM, Hexapawn, > Tic-Tac-Toe, Orbit, Hamrabi and Derby. > > Carroll, do you have images for the rest of these? > > Jack > > -- > Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Tue May 4 07:41:05 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Tue, 04 May 2004 08:41:05 -0400 Subject: [sebhc] new docs In-Reply-To: <000001c43186$1737ad40$1f6fa8c0@eths.k12.il.us> References: <000001c43186$1737ad40$1f6fa8c0@eths.k12.il.us> Message-ID: <40978F61.60807@sc.rr.com> Unfortunately, the only game image I could find was hangman. CEW Jack Rubin wrote: >Manuals for H8-7 Breadboard (thanks to Wayne and Eric) and for GamePak >#1 (8 games on cassette, including Hangman, Craps, NIM, Hexapawn, >Tic-Tac-Toe, Orbit, Hamrabi and Derby. > >Carroll, do you have images for the rest of these? > >Jack > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Tue May 4 18:00:34 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Tue, 4 May 2004 19:00:34 -0400 Subject: [sebhc] H8 game files uploaded Message-ID: <009401c4322b$9bd84140$02a8a8c0@IBMD9HY10WBGXB> Hi folks, I've just uploaded NIM, Hexapawn, Craps, and Hangman for the H8 in Intel Hex format. All load to 2040h ... Regards, Scott -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 4 18:24:36 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 4 May 2004 18:24:36 -0500 Subject: [sebhc] H8 game files uploaded In-Reply-To: <009401c4322b$9bd84140$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> And I've just put them in software directory called 'games' Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Scott LaBombard > Sent: Tuesday, May 04, 2004 6:01 PM > To: sebhc at sebhc.org > Subject: [sebhc] H8 game files uploaded > > > Hi folks, > > I've just uploaded NIM, Hexapawn, Craps, and Hangman for the > H8 in Intel Hex format. All load to 2040h ... > > > Regards, > > Scott > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Wed May 5 01:16:29 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Wed, 5 May 2004 01:16:29 -0500 Subject: [sebhc] H8 game files uploaded References: <009401c4322b$9bd84140$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <00cb01c43268$812d8c50$a301010a@gr390> So for those of us with little to no H8 experience... Can these be loaded on the emulator? If so, how? Mark ----- Original Message ----- From: "Scott LaBombard" To: Sent: Tuesday, May 04, 2004 6:00 PM Subject: [sebhc] H8 game files uploaded > Hi folks, > > I've just uploaded NIM, Hexapawn, Craps, and Hangman for the H8 > in Intel Hex format. All load to 2040h ... > > > Regards, > > Scott > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From eric at rothfus.com Wed May 5 10:47:39 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Wed, 5 May 2004 11:47:39 -0400 Subject: [sebhc] H8 game files uploaded In-Reply-To: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> (jack.rubin@ameritech.net) References: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> Message-ID: <1083769939@rothfus.com> Could someone possibly convert these HEX files to binaries that can be loaded as if they were executable command files from a floppy? Or maybe provide me a pointer on how to do this? I imagine it's as simple as composing the right header and converting the HEX to binary... Eric PS - I want to play NIM on my H8 :-). Also, gives me a good test of the "file" download capability of the SVD... -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Wed May 5 11:01:03 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Wed, 5 May 2004 12:01:03 -0400 Subject: [sebhc] H8 game files uploaded References: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> <1083769939@rothfus.com> Message-ID: <001e01c432ba$2c0b4b20$02a8a8c0@IBMD9HY10WBGXB> Eric ... I can eaqsily convert these to straight binary files ... not sure if that will help though. I am not familiar with the operation of the H8 emulator ... is there an ability within the emulator to load binaries directly to the H8's memory image (ie. in the case of the game files, specifying the load address for the binary as 2040h)? Alternatively, is there an IP console interface ala simh or Altair32 (both of which I have extensive experience with) on the H8 emulator? This would allow using a term emulator as the 'console' and thus allow uploading hex files to the H8's memory image ... Scott ----- Original Message ----- From: "Eric J. Rothfus" To: Sent: Wednesday, May 05, 2004 11:47 AM Subject: Re: [sebhc] H8 game files uploaded > Could someone possibly convert these HEX files to binaries > that can be loaded as if they were executable command files > from a floppy? Or maybe provide me a pointer on how to do > this? I imagine it's as simple as composing the right header > and converting the HEX to binary... > > Eric > > PS - I want to play NIM on my H8 :-). Also, gives me a good > test of the "file" download capability of the SVD... > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Wed May 5 11:09:46 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Wed, 5 May 2004 12:09:46 -0400 Subject: [sebhc] H8 game files uploaded References: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> <1083769939@rothfus.com> <001e01c432ba$2c0b4b20$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <003501c432bb$62eae190$02a8a8c0@IBMD9HY10WBGXB> Just in case ... I just uploaded the binary iterations of the subject files ... Scott ----- Original Message ----- From: "Scott LaBombard" To: Sent: Wednesday, May 05, 2004 12:01 PM Subject: Re: [sebhc] H8 game files uploaded > Eric ... > > I can eaqsily convert these to straight binary files ... not sure if that will help > though. I am not familiar with the operation of the H8 emulator ... is there an > ability within the emulator to load binaries directly to the H8's memory image > (ie. in the case of the game files, specifying the load address for the binary as > 2040h)? > > Alternatively, is there an IP console interface ala simh or Altair32 (both of > which I have extensive experience with) on the H8 emulator? This would > allow using a term emulator as the 'console' and thus allow uploading hex > files to the H8's memory image ... > > Scott > > ----- Original Message ----- > From: "Eric J. Rothfus" > To: > Sent: Wednesday, May 05, 2004 11:47 AM > Subject: Re: [sebhc] H8 game files uploaded > > > > Could someone possibly convert these HEX files to binaries > > that can be loaded as if they were executable command files > > from a floppy? Or maybe provide me a pointer on how to do > > this? I imagine it's as simple as composing the right header > > and converting the HEX to binary... > > > > Eric > > > > PS - I want to play NIM on my H8 :-). Also, gives me a good > > test of the "file" download capability of the SVD... > > > > -- > > Delivered by the SEBHC Mailing List > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From eric at rothfus.com Wed May 5 13:28:57 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Wed, 5 May 2004 14:28:57 -0400 Subject: [sebhc] H8 game files uploaded In-Reply-To: <003501c432bb$62eae190$02a8a8c0@IBMD9HY10WBGXB> (labomb@rochester.rr.com) References: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> <1083769939@rothfus.com> <001e01c432ba$2c0b4b20$02a8a8c0@IBMD9HY10WBGXB> <003501c432bb$62eae190$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <1083772565@rothfus.com> Thanks Scott. The issue I was most interested in was getting the files into a form that can execute right off of a floppy in HDOS or CP/M. In other words, the monitor program (in either CP/M or HDOS) would know how to load the file into the appropriate location (apparently 2040h) and kick it off. I've seen the formats for executables, but don't remember them or even where I've seen them. Maybe, however, I'm over-engineering-thinking the problem, and simple binary files will load and execute just fine without a specialized format in HDOS. Though I'm fairly sure that something more interesting is necessary in CP/M. Regarding how I use the files - I've built a little box that emulates a physical floppy drive for the H8/89 (as well as a few others). You download a floppy image from the PC and then boot/read it on the H8/89. One of the nice things about the PC software is that you can download a single program and it will be wrapped in a floppy image so you can run it. That's what I want to do with the posted game images. (for more info see www.theSVD.com) Eric -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Wed May 5 14:06:32 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Wed, 5 May 2004 15:06:32 -0400 Subject: [sebhc] H8 game files uploaded References: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> <1083769939@rothfus.com> <001e01c432ba$2c0b4b20$02a8a8c0@IBMD9HY10WBGXB> <003501c432bb$62eae190$02a8a8c0@IBMD9HY10WBGXB> <1083772565@rothfus.com> Message-ID: <005301c432d4$1415e010$02a8a8c0@IBMD9HY10WBGXB> Actually, the format needed (under HDOS) is the 'Absolute Binary Format'. Apparently, this is the a Heathkit specification that includes information relating to where a given binary should be loaded (perhaps among other things ...such as a checksum mechanism). You'll note the .abs file extension under HDOS. I've checked the HDOS docs that I have and I see no reference to the format details. If anyone has such a reference, I'd be interested in seeing them. I'm quite confident that I can write a quick utility to generate the appropriate format using either raw binary or Intel hex as the input source. In terms of cp/m ... a simple Intel-Hex file loader would do the trick. As per my previous post, you would need a serial port and a terminal emulator to facilitate the upload (or on the emulator, and IP accessible 'console'). I use this method extensively on most all of my vintage platforms. Scott ----- Original Message ----- From: "Eric J. Rothfus" To: Sent: Wednesday, May 05, 2004 2:28 PM Subject: Re: [sebhc] H8 game files uploaded > Thanks Scott. The issue I was most interested in was > getting the files into a form that can execute right off > of a floppy in HDOS or CP/M. In other words, the monitor > program (in either CP/M or HDOS) would know how to load > the file into the appropriate location (apparently 2040h) > and kick it off. > > I've seen the formats for executables, but don't remember > them or even where I've seen them. Maybe, however, I'm > over-engineering-thinking the problem, and simple binary > files will load and execute just fine without a specialized > format in HDOS. Though I'm fairly sure that something more > interesting is necessary in CP/M. > > Regarding how I use the files - I've built a little box > that emulates a physical floppy drive for the H8/89 (as > well as a few others). You download a floppy image from > the PC and then boot/read it on the H8/89. One of the > nice things about the PC software is that you can download > a single program and it will be wrapped in a floppy image > so you can run it. That's what I want to do with the > posted game images. (for more info see www.theSVD.com) > > Eric > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Wed May 5 14:33:06 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Wed, 5 May 2004 15:33:06 -0400 Subject: [sebhc] H8 game files uploaded References: <000001c4322e$f7505d20$1f6fa8c0@eths.k12.il.us> <1083769939@rothfus.com> <001e01c432ba$2c0b4b20$02a8a8c0@IBMD9HY10WBGXB> <003501c432bb$62eae190$02a8a8c0@IBMD9HY10WBGXB> <1083772565@rothfus.com> <005301c432d4$1415e010$02a8a8c0@IBMD9HY10WBGXB> Message-ID: <005901c432d7$cac1ea40$02a8a8c0@IBMD9HY10WBGXB> A couple more comments regarding running these games within the cp/m environment ... Once the I-hex files are on the disk image, you can use cp/m's debug command to load and subsequently execute them. A word of caution (and likely applicable under HDOS as well) ...remember that these games were distributed on cassette and assumed no operating system. As such, they access the H8's hardware directly (IO specifically). It's usually not a good idea to run such programs under cp/m ...utilizing standard bdos calls is, for the most part, a safer bet. But in the case of these simple programs, I doubt that it will matter... Scott ----- Original Message ----- From: "Scott LaBombard" To: Sent: Wednesday, May 05, 2004 3:06 PM Subject: Re: [sebhc] H8 game files uploaded > Actually, the format needed (under HDOS) is the 'Absolute Binary Format'. > Apparently, this is the a Heathkit specification that includes information > relating to where a given binary should be loaded (perhaps among other > things ...such as a checksum mechanism). You'll note the .abs file > extension under HDOS. > > I've checked the HDOS docs that I have and I see no reference to the > format details. If anyone has such a reference, I'd be interested in seeing > them. I'm quite confident that I can write a quick utility to generate the > appropriate format using either raw binary or Intel hex as the input source. > > In terms of cp/m ... a simple Intel-Hex file loader would do the trick. As > per my previous post, you would need a serial port and a terminal emulator > to facilitate the upload (or on the emulator, and IP accessible 'console'). I > use this method extensively on most all of my vintage platforms. > > > Scott > > ----- Original Message ----- > From: "Eric J. Rothfus" > To: > Sent: Wednesday, May 05, 2004 2:28 PM > Subject: Re: [sebhc] H8 game files uploaded > > > > Thanks Scott. The issue I was most interested in was > > getting the files into a form that can execute right off > > of a floppy in HDOS or CP/M. In other words, the monitor > > program (in either CP/M or HDOS) would know how to load > > the file into the appropriate location (apparently 2040h) > > and kick it off. > > > > I've seen the formats for executables, but don't remember > > them or even where I've seen them. Maybe, however, I'm > > over-engineering-thinking the problem, and simple binary > > files will load and execute just fine without a specialized > > format in HDOS. Though I'm fairly sure that something more > > interesting is necessary in CP/M. > > > > Regarding how I use the files - I've built a little box > > that emulates a physical floppy drive for the H8/89 (as > > well as a few others). You download a floppy image from > > the PC and then boot/read it on the H8/89. One of the > > nice things about the PC software is that you can download > > a single program and it will be wrapped in a floppy image > > so you can run it. That's what I want to do with the > > posted game images. (for more info see www.theSVD.com) > > > > Eric > > > > -- > > Delivered by the SEBHC Mailing List > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed May 5 19:56:52 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 5 May 2004 17:56:52 -0700 (PDT) Subject: [sebhc] logging into the archive Message-ID: <200405060056.RAA26530@clulw009.amd.com> Hi I'm having a pain trying to log in to the archive. Most of the ftp programs I have are blocked by the firewall. I could do it from a browser but I don't know how to stop the auto loggin. Can anyone help here? I'm on both UNIX and Linux. Thanks Dwight -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Wed May 5 20:17:00 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Wed, 5 May 2004 18:17:00 -0700 Subject: [sebhc] logging into the archive In-Reply-To: <200405060056.RAA26530@clulw009.amd.com> Message-ID: <005801c43307$d53aba80$f300a8c0@berkeley.evocative.com> Dwight, have you tried enabling passive mode in your FTP client? --Patrick > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dwight K. Elvey > Sent: Wednesday, May 05, 2004 5:57 PM > To: sebhc at sebhc.org > Subject: [sebhc] logging into the archive > > > Hi > I'm having a pain trying to log in to the archive. > Most of the ftp programs I have are blocked by the > firewall. I could do it from a browser but I don't > know how to stop the auto loggin. Can anyone help > here? I'm on both UNIX and Linux. > Thanks > Dwight > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From robert at ameritech.net Wed May 5 20:37:52 2004 From: robert at ameritech.net (His Excellency, Robert) Date: Wed, 05 May 2004 21:37:52 -0400 Subject: [sebhc] logging into the archive In-Reply-To: <200405060056.RAA26530@clulw009.amd.com> References: <200405060056.RAA26530@clulw009.amd.com> Message-ID: <409996F0.3040906@ameritech.net> Hi Dwight, Your in a pickle! I'm assuming the "firewall" is on your end/side of the network/internet? What some FW admins will do for "special" people, is to create an account on the firewall box, allow you to telnet to the firewall, login (restricted), and ftp from the firewall to the outside world. The files are then ftp'd to the firewall, and then re-ftp'd to your "inside" client destination. Sending files out to the archive, would be just the reverse, ftp'd from client to firewall, then again from firewall to the archive. Not elegant by any means, but it works! You might be able to bribe your FW Admin with a WM Shatner Autograph, chocolate, or get him/her interested in sebhc! Just Bob! Dwight K. Elvey wrote: >Hi > I'm having a pain trying to log in to the archive. >Most of the ftp programs I have are blocked by the >firewall. I could do it from a browser but I don't >know how to stop the auto loggin. Can anyone help >here? I'm on both UNIX and Linux. >Thanks >Dwight > > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed May 5 23:08:06 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 06 May 2004 04:08:06 +0000 Subject: [sebhc] using the game files Message-ID: Eric was interested in getting files into a form that you could execute off a floppy. HUG distributed a suite of programs I wrote for HDOS to load in tapes, store them in files, and then run them later. I remember calling the file format "TMI" (for Tape Memory Image). As Scott pointed out, it's "rude" to do hardware I/O under an operating system .. my run program took care of that by completely restoring the state of a pristinely-loaded tape before executing it (making it as if HDOS was never there). Does anyone have that package? The hex dumps (and raw binaries) of these games do not contain the initial PC value that is normally stored on tape. Luckily, all the original Heath stuff starts executing at the load point, 040.100 (0x2040). Mark wanted to try these on the emulator .. to simplify that I converted them to the .PID (AKA .tape) format the emulator uses. I uploaded those to the ftp area. By the way .. does anything besides the emulator use that format? These are the software issue versions of those games (note that H8HANGM.xxx is the same software product as the HANGMAN.PID previously posted): HANGMAN ISSUE # 20.00.00. CRAPS ISSUE # 21.00.00. NIM ISSUE # 22.00.00. HEXAPAWN ISSUE # 23.00.00. And Scott - I'll have to dig around a bit, but I know I have the .ABS format somewhere. _________________________________________________________________ Getting married? Find tips, tools and the latest trends at MSN Life Events. http://lifeevents.msn.com/category.aspx?cid=married -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 6 07:49:28 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 6 May 2004 07:49:28 -0500 Subject: [sebhc] H8 data record format Message-ID: <000001c43368$9245a670$1f6fa8c0@eths.k12.il.us> I've excerpted the pages describing the H8 data record format from the Software Reference Manual (SRM) into a 72K download. It's at /docs/h8-sware/data-rcd.pdf Jack -- Delivered by the SEBHC Mailing List From RONALD.S.WEST at saic.com Thu May 6 09:36:39 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Thu, 6 May 2004 10:36:39 -0400 Subject: [sebhc] logging into the archive Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C04@mcl-its-exs03.mail.saic.com> Dwight, Try downloading WS_FTP from ipswitch.com. It will allow you to install it for a 30 day trial period. That will make viewing/getting the files easier (graphical) but if the firewall is blocking the FTP ports there is nothing you can do unless the sebhc folks can put set their site up to use HTTP (port 80). Ron -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of His Excellency, Robert Sent: Wednesday, May 05, 2004 9:38 PM To: sebhc at sebhc.org Subject: Re: [sebhc] logging into the archive Hi Dwight, Your in a pickle! I'm assuming the "firewall" is on your end/side of the network/internet? What some FW admins will do for "special" people, is to create an account on the firewall box, allow you to telnet to the firewall, login (restricted), and ftp from the firewall to the outside world. The files are then ftp'd to the firewall, and then re-ftp'd to your "inside" client destination. Sending files out to the archive, would be just the reverse, ftp'd from client to firewall, then again from firewall to the archive. Not elegant by any means, but it works! You might be able to bribe your FW Admin with a WM Shatner Autograph, chocolate, or get him/her interested in sebhc! Just Bob! Dwight K. Elvey wrote: >Hi > I'm having a pain trying to log in to the archive. >Most of the ftp programs I have are blocked by the >firewall. I could do it from a browser but I don't >know how to stop the auto loggin. Can anyone help >here? I'm on both UNIX and Linux. >Thanks >Dwight > > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu May 6 11:38:07 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Thu, 6 May 2004 09:38:07 -0700 Subject: [sebhc] logging into the archive In-Reply-To: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C04@mcl-its-exs03.mail.saic.com> Message-ID: <001001c43388$8297ece0$f300a8c0@berkeley.evocative.com> > there is nothing you can do unless the sebhc folks can put > set their site up to use HTTP (port 80). http://www.sebhc.org/archive Same username and password as FTP... Patrick :-) -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 6 11:45:47 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 6 May 2004 09:45:47 -0700 (PDT) Subject: [sebhc] logging into the archive Message-ID: <200405061645.JAA27149@clulw009.amd.com> Hi Patrick That works fine. Thanks. Dwight >From: "Patrick Rigney" > >> there is nothing you can do unless the sebhc folks can put >> set their site up to use HTTP (port 80). > >http://www.sebhc.org/archive > >Same username and password as FTP... > >Patrick :-) > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Thu May 6 12:57:58 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Thu, 6 May 2004 13:57:58 -0400 Subject: [sebhc] H8 data record format References: <000001c43368$9245a670$1f6fa8c0@eths.k12.il.us> Message-ID: <005e01c43393$c700e430$02a8a8c0@IBMD9HY10WBGXB> Hmmm ... I'm not clear if/how the 'Tape Format' described is related the 'Absolute Binary Format'. Anyone know? Scott ----- Original Message ----- From: "Jack Rubin" To: "SEBHC" Sent: Thursday, May 06, 2004 8:49 AM Subject: [sebhc] H8 data record format > I've excerpted the pages describing the H8 data record format from the > Software Reference Manual (SRM) into a 72K download. It's at > /docs/h8-sware/data-rcd.pdf > > Jack > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From RONALD.S.WEST at saic.com Thu May 6 13:48:12 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Thu, 6 May 2004 14:48:12 -0400 Subject: [sebhc] RGT question for Pat Swayne Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C07@mcl-its-exs03.mail.saic.com> This is a question for Pat Swayne or anyone else who was involved in HDOS software development. I am working on a device driver for an IDE port for the H8. I think its the GRT (Group Reservation Table) that is written to a floppy when it is initialized that essentially limits the number of groups of sectors and thus files to 200. Does anyone know if HDOS used multiple GRT's when a drive was large (such as the H67 winchester disk)? Also, am I correct that HDOS itself appears to address sectors individually using a two byte value. If that is the case the system would be limited to 65,535 sectors. With 256 byte sectors the drive size could (theoretically) be 65,535 x 256 = 16,776,960 bytes. With 512 byte sectors we should get twice that amount. Pretty good, actually, at 32mb! Thanks, Ron -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 6 15:19:24 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 6 May 2004 15:19:24 -0500 Subject: [sebhc] archives Message-ID: <000001c433a7$6cfbc1d0$1f6fa8c0@eths.k12.il.us> The sebhc archives are available: via ftp at archive.sebhc.org via http at www.sebhc.org/archive username - heathkit password - hdos8bit Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Thu May 6 15:27:46 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 06 May 2004 20:27:46 +0000 Subject: [sebhc] Re: H8 data record format Message-ID: Scott asks: >Hmmm ... I'm not clear if/how the 'Tape Format' described is related the >'Absolute Binary Format'. Anyone know? Sure thing. The .PID (AKA .tape) format contains all the bytes that would be written to a tape in a dump operation. This makes it ideal for emulation. In the case of a PAM-8 dump this would be: bytes contents 32 SYN chars (0x16) 1 STX char (0x02) 1 record type / end flag 1 block sequence number 2 byte count (of data) 2 execute address 2 load address (cnt) data bytes 2 checksum 2 extra bytes to flush buffer (actually a 2nd copy of checksum) (the above may be repeated for multiple-block files) The .BIN binary format is just the data bytes. Since the execute and load address are missing, and there's no way to represent non-contiguous multiple blocks, it is therefore not as well suited for storing tape software. Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 6 15:25:01 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 6 May 2004 15:25:01 -0500 Subject: [sebhc] IDE interface? - was RGT question for Pat Swayne In-Reply-To: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C07@mcl-its-exs03.mail.saic.com> Message-ID: <000101c433a8$360005f0$1f6fa8c0@eths.k12.il.us> Ron, Please tell us more - I'm sure there would be great interest in such a project among the group. Both Pat and Dean Gibson (who is not a list member) have released their code to us, though neither can supply source at this point. Hopefully, Pat will be able to at some point in the future, but in the meanwhile, if anyone has source or disassemblies of the HUG SY: driver or similar material, please upload it to the archive! I know that Ward Christiansen's RESOURCE disassembler was modified for HDOS - anyone have a copy? Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > West, Ronald S. > Sent: Thursday, May 06, 2004 1:48 PM > To: 'sebhc at sebhc.org' > Subject: [sebhc] RGT question for Pat Swayne > > > This is a question for Pat Swayne or anyone else who was > involved in HDOS software development. > > I am working on a device driver for an IDE port for the H8. I > think its the GRT (Group Reservation Table) that is written > to a floppy when it is initialized that essentially limits > the number of groups of sectors and thus files to 200. Does > anyone know if HDOS used multiple GRT's when a drive was > large (such as the H67 winchester disk)? > > Also, am I correct that HDOS itself appears to address > sectors individually using a two byte value. If that is the > case the system would be limited to 65,535 sectors. With 256 > byte sectors the drive size could (theoretically) be 65,535 x > 256 = 16,776,960 bytes. With 512 byte sectors we should get > twice that amount. Pretty good, actually, at 32mb! > > Thanks, > > Ron > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Thu May 6 16:07:08 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Thu, 6 May 2004 17:07:08 -0400 Subject: [sebhc] Re: H8 data record format References: Message-ID: <008801c433ae$17ed4bd0$02a8a8c0@IBMD9HY10WBGXB> Thanks Steven. I understand the difference between the tape format raw binary ... I think what I am am most interested in at this point is if/how the tape format is different from the ABS format used for executables within HDOS. Thx again ... Scott ----- Original Message ----- From: "Steven Parker" To: Sent: Thursday, May 06, 2004 4:27 PM Subject: [sebhc] Re: H8 data record format > Scott asks: > >Hmmm ... I'm not clear if/how the 'Tape Format' described is related the > >'Absolute Binary Format'. Anyone know? > > Sure thing. The .PID (AKA .tape) format contains all the bytes that would > be written to a tape in a dump operation. This makes it ideal for > emulation. In the case of a PAM-8 dump this would be: > > bytes contents > > 32 SYN chars (0x16) > 1 STX char (0x02) > 1 record type / end flag > 1 block sequence number > 2 byte count (of data) > 2 execute address > 2 load address > (cnt) data bytes > 2 checksum > 2 extra bytes to flush buffer (actually a 2nd copy of > checksum) > > (the above may be repeated for multiple-block files) > > The .BIN binary format is just the data bytes. Since the execute and load > address are missing, and there's no way to represent non-contiguous multiple > blocks, it is therefore not as well suited for storing tape software. > > Cheers, > > - Steven > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.com/go/onm00200415ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Thu May 6 19:11:28 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 07 May 2004 00:11:28 +0000 Subject: [sebhc] Re: H8 data record format Message-ID: Scott asks: >... I think what I am am most interested in at this point is >if/how the tape format is different from the ABS format used for >executables within HDOS. The .ABS format is simpler and has no framing (SYN, CRC, etc). It does have entry and load addresses so it could potentially be used to store single-block tape files (PAM-8 dumps are all single-block). But remember if you store it this way and load it under HDOS, the software and HDOS could compete for I/O and interrupts. That's what the TMI format and loader was designed to handle (HUG product number 885-1061 .. anyone got that?). Here's the .ABS format: bytes contents 1 file type prefix (0xFF) 1 file type (0x00) 2 load address 2 byte count * 2 entry point (*) data bytes * = I would expect the count to be just data, but I've seen it mentioned in listings as "length of entire record" - a quick check of an existing .ABS file should settle it, but I don't have my gear set up yet. Speaking of setting up old gear, I plugged in one of my H-8's yesterday and got a pop, spark, and puff of smoke from the CPU. I think it's one of the little blue capactors - there's a slight discoloration near one now (but oddly the part itself has no visible damage). Anyone have experience reviving old gear? Mine's been boxed for over a decade. Any precautions I should take before I try to power up another unit? Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu May 6 21:32:38 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Thu, 6 May 2004 19:32:38 -0700 Subject: [sebhc] Re: H8 data record format In-Reply-To: Message-ID: <00a001c433db$90408b60$f300a8c0@berkeley.evocative.com> > got a pop, spark, and puff of smoke from the CPU. I think > it's one of the > little blue capactors > [snip] > Anyone have experience reviving old gear? Mine's been boxed > for over a > decade. Any precautions I should take before I try to power > up another > unit? My offerings: 1) Have a generous supply of bypass caps on hand, because you WILL (do) need them. 2) Don't lean over the machine when applying power. Big caps fail too. 3) Have another way to cut power quickly, in case you're not comfortable reaching across flaming innards to get to a rear-mounted power switch. 4) Remove boards and test the power supply separately before applying power with boards in. You can also spot check each board for shorts while they're out, which isn't totally deterministic since some shorts can/will occur when power is first applied and the part dies at that moment. With S-100 stuff I've been using a bench supply with adjustable current limiting to power test boards... better than throwing the weight of a chassis' high-current supply into a shorted board. You just get an over-current light rather than letting the magic smoke out. In a few cases I've also been able to find bad parts quickly this way, just by setting the current limit low--0.5 amp or so can warm up a shorted part enough to find it with a fingertip, but not do any damage to the board. 5) A little eye protection never hurts, because you never know what direction or distance those little bits are going to go. Your experience is how two of my H-89's came to be dubbed Sparky and Smokey. I have another called Shell. ;-) Patrick -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 6 21:54:52 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 6 May 2004 21:54:52 -0500 Subject: [sebhc] waking up old computers In-Reply-To: <00a001c433db$90408b60$f300a8c0@berkeley.evocative.com> Message-ID: <000201c433de$abc72d50$1f6fa8c0@eths.k12.il.us> plus: 1) eyeball the electrolytic caps for swelling/leakage; an ESR meter is a nice thing to have 2) use a Variac to bring up the power supply (assuming it's a vintage linear and not a switcher) take a look at http://www.repairfaq.org/REPAIR/ - see especially the sections on capacitor and semiconductor testing, as well as flyback transformers > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Patrick Rigney > Sent: Thursday, May 06, 2004 9:33 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] Re: H8 data record format > > > > got a pop, spark, and puff of smoke from the CPU. I think > > it's one of the > > little blue capactors > > [snip] > > Anyone have experience reviving old gear? Mine's been boxed > > for over a > > decade. Any precautions I should take before I try to power > > up another > > unit? > > My offerings: > > 1) Have a generous supply of bypass caps on hand, because you > WILL (do) need them. > > 2) Don't lean over the machine when applying power. Big caps > fail too. > > 3) Have another way to cut power quickly, in case you're not > comfortable reaching across flaming innards to get to a > rear-mounted power switch. > > 4) Remove boards and test the power supply separately before > applying power with boards in. You can also spot check each > board for shorts while they're out, which isn't totally > deterministic since some shorts can/will occur when power is > first applied and the part dies at that moment. With S-100 > stuff I've been using a bench supply with adjustable current > limiting to power test boards... better than throwing the > weight of a chassis' high-current supply into a shorted > board. You just get an over-current light rather than > letting the magic smoke out. In a few cases I've also been > able to find bad parts quickly this way, just by setting the > current limit low--0.5 amp or so can warm up a shorted part > enough to find it with a fingertip, but not do any damage to > the board. > > 5) A little eye protection never hurts, because you never > know what direction or distance those little bits are going to go. > > Your experience is how two of my H-89's came to be dubbed > Sparky and Smokey. I have another called Shell. ;-) > > Patrick > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 6 23:09:41 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 6 May 2004 23:09:41 -0500 Subject: [sebhc] anybody going to Dayton Message-ID: <000301c433e9$1fb83920$1f6fa8c0@eths.k12.il.us> Hamfest next weekend? Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Fri May 7 05:18:31 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 7 May 2004 03:18:31 -0700 (PDT) Subject: [sebhc] Re: H8 data record format Message-ID: <200405071018.i47AIUKj046388@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 7 May 2004 10:33:39 -0000 >> Anyone have experience reviving old gear? Mine's been boxed >> for over a decade. Any precautions I should take before I try to power >> up another unit? #1 - Wear eye protection. This is VERY IMPORTANT. I've had a power supply cap short, causing a regulator to explode which buried part of the casing in the wall!!! - Visual inspection, especially look for leaking, deformed or discolored capacitors. - Test power supply alone first. Remove all logic boards or disconnect the power supply DC leads. Switchers may require a small load to operate correctly. - Current limit the supply. For small linear supplies, running through a 100w light bulb initially is a good idea. This works ok for small switchers too, but be careful that the supply operates correctly on reduced voltage. - Use a variac to bring the supply voltage up SLOWLY - for very old long-out of service equipment, take a good long time, allowing the capacitors to reform. Don't do this for switchers or if the power supply is not completely disconnected from the rest of the system. Monitor the output as you do this and confirm that it is coming up as expected. Monitor voltage and waveform across filter caps to insure that they are not shorted or open. - Check power supply voltages. - Power the logic boards one at a time - If the system is small enough, continue to use the 100w light bulb in the AC power loop - use fuses on the DC side (you will have to estimate power requirements for the boards). ** WEAR EYE PROTECTION ** Regards, -- 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 jack.rubin at ameritech.net Fri May 7 07:02:49 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 7 May 2004 07:02:49 -0500 Subject: [sebhc] New Media Order In-Reply-To: <408C4A88.6C44@earthlink.net> Message-ID: <001701c4342b$38198090$1f6fa8c0@eths.k12.il.us> Lee, Several of us have PAL burners - would you mind uploading the program files? Thanks. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Lee Hart > Sent: Sunday, April 25, 2004 6:32 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] New Media Order > > > Patrick wrote: > > > > > I still have blank Z89-37 soft-sector boards, and most of > the parts > > > to build them, if you're "up" for building one as a kit. > > > > Lee, that reminds me... I have one of your blanks, but I > need the PROM > > that goes on it (forgot the number). Can I purchase from you? > > No PROMs, but there are two PALs on the Z89-37 board. Heath > part# 444-81 and 444-82. I have a couple left of each. Heath > also gave the programming of them, so someone with a PAL > programmer can make them. Unfortunately, I don't have one. > -- > "Never doubt that a small group of committed people can > change the world. Indeed, it's the only thing that ever has!" > -- Margaret Meade > -- > Lee A. Hart 814 8th Ave N Sartell MN 56377 > leeahart_at_earthlink.net > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From RONALD.S.WEST at saic.com Fri May 7 08:37:14 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Fri, 7 May 2004 09:37:14 -0400 Subject: [sebhc] New Media Order Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C0A@mcl-its-exs03.mail.saic.com> > No PROMs, but there are two PALs on the Z89-37 board. Heath > part# 444-81 and 444-82. I have a couple left of each. Heath > also gave the programming of them, so someone with a PAL > programmer can make them. Unfortunately, I don't have one. That would be another thing we should have on the SEBHC archive site. Can you upload the contents of those PAL's? Ron -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri May 7 11:36:25 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 7 May 2004 09:36:25 -0700 (PDT) Subject: [sebhc] Re: H8 data record format Message-ID: <200405071636.JAA28250@clulw009.amd.com> >From: "Dave Dunfield" > > >>> Anyone have experience reviving old gear? Mine's been boxed >>> for over a decade. Any precautions I should take before I try to power >>> up another unit? > >#1 - Wear eye protection. This is VERY IMPORTANT. > I've had a power supply cap short, causing a regulator to explode which > buried part of the casing in the wall!!! > >- Visual inspection, especially look for leaking, deformed or discolored capacitors. > >- Test power supply alone first. Remove all logic boards or disconnect the power > supply DC leads. Switchers may require a small load to operate correctly. > >- Current limit the supply. For small linear supplies, running through a 100w light > bulb initially is a good idea. This works ok for small switchers too, but be careful > that the supply operates correctly on reduced voltage. > >- Use a variac to bring the supply voltage up SLOWLY - for very old long-out of service > equipment, take a good long time, allowing the capacitors to reform. > Don't do this for switchers or if the power supply is not completely disconnected from > the rest of the system. Hi When I bring up a switcher that has been off for a real long time, I often will disconnect the prinary side filter cap and put it on a DC supply with a limiting resistor for some time. One can also connect at most rectifiers of the switchers to form these capacitors without disconnecting from circuits but it is best to remove as much loads as one can. There will always be current paths around the filter capacitor so one can't just use a limiting resistor. Still, bringing the voltage up slowly over a day or so is a good idea. The issue with most switchers is that unless they are designed with an under voltage protection, they will often do things like leaving the flyback transistor on constantly ( quick smoke ) or cause the switching transistor to dissipate too much power if under load, to maintain voltage out. Dwight > Monitor the output as you do this and confirm that it is coming up as expected. > Monitor voltage and waveform across filter caps to insure that they are not shorted or > open. > >- Check power supply voltages. > >- Power the logic boards one at a time - If the system is small enough, continue to use > the 100w light bulb in the AC power loop - use fuses on the DC side (you will have to > estimate power requirements for the boards). > ** WEAR EYE PROTECTION ** > >Regards, >-- >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 leeahart at earthlink.net Fri May 7 14:47:07 2004 From: leeahart at earthlink.net (Lee Hart) Date: Fri, 07 May 2004 12:47:07 -0700 Subject: [sebhc] Re: H8 data record format References: <00a001c433db$90408b60$f300a8c0@berkeley.evocative.com> Message-ID: <409BE7BB.2F55@earthlink.net> > Anyone have experience reviving old gear? Mine's been boxed > for over a decade. Any precautions I should take before I try > to power up another unit? Patrick Rigney had some good ideas. Here is my contribution. The main offenders are old batteries (but the H8 doesn't have any unless you have added a real time clock board), electrolytic capacitors, and tantalum capacitors, and high-current connectors. These parts all age (get much worse over time), and can fail in dramatic, dangerous ways. Batteries Any batteries over 5-10 years old should automatically be replaced. On some equipment, they will be little cylindrical or coin cells hiding on a clock board somewhere. They will leak, and short or corrode traces to cause all sorts of bizarre circuit behavior. Electrolytic capacitors Electrolytics have two main problems; they dry out, and they lose their dielectric forming. Dryout means they have lost water, which increases internal resistance and reduces capacitance. Dryout is proportional to *operating* time; the amount of time the equipment has been turned on and working. High voltage and high temperature drastically increase the rate! For instance, a 25vdc 85 deg.C rated electrolytic will last 10 years at 16vdc 45 deg.C -- but only 2 months at its full ratings; 25vdc 85 deg.C! (Now you can see why you shouldn't use electrolytics at their full rated voltage or temperature). An electrolytic that has dried out isn't really working as a capacitor. It allows excessive noise and ripple in the circuit that will cause other parts to malfunction or fail. It will also get hot. If the heating gets bad enough, it will leak or explode! So, if the equipment has spent a lot of time turned on and tends to run hot, replace the electrolytics. An aluminum electrolytic consists of two aluminum plates in a caustic water-based electrolyte. During manufacture, they apply a DC voltage until a small current flows. Like a battery, this current "reduces" one plate (makes is pure aluminum) and "oxidizes" the other (coats it with aluminum oxide). This is called "forming" the capacitor. Since aluminum oxide is an insulator, the current stops when the plate is completely coated, and you have a capacitor. If the capacitor is not powered for a long time (years), this oxide coating gradually goes away. When you later apply voltage, it isn't a capacitor; it's a *resistor*! It will get hot, and if hot enough to boil the water inside, it will vent or even explode! So, if the equipment has not been used for several years, power it up slowly, with a light bulb or variac or light dimmer in the primary. Start at about half voltage, and crank it up slowly over a 24-hour period. This allows time to re-form the oxide layer so it will work again. Tantalum capacitors Tantalum capacitors are similar to electrolytics, but with tantalum oxide forming the dielectric. Their problem is that their breakdown voltage gradually falls as they age, usually from high temperatures or tiny cracks or damage to their case during assembly. When the breakdown voltage gets down to the applied voltage, they suddenly fail shorted. If they happen to be connected as filter capacitors right across a high-current power supply, they explode with a violent bang! There's no way to fix them, and they are usually reliable enough that it's not worth blindly replacing them. But be prepared for a sudden "bang!" shortly after you put an old piece of equipment back in operation. The good news is that tantalums are tiny, and rarely do any real damage unless your eyeball is in the path (running with the boards exposed. Then, you have to find the place where the tantalum capacitor is now missing from a board, and replace it (easy with Heathkits, thanks to their magnificent documentation). Connectors Equipment stored in basements, garages, attics, and other "dirty" areas will suffer from corrosion damage to connectors. The effect is much worse if you live in a city or other area with high air pollution levels. Connector problems mainly cause intermittents and flaky operation. But a high-current connector can melt down or even burn up. As a preventative, I generally unplug and re-plug all the connectors in an old piece of equipment; the friction helps clean them up. It's generally *not* a good idea to do this with cheap IC sockets, though. Many of them that Heath used are really garbage-grade, and you'll create more intermittents than you fix if you plug/unplug ICs in these sockets more than a few times. There are contact lubricants and greases that help prevent these problems, as have been mentioned previously. But they don't do much good once the connection is already bad. You may have to just mechanically clean or replace any connectors that get hot or are discolored or corroded. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- 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 May 7 16:38:37 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 07 May 2004 17:38:37 -0400 Subject: [sebhc] Re: H8 data record format In-Reply-To: <409BE7BB.2F55@earthlink.net> References: <00a001c433db$90408b60$f300a8c0@berkeley.evocative.com> <409BE7BB.2F55@earthlink.net> Message-ID: <409C01DD.9020706@sc.rr.com> I heard someone talk about Deoxit. What is this, what does it do, and where do you get it? Carroll Lee Hart wrote: >>Anyone have experience reviving old gear? Mine's been boxed >>for over a decade. Any precautions I should take before I try >>to power up another unit? >> >> > >Patrick Rigney had some good ideas. Here is my contribution. > >The main offenders are old batteries (but the H8 doesn't have any unless >you have added a real time clock board), electrolytic capacitors, and >tantalum capacitors, and high-current connectors. These parts all age >(get much worse over time), and can fail in dramatic, dangerous ways. > >Batteries > >Any batteries over 5-10 years old should automatically be replaced. On >some equipment, they will be little cylindrical or coin cells hiding on >a clock board somewhere. They will leak, and short or corrode traces to >cause all sorts of bizarre circuit behavior. > >Electrolytic capacitors > >Electrolytics have two main problems; they dry out, and they lose their >dielectric forming. > >Dryout means they have lost water, which increases internal resistance >and reduces capacitance. Dryout is proportional to *operating* time; the >amount of time the equipment has been turned on and working. High >voltage and high temperature drastically increase the rate! For >instance, a 25vdc 85 deg.C rated electrolytic will last 10 years at >16vdc 45 deg.C -- but only 2 months at its full ratings; 25vdc 85 deg.C! >(Now you can see why you shouldn't use electrolytics at their full rated >voltage or temperature). > >An electrolytic that has dried out isn't really working as a capacitor. >It allows excessive noise and ripple in the circuit that will cause >other parts to malfunction or fail. It will also get hot. If the heating >gets bad enough, it will leak or explode! So, if the equipment has spent >a lot of time turned on and tends to run hot, replace the electrolytics. > >An aluminum electrolytic consists of two aluminum plates in a caustic >water-based electrolyte. During manufacture, they apply a DC voltage >until a small current flows. Like a battery, this current "reduces" one >plate (makes is pure aluminum) and "oxidizes" the other (coats it with >aluminum oxide). This is called "forming" the capacitor. Since aluminum >oxide is an insulator, the current stops when the plate is completely >coated, and you have a capacitor. > >If the capacitor is not powered for a long time (years), this oxide >coating gradually goes away. When you later apply voltage, it isn't a >capacitor; it's a *resistor*! It will get hot, and if hot enough to boil >the water inside, it will vent or even explode! > >So, if the equipment has not been used for several years, power it up >slowly, with a light bulb or variac or light dimmer in the primary. >Start at about half voltage, and crank it up slowly over a 24-hour >period. This allows time to re-form the oxide layer so it will work >again. > >Tantalum capacitors > >Tantalum capacitors are similar to electrolytics, but with tantalum >oxide forming the dielectric. Their problem is that their breakdown >voltage gradually falls as they age, usually from high temperatures or >tiny cracks or damage to their case during assembly. When the breakdown >voltage gets down to the applied voltage, they suddenly fail shorted. If >they happen to be connected as filter capacitors right across a >high-current power supply, they explode with a violent bang! > >There's no way to fix them, and they are usually reliable enough that >it's not worth blindly replacing them. But be prepared for a sudden >"bang!" shortly after you put an old piece of equipment back in >operation. The good news is that tantalums are tiny, and rarely do any >real damage unless your eyeball is in the path (running with the boards >exposed. Then, you have to find the place where the tantalum capacitor >is now missing from a board, and replace it (easy with Heathkits, thanks >to their magnificent documentation). > >Connectors > >Equipment stored in basements, garages, attics, and other "dirty" areas >will suffer from corrosion damage to connectors. The effect is much >worse if you live in a city or other area with high air pollution >levels. > >Connector problems mainly cause intermittents and flaky operation. But a >high-current connector can melt down or even burn up. As a preventative, >I generally unplug and re-plug all the connectors in an old piece of >equipment; the friction helps clean them up. > >It's generally *not* a good idea to do this with cheap IC sockets, >though. Many of them that Heath used are really garbage-grade, and >you'll create more intermittents than you fix if you plug/unplug ICs in >these sockets more than a few times. > >There are contact lubricants and greases that help prevent these >problems, as have been mentioned previously. But they don't do much good >once the connection is already bad. You may have to just mechanically >clean or replace any connectors that get hot or are discolored or >corroded. > > From jack.rubin at ameritech.net Fri May 7 17:03:08 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 7 May 2004 17:03:08 -0500 Subject: [sebhc] DeOxit and other things to help revive old systems In-Reply-To: <409C01DD.9020706@sc.rr.com> Message-ID: <002101c4347f$14f29670$1f6fa8c0@eths.k12.il.us> Take a look at http://www.caig.com - DeOxit is only one of their products for cleaning and lubricating contacts. The stuff is magic! I prefer Nye Lubricant's Nyogel to Caig's contact grease and Dwight makes a good case for a silicone lubricant, but deoxidizing components and sockets, and cleaning and lubing connectors can solve a bunch of mysterious intermittent problems. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Friday, May 07, 2004 4:39 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] Re: H8 data record format > > > I heard someone talk about Deoxit. What is this, what does it do, and > where do you get it? > Carroll > > Lee Hart wrote: > > >>Anyone have experience reviving old gear? Mine's been boxed > for over a > >>decade. Any precautions I should take before I try to power > up another > >>unit? > >> > >> > > > >Patrick Rigney had some good ideas. Here is my contribution. > > > >The main offenders are old batteries (but the H8 doesn't have any > >unless you have added a real time clock board), electrolytic > >capacitors, and tantalum capacitors, and high-current > connectors. These > >parts all age (get much worse over time), and can fail in dramatic, > >dangerous ways. > > > >Batteries > > > >Any batteries over 5-10 years old should automatically be > replaced. On > >some equipment, they will be little cylindrical or coin > cells hiding on > >a clock board somewhere. They will leak, and short or > corrode traces to > >cause all sorts of bizarre circuit behavior. > > > >Electrolytic capacitors > > > >Electrolytics have two main problems; they dry out, and they > lose their > >dielectric forming. > > > >Dryout means they have lost water, which increases internal > resistance > >and reduces capacitance. Dryout is proportional to *operating* time; > >the amount of time the equipment has been turned on and > working. High > >voltage and high temperature drastically increase the rate! For > >instance, a 25vdc 85 deg.C rated electrolytic will last 10 years at > >16vdc 45 deg.C -- but only 2 months at its full ratings; 25vdc 85 > >deg.C! (Now you can see why you shouldn't use electrolytics at their > >full rated voltage or temperature). > > > >An electrolytic that has dried out isn't really working as a > capacitor. > >It allows excessive noise and ripple in the circuit that will cause > >other parts to malfunction or fail. It will also get hot. If the > >heating gets bad enough, it will leak or explode! So, if the > equipment > >has spent a lot of time turned on and tends to run hot, replace the > >electrolytics. > > > >An aluminum electrolytic consists of two aluminum plates in > a caustic > >water-based electrolyte. During manufacture, they apply a DC voltage > >until a small current flows. Like a battery, this current > "reduces" one > >plate (makes is pure aluminum) and "oxidizes" the other > (coats it with > >aluminum oxide). This is called "forming" the capacitor. > Since aluminum > >oxide is an insulator, the current stops when the plate is > completely > >coated, and you have a capacitor. > > > >If the capacitor is not powered for a long time (years), this oxide > >coating gradually goes away. When you later apply voltage, > it isn't a > >capacitor; it's a *resistor*! It will get hot, and if hot enough to > >boil the water inside, it will vent or even explode! > > > >So, if the equipment has not been used for several years, > power it up > >slowly, with a light bulb or variac or light dimmer in the primary. > >Start at about half voltage, and crank it up slowly over a 24-hour > >period. This allows time to re-form the oxide layer so it will work > >again. > > > >Tantalum capacitors > > > >Tantalum capacitors are similar to electrolytics, but with tantalum > >oxide forming the dielectric. Their problem is that their breakdown > >voltage gradually falls as they age, usually from high > temperatures or > >tiny cracks or damage to their case during assembly. When > the breakdown > >voltage gets down to the applied voltage, they suddenly fail > shorted. > >If they happen to be connected as filter capacitors right across a > >high-current power supply, they explode with a violent bang! > > > >There's no way to fix them, and they are usually reliable > enough that > >it's not worth blindly replacing them. But be prepared for a sudden > >"bang!" shortly after you put an old piece of equipment back in > >operation. The good news is that tantalums are tiny, and > rarely do any > >real damage unless your eyeball is in the path (running with > the boards > >exposed. Then, you have to find the place where the tantalum > capacitor > >is now missing from a board, and replace it (easy with Heathkits, > >thanks to their magnificent documentation). > > > >Connectors > > > >Equipment stored in basements, garages, attics, and other > "dirty" areas > >will suffer from corrosion damage to connectors. The effect is much > >worse if you live in a city or other area with high air pollution > >levels. > > > >Connector problems mainly cause intermittents and flaky > operation. But > >a high-current connector can melt down or even burn up. As a > >preventative, I generally unplug and re-plug all the > connectors in an > >old piece of equipment; the friction helps clean them up. > > > >It's generally *not* a good idea to do this with cheap IC sockets, > >though. Many of them that Heath used are really garbage-grade, and > >you'll create more intermittents than you fix if you > plug/unplug ICs in > >these sockets more than a few times. > > > >There are contact lubricants and greases that help prevent these > >problems, as have been mentioned previously. But they don't do much > >good once the connection is already bad. You may have to just > >mechanically clean or replace any connectors that get hot or are > >discolored or corroded. > > > > > -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Fri May 7 18:19:55 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Fri, 7 May 2004 18:19:55 -0500 Subject: [sebhc] Reaching David Wallace. Message-ID: <017901c43489$cf010150$a301010a@gr390> Is anyone aware of another way to reach David Wallace ( the H8 Emulator writer)? Both Steven and I have not been able to reach him via the email link on his page (Steven for about 6 weeks, and only about 1 week for me). But we would like to get the source setup on someplace like sourceforge.net so that several of us can work and improve the emulator. One of the restrictions on sourceforge is the project must have an open source license. Based on the statement on his web page is sounds alot like a BSD-styled license: License and Copyright Information I thought about doing some take-off on the Gnu Public License. But let's be real: this code isn't a product that's ever going to make me or anybody else rich. So let's just say that I mean it when I say "Copyright" -- I wrote the damn thing. I get the credit. I keep control of the code. You get to use it if you want. Just play nice: if you mess with the code, continue to acknowledge the author. But the phrase "I keep control of the code." could cause problems getting the project added to the site. If we could get it to plainly state 'BSD' and had him in the loop, it will make it easier. I've tried looking him up on yahoo's people search, but found 22 David's in MA and none at the address listed in the code. Let us know if he has a newer email address or other contact method for him. Thanks, Mark From jack.rubin at ameritech.net Fri May 7 19:40:49 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 7 May 2004 19:40:49 -0500 Subject: [sebhc] was: Reaching David Wallace. - version control on sebhc server In-Reply-To: <017901c43489$cf010150$a301010a@gr390> Message-ID: <000a01c43495$1c2e3be0$1f6fa8c0@eths.k12.il.us> As Patrick noted a week or so back, the server which hosts sebhc.org is also set up with a version control system; there is no reason not to register the VH8 code here and work on it within Dave's guidelines - acknowledging his ownership and re-affirming the public-domain nature of the work done. An explicit copy-left statement could be added referring to all derivative work. As Dwight so often asks, "Is anybody listening to what I say?" ;>) Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Mark Garlanger > Sent: Friday, May 07, 2004 6:20 PM > To: sebhc at sebhc.org > Subject: [sebhc] Reaching David Wallace. > > > > Is anyone aware of another way to reach David Wallace ( the > H8 Emulator writer)? Both Steven and I have not been able to > reach him via the email link on his page (Steven for about 6 > weeks, and only about 1 week for me). But we would like to > get the source setup on someplace like sourceforge.net so > that several of us can work and improve the emulator. One of > the restrictions on sourceforge is the project must have an > open source license. Based on the statement on his web page > is sounds alot like a BSD-styled license: > License and Copyright Information > > I thought about doing some take-off on the Gnu Public > License. But let's be real: this code isn't a product that's > ever going to make me or anybody else rich. So let's just say > that I mean it when I say "Copyright" -- I wrote the damn > thing. I get the credit. I keep control of the code. You get > to use it if you want. Just play nice: if you mess with the > code, continue to acknowledge the author. > > But the phrase "I keep control of the code." could cause > problems getting the project added to the site. If we could > get it to plainly state 'BSD' and had him in the loop, it > will make it easier. > > I've tried looking him up on yahoo's people search, but found > 22 David's in MA and none at the address listed in the code. > > Let us know if he has a newer email address or other contact > method for him. > > Thanks, > > Mark > -- Delivered by the SEBHC Mailing List From eric at rothfus.com Fri May 7 19:45:57 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Fri, 7 May 2004 20:45:57 -0400 Subject: [sebhc] Reaching David Wallace. In-Reply-To: <017901c43489$cf010150$a301010a@gr390> (garlangr@verizon.net) References: <017901c43489$cf010150$a301010a@gr390> Message-ID: <1083976821@rothfus.com> I've e-mailed to David before at davidwallace2000 at comcast.net, which is different from his current link on the web-site. Don't know, however, if that is current. This was as of Dec of last year. Eric -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Fri May 7 20:46:26 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Fri, 7 May 2004 20:46:26 -0500 Subject: [sebhc] was: Reaching David Wallace. - version control on sebhc server References: <000a01c43495$1c2e3be0$1f6fa8c0@eths.k12.il.us> Message-ID: <021601c4349e$46c550b0$a301010a@gr390> I guess I missed that... I looked back through the email and didn't see it. Is there any documentation/info on how to use the source control system on the server? Mark ----- Original Message ----- From: "Jack Rubin" To: Sent: Friday, May 07, 2004 7:40 PM Subject: [sebhc] was: Reaching David Wallace. - version control on sebhc server > As Patrick noted a week or so back, the server which hosts sebhc.org is > also set up with a version control system; there is no reason not to > register the VH8 code here and work on it within Dave's guidelines - > acknowledging his ownership and re-affirming the public-domain nature of > the work done. An explicit copy-left statement could be added referring > to all derivative work. > > As Dwight so often asks, "Is anybody listening to what I say?" ;>) > > Jack > > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri May 7 21:05:13 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 07 May 2004 22:05:13 -0400 Subject: [sebhc] H19 emulation Message-ID: <409C4059.5060700@sc.rr.com> I working on a new H19 emulation that will execute all the H19 functions, both Heath and ANSI, as well as graphics. I just finished designing the graphics characters. This emulation will be executed in a true DOS machine. I can't find a way to create graphics character fonts in Windows. Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Fri May 7 21:16:30 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 7 May 2004 21:16:30 -0500 Subject: [sebhc] was: Reaching David Wallace. - version control on sebhc server In-Reply-To: <021601c4349e$46c550b0$a301010a@gr390> Message-ID: <000301c434a2$7a95f210$1f6fa8c0@eths.k12.il.us> (this is the part where Patrick jumps in with the details) > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Mark Garlanger > Sent: Friday, May 07, 2004 8:46 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] was: Reaching David Wallace. - version > control on sebhc server > > > I guess I missed that... I looked back through the email and > didn't see it. Is there any documentation/info on how to use > the source control system on the server? > > Mark > > ----- Original Message ----- > From: "Jack Rubin" > To: > Sent: Friday, May 07, 2004 7:40 PM > Subject: [sebhc] was: Reaching David Wallace. - version > control on sebhc server > > > > As Patrick noted a week or so back, the server which hosts > sebhc.org > > is also set up with a version control system; there is no > reason not > > to register the VH8 code here and work on it within Dave's > guidelines > > - acknowledging his ownership and re-affirming the public-domain > > nature of the work done. An explicit copy-left statement could be > > added referring to all derivative work. > > > > As Dwight so often asks, "Is anybody listening to what I say?" ;>) > > > > Jack > > > > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sat May 8 22:01:08 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 8 May 2004 22:01:08 -0500 Subject: [sebhc] Dave Shaw's Project8080 H8 emulator - more info on disk files, H19 graphics Message-ID: <000001c43571$e0b7b950$1f6fa8c0@eths.k12.il.us> I spent some serious time this afternoon reviewing the docs for Dave Shaw's H8 emulator - his site is gone, but an archive is linked off Dave Wallace's H8 emulator (recursive emulation?) - http://home.comcast.net/~davidwallace2000/h8/project8080_archive/heath80 80a_intro.htm . Dave S has provided extensive docs on the H17 and H19 subsystems - definitely worth reviewing for detailed information. Did anyone manage to download the emulator or related files before Dave Shaw closed his site just one year ago? Jack -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sun May 9 02:51:35 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sun, 9 May 2004 00:51:35 -0700 Subject: [sebhc] Dave Shaw's Project8080 H8 emulator - more info on disk files, H19 graphics In-Reply-To: <000001c43571$e0b7b950$1f6fa8c0@eths.k12.il.us> Message-ID: <000001c4359a$9bdcefc0$0700a8c0@walterp4> I have uploaded everything that I managed to get off of the site before it went down. I think I got everything except the HDOS 1.6 image (I cannot explain why I did not get it, other than maybe at the time I was only interested in 2.0). I only discovered the site shortly before it went down, So I don't have any archives of previous releases. I have not done anything with these files since I downloaded them other than bring up the web pages. I guess you will need stuffit to decode the files. ..walt -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Jack Rubin Sent: Saturday, May 08, 2004 8:01 PM To: SEBHC Subject: [sebhc] Dave Shaw's Project8080 H8 emulator - more info on disk files, H19 graphics I spent some serious time this afternoon reviewing the docs for Dave Shaw's H8 emulator - his site is gone, but an archive is linked off Dave Wallace's H8 emulator (recursive emulation?) - http://home.comcast.net/~davidwallace2000/h8/project8080_archive/heath80 80a_intro.htm . Dave S has provided extensive docs on the H17 and H19 subsystems - definitely worth reviewing for detailed information. Did anyone manage to download the emulator or related files before Dave Shaw closed his site just one year ago? Jack -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 9 07:16:18 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 9 May 2004 07:16:18 -0500 Subject: [sebhc] Dave Shaw's Project8080 H8 emulator - more info on disk files, H19 graphics In-Reply-To: <000001c4359a$9bdcefc0$0700a8c0@walterp4> Message-ID: <000101c435bf$6f551890$1f6fa8c0@eths.k12.il.us> Thanks Walt - I'll take care of de-stuffing. I have a copy of the HDOS 1.6 file courtesy of Eric; I'll get things posted shortly. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Walter Moore > Sent: Sunday, May 09, 2004 2:52 AM > To: sebhc at sebhc.org > Subject: RE: [sebhc] Dave Shaw's Project8080 H8 emulator - > more info on disk files, H19 graphics > > > I have uploaded everything that I managed to get off of the > site before it went down. I think I got everything except > the HDOS 1.6 image (I cannot explain why I did not get it, > other than maybe at the time I was only interested in 2.0). > I only discovered the site shortly before it went down, So I > don't have any archives of previous releases. > > I have not done anything with these files since I downloaded > them other than bring up the web pages. I guess you will > need stuffit to decode the files. > > ..walt > > > > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Jack Rubin > Sent: Saturday, May 08, 2004 8:01 PM > To: SEBHC > Subject: [sebhc] Dave Shaw's Project8080 H8 emulator - more > info on disk files, H19 graphics > > I spent some serious time this afternoon reviewing the docs > for Dave Shaw's H8 emulator - his site is gone, but an > archive is linked off Dave Wallace's H8 emulator (recursive > emulation?) - > http://home.comcast.net/~davidwallace2000/h8/project8080_archi ve/heath80 80a_intro.htm . Dave S has provided extensive docs on the H17 and H19 subsystems - definitely worth reviewing for detailed information. Did anyone manage to download the emulator or related files before Dave Shaw closed his site just one year ago? Jack -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 9 08:51:07 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 9 May 2004 08:51:07 -0500 Subject: [sebhc] Dave Shaw's H8 emulator in the archive Message-ID: <000001c435cc$ae150470$1f6fa8c0@eths.k12.il.us> Walt uploaded a zipped package containing Dave Shaw's defunct website which includes Dave's emulator in source and assembled form, as well as additional documentation, ROM and demo disk resources. When Dave took down his website, he offered it as package to individual users but asked that the site itself not be re-posted in public. The one exception is the link through Dave Wallace's site noted in a prior email. Walt's archive includes almost all the resource links that are now inactive on Dave Wallace's site. One file was missing from Walt's download - the HDOS 1.6 system disk. I inserted a copy of the .dsk image I have from Eric, but the byte count is different between Eric's .dsk file and Dave Shaw's .dsk files. I don't have a Mac handy, so I can't test to see if the files run in cross environments. Let me know what you find out. Dave's emulator runs in a Mac environment, so I've converted all his .sit files to .zip files for the rest of us. This includes his c source code which should be of interest to those working on upgrading Dave Wallace's Windows-based emulator. And to Dave Dunfield, working on a DOS-based emulator. Maybe Mark and Steven should change their names to Dave? All this material is in a new sebhc archive directory called 'emulators'. Walt's archive, including Dave's original stuffed Mac source and executable files, is a single zipped file called 'DaveShaw8080.ZIP'. I've extracted, unstuffed and rezipped the files and placed them in a directory called 'DaveShawUnstuffed'. Happy Mother's Day. Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 9 12:22:47 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 09 May 2004 17:22:47 +0000 Subject: [sebhc] RE: Dave Shaw's H8 emulator in the archive Message-ID: Very nice, I was hoping the rest of that site would turn up eventually! Now, is anyone currently in contact with THAT Dave? >One file was missing from Walt's download - the HDOS 1.6 system disk. I >inserted a copy of the .dsk image I have from Eric, but the byte count >is different between Eric's .dsk file and Dave Shaw's .dsk files. I >don't have a Mac handy, so I can't test to see if the files run in cross >environments. Let me know what you find out. The file you added is in the same format as the HUG disks, but with mac-style line endings. The other files in the collection are also in this format, but have no spaces or comments, which accounts for the size difference. The emulator docs say the function would be unaffected by the presence or absence of the spaces and comments. >Maybe Mark and Steven should change their names to Dave? Actually I know a Dave Parker, and he used to work with H8's! His was boxed for a while and when he tried pugging it in again the big cap blew up, trashing the whole boxl. :-( I'm doing much better - those suggestions are helping out.. so far I've used a variac to power up another entire machine and the rest of the boards from the one who's CPU smoked. The good machine is running the memory test as I write this. I haven't tried to warm up the H-19 yet (aren't video circuts sensitive to undervoltage?) or the H-17 (needs a switch). And I'm still digging out other buried treasures. :-) Besides the CPU cap (can I get one of those at radio shack?) my other casualties so far are: One bad 4044 memory (stuck bit). One bad 4104 memory (also stuck bit). Bad power switch on the H-17 (open in both positions). Mark said something about having our own private "sourceforge" on the archive machine .. what do we need to get that going? Can I help? Cheers, - Steven _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 10 07:30:56 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 10 May 2004 05:30:56 -0700 (PDT) Subject: [sebhc] Emulator progress & Hardware Q's Message-ID: <200405101230.i4ACUuVw011612@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 10 May 2004 12:48:11 -0000 Hi Guys, I've been poking away at my H8 simulator - busy with other tasks so it has gone slowly, however I'm going to try and allocate more time to it over the next couple of weeks and try to get a first edition out. Progress so far: - I have the 8080 emulation engine working and debugged (from my Altair simulator). - I have the basic framework for the simulator in place, which allows me to switch between full terminal display, split panel/terminal display, and full-screen debug modes. Most of this is also derived from my Altair simulator. - I have the H8 front panel display implemented, with all LED segments, status lights, and Key hiliting. - I have 8251 UART emulation code working (also from my Altair) including redirect to emulated terminal (video/keyboard), or to PC serial port. - All that really remains to get the basic H8 simulator running is to "hook up" the front panel, and fixup the terminal emulator to correctly implement H19 codes - after that, I want to add the disk controller, and it should be able to boot! I have a few questions regarding the H8 hardware, that I did not find readily answered in the documentation. Perhaps someone can help clairify these points, or at least provide pointers to reference material which can help: #1 - Can anyone provide clairification as to the purposes of bits 4-5 in the front panel control register (Address F0h - 360o): From H8 operations manual, Page 38: "When the interrupt enable, IC108A and B will count two M cycles before the -Q output (pin 11) goes low. If during the update process, D5 set the latch (IC106), the Q output (pin 2) will be high, enabling IC112C. When the -Q output (pin 11) of IC108 goes low, pin 6 of IC112C will go low. Pin 6 of IC112C going low is decoded as a level 20 interrupt. Execution of additional instructions is halted unless the single instruction key is pressed. The CPU will not execute addtional instructions, but will continue to update the front panel and strobe the keys for additional instructions." Looking at the PAM-8 documents, we can see that level 2 interrupt (020) is a single-step interrupt. The above text would suggest that data bit 5 ("D5 set the latch" ?) controls single-stepping, however on the schematic, D5 is connected to pin 13 of IC106, and the corresponding outputs are not connected. On the schematic, D4 is connected to IC106 pin4, and the output (pin 2) operates as described. Does anyone know which is correct (D4 or D5)? Am I correct in assuming that the other one is unused? #2 - Can someone send me or point me to a reference for detailed info on the H19 terminal so that I can correctly implement the various control codes? (I don't have an H19) #3 - Can someone send me or point me to a reference for detailed info on the disk controller. (I don't have a disk controller). #4 - Can someone send me a binary image of the PAM-8 ROM - save me having to set up the H8 and figure out how to download it ? #5 - Here are some notes I've made on the H8 hardware, if anyone out there is intimately familier with this material could give it a review and let me know of any errors, or additional information that I have missed, that would be greatly appreciated. Memory Map: ----------- 0000-03FF = System ROM 0400-1FFF = Reserved for future expansion 2000-203F = Monitor RAM 2040-FFFF = User RAM I/O ports: ---------- C0 = Reserved F0 = Front panel Commands, Digit Select, Keypad Write: 7 - 1 = Enable Buzzer 6 - Clock interrupt enable (010 interrupt) 5 - Unused ?? 4 - Single-Step ?? (020 interrupt) 3 - \ 0000=Blank 0100=Addr3 1000=Status2 2 - Digit 0001=Addr6 0101=Addr2 1001=Status1 1 - Select 0010=Addr5 0110=Addr1 1010=Blank 0 - / 0011=Addr4 0111=Status3 1011=Blank 11xx=Blank Read: 7 - \ 000=. 011=* 110=9 6 - High key code: 001=# 100=- 111=8 5 - / 010=/ 101=+ 4 - High key pressed (0=Pressed) 3 - \ 000=7 011=4 110=1 2 - Low key code : 001=6 100=3 111=0 1 - / 010=5 101=2 0 - Low key pressed (0=Pressed) F1 = Front panel segment select Write: 1 6 2 0 5 3 4 8 F8 = Load/Dump data port (8251) F9 = Load/Dump control port (8251) FA = Console data port (8251) FB = Console control port (8251) FF = Reserved Clock interrupt: ---------------- Every 2ms (500khz) Regards, Dave Dunfield -- 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 garlangr at verizon.net Mon May 10 09:49:28 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Mon, 10 May 2004 09:49:28 -0500 Subject: [sebhc] Emulator progress & Hardware Q's References: <200405101230.i4ACUuVw011612@gatekeeper.evocative.com> Message-ID: <000c01c4369d$ff1b2170$a301010a@gr390> Dave Dunfield wrote: > Hi Guys, > > I've been poking away at my H8 simulator - busy with other tasks so it > has gone slowly, however I'm going to try and allocate more time to it > over the next couple of weeks and try to get a first edition out. > Hi Dave, So what platform are you making this for? Any reason that you are starting your own instead of working off one of the existing ones? It seems like working one an existing project would be more productive. A few of us on the list have talked about working/extending David Wallace's emulator. I know I don't have alot of time to work on it, but if we could focus on one project alot more would get accomplished. Have you decided on a license for it? Picking an existing open source license makes it easier for others to contribute to the project, and if you drop the project someone will be able to take over without having to decipher what you exactly meant. David Wallace's emulator has the following statement on his web page, I didn't see anything but a copyright notice in the code: License and Copyright Information I thought about doing some take-off on the Gnu Public License. But let's be real: this code isn't a product that's ever going to make me or anybody else rich. So let's just say that I mean it when I say "Copyright" -- I wrote the damn thing. I get the credit. I keep control of the code. You get to use it if you want. Just play nice: if you mess with the code, continue to acknowledge the author. So what does that exactly mean? Sounds alot like a BSD-Style license, but not quite. If I 'mess' with the code, where do I need to acknowledge the author? In the code, in the documentation, displayed in the about box, splash screen when the program starts, or somewhere else... What does 'I keep control of the code.' mean? Am I allowed to use the code to start a new project? Do I have to give the changes back to the author, am I allowed to sell it? Not using a standard license just leaves so many questions up in the air. Giving the code one of the standard opensource licenses allows people to know what it means. > Progress so far: > - I have the 8080 emulation engine working and debugged (from my Altair > simulator). > > - I have the basic framework for the simulator in place, which allows me > to switch between full terminal display, split panel/terminal display, > and full-screen debug modes. Most of this is also derived from my Altair > simulator. > > - I have the H8 front panel display implemented, with all LED segments, > status lights, and Key hiliting. > > - I have 8251 UART emulation code working (also from my Altair) including > redirect to emulated terminal (video/keyboard), or to PC serial port. > > - All that really remains to get the basic H8 simulator running is to > "hook up" the front panel, and fixup the terminal emulator to correctly > implement H19 codes - after that, I want to add the disk controller, > and it should be able to boot! > > I have a few questions regarding the H8 hardware, that I did not find > readily answered in the documentation. Perhaps someone can help clairify > these points, or at least provide pointers to reference material which > can help: > > > #2 - Can someone send me or point me to a reference for detailed info > on the H19 terminal so that I can correctly implement the various > control codes? (I don't have an H19) Take a look at the archives, a few weeks ago I uploaded the operational manual for the H19. It has all the codes. Also the manaul for the H9 terminal if you would like to start with that. The current tape software doesn't appear to support the H19 esc codes anyway. #4 - ROMs are also in the archive. From leeahart at earthlink.net Mon May 10 12:19:31 2004 From: leeahart at earthlink.net (Lee Hart) Date: Mon, 10 May 2004 10:19:31 -0700 Subject: [sebhc] Emulator progress & Hardware Q's References: <200405101230.i4ACUuVw011612@gatekeeper.evocative.com> Message-ID: <409FB9A3.5C15@earthlink.net> Dave Dunfield wrote: > I've been poking away at my H8 simulator... Progress so far: Wow; sounds like you have a lot done! > I have a few questions regarding the H8 hardware... It's been a *long* time, but I'll try to remember. > #1 - Can anyone provide clairification as to the purposes of bits 4-5 > in the front panel control register (Address F0h - 360o): Bit D4 of port 360o controls the single-step function. D4=0 enables single-step. As I think you've figured out, single-step works by having the PAM8 monitor enable interrupts, and "return" to the program to be single-stepped. The hardware counts two M1 cycles; the "return" instruction and one instruction of your program; and generates an /INT20 interrupt to call to the PAM8 monitor. PAM8 then lets you examine or change registers, memory, I/O etc. and when ready, do another single-step. Kinda neat; it can even trace programs in ROMs. Bit D5 of port 360o controls the "MON" LED on the front panel. D5=1 turns the LED on. It normally indicates when the front panel PAM8 software is running, so the front panel is working. D5 is latched by IC106, but its outputs are unconnected. Bit D5 has another function when the "0 org" option is installed. It disables the PAM8 ROM and H17 board ROM and RAM, and selects the "all RAM" memory map. This is necessary to run 0 org CP/M. > #2 - Can someone send me or point me to a reference for detailed info > on the H19 terminal so that I can correctly implement the various > control codes? (I don't have an H19) I've got all the H19 manuals, but no scanner. Here's a quick summary of the Heath mode ESC sequences and modes (the other mode is VT-52 ANSI mode): ENABLE H19 MODES DISABLE H19 FUNCTIONS ESC F graphics mode ESC G ESC z reset to power-up config ESC p reverse video mode ESC q ESC # transmit page ESC v wrap at end of line ESC w ESC ] transmit 25th line ESC t shifted keypad ESC u ESC n transmit cursor position ESC = alternate keypad ESC > ESC < enter ANSI mode ESC { keyboard enable ESC } CTL-T-Y-BACKSPACE unlocks keyboard ENABLE DISABLE ENABLE DISABLE ESC x 1 25th line ESC y 1 ESC x 6 shifted keypad ESC y 6 2 key click 2 7 alternate keypad 7 3 hold screen mode 3 8 auto LF on CR 8 4 block cursor 4 9 auto CR on LF 9 5 cursor off 5 ESC [ hold screen mode ESC \ BAUD RATE ESC r A 110 baud ESC r F 1800 baud ESC r K 7200 baud B 150 baud G 2000 baud L 9600 baud C 300 baud H 2400 baud M 19200 baud D 600 baud I 3600 baud E 1200 baud J 4800 baud FUNCTION KEYS BLUE = ESC P f1 = ESC S f5 = ESC W RED = ESC Q f2 = ESC T ERASE = ESC J WHITE = ESC R f3 = ESC U shift ERASE = ESC E BREAK = NULL + garbage f4 = ESC V NUMERIC KEYPAD key normal shift alternate 0 0 0 ESC ? p 1 (IL) 1 ESC L ESC ? q 2 (v) 2 ESC B ESC ? r 3 (DL) 3 ESC M ESC ? s 4 ( < ) 4 ESC D ESC ? t 5 (HOME) 5 ESC H ESC ? u 6 ( > ) 6 ESC C ESC ? v 7 (IC) 7 ESC @ ESC ? w 8 ( ^ ) 8 ESC A ESC ? x 9 (DC) 9 ESC N ESC ? y . . . ESC ? n ENTER CR CR ESC ? M CURSOR & SCREEN CONTROL ESC A cursor up ESC B cursor down ESC C cursor right ESC D cursor left ESC E erase page ESC H cursor home ESC I reverse index (backwards TAB) ESC J erase to end of page ESC K erase to end of line ESC L insert line ESC M delete line ESC N delete character ESC O end insert mode ESC Y line# col# position cursor ESC l erase line ESC @ insert char mode ESC j save cursor position ESC k restore position > #3 - Can someone send me or point me to a reference for detailed info > on the disk controller. (I don't have a disk controller). > > #4 - Can someone send me a binary image of the PAM-8 ROM - save me > having to set up the H8 and figure out how to download it? Someone else will have to help you with this. > #5 - Here are some notes I've made on the H8 hardware, if anyone out > there is intimately familier with this material could give it a > review and let me know of any errors, or additional information > that I have missed, that would be greatly appreciated. > > Memory Map: > ----------- > 0000-03FF = System ROM > 0400-1FFF = Reserved for future expansion > 2000-203F = Monitor RAM > 2040-FFFF = User RAM Yes, this is the standard power-up memory map. The H17 hard-sector board adds: 1800-1FFF = 2k floppy ROM (Heath 444-19) 1400-17FF = floppy RAM The ROM space from 0000-1FFF can have a variety of different ROMs, depending on what other disk controllers and accessories are installed. > I/O ports: [snip] On a casual look, these all appear correct. Minor typo; the 7-segment LED display's decimal point is controlled by bit D7, not D8. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- 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 Mon May 10 10:52:13 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 10 May 2004 08:52:13 -0700 Subject: [sebhc] was: Reaching David Wallace. - version control on sebhc server In-Reply-To: <000301c434a2$7a95f210$1f6fa8c0@eths.k12.il.us> Message-ID: <007e01c436a6$c31f5ca0$f300a8c0@berkeley.evocative.com> > (this is the part where Patrick jumps in with the details) The system is called CVS, and it's the "standard" version control system that comes with *nix. It's fairly straightforward to use, does the usual good stuff like branching and merging, and there are some good front-end GUI and web tools available. There's lots of info at http://www.cvshome.org/ Patrick -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 10 12:38:05 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 10 May 2004 17:38:05 +0000 Subject: [sebhc] RE: Emulator progress & Hardware Q's Message-ID: I had no idea 25 years ago that today I would be reprising my role as a Heathkit Technical Consultant. :-) Dave asks: >#1 - Can anyone provide clairification as to the purposes of bits 4-5 > in the front panel control register (Address F0h - 360o): Typos in Heathkit manuals are extremely rare - Congrats! You found one. :-) When in doubt, trust the PAM-8 listing. That's what you'll actually be supporting. > on the schematic, D5 is connected to pin 13 of IC106, and the > corresponding outputs are not connected. On the schematic, D4 is > connected to IC106 pin4, and the output (pin 2) operates as > described. D5 drives the MON light, and it has a separate latch (IC102), so the output from IC106 is not used. D4 is indeed the single-step control, defined in PAM-8 as CB.SSI. >#2 - Can someone send me or point me to a reference for detailed info > on the H19 terminal so that I can correctly implement the various > control codes? (I don't have an H19) In the FTP archives: documents/HZ19-manuals/z19-om.pdf >#3 - Can someone send me or point me to a reference for detailed info > on the disk controller. (I don't have a disk controller). I don't think anyone has scanned and uploaded it yet. I've listed port and bit assignments under "I/O ports" below to get you started. >#4 - Can someone send me a binary image of the PAM-8 ROM - save me > having to set up the H8 and figure out how to download it ? I uploaded it to the FTP archives last month: software/H8-ROMs/PAM8.ROM The H17 ROM is there too, and a few others. >#5 - Here are some notes I've made on the H8 hardware, if anyone out > there is intimately familier with this material could give it a > review and let me know of any errors, or additional information > that I have missed, that would be greatly appreciated. >Memory Map: >----------- >0000-03FF = System ROM ............................................(PAM-8) -or- 0000-07FF = XCON-8 ROM -or- 0000-0FFF = PAM-37 ROM (with H-8-37 upgrade) 1000-17FF = XCON ROM (with H-8-37 upgrade) >0400-1FFF = Reserved for future expansion 1800-1FFF = H-17 ROM >2000-203F = Monitor RAM >2040-FFFF = User RAM > >I/O ports: >---------- >C0 = Reserved C0-C7 = AT0 (Alternate Terminal) on H8-4 (8250) C8-CF = AT1 on H8-4 (8250) D0-D7 = AT2 on H8-4 (8250) D8-DF = AT3 on H8-4 (8250) E0-E7 = Printer on H8-4 (8250) E8-EF = Console on H8-4 (8250) 7C = H-17 Data Port (2350 USRT) 7D = H-17 Fill/Status Port 7E = H-17 SYN/Sync Port 7F = H-17 Control Port H-17 Control Port bits: D0 = Index Detect D1 = Track 0 Detect D2 = Write Protect D3 = Sync Detect D0 = Write Gate Enable D1 = Drive Select 0 D2 = Drive Select 1 D3 = Drive Select 2 D4 = Motor On D5 = Direction (0=out) D6 = Step Command D7 = Write Enable RAM H-17 Status Port bits: D0 = Rcv Data Ready D1 = Rcv Overrun D2 = Rcv Parity Error D6 = Fill Chr Transmitted D7 = Tx Buffer Empty Cheers, - Steven _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 10 14:32:12 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 10 May 2004 19:32:12 +0000 Subject: [sebhc] RE: version control on sebhc server Message-ID: >The system is called CVS, and it's the "standard" version control system >that comes with *nix. Great. I've done most of my development under CVS and set it up a few times myself. Is it ready to use now? I tried to connect to a cvs pserver at archive.sebhc.org and nothing happened. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Mon May 10 14:39:25 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 10 May 2004 12:39:25 -0700 Subject: [sebhc] RE: version control on sebhc server In-Reply-To: Message-ID: <00e601c436c6$8014ae40$f300a8c0@berkeley.evocative.com> > Great. I've done most of my development under CVS and set it > up a few times > myself. > > Is it ready to use now? I tried to connect to a cvs pserver at > archive.sebhc.org and nothing happened. Fabulous! It's not ready yet, but soon will be. I'll let you know; it will be a lot easier to get bootstrapped with someone at a distance who knows what "working" looks like! Patrick -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 10 16:26:33 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 10 May 2004 21:26:33 +0000 Subject: [sebhc] RE: status of resurrections - and a question Message-ID: Let me know if this is boring you guys... The H-19 came up fine. The H17 came up but the 2nd drive isn't working, at first look it appears to have a dead head positioning step motor. I've only found a few of the floppies yet. Half the bootable ones ... don't. :-) I haven't tested the pure data disks yet. But one that did boot contained the chess program I released to HUG with the H19 graphics (I had forgotten about it!). I'm getting close to being able to submit stuff to the archives... Speaking of archive software, I have a question for entire list.... Who uses what software, in what format, on what gear? I know Dave G. and I have been using the tape software in .PID/.tape format on the emulator. Has anyone used the HUG or HDOS disk images on actual computers yet? How do you make the disks from the data? Would there be a use for HDOS software in other forms than complete disk images? Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 10 16:47:44 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 10 May 2004 14:47:44 -0700 (PDT) Subject: [sebhc] RE: status of resurrections - and a question Message-ID: <200405102147.OAA01497@clulw009.amd.com> >From: "Steven Parker" > >Let me know if this is boring you guys... > >The H-19 came up fine. > >The H17 came up but the 2nd drive isn't working, at first look it appears to >have a dead head positioning step motor. Hi It is quite common to have the lubrication of these stepper motors dry up. Before giving up on it, try getting some new oil into the bearings. > >I've only found a few of the floppies yet. Half the bootable ones ... >don't. :-) I haven't tested the pure data disks yet. But one that did >boot contained the chess program I released to HUG with the H19 graphics (I >had forgotten about it!). I'm getting close to being able to submit stuff >to the archives... > >Speaking of archive software, I have a question for entire list.... Who >uses what software, in what format, on what gear? I know Dave G. and I have >been using the tape software in .PID/.tape format on the emulator. Has >anyone used the HUG or HDOS disk images on actual computers yet? How do >you make the disks from the data? Would there be a use for HDOS software in >other forms than complete disk images? > >Cheers, > >- Steven > I use complete disk images ( actually prefer them ). The problem is that right now, my images don't match any of the current formats used by the simulators. I use raw images. I'm looking at being able to handle other formats but I've been involved in a massive spring cleanup that has been consuming much of my free time. I think Patrick or someone was going to release it to the ftp soon. It is used to copy disk images to and from a H89 ( hasn't been tested on a H8 yet ), via that LP serial port, to a PC serial. It is also designed to bootstrap a machine from ground zero. That is, H89 ( or H8 ), a unformatted 10 sectored disk, serial cable and a PC. One enters about 50 bytes using the monitor and then bootstraps a disk copy program. Dwight -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 10 16:54:01 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 10 May 2004 17:54:01 -0400 Subject: [sebhc] RE: status of resurrections - and a question In-Reply-To: (sp11@hotmail.com) References: Message-ID: <1084198647@rothfus.com> > Speaking of archive software, I have a question for entire list.... Who > uses what software, in what format, on what gear? I know Dave G. and I have > been using the tape software in .PID/.tape format on the emulator. Has > anyone used the HUG or HDOS disk images on actual computers yet? How do > you make the disks from the data? Would there be a use for HDOS software in > other forms than complete disk images? OK, who wants to tell Steven of the SVD and the software that Dwight has created? :-) Eric -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Mon May 10 16:57:53 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 10 May 2004 14:57:53 -0700 Subject: [sebhc] RE: status of resurrections - and a question In-Reply-To: <200405102147.OAA01497@clulw009.amd.com> Message-ID: <012b01c436d9$d843ed70$f300a8c0@berkeley.evocative.com> > >The H17 came up but the 2nd drive isn't working, at first look it > >appears to > >have a dead head positioning step motor. > > Hi > It is quite common to have the lubrication of these > stepper motors dry up. Before giving up on it, try getting > some new oil into the bearings. Indeed... About half of the Siemen's drives I have weren't positioning when first tested, and 100% of them made a speedy recovery with a little lubricant. --Patrick -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 10 17:10:36 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 10 May 2004 22:10:36 +0000 Subject: [sebhc] Disk formats and emulators Message-ID: Dwight sayis: > I use complete disk images ( actually prefer them ). The >problem is that right now, my images don't match any of the >current formats used by the simulators. What simulator does disk simulation now? It's a yet-to-be-implemented feature of the one I have (Dave Wallace's). However, I was thinking about completing it, and I was going to make it work with binary images, perhaps with additional formatting info (I'm not sure yet if that can be uniquely implied by the file size). It's no big deal to convert between the various formats, but it would be nice to have a "standard" one for archival storage. >It is used to copy disk images to and from >a H89 ( hasn't been tested on a H8 yet ), The main catch to portability is refraining from using z80 opcodes. Otherwise, it would only be usable on H8's equipped with the HA-8-6 CPU upgrade. Ironically, I don't have one of those, despite the fact that I designed the ROM for it (PAM-37). I'll let you know if that oil trick works! Cheers, - Steven _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 10 17:27:47 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 10 May 2004 15:27:47 -0700 (PDT) Subject: [sebhc] Disk formats and emulators Message-ID: <200405102227.PAA01515@clulw009.amd.com> >From: "Steven Parker" > >Dwight sayis: >> I use complete disk images ( actually prefer them ). The >>problem is that right now, my images don't match any of the >>current formats used by the simulators. > >What simulator does disk simulation now? It's a yet-to-be-implemented >feature of the one I have (Dave Wallace's). However, I was thinking about >completing it, and I was going to make it work with binary images, perhaps >with additional formatting info (I'm not sure yet if that can be uniquely >implied by the file size). Hi The main difference between mine and SVD is that SVD has a header and the data is in an ascii format ( octal as I recall ). I have no header and it is just the raw sectors piled into a file. I also have nothing yet for 35 track, 96tpi or softsectored. It only works with 40 track 10 hardsectored. These are things that need enhancements but I'd need some hardware local or remote to verify on. I have 2 H8 boxes and a H17 disk drive setup but like all else, I'd need to power up and debug. Spring cleaning has taken precedence. > >It's no big deal to convert between the various formats, but it would be >nice to have a "standard" one for archival storage. Yes, I agree. The SVD format looks reasonably good. The header contains a lot of useful information. I expect to make efforts on this soon but I think we can still start image transfers initially. Once I get rolling, converting formats for final archieving is not an issue. > >>It is used to copy disk images to and from >>a H89 ( hasn't been tested on a H8 yet ), > >The main catch to portability is refraining from using z80 opcodes. >Otherwise, it would only be usable on H8's equipped with the HA-8-6 CPU >upgrade. Ironically, I don't have one of those, despite the fact that I >designed the ROM for it (PAM-37). It is all written in 8080. I don't know if I even have a Z80 assembler handy ( of course the PC side is '86 code ). I actually assemble the 8080 code on my IMSAI. I guess I could use a cross assembler on the PC but this justifies having the IMSAI powered on every now and then. Dwight > >I'll let you know if that oil trick works! > >Cheers, > >- Steven > >_________________________________________________________________ >Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! >http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/dir ect/01/ > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 10 17:48:36 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 10 May 2004 18:48:36 -0400 Subject: [sebhc] Disk formats and emulators In-Reply-To: <200405102227.PAA01515@clulw009.amd.com> (dwight.elvey@amd.com) References: <200405102227.PAA01515@clulw009.amd.com> Message-ID: <1084225212@rothfus.com> > Yes, I agree. The SVD format looks reasonably good. The header > contains a lot of useful information. I expect to make efforts on > this soon but I think we can still start image transfers > initially. Once I get rolling, converting formats for final > archieving is not an issue. To give credit where it is due, the "SVD" format is actually the Daves' format for emulated disks. The Dave S emulator used this format, and the Dave W format was moving that way...though was never (as far as I know) completed. It isn't the most efficient format, but I don't like to re-invent things that exist. I think we should consider standardizing on this format, again, even though it isn't ideal. It has the following things going for it: (1) it exists and is in use, (2) the image is completely distinguishable from other formats, such as those used to store other machines' images (such as TRS-80 or Apple), and (3) it is quite simple to convert to/from it. You should see the "DMK" format for the TRS-80... Note that Dwight and I have had some discussions about trying to make it easier to convert/download the different formats, using his software solution for getting images to the H8/H89. Hopefully (after spring cleaning and the like :-) we'll get a chance to work on it. Eric -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 10 17:56:20 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 10 May 2004 15:56:20 -0700 (PDT) Subject: [sebhc] More on Emulator progress Message-ID: <200405102256.i4AMuGVw021703@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 10 May 2004 23:19:08 -0000 Lee, Steven, Mark, Thanks for the information - very helpful. I did some more work on the emulator today (nothing like a bit of discussion to get you "back into" a suspended project) - I have now "connected" the front panel to the virtual CPU - installed the PAM8 ROM into the memory map, and so far everything is working well. PAM8 comes up - you can poke around, look at memory and registers just like the real H8 (which I have sitting beside my desk for comparison). I even entered (through the virtual front panel keypad) the test program at the start of the H8 operation manual, it runs and displays "your H8" "IS up And" "running" "|-| |-| |-|", then beeps twice and repeats - exactly what the real H8 does! Still lots of work to do, unkludge some quickie patches and fully implement the switchable console/terminal, as well as the full terminal emulation and the disk controller, but it's looking really good so far. No doubt I shall call upon your assistance in the coming days! Btw, found an interesting "quirk" in PAM8 while getting this going - at first I did not bother to "write protect" the ROM ... With RAM all the way to FFFF, PAM8 goes into an endless loop trying to locate the top of RAM - it wraps into the ROM and keeps on going if it's writable... Once I made the ROM truly read only, there was no problem! Regarding Mark's questions: > Why not work on Dave Wallace's emulator? Because this emulator requires the latest/most bloated/viral winblows and is therefore useless to me... No point going further into this discussion, I simply have no interest in being involved with such a project. > What platform are you making this for? DOS - will also run on all versions of Winblows, Linux DOSemu, SoftPC on a Mac, and even PocketDOS on my handheld (that looks really cool - pocket PC with an H8 front panel on it!) - It's written using my own C compiler which does not employ any "tricks" that cause compatibility problems. I run my code on all platforms listed above (and more) with no known problems, so the emulator should run anywhere that supports plain old DOS. Don't bother telling me why you think it should be a wintendo game - I really don't expect everyone to like it. It's free... if you don't like it, you can delete it and be out nothing - I won't mind. > License and Copyright Information Haven't decided yet. The executable will definately be free, I'll probably make the source code available as well, but I'll think about that when it's further along. Regards, -- 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 Mon May 10 18:53:25 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 10 May 2004 23:53:25 +0000 Subject: [sebhc] Emulator progress (Dave D's) Message-ID: Dave Dunfield said: >It's written using my own C compiler >which does not employ any "tricks" that cause compatibility problems. Neat, can we have the compiler as well? Now that it's working, is there a place on your website where we can download the current version and try it out? One of the things I've enjoyed about the DAW emulator is that it includes the HA-8-6 CPU (with the z80). One improvement I'd like to see is the ability to switch between configurations. Would you be interested in having that in yours? Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 10 19:43:06 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 11 May 2004 00:43:06 +0000 Subject: [sebhc] Disk formats and emulators Message-ID: Eric says: >...the Dave W format was moving that way...though >was never (as far as I know) completed. It's definitely not in the version you can download from his website. >I think we should consider standardizing on this format, again, even though >it isn't ideal. It may be worth considering other options, particularly at this time. A few issues that come to mind are (1) It was intended to load a hardware device (like hex dumps are used to load prom burners). (2) the text file requires conversion both before and after it's used (assuming the implementation makes the disk writable). (3) If you don't have a hardware SVD or dont' want to hold the entire image in memory while working with it, the text format would significantly complicate paging. (4) More direct formats would require about the same space as the capacity of the disk being stored. The SVD format requires 3-4 times as much space, and even more with track comments. (5) While the text format is "readable", I'm not sure it's particularly useful to do so. And creating readable dumps of binary files is trivial on most platforms. (6) It's not analagous to the more direct format already being used to store and emulate tape files (.PID, .tape). (7) There's no facility in the format to verify data integrity (as there is in a real disk). I was able to identify damage to one of the HUG files in the archive and reconstruct it because it was missing a byte entirely - a changed but still present byte would have been impossible to detect. I like the header in the SVD format, but I'm still not sure if it's really needed. It's possible that information can be uniquely implied just by the size of a binary file. My preference of the moment would be to store disk images in a binary format, which would have integral crc's and might include some additional information, to take advantage of the storage savings and more direct usability in new emulators. A tool could be provided in the archives to convert to the SVD format for those using actual SVD's or old emulators. The additional information could potentially be provided by an associated description file which would include label information. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 10 20:01:20 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 10 May 2004 18:01:20 -0700 (PDT) Subject: [sebhc] Emulator progress (Dave D's) Message-ID: <200405110101.i4B11KXJ001130@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 11 May 2004 01:06:53 -0000 >>It's written using my own C compiler >>which does not employ any "tricks" that cause compatibility problems. >Neat, can we have the compiler as well? Although I still sell embedded versions of my Micro-C compiler commercially,m the PC version (which is what the emulator is written in) is available free from my web site: www.dunfield.com One of these days I'll open it all up, and we could even compile it to run on the H8 if anyone is interested (I have an 8080 code generator). >Now that it's working, is there a place on your website where we can >download the current version >and try it out? All in good time - there is still a fair bit of work to do before I want to release it publically - I have not implemented the H19 yet, nor the disk controller. I also need to integrate my 8080 debugger (I already have one written in my Altair simulator), and clean up a number of little things and flesh out the user interface a fair bit. I'll try to work on it on a regular basis and parhaps have something to show in a week or two (I wrote the entire Altair simulator in the evenings during the christmas break - so it shouldn't take too long). If you want to get an idea of what it will be like, download my Altair simulator from my Museum website ( http://www.parse.com/~ddunfield/museum/index.html ) The H8 simulator is going to be very similar, except that the front panel shown will be an H8, it will have/run PAM8 at startup, and the terminal will be a heathkit terminal instead of an ADM-3A. It really won't be all that useful until I get the disk controller implemented, which will probably take me a little while, since I don't currently have one or the docs for it. >One of the things I've enjoyed about the DAW emulator is that it includes >the HA-8-6 CPU (with the z80). One improvement I'd like to see is the >ability to switch between configurations. Would you be interested in having >that in yours? Perhaps eventually - my main goal is in simulating the machines I actually have on hand, but since Ive already decided to add the disk, I may go one further and add the Z80 - main problem is that doing so will change the debugger significantly which I already have implemented. Regards, -- 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 garlangr at verizon.net Mon May 10 20:27:11 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Mon, 10 May 2004 20:27:11 -0500 Subject: [sebhc] More on Emulator progress References: <200405102256.i4AMuGVw021703@gatekeeper.evocative.com> Message-ID: <003901c436f7$155c9eb0$a301010a@gr390> Hi Dave, > > Regarding Mark's questions: > > > Why not work on Dave Wallace's emulator? > > Because this emulator requires the latest/most bloated/viral winblows and > is therefore useless to me... No point going further into this discussion, > I simply have no interest in being involved with such a project. > Understandable... the majority of my boxes are running Linux. > > > What platform are you making this for? > > DOS - will also run on all versions of Winblows, Linux DOSemu, SoftPC on > a Mac, and even PocketDOS on my handheld (that looks really cool - pocket > PC with an H8 front panel on it!) - It's written using my own C compiler > which does not employ any "tricks" that cause compatibility problems. I > run my code on all platforms listed above (and more) with no known problems, > so the emulator should run anywhere that supports plain old DOS. > > Don't bother telling me why you think it should be a wintendo game - I > really don't expect everyone to like it. It's free... if you don't like > it, you can delete it and be out nothing - I won't mind. > You're not going to hear that from me, one of the things I would like to see with the emulators is running across a wide range of equipment/OSs, it looks like yours is going to cover that, although it doesn't look like PocketDOS is available for the Palm ;-) -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 10 20:20:49 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 10 May 2004 20:20:49 -0500 Subject: [sebhc] Emulator progress (Dave D's) - c compilers In-Reply-To: <200405110101.i4B11KXJ001130@gatekeeper.evocative.com> Message-ID: <000b01c436f6$32207860$1f6fa8c0@eths.k12.il.us> > >>It's written using my own C compiler > >>which does not employ any "tricks" that cause compatibility > problems. > >Neat, can we have the compiler as well? I have a couple versions of Walt Bilofsky's C/80 in HDOS format, as well as permission from Walt to redistribute it for non-commercial use, so if we can agree on a format, we can share it. Meanwhile, I'll dig out the disks and dump them in the existing .h17 (dave/dave) format. I've also got PIE docs. Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 10 20:38:10 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 10 May 2004 20:38:10 -0500 Subject: [sebhc] RE: status of resurrections - and a question In-Reply-To: <200405102147.OAA01497@clulw009.amd.com> Message-ID: <000c01c436f8$9e4dbaa0$1f6fa8c0@eths.k12.il.us> > >The H17 came up but the 2nd drive isn't working, at first look it > >appears to > >have a dead head positioning step motor. > > Hi > It is quite common to have the lubrication of these > stepper motors dry up. Before giving up on it, try getting > some new oil into the bearings. Walt just went through a similar exercise with his 8" Remex drives and he mentioned using a synthetic lube. Anyone have specific recommendations, especially for light weight synthetics? Otherwise, there's always WD-40! Jack -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Mon May 10 20:54:56 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Mon, 10 May 2004 20:54:56 -0500 Subject: [sebhc] RE: Dave Shaw's H8 emulator in the archive References: Message-ID: <005d01c436fa$f5d8da50$a301010a@gr390> It seems that his license is even more restrictive(It wasn't even included with the code, but I found it on David Wallace's mirror of the Heath8080A pages): The emulator itself is ? 2001, 2002, 2003 by David A. Shaw. The emulator is being distributed as freeware. You may feel free to redistribute the emulator, without modification, as long as the copyright notices are included, and as long as you do so at no cost except for any cost of media. You may feel free to modify the emulator, but please do not redistribute the modified emulator. It's disappointing to have these programs/code that would provide a good starting points, but to have the use of the code prohibited. > Very nice, I was hoping the rest of that site would turn up eventually! > Now, is anyone currently in contact with THAT Dave? > From dwight.elvey at amd.com Mon May 10 20:58:55 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 10 May 2004 18:58:55 -0700 (PDT) Subject: [sebhc] RE: status of resurrections - and a question Message-ID: <200405110158.SAA01646@clulw009.amd.com> Hi I always recommend carful removal of the old grease. WD-40 isn't a good long term solution. It tends to dry out ( volatiles ). I have some Moble (sp?) Delvac that is similar to Moble One. It seem to work OK. For cleaning, I like to use "brake clean". The only issue here is to make sure that you use it outside and that whatever plastic parts it comes in contact with do not melt. It is strong stuff. If you think there will be a problem, kerosene works well. Some of the plastic head arms may melt while others ignore any solvent you might try. Dwight >From: "Jack Rubin" > >> >The H17 came up but the 2nd drive isn't working, at first look it >> >appears to >> >have a dead head positioning step motor. >> >> Hi >> It is quite common to have the lubrication of these >> stepper motors dry up. Before giving up on it, try getting >> some new oil into the bearings. > >Walt just went through a similar exercise with his 8" Remex drives and >he mentioned using a synthetic lube. Anyone have specific >recommendations, especially for light weight synthetics? Otherwise, >there's always WD-40! > >Jack > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 10 21:00:33 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 10 May 2004 22:00:33 -0400 Subject: [sebhc] Disk formats and emulators In-Reply-To: (sp11@hotmail.com) References: Message-ID: <1084150947@rothfus.com> OK, I had three reasons, Steven had 7. He wins! > I like the header in the SVD format, but I'm still not sure if it's really > needed. It's possible that information can be uniquely implied just by the > size of a binary file. My goal is simply to make sure that the files are somewhat "self-describing." That is, when you see one, a SIMPLE algorithm can identify them uniquely as H8'ish things. The size of the binary file isn't really good enough. I've run across around a dozen different formats, and those that are self-identifying are, in the long run, much more useful. Franz (of Vintage Computer Festival fame) proposes an XML storage format for floppy images. Interesting, to be sure, but a bit overkill for my tastes...though I can't really argue against it. Regarding the big 7: > (1) It was intended to load a hardware device (like hex dumps are used to > load prom burners). Actually, I think the original idea was to make the images easily dumpable on an ascii terminal. The "Daves'" diskdump program dumps images to the TT:. The thought, too, was to make them easily mailable. These two things aren't bad considerations...though I'm not religious about text formats. > (2) the text file requires conversion both before and after it's used > (assuming the implementation makes the disk writable). Yup, though this format is WAY easy to convert. Most other floppy disk image storage formats require some conversion to retrieve and to store. Most of the time, the conversion is necessary due to descriptive (or maybe self-descriptive) information that is being stored with the format. A notable binary format, DMK, includes checksum information...though it includes a bunch of other "garbage" in it too. Another important point about conversion is interesting for architectures other than the H8/H89: the ability to generate interesting mixed formats. Some software was recorded in mixed SD/DD formats (most for copy protection), and this mixing can't be represented without cues encoded in the data file. These cues would be decoded when being loaded into the real machine or into an emulator. > (3) If you don't have a hardware SVD or dont' want to hold the entire > image in memory while working with it, the text format would > significantly complicate paging. Yup. Not really worried about it! :-) As with #4, I'm a bit polluted by the 512 Meg sitting on my desktop, and a decent swapping/paging OS. > (4) More direct formats would require about the same space as the > capacity of the disk being stored. The SVD format requires > 3-4 times as much space, and even more with track comments. Yup. Another one I'm not really worried about. I'm polluted by the small 100G drive I have sitting on my desk. In the grand scheme of things, when I save a 10 line Word document in Windoze, and it explodes to half-a-meg, I tend to get desensitized. Not necessarily a good thing, I know. > (5) While the text format is "readable", I'm not sure it's > particularly useful to do so. And creating readable dumps of binary files > is trivial on most platforms. This is closely related to #1. I, too, don't think it matters much. Though the "diskdump" program method would NOT work with a binary dump. If you ask Jack, though, he'll say the diskdump program doesn't work too well anyway! :-) (he got a lot of NULL characters when dumping) > (6) It's not analagous to the more direct format already being used > to store and emulate tape files (.PID, .tape). Actually, the .PID and .tape aren't analogous to the Daves' format! > (7) There's no facility in the format to verify data integrity (as > there is in a real disk). THIS is a good one! And one that could sway me in a big way. I imagine any simple checksum scheme would work...including the one stored in the floppy sectors themselves (XOR, SHIFT). SOOOOoooo, I still think that creating/propagating new formats for floppy images is of limited value even with the reasons above (with the notable exception of #7)...though it often happens when engineers get together to re-invent something! :-) In any case, I'm always open for change. We should realize, however, that Dave S's emulator will be broken relative to a new format. I'm not worried about the SVD, I can whip up new formats for that quickly. My $.02, (maybe more), Eric -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 10 21:24:39 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 10 May 2004 21:24:39 -0500 Subject: [sebhc] RE: Dave Shaw's H8 emulator in the archive In-Reply-To: <005d01c436fa$f5d8da50$a301010a@gr390> Message-ID: <001201c436ff$1d354fd0$1f6fa8c0@eths.k12.il.us> Dave also posted this notice (under the link 'Download this Site'): ------------------------------------------------------------------------ -------- Download This Site This site will be taken down on or about July 1. The project has run its course and I need to free my AOL screen names for other use. Near as I can tell based on how the counter has been incrementing, I'm the only one accessing the site. If you would like to have a copy of the site for continued access to the design notes, etc., click here to download a copy for installation on your computer. Installation instructions: Please do not repost the site on another publicly-available server. I retain my copyright over this material; the downloaded pages are for your personal use only. **************************************************** **************************************************** Both Daves' copyrights and the unresolved issues with Heath Company copyrights are examples the reason that sebhc is a private mailing list with members-only access to the list and the archives. Information posted here is _not_ publicly available and is only intended for the personal (not-for-profit) use of list members. I am working to contact as many authors as I can in the hopes of clarifying licensing issues - most recently, we have received permission for non-profit use of Heath code from Walt Bilofsky (_his_ titles from Software Toolworks) and Dean K. Gibson (Ultimeth), creator of the HUG SY: driver and several 3rd party ROMs. I'm working on located the Daves. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Mark Garlanger > Sent: Monday, May 10, 2004 8:55 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] RE: Dave Shaw's H8 emulator in the archive > > > It seems that his license is even more restrictive(It wasn't > even included with > the code, but I found it on David Wallace's mirror of the > Heath8080A pages): > > > The emulator itself is C 2001, 2002, 2003 by David A. Shaw. > The emulator is being distributed as freeware. You may feel > free to redistribute the emulator, without modification, as > long as the copyright notices are included, and as long as > you do so at no cost except for any cost of media. > > You may feel free to modify the emulator, but please do not > redistribute the modified emulator. > > It's disappointing to have these programs/code that would > provide a good > starting points, but to have the use of the code prohibited. > > > Very nice, I was hoping the rest of that site would turn up > > eventually! > > Now, is anyone currently in contact with THAT Dave? > > > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 10 22:08:56 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 10 May 2004 22:08:56 -0500 Subject: [sebhc] Disk formats and emulators In-Reply-To: <1084150947@rothfus.com> Message-ID: <001401c43705$4cba04c0$1f6fa8c0@eths.k12.il.us> (view from 10,000 feet) > My goal is simply to make sure that the files are somewhat > "self-describing." That is, when you see one, a SIMPLE > algorithm can identify them uniquely as H8'ish things. amen > Actually, I think the original idea was to make the images > easily dumpable on an ascii terminal. The "Daves'" diskdump > program dumps images to the TT:. The thought, too, was to > make them easily mailable. kind of a nice legacy from 7-bit modem dialup days, but if binary works better, why not? > > (assuming the implementation makes the disk writable). being able to write back to the image is getting to be a high priority, since it allows "configuration" of the system to meet various hardware environments. With more real and virtual machines coming online, this kind of flexibility will be very useful. > Yup. Another one I'm not really worried about. I'm polluted > by the small 100G drive I have sitting on my desk. It would make sense that 'chunks' (images) be granular at least at the file level, and that they could be arbitrarily large (or small) within the limits of the directory scheme. Then the PC could serve directly as a host (via something as simple as a 16550 serial connection and modified HDOS driver) or an IDE hardcard could be used. Code could be dropped right into the ROM image; Steven reserved a lot of space in PAM37! ;>) > > > (7) There's no facility in the format to verify data integrity (as > > there is in a real disk). why not full-boat CRC at the file and 'chunk' level? This is getting good! Jack -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Mon May 10 22:08:28 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 10 May 2004 23:08:28 -0400 Subject: [sebhc] Disk formats and emulators In-Reply-To: <1084150947@rothfus.com> References: <1084150947@rothfus.com> Message-ID: <40A043AC.1080109@sc.rr.com> Concerning the PID tape format. These are binary images of the Heathkit H8 tapes. When the tapes were written, they contained (as well as I remember) 2 checksum bytes. If they are loaded into an H8, the checksum generated by the load and the one on the image (tape) must match or the H8 will give an error beep. Carroll Eric J. Rothfus wrote: >OK, I had three reasons, Steven had 7. He wins! > > > >>I like the header in the SVD format, but I'm still not sure if it's really >>needed. It's possible that information can be uniquely implied just by the >>size of a binary file. >> >> > >My goal is simply to make sure that the files are somewhat "self-describing." >That is, when you see one, a SIMPLE algorithm can identify them uniquely >as H8'ish things. The size of the binary file isn't really good enough. >I've run across around a dozen different formats, and those that are >self-identifying are, in the long run, much more useful. Franz (of Vintage >Computer Festival fame) proposes an XML storage format for floppy images. >Interesting, to be sure, but a bit overkill for my tastes...though I can't >really argue against it. > >Regarding the big 7: > > > >> (1) It was intended to load a hardware device (like hex dumps are used to >> load prom burners). >> >> > >Actually, I think the original idea was to make the images easily dumpable >on an ascii terminal. The "Daves'" diskdump program dumps images to the >TT:. The thought, too, was to make them easily mailable. These two things >aren't bad considerations...though I'm not religious about text formats. > > > >>(2) the text file requires conversion both before and after it's used >> (assuming the implementation makes the disk writable). >> >> > >Yup, though this format is WAY easy to convert. Most other floppy disk >image storage formats require some conversion to retrieve and to store. >Most of the time, the conversion is necessary due to descriptive (or >maybe self-descriptive) information that is being stored with the format. >A notable binary format, DMK, includes checksum information...though it >includes a bunch of other "garbage" in it too. > >Another important point about conversion is interesting for architectures >other than the H8/H89: the ability to generate interesting mixed formats. >Some software was recorded in mixed SD/DD formats (most for copy protection), >and this mixing can't be represented without cues encoded in the data file. >These cues would be decoded when being loaded into the real machine or >into an emulator. > > > >>(3) If you don't have a hardware SVD or dont' want to hold the entire >> image in memory while working with it, the text format would >> significantly complicate paging. >> >> > >Yup. Not really worried about it! :-) As with #4, I'm a bit polluted by >the 512 Meg sitting on my desktop, and a decent swapping/paging OS. > > > >>(4) More direct formats would require about the same space as the >> capacity of the disk being stored. The SVD format requires >> 3-4 times as much space, and even more with track comments. >> >> > >Yup. Another one I'm not really worried about. I'm polluted by the >small 100G drive I have sitting on my desk. In the grand scheme of >things, when I save a 10 line Word document in Windoze, and it explodes >to half-a-meg, I tend to get desensitized. Not necessarily a good thing, >I know. > > > >>(5) While the text format is "readable", I'm not sure it's >> particularly useful to do so. And creating readable dumps of binary files >> is trivial on most platforms. >> >> > >This is closely related to #1. I, too, don't think it matters much. >Though the "diskdump" program method would NOT work with a binary dump. >If you ask Jack, though, he'll say the diskdump program doesn't work >too well anyway! :-) (he got a lot of NULL characters when dumping) > > > >>(6) It's not analagous to the more direct format already being used >> to store and emulate tape files (.PID, .tape). >> >> > >Actually, the .PID and .tape aren't analogous to the Daves' format! > > > >>(7) There's no facility in the format to verify data integrity (as >> there is in a real disk). >> >> > >THIS is a good one! And one that could sway me in a big way. >I imagine any simple checksum scheme would work...including the >one stored in the floppy sectors themselves (XOR, SHIFT). > >SOOOOoooo, I still think that creating/propagating new formats for >floppy images is of limited value even with the reasons above (with >the notable exception of #7)...though it often happens when >engineers get together to re-invent something! :-) In any case, >I'm always open for change. We should realize, however, that >Dave S's emulator will be broken relative to a new format. I'm >not worried about the SVD, I can whip up new formats for that >quickly. > >My $.02, (maybe more), >Eric > > >-- >Delivered by the SEBHC Mailing List > > > From sp11 at hotmail.com Mon May 10 22:13:16 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 11 May 2004 03:13:16 +0000 Subject: [sebhc] Disk formats and emulators Message-ID: Eric says: >OK, I had three reasons, Steven had 7. He wins! Well, just as long as the quality matches the quantity. :-) >That is, when you see one, a SIMPLE algorithm can identify them uniquely >as H8'ish things. Do have any other suggestions for this besides XML? I do have XML experience, but I really hate using it for binary stuff. >Some software was recorded in mixed SD/DD formats (most for copy >protection), >and this mixing can't be represented without cues encoded in the data file. Let's call that number eight. :-) Good catch! I wasn't aware of that myself. Do you know of a specific example of something done that way? > > (4) ...The SVD format requires 3-4 times as much space,... > >Yup. Another one I'm not really worried about. Okay, but how big is the archive collection going to eventually be? > > (6) It's not analagous to the ... tape files (.PID, .tape). > >Actually, the .PID and .tape aren't analogous to the Daves' format! Would you want them to be? One advantage of the H8 tape format was that it was designed to be media-independent. So you could use it with any type, density, speed, etc. of media, although I think it was only practially implemented on audio cassettes and paper tape. So no additional header info is needed, and it already has crc built in. >I'm always open for change. We should realize, however, that >Dave S's emulator will be broken relative to a new format. Whatever format we wind up storing them in, we can provide a convertor program to put it back into the "DS" format (execept for the few that cannot be represented that way, of course). Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Mon May 10 23:27:32 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Mon, 10 May 2004 23:27:32 -0500 Subject: [sebhc] Large Picture of H9 Terminal Message-ID: <008301c43710$4bbf2900$a301010a@gr390> Does anyone have a H9 terminal that they could take a picture of and email me? Ideally two, one close-up of the keyboard and one straight on. Thanks, Mark From jack.rubin at ameritech.net Tue May 11 07:49:53 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 11 May 2004 07:49:53 -0500 Subject: [sebhc] design parameters for H8 emulation Message-ID: <000001c43756$74f33eb0$1f6fa8c0@eths.k12.il.us> You might find it worth while to take a look at Mike Evenson's FLEX emulator for the Motorola 680x family ( http://www.evenson-consulting.com/swtpc/ ) for some helpful ideas about emulator design - - the design is modular in a way that follows the architecture of the original systems. You can change monitor ROMs and bus cards at will, so that you can upgrade from a 6800 to a 6809 processor and boot various operating systems. Mike has also provided a stub template so that other cards can be emulated or even prototyped. Given our ROM library (I just got a copy of PAM8/GO to complete the collection) and the real-world incompatibility of some CPU/ROM/controller/OS combinations, this is a valuable feature. - there is a full virtual disk system which allows reading/writing disks at the file level and transparently moving from real to virtual disks - the virtual disk system is enhanced by NetPC (Scott talked about this last week) which allows a PC to act as a large disk on either a real or virtual system. As with the SVD, you can mix real and virtual disks in real time. Wouldn't it make sense to spend time now on developing some overall system design parameters before getting too deep into issues like disk formats? It sounds like there is a lot of overlap in the several projects currently underway; it would be a shame to lose the synergy further down the road because of unexamined assumptions at the beginning of the process. It will also allow people to work independently on various aspects of the system (e.g. terminal emulation, storage subsystems, etc.) simultaneously. Jack -- Delivered by the SEBHC Mailing List From eric at rothfus.com Tue May 11 14:35:53 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Tue, 11 May 2004 15:35:53 -0400 Subject: [sebhc] Disk formats and emulators In-Reply-To: (sp11@hotmail.com) References: Message-ID: <1084297796@rothfus.com> As Jack said "This is getting good!" > Steven: > > Do have any other suggestions for this besides XML? I do have XML > experience, but I really hate using it for binary stuff. I don't think that the file needs to be XML or even ascii for that matter. A binary file would be fine, but maybe it would have a header that is somewhat identifiable. You know, something that uniquely says "H8/H89". Of all of the formats that I've seen, most have uniquely identifying characteristics or formats that a simple test would prove out. Here are three examples: - DMK - (a TRS-80 format) looking at the data (binary) in the file, there are well known characteristics that must be in place. For example, a particular integer (encoded in a certain endian) in a particular location indicates the size of the file. That needs to be exact. And the odds of it "just occurring" within a binary file is quite low. This is an example of a hand-crafted but simple algorithm. - SVD - the SVD internal format (not the ascii Daves' format) is binary, but includes a three line header with version #, sides, tracks, and sectors. There is a well-known set of version #'s that are unlikely to occur in a random binary file. - JV1 - (another TRS-80 format) this one is tough. It is an obsolete format that is simply a binary image of the floppy. It is assumed to be SD (WD-1771) format, 10 sectors, 35 tracks. It is HARD to determine if you have a JV1 file in front of you. The algorithm I use (no laughing please) is: - pretend it IS a JV1, and load it up - look at the directory track given the assumptions of tracks/sectors - ensure that a distribution of the data in the tracks LOOKS like a directory Yeah, I know, messy. The important part of this discussion, IMHO, is that there be SOMETHING that lets us know what type of image, its variable structure (like tracks, sectors, encoding), and the version of the image file. >> Some software was recorded in mixed SD/DD formats (most for copy >> protection), >> and this mixing can't be represented without cues encoded in the data file. > > Steven: > > Let's call that number eight. :-) Good catch! I wasn't aware of that > myself. Do you know of a specific example of something done that way? I don't know of any examples in the H8/H89 world. I know of quite a few in the Apple and TRS-80 world. For the TRS-80, the Model II always (?) encodes its first track in SD, even if the disk is DD. The Model I/III/IV game Zaxxon uses mixed density encoding as a copy protection mechanism. The Apple is even more tricky, part of their encoding CAN be what half-track the sector is on. Nasty, nasty. This, too, is used in copy-protection. I'm not sure if we really need to worry about this in the H8/H89 world. But I haven't seen too much software. Maybe someone out there.... > Jack: > > being able to write back to the image is getting to be a high > priority, since it allows "configuration" of the system to meet > various hardware environments. With more real and virtual machines > coming online, this kind of flexibility will be very useful. I think you're quite right. And this is probably the main reason why most TRS-80 emulators use a binary format. I haven't checked the source, but it wouldn't surprise me if they didn't memory-map the image, or chunks of it. There's only ONE image format that I've seen that is, in its entirety, mappable into memory: DMK. But that is a WAY complicated format that hides the data within floppy-controller garbage. So it looks like we're well on our way to a new format! But the important question is: "What do we call it?" :-) Eric -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Tue May 11 16:19:47 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 11 May 2004 14:19:47 -0700 (PDT) Subject: [sebhc] Disk formats and emulators Message-ID: <200405112119.OAA02550@clulw009.amd.com> >From: "Eric J. Rothfus" ---snip--- > >So it looks like we're well on our way to a new format! But the >important question is: "What do we call it?" :-) > >Eric Hi Ok. It looks like we would need something like a header that describes the data that follows. It would map data offset to physical tracks with track size and encoding methods. Even in double sided soft sectored, one can alternate sides or simply run up one side and down the next. We should try to make things as universal as we can so that any oddball condition can be handled. The header portion should be in both human and machine readable format. Something like a restricted language. This way, the proper interpreter can handle the file as well as a human. If all is forgotten, a human should, from the header be able to recreate the disk or file. The file it self can be in binary or ASCII. If in ASCII, I do recommend using hex instead of octal ( very anti-H8 front panel ). Other things that would be needed are things like the encoding methods ( nrz, mfm, fm, m2fm etc. ) and the actual track format. What ever converter we write doesn't have to use all this information or provide it. We do need to define it. If we do it well, it may be more universally used by others for general floppy exchange. Here is an example of a real floppy format that exist to give an idea of the strange things that exist ( I have a machine with this ): 8 inch 16 hard sectored disk single sided two sectors per track of 8 hard indexes per sector. Sector size is 1024 by 20 bit words in msb first order. Tracks are headered by a track number that is in lsb first order Data is encoded as fm. There are no special sector marks. If our headers were done correctly, we should be able to handle any odd ball type formats. We would need a central location for maintaining a centralized document file for the exact meanings of elements of the headers. Still the headers would need to be self descriptive enough that for someone that understands floppy formats they would be able to create the disk image from that description. The headers might only describe the format relative to a specific disk controller but they should also, when available, describe the format of the raw data. We can start with our HDOS, Heath CPM and possibly heath tape data. We should make each incremental step to not trap ourselves into thinking we really covered it all. As you can see from the format I mentioned, there are many strange things out there. Any part of the header that isn't used or interpreted by the tool that is scanning the file, must report to the user that some section was skipped and for what reason. It might even be that it wasn't up to that level or that it was outside the scope of that tools use. This way if something didn't work, the user would know where to look. It would be something they'd find in the header. One thing about the centralized ( and mirrored ) definitions. There should be a web searchable name in the header that one could use to find the definitions on the web. I know, I'm assuming that the web still exist in the future. Still, we need to make things as self useful without just making grossly large files. I don't like the idea of having the header information in separate files from the data. Sounds ambitious! Dwight -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Tue May 11 17:17:07 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 11 May 2004 15:17:07 -0700 (PDT) Subject: [sebhc] More Emulator (Got BASIC running) & Q on interrupts Message-ID: <200405112217.i4BMH2Sj004125@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 11 May 2004 22:24:58 -0000 Made reasonable progress today... The front panel implementation is complete, looks and works quite nicely. This morning, I implemented the single-step interrupt, and support for the console break to monitor function --- what a pain! - spent several hours figuring it out. System kept hanging and when I stopped and looked, it was in the TAPE LOAD function! Turns out that the "invalid" 0+# key combination used to force monitor entry produces an 8 when run through the 'RCK' routine at 003,260 - this is the same as the '8' button, so the system thinks you are doing LOAD when you hold these keys down. The real H8 does this too, however it relies on the fact that you will continually interrupt the tape loader while the keys are held down ... thats why the display flickers and you get sporadic beeps when holding these keys --- poor design if you ask me. Anyway, my emulator now does it just like the real H8. Btw, I'm too lazy to implement an entire keyboard interrupt handler just to detect the these two-key combinations, so when in console mode, I have used 'R' to Reset (0+/) and 'M' to force monitor entry (0+#). Not having a special INT-9 handler will also insure that the emulator remains highly portable. After that, I could start/stop/step program just like on the real H8. This afternoon, I cooked up a rudimentary virtual 8251 console port tied to a terminal window, decoded the BHBASIC.PID file that Carrol sent to me, and loaded it into the emulator. Launched it at 040,100 and up came the startup prompts! Took a little while to figure out that I needed an interrupt (3) tied to the virtual 8251 for input, but after that input worked as well, and I was able to enter, list and run (correctly): 10 FOR I=1 to 100 20 PRINT I 30 NEXT I [I didn't know that the H8 basic did word completion!] As far as I can tell, the BASIC seems fully functional. Still have to implement the complete H19 (or perhaps H9 at first), the serial I/O redirector (for real serial I/O), and possibly a file I/O redirector - so you can load/save .PID files directly. Haven't even started moving the debugger over from the Altair simulator, however it shouldn't take too long as it's all been done and is working - just a matter of connecting it up - mostly cosmetic things. Haven't even thought about the disk controller yet (need docs etc.) Question: I didn't find a standard for the interrupt assignments in the docs - I note that the serial port allows you to configure them any way you like. - Is there a standard assignment for the basic hardware interrupt (Console, Tape etc.) - Does this need to be configurable in an INI file or some such? Regards, Dave Dunfield -- 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 leeahart at earthlink.net Tue May 11 23:50:01 2004 From: leeahart at earthlink.net (Lee Hart) Date: Tue, 11 May 2004 21:50:01 -0700 Subject: [sebhc] Disk formats and emulators References: <1084297796@rothfus.com> Message-ID: <40A1ACF9.2033@earthlink.net> Eric J. Rothfus wrote: > > As Jack said "This is getting good!" > > > Steven: > > > > Do have any other suggestions for this besides XML? I do have XML > > experience, but I really hate using it for binary stuff. > > I don't think that the file needs to be XML or even ascii > for that matter. A binary file would be fine, but maybe it > would have a header that is somewhat identifiable. You know, > something that uniquely says "H8/H89". > > Of all of the formats that I've seen, most have uniquely identifying > characteristics or formats that a simple test would prove out. Here > are three examples: > > - DMK - (a TRS-80 format) looking at the data (binary) in the file, > there are well known characteristics that must be in place. For > example, a particular integer (encoded in a certain endian) in a > particular location indicates the size of the file. That needs > to be exact. And the odds of it "just occurring" within a binary > file is quite low. This is an example of a hand-crafted but > simple algorithm. > > - SVD - the SVD internal format (not the ascii Daves' format) is > binary, but includes a three line header with version #, sides, > tracks, and sectors. There is a well-known set of version #'s > that are unlikely to occur in a random binary file. > > - JV1 - (another TRS-80 format) this one is tough. It is an > obsolete format that is simply a binary image of the floppy. > It is assumed to be SD (WD-1771) format, 10 sectors, 35 tracks. > It is HARD to determine if you have a JV1 file in front of you. > The algorithm I use (no laughing please) is: > > - pretend it IS a JV1, and load it up > - look at the directory track given the assumptions of tracks/sectors > - ensure that a distribution of the data in the tracks LOOKS like > a directory > > Yeah, I know, messy. > > The important part of this discussion, IMHO, is that there be SOMETHING > that lets us know what type of image, its variable structure (like > tracks, sectors, encoding), and the version of the image file. > > >> Some software was recorded in mixed SD/DD formats (most for copy > >> protection), > >> and this mixing can't be represented without cues encoded in the data file. > > > > Steven: > > > > Let's call that number eight. :-) Good catch! I wasn't aware of that > > myself. Do you know of a specific example of something done that way? > > I don't know of any examples in the H8/H89 world. I know of quite a > few in the Apple and TRS-80 world. For the TRS-80, the Model II > always (?) encodes its first track in SD, even if the disk is DD. > The Model I/III/IV game Zaxxon uses mixed density encoding as a copy > protection mechanism. The Apple is even more tricky, part of their > encoding CAN be what half-track the sector is on. Nasty, nasty. > This, too, is used in copy-protection. > > I'm not sure if we really need to worry about this in the H8/H89 > world. But I haven't seen too much software. Maybe someone out > there.... > > > Jack: > > > > being able to write back to the image is getting to be a high > > priority, since it allows "configuration" of the system to meet > > various hardware environments. With more real and virtual machines > > coming online, this kind of flexibility will be very useful. > > I think you're quite right. And this is probably the main reason > why most TRS-80 emulators use a binary format. I haven't checked > the source, but it wouldn't surprise me if they didn't memory-map > the image, or chunks of it. There's only ONE image format that > I've seen that is, in its entirety, mappable into memory: DMK. > But that is a WAY complicated format that hides the data within > floppy-controller garbage. > > So it looks like we're well on our way to a new format! But the > important question is: "What do we call it?" :-) It is really all that hard? The "standard" disk format for the H8 and H89 is the hard-sector (H17) format; 10 256-bytes sectors per track, 40 tracks, single-density, single-sided. Everything is (or can be put) into that format. To recreate a physical disk from a file, you should be able to just load those 256 x 10 x 40 = 102,400 bytes onto a disk and it will work. The "standard" soft-sector format (which only came about after Heath produced the soft-sector controllers) is essentially the same. All that's different is the order of the sectors within each track, and that the code in the boot tracks (if any) was to boot with a soft-sector disk instead of a hard-sector disk. All Heath and HUG software was distributed in these formats, as far as I can recall. They never used double-sided or double-density or 80-track formats for distribution disks. So, perhaps all one needs is a clear ASCII message at the beginning of a file that clearly identifies it as a Heath disk image, followed by the 102,400 byte binary image. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed May 12 07:02:30 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 12 May 2004 05:02:30 -0700 (PDT) Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: <200405121202.i4CC2USj017897@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 12 May 2004 12:31:23 -0000 I have all of the H8 software that I have images for running under my emulator now. This includes: H8DEMO, BUG-8, TED-8, HASL-8, BHBASIC and EXBASIC In doing so, I discovered a problem with HASL-8 : If at the "BINARY (Y/N)?" prompt, I answer 'Y', the emulator aborts with an invalid opcode at $3221 (062 041). This is a 0x20 byte which appears to be a space at the end of a "BINARY TAPE (Y/N)? " prompt (and is indeed an invalid 8080 opcode). It is however getting called! - the offending call instruction is located at $3961 (071 141). The opcode is C3(303) 21(041) 32(062) If you look at this block of code, you can see it calls a subroutine to get a key, compares it for 'Y', and if not, branches away - if 'Y' is entered, it proceeds to CALL $3221 which contains an invalid opcode! So .. it looks like there's either a bug in HASL-8, or my copy of it is corrupted. Could anyone with an original copy of HASL-8 please check these two locations and confirm (or deny) that this is what is supposed to be located there? Regards, -- 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 jack.rubin at ameritech.net Wed May 12 07:37:03 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 12 May 2004 07:37:03 -0500 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: <200405121202.i4CC2USj017897@gatekeeper.evocative.com> Message-ID: <003101c4381d$d43d4a10$1f6fa8c0@eths.k12.il.us> > So .. it looks like there's either a bug in HASL-8, or my > copy of it is corrupted. > > Could anyone with an original copy of HASL-8 please check > these two locations and confirm (or deny) that this is what > is supposed to be located there? > If you're doubly lucky, the tapes I sent you will have a copy of HASL-8 _and_ you'll be able to load it _and_ it will run. Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed May 12 10:52:36 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 12 May 2004 15:52:36 +0000 Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: >So .. it looks like there's either a bug in HASL-8, or my copy of it is >corrupted. Wow .. it sure sounds corrupted. I wonder how these files were created, since the CRC at the end of the file is good. Anyone know? On the off chance that is really is a bug, it would have to be one that was not apparent on the H8. Can you set your emulator to ignore an unimplemented code and keep running like a real 8080 would? See if the software happens to "work" in that case. _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Wed May 12 12:45:33 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Wed, 12 May 2004 13:45:33 -0400 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: References: Message-ID: <40A262BD.1020701@sc.rr.com> I just tried loading HASL-8 on my H8 to see what would happen. It first said: LISTING TO PRINTER (I entered N) then: BINARY (I entered Y) then it asked: BINARY TAPE (I entered Y) then it asked: INPUT? That was as far as I could go without looking at the docs. If I understood you right, you were interested in the contents of code beginning at 062 041. Is this correct? Carroll Steven Parker wrote: >> So .. it looks like there's either a bug in HASL-8, or my copy of it is >> corrupted. > > > Wow .. it sure sounds corrupted. I wonder how these files were > created, since the CRC at the end of the file is good. Anyone know? > > On the off chance that is really is a bug, it would have to be one > that was not apparent on the H8. Can you set your emulator to ignore > an unimplemented code and keep running like a real 8080 would? See if > the software happens to "work" in that case. > > _________________________________________________________________ > MSN Toolbar provides one-click access to Hotmail from any Web page ? > FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed May 12 13:21:18 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 12 May 2004 18:21:18 +0000 Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: Since Carroll was able to run HASL-8 past the point in question, I loaded it up in the (DAW) emulator and looked at those locations... >It is however getting called! - the offending call instruction is located >at >$3961 (071 141). The opcode is C3(303) 21(041) 32(062) Except that 303 is a JMP, not a CALL. However, I do see a CALL there (315), to that address (did you just write it down wrong?) Maybe this really is a bug, but one that works on a real H8 (or perhaps if you change your emulator to ignore undefined codes). In a real 8080, the eight codes that match 0?0 are all no-ops. Maybe Carroll would confirm the contents of those locations on his real H8? By the way, it doesn't run on the DAW emulator even that far - the first key I hit on the keyboard causes the INT light to go out and it gets lost in some loop. I'm guessing there's still some bug in that emulator related to I/O or interrupt function. Cheers, - Steven _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed May 12 17:27:55 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 12 May 2004 15:27:55 -0700 (PDT) Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: <200405122227.i4CMRtuY005032@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 12 May 2004 22:57:16 -0000 At 18:21 12/05/2004 +0000, you wrote: >Since Carroll was able to run HASL-8 past the point in question, I loaded it >up in the (DAW) emulator and looked at those locations... > >>It is however getting called! - the offending call instruction is located >>at >>$3961 (071 141). The opcode is C3(303) 21(041) 32(062) > >Except that 303 is a JMP, not a CALL. However, I do see a CALL there (315), >to that address (did you just write it down wrong?) Maybe this really is a >bug, but one that works on a real H8 (or perhaps if you change your emulator >to ignore undefined codes). In a real 8080, the eight codes that match 0?0 >are all no-ops. Yeah, it's a typo on my part ... I work in hex (main reason I never really liked the H8) - and I sometimes interchange C3 (JMP) with CD (CALL), apparently I wrote down C3 - in this case it does not matter, as it's a valid transfer of control to an invalid opcode. My emulator has a 4k traceback buffer which allows me to see "how it got here" up to 4k instructions in the past, so I could easily see exactly where it came from. If you look at the code, you will see that Data and Executable codes are mixed all over the place... Here's the offending sequence, with enough extra shown around it so that you can see code/data: 3200 C2 DF 31 ..1 JNZ $31DF <- Executable code 3203 7D } MOV A,L 3204 32 64 2A 2d* STA $2A64 3207 FE D5 .. CPI $D5 3209 C2 3A 32 .:2 JNZ $323A 320C F7 . RST 6 <- Ends here with transfer to vector 320D 13 . INX D <- This must be data 320E 00 . NOP 320F 42 B MOV B,D <- This is clearly data 3210 49 I MOV C,C 3211 4E N MOV C,M 3212 41 A MOV B,C 3213 52 R MOV D,D 3214 59 Y MOV E,C 3215 20 DB $20 3216 54 T MOV D,H 3217 41 A MOV B,C 3218 50 P MOV D,B 3219 45 E MOV B,L 321A 20 RIM 321B 28 ( DB $28 321C 59 Y MOV E,C 321D 2F / CMA 321E 4E N MOV C,M 321F 29 ) DAD H 3220 3F ? CMC 3221 20 DB $20 <- Offending instruction (probably SPACE) 3222 CD 46 20 .F CALL $2046 <- Immediately followed by executable 3225 CD 49 20 .I CALL $2049 3228 2E 3A .: MVI L,$3A 322A FE 59 .Y CPI $59 322C CA 36 32 .62 JZ $3236 322F 2E C3 .. MVI L,$C3 ... much deleted ... 3950 05 . DCR B <- This is data 3951 53 S MOV D,E 3952 41 A MOV B,C 3953 56 V MOV D,M 3954 45 E MOV B,L 3955 3F ? CMC 3956 CD 46 20 .F CALL $2046 <- This is executable 3959 CD 49 20 .I CALL $2049 395C FE 59 .Y CPI $59 395E C2 C2 38 ..8 JNZ $38C2 3961 CD 21 32 .!2 CALL $3221 <- Here's where it came from 3964 21 01 81 !.. LXI H,$8101 3967 CD 03 33 ..3 CALL $3303 396A 21 37 18 !7. LXI H,$1837 396D CD 22 33 ."3 CALL $3322 >Maybe Carroll would confirm the contents of those locations on his real H8? Thats what I'm hoping - I also got a set of tapes from Jack today, so if I can get my H8 to load I may be able to perform this test as well. >By the way, it doesn't run on the DAW emulator even that far - the first key >I hit on the keyboard causes the INT light to go out and it gets lost in >some loop. I'm guessing there's still some bug in that emulator related to >I/O or interrupt function. I had a fair bit of trouble with the interrupt system, as the H8 uses interrupts a lot, and some tricks they use are not so obvious - Now that I have it figured out, all the code that I have (including HASL-8 if I ignore the bad opcode) appears to run correctly under the emulator. I didn't do much to it today (have to do my real work sometimes) - I added a key to toggle the panel display ON/OFF, you can run run with the H8 panel visible and a 13 line terminal, or with the H8 panel hidden and a 24 line terminal - I also added a status line on the bottom, and a few other cosmetic improvements. I'll try and post a preliminary version of it somewhere soon so that you guys can play with it if you are interested. Regards, -- 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 May 12 17:27:55 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 12 May 2004 15:27:55 -0700 (PDT) Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: <200405122227.i4CMRpuY005030@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 12 May 2004 22:57:13 -0000 Hi Carroll, >That was as far as I could go without looking at the docs. >If I understood you right, you were interested in the contents of code >beginning at 062 041. Is this correct? I just wanted to make sure that my copy of HASL-8 was not corrupted. I want to know if location 062 041 contains 040 (ASCII space = invalid opcode) and if location 071 141 contains 315 041 062 (CALL 062,041) If it does, then this is a bug in HASL-8. Regards, -- 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 May 12 17:27:55 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 12 May 2004 15:27:55 -0700 (PDT) Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: <200405122227.i4CMRtuY005031@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 12 May 2004 22:57:15 -0000 At 15:52 12/05/2004 +0000, you wrote: >>So .. it looks like there's either a bug in HASL-8, or my copy of it is >>corrupted. > >Wow .. it sure sounds corrupted. I wonder how these files were created, >since the CRC at the end of the file is good. Anyone know? Well... A: I didn't check the CRC - I just clipped the code out of the PID file and loaded it into the emulator, and B: The PID file was probably created by someone who loaded the tape and then saved it - if it was corrupted in memory between these two events, it would have been saved with a correct CRC (for the incorrect code), so I think that it's possible that it has been corrupted. >On the off chance that is really is a bug, it would have to be one that was >not apparent on the H8. Can you set your emulator to ignore an >unimplemented code and keep running like a real 8080 would? See if the >software happens to "work" in that case. I've added a '/I' option to Ignore bad opcoes, and the program does appear to work, however you can't always just Ignore a bad opcode - due to imcomplete decoding in the 8080, some "bad" opcodes behave just like other valid opcodes (which do something) - $20 (040) is "lucky" in that it decodes to a NOP, so it doesn't matter. My favorite use of this was I once modified my assembler to output $DD for all CALL instructions - worked fine on my 8080 which decodes it as a CALL, however it drove a friend with a Z80 nuts! Regards, -- 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 May 12 18:42:58 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 12 May 2004 16:42:58 -0700 (PDT) Subject: [sebhc] Go nuts guys (emulator preview) Message-ID: <200405122342.i4CNgquY006291@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 12 May 2004 23:58:09 -0000 Hi Guys, I downloaded some more images from the SEBHC site today, and so far they all seem to work under my emulator (except for the HASL-8 bug with the bad opcode, which works with the /Ignore option). The complete list I have tried is: H8DEMO - H8 demo program BUG8 - H8 console debugger TED8 - H8 text editor HASL8 - H8 Assembly language BHBASIC - Benton harbor basic EXBASIC - Extended Benton harbor basic HANGMAN - Hangman game H8CRAPS - Craps game H8HEXPAW - Hexpawn game H8NIM - NIM game Lots more to do, however I've decided that it's at least reached the point where you might have a bit of fun foolin with it, so I have made it available for download. Please point your browser to: http://www.dunfield.com/pub/h8.zip Please keep in mind that this is very preliminary, and nowhere near production quality code (whatdya expect in 3 days) - Constructive input is be appreciated, but please keep laughter to yourself. Also, be aware that I do plan many features that are not currently implemented - no need to ask for them - you can get a better idea of what it should be able to do when I am done by looking at my Altair simulator (see reference in H8 README.TXT) NOW - If only I can get my hands on the disk controller specs! 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 CarrollWaddell at sc.rr.com Wed May 12 18:51:55 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Wed, 12 May 2004 19:51:55 -0400 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: <200405122227.i4CMRpuY005030@gatekeeper.evocative.com> References: <200405122227.i4CMRpuY005030@gatekeeper.evocative.com> Message-ID: <40A2B89B.9010509@sc.rr.com> Yes. That is in those locations. Carroll Dave Dunfield wrote: >Hi Carroll, > > > >>That was as far as I could go without looking at the docs. >>If I understood you right, you were interested in the contents of code >>beginning at 062 041. Is this correct? >> >> > >I just wanted to make sure that my copy of HASL-8 was not corrupted. >I want to know if location 062 041 contains 040 (ASCII space = invalid opcode) >and if location 071 141 contains 315 041 062 (CALL 062,041) > >If it does, then this is a bug in HASL-8. > >Regards, > > From dave04a at dunfield.com Wed May 12 19:07:53 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 12 May 2004 17:07:53 -0700 (PDT) Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: <200405130007.i4D07ruY006789@gatekeeper.evocative.com> by softdnserror with SMTP; 13 May 2004 00:31:14 -0000 >>I just wanted to make sure that my copy of HASL-8 was not corrupted. >>I want to know if location 062 041 contains 040 (ASCII space = invalid opcode) >>and if location 071 141 contains 315 041 062 (CALL 062,041) >Yes. That is in those locations. >Carroll Humm ... looks like a bug! Thanks - 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 May 12 20:40:56 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 13 May 2004 01:40:56 +0000 Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: >Well... A: I didn't check the CRC - I just clipped the code out of the PID >file and loaded it into the emulator, But when you load it with the PAM-8 "load" function it will check it. The other emulator loads via the monitor, I checked it that way and also by computing the crc externally. >...however you can't always just Ignore a bad opcode - $DD .. decodes it as >a CALL, Neat, I didn't remember that. I'm guessing that any 11xx1101 would be a CALL, and any 1100x011 would be a JMP, and 110x1001 would be RET (and of course, all 00xxx000 are NOP). I suppose for accurate emulation all of those would have to be handled. >NOW - If only I can get my hands on the disk controller specs! Who was inputting the other manuals? Could you do the H-17 (op) manual next? I't would be a shame to stall Dave while he's on a roll! Also, anyone got H-37/47/67 manuals? Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed May 12 20:05:15 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 12 May 2004 20:05:15 -0500 Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <000001c43886$59e8f930$1f6fa8c0@eths.k12.il.us> is in the 'emulators' directory. First attempts in a DOS window on my W2K machine dump me back to the command prompt when I hit the 'go' key. I loaded hangman and h8demo with the same results - setting PC to 040.000 worked fine, then boom. I'll go try it on my real DOS machine next. I'll read the instructions too. way cool. Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed May 12 22:01:39 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 12 May 2004 22:01:39 -0500 Subject: [sebhc] Dave Dunfield's H8 emulator In-Reply-To: <000001c43886$59e8f930$1f6fa8c0@eths.k12.il.us> Message-ID: <000201c43896$9cf33190$1f6fa8c0@eths.k12.il.us> Not even RTFM - just RTFScreen - setting the PC to 040.100 works just fine on my windows machines (2K and XP); just barely loads on my 386SX/16. Thanks Dave! > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Jack Rubin > Sent: Wednesday, May 12, 2004 8:05 PM > To: SEBHC > Subject: [sebhc] Dave Dunfield's H8 emulator > > > is in the 'emulators' directory. First attempts in a DOS > window on my W2K machine dump me back to the command prompt > when I hit the 'go' key. I loaded hangman and h8demo with the > same results - setting PC to 040.000 worked fine, then boom. > I'll go try it on my real DOS machine next. I'll read the > instructions too. > > way cool. > > Jack > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed May 12 22:02:06 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 12 May 2004 22:02:06 -0500 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: Message-ID: <000301c43896$acfa6f40$1f6fa8c0@eths.k12.il.us> 37-67 and 47 manuals are in the archive; 17 is going into the hopper in a minute. sheesh - all I want to do is play hangman! > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Steven Parker > Sent: Wednesday, May 12, 2004 8:41 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] HASL-8 Bug/Corruption? > > > >Well... A: I didn't check the CRC - I just clipped the code > out of the > >PID file and loaded it into the emulator, > > But when you load it with the PAM-8 "load" function it will > check it. The > other emulator loads via the monitor, I checked it that way > and also by > computing the crc externally. > > >...however you can't always just Ignore a bad opcode - $DD > .. decodes > >it as > >a CALL, > > Neat, I didn't remember that. I'm guessing that any 11xx1101 > would be a > CALL, and any 1100x011 would be a JMP, and 110x1001 would be > RET (and of > course, all 00xxx000 are NOP). I suppose for accurate > emulation all of > those would have to be handled. > > >NOW - If only I can get my hands on the disk controller specs! > > Who was inputting the other manuals? Could you do the H-17 > (op) manual > next? I't would be a shame to stall Dave while he's on a > roll! Also, > anyone got H-37/47/67 manuals? > > Cheers, > > - Steven > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.com/go/onm00200415ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed May 12 23:23:21 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 12 May 2004 23:23:21 -0500 Subject: [sebhc] floppy disk resources Message-ID: <000001c438a2$06e67340$1f6fa8c0@eths.k12.il.us> The Operation Manual for the H17 floppy disk system is in the /documents/H8-hdw directory; the H17 ROM and a listing of the H17 ROM source are in the /software/h8-roms directory. If you are building a virtual disk subsystem, you might find the 2 Daves' docs a valuable reference. Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Thu May 13 03:53:11 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 01:53:11 -0700 (PDT) Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <200405130853.i4D8rAuY015133@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 09:05:47 -0000 At 20:05 12/05/2004 -0500, you wrote: >is in the 'emulators' directory. First attempts in a DOS window on my >W2K machine dump me back to the command prompt when I hit the 'go' key. >I loaded hangman and h8demo with the same results - setting PC to >040.000 worked fine, then boom. I'll go try it on my real DOS machine >next. I'll read the instructions too. Hi Jack, I have not seen a total exit in all of my testing ... Can you tell me anything about your system configuration, the launch command line and the EXACT keys entered from the moment you launch until "boom". Btw, it's 040.100, but this should not cause the program to exit - just the virtual H8 to crash. I have tried this under Win2k, however I have not tried this exact type of failure - please give me the info requested above and I will give it a go. 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 Thu May 13 03:53:14 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 01:53:14 -0700 (PDT) Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <200405130853.i4D8rEuY015134@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 09:05:49 -0000 At 22:01 12/05/2004 -0500, you wrote: >Not even RTFM - just RTFScreen - setting the PC to 040.100 works just >fine on my windows machines (2K and XP); just barely loads on my >386SX/16. So does this mean you got it to work? I'd still like to follow up the "crash and burn" problem that you were having at 040.000. Btw, an SX16 should work, but it's getting on the low range for the emulator - There are two speed issues: A) The constant H8 interrupt takes a fair bit of work to simulate, and the # instructions/sec seems to go down exponentially as the PC clock slows. B) The emulator requires a calibration to emulate this interrupt correctly - It has an ongoing "correction" which gets applied to account for drift in the operating environment, but it does not currently perform a calibration at startup - I have been assuming a relatively fast machine. It will probably work OK if you leave it sit long enough! My 386/33 took a few seconds to get synced, then everything was OK - it executes about 260,000 virtual 8080 instruction/second (on contrast to about 20mips on my P3/733). Once I add a startup calibration it should work much better on slower machines. 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 Thu May 13 03:53:15 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 01:53:15 -0700 (PDT) Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: <200405130853.i4D8rFuY015132@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 09:05:45 -0000 At 01:40 13/05/2004 +0000, you wrote: >>Well... A: I didn't check the CRC - I just clipped the code out of the PID >>file and loaded it into the emulator, > >But when you load it with the PAM-8 "load" function it will check it. The >other emulator loads via the monitor, I checked it that way and also by >computing the crc externally. If you look at my emulator (it's available for download now), you will see that I have not implemented the download port yet... I have implemented a very simple loaded which lets you get data into the emulator, but does not use the PID format (yet) and does not do it through PAM-8. Btw, does anyone have detailed information on the PID format? >>...however you can't always just Ignore a bad opcode - $DD .. decodes it as >>a CALL, > >Neat, I didn't remember that. I'm guessing that any 11xx1101 would be a >CALL, and any 1100x011 would be a JMP, and 110x1001 would be RET (and of >course, all 00xxx000 are NOP). I suppose for accurate emulation all of >those would have to be handled. Yeah - only problem is I do not know exactly what all the unimplemented opcodes partially decode to .. I could probably guess, but even that would take some time looking at the instruction encodings, and I don't really have time to verify them all ... So for now I've only implemented "ignore", however this will not mimic a real 8080 for many opcodes. >>NOW - If only I can get my hands on the disk controller specs! > >Who was inputting the other manuals? Could you do the H-17 (op) manual >next? I't would be a shame to stall Dave while he's on a roll! Also, >anyone got H-37/47/67 manuals? I wouldn't say I'm stalled --- lots to do yet! Regards, -- 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 Thu May 13 04:18:12 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 02:18:12 -0700 (PDT) Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <200405130918.i4D9IBuY017547@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 09:23:12 -0000 At 20:05 12/05/2004 -0500, you wrote: >is in the 'emulators' directory. First attempts in a DOS window on my >W2K machine dump me back to the command prompt when I hit the 'go' key. >I loaded hangman and h8demo with the same results - setting PC to >040.000 worked fine, then boom. I'll go try it on my real DOS machine >next. I'll read the instructions too. I have found the cause of this: When 040.000 is the monitors RAM area. It just happens that at 040.003 there is $C9(311) which is a RET instruction. PAM-8 is setting the virtual 8080 stack pointer to $FFFF (top of RAM) when it launches the code, which causes the emulation engine to try and retrieve a 16 bit value from FFFF,0000 wrapping a segment register, and causing a processor exception. This will not happen in normal operation (unless you normally wrap the stack into the ROM space). I can fix it, however since I use SI for the virtual 8080 PC, I cannot easily do this in two 8-bit operations, so it would slow down the emulator - the same is true of pushing/poping the other register pairs over the FFFF:0000 boundary. I see three options: 1 - do nothing - the emulator will crash under these conditions, however it will operate at it's highest speed 2 - split all 16 bit accesses into 2 8-bit accesses, this will slow it down, but it will crash the virtual 8080 only - just like the real H8. 3 - Perform a test and halt the simulation (eventually into the debugger) if a stack wrap occurs. Preferences? Regards, -- 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 Thu May 13 04:26:08 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 13 May 2004 09:26:08 +0000 Subject: [sebhc] HASL-8 Bug/Corruption? Message-ID: >Btw, does anyone have detailed information on the PID format? Yea, I posted it last week. Grab the sebhc.0405 file from the archives, or get the H8-5 manual. But if you are emulating the serial I/O to the tape, the format will probably be transparent anyway since PAM takes care of it for you. > >Neat, I didn't remember that. I'm guessing that any 11xx1101 would be a > >CALL, and any 1100x011 would be a JMP, and 110x1001 would be RET (and of > >course, all 00xxx000 are NOP). I suppose for accurate emulation all of > >those would have to be handled. > >Yeah - only problem is I do not know exactly what all the unimplemented >opcodes >partially decode to .. I believe what I listed above is the complete set. If you add all those you should have every possible code covered. >I loaded hangman and h8demo with the same results - setting PC to >040.000 worked fine, then boom. I'm surprised it worked at all. 040.000 is where PAM's ram scratchpad is. Tape software starts at 040.100! Cheers, - Steven _________________________________________________________________ Getting married? Find tips, tools and the latest trends at MSN Life Events. http://lifeevents.msn.com/category.aspx?cid=married -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 13 06:30:08 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 13 May 2004 06:30:08 -0500 Subject: [sebhc] Dave Dunfield's H8 emulator In-Reply-To: <200405130853.i4D8rEuY015134@gatekeeper.evocative.com> Message-ID: <000001c438dd$a5904580$1f6fa8c0@eths.k12.il.us> > > Btw, an SX16 should work, but it's getting on the low range > for the emulator - There are two speed issues: > > B) The emulator requires a calibration to emulate this > interrupt correctly > - It has an ongoing "correction" which gets applied to > account for drift > in the operating environment, but it does not currently > perform a calibration > at startup - I have been assuming a relatively fast machine. > It will probably work OK if you leave it sit long enough! > My 386/33 took a few seconds to get synced, then > everything was OK - it > executes about 260,000 virtual 8080 instruction/second (on > contrast to > about 20mips on my P3/733). > Once I add a startup calibration it should work much > better on slower > machines. > Usually, H8 comes up with a constant beep on the sx. It responds to a reset but then goes back to beeping as soon as a key is pressed. It does seem to be attempting to synch, but it's not succeeding. I'll try giving it several-to-many seconds between keypresses to see if that helps, but clearly this is not a big problem. Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 13 06:44:48 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 13 May 2004 06:44:48 -0500 Subject: [sebhc] Dave Dunfield's H8 emulator In-Reply-To: <200405130918.i4D9IBuY017547@gatekeeper.evocative.com> Message-ID: <000101c438df$b27c2780$1f6fa8c0@eths.k12.il.us> > > I have found the cause of this: > > When 040.000 is the monitors RAM area. It just happens that > at 040.003 there is $C9(311) which is a RET instruction. > > I see three options: > > 1 - do nothing - the emulator will crash under these > conditions, however > it will operate at it's highest speed > > 2 - split all 16 bit accesses into 2 8-bit accesses, this > will slow it down, > but it will crash the virtual 8080 only - just like the real H8. > > 3 - Perform a test and halt the simulation (eventually into > the debugger) if > a stack wrap occurs. > I would suggest a combination of (1) and (3) - under normal conditions, do nothing and let the emulator run at full speed. Implement (3) as an option (like the Ignore parameter) for debugging. A semi-related issue is how fast the emulator should run relative to wall-time. Are you planning to allow an option for running H8 as if it were a true 1MHz system regardless of the system clock of the host? I think this will become more important if you interface to real-world devices like disk drives and tape drives. Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Thu May 13 06:48:20 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 04:48:20 -0700 (PDT) Subject: [sebhc] RE: Go nuts guys (emulator preview) Message-ID: <200405131148.i4DBmGuY020701@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 11:54:30 -0000 >One minor quirk I saw was no MON light one time when I brought it up, even >after reset (R). But I couldn't replicate that - it came up with it on for >other tries. I found something which may be related to this. I was drawing the MON light OFF when I drew the front panel - since PAM-8 writes the output latch anyway when it starts it didn't matter at first, however now that I can toggle the panel On/Off, the light gets turned off if you do that - since the emulator only redraws the light when the output latch bit changes, the light stays OFF, even though it's actually ON in the output latch. I have corrected this so that when drawing the front panel, I always reflect the current state of the lights. 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 jack.rubin at ameritech.net Thu May 13 06:48:55 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 13 May 2004 06:48:55 -0500 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: Message-ID: <000201c438e0$455848e0$1f6fa8c0@eths.k12.il.us> > I'm surprised it worked at all. 040.000 is where PAM's ram > scratchpad is. > Tape software starts at 040.100! > That's what front panels are for - you need good tools to do a good job of breaking things. I really enjoyed walking through PAM RAM and watching TICCNT ticking away! Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Thu May 13 07:13:20 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 05:13:20 -0700 (PDT) Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <200405131213.i4DCDKuY021217@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 12:36:34 -0000 At 06:44 13/05/2004 -0500, you wrote: >> >> I have found the cause of this: >> >> When 040.000 is the monitors RAM area. It just happens that >> at 040.003 there is $C9(311) which is a RET instruction. >> >> I see three options: >> >> 1 - do nothing - the emulator will crash under these >> conditions, however >> it will operate at it's highest speed >> >> 2 - split all 16 bit accesses into 2 8-bit accesses, this >> will slow it down, >> but it will crash the virtual 8080 only - just like the real H8. >> >> 3 - Perform a test and halt the simulation (eventually into >> the debugger) if >> a stack wrap occurs. >> > >I would suggest a combination of (1) and (3) - under normal conditions, >do nothing and let the emulator run at full speed. Implement (3) as an >option (like the Ignore parameter) for debugging. Unfortuntely such a "combination" is not practical - to perform a test to see if stack wrap checking is enabled would take as many instructions as to check the stack pointer - so you would be no further ahead - I'll probably just perform the (3) test all the time - (But later - got lots else to do for now) - in the meantime, don't go executing RET without a valid stack. Once I have the debugger installed (hopefully in the next few days), I can add the stack check and have it trap to the debugger when it finds a pending fault. >A semi-related issue is how fast the emulator should run relative to >wall-time. Are you planning to allow an option for running H8 as if it >were a true 1MHz system regardless of the system clock of the host? I >think this will become more important if you interface to real-world >devices like disk drives and tape drives. The 8080 engine already has a throttle implemented, however because I have not installed the calibration, it does not get set. I will make this an option, which allows you to run "real time" or "full bore". [It's really cool on my Altair simulator - I have a chess game which has 5 levels of play - on the top level, it takes about 1/2 hour to make a move on the actual machine (or the emulator in real-time), but in "full bore" mode on my P3/733 it takes only a few seconds]. Regards, -- 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 Thu May 13 07:13:17 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 05:13:17 -0700 (PDT) Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <200405131213.i4DCDHuY021216@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 12:36:33 -0000 >Usually, H8 comes up with a constant beep on the sx. It responds to a >reset but then goes back to beeping as soon as a key is pressed. It does >seem to be attempting to synch, but it's not succeeding. I'll try giving >it several-to-many seconds between keypresses to see if that helps, but >clearly this is not a big problem. Hi Jack, This is "normal" on a slow machine - it will (well - should) eventually sort itself out, but it takes a LONG time on a machine less than 386/33 - if you want closely, you will (after while) see the display segments start to update - one at a time. This is because the emulator is inserting virtual interrupts between intervals of 8080 instructions, and on a slow machine they are inserted very infrequently - the VM self-adjusts to bring them to a 500hz rate, however this adjustment is very slow, so that it does not get fooled by momentary changes in system performance (interrupts, multitasking etc.) - It's more of a "slow drift". Basically what is happening is that the H8 turns on the buzzer, and is now waiting for a timeout - on a slow machine, the interrupts are happening so infrequently that this takes a LONG time. I chose this method rather than programming a PC timer interrupt at a 500hz rate because it makes the emulator very much more portable and tolerant of non-DOS environments... I may still change it to a better approach, but at this stage it works well enough - on my todo list. 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 jack.rubin at ameritech.net Thu May 13 07:27:13 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 13 May 2004 07:27:13 -0500 Subject: [sebhc] Dave Dunfield's H8 emulator In-Reply-To: <200405131213.i4DCDHuY021216@gatekeeper.evocative.com> Message-ID: <001b01c438e5$9f4fa640$1f6fa8c0@eths.k12.il.us> > This is "normal" on a slow machine - it will (well - should) > eventually sort itself out, but it takes a LONG time on a > machine less than 386/33 > - if you want closely, you will (after while) see the display > segments start to update - one at a time. > > This is because the emulator is inserting virtual interrupts > between intervals of 8080 instructions, and on a slow machine > they are inserted very infrequently - the VM self-adjusts to > bring them to a 500hz rate, however this adjustment is very > slow, so that it does not get fooled by momentary changes in > system performance (interrupts, multitasking etc.) > - It's more of a "slow drift". > > Basically what is happening is that the H8 turns on the > buzzer, and is now waiting for a timeout - on a slow machine, > the interrupts are happening so infrequently that this takes > a LONG time. > yeah - I've been thinking about upgrading to a 386DX/33 - this may be the killer app that pushes me over the edge! Jack -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Thu May 13 08:16:08 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Thu, 13 May 2004 09:16:08 -0400 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: References: Message-ID: <40A37518.70106@sc.rr.com> When I created the tape images about 15 years ago, I copied the original Heath tapes, byte for byte, to my PC, and gave them the PID extension. At that time I was working for IBM and PID was the name given to tapes sent from the plant containing software updates. This is how I came up with the PID file extension. If you will look at the H8-5 book, you will find the format for Heath tapes. There are some SYNC bytes, a byte count of the number of bytes on the tape, the data, and a CRC check. This is exactly what the PID file is. I've also noticed some question about the 040 000 address. When you do a tape dump to write a tape image, 040 000 and 040 001 contain the beginning dump address for the tape. In the case of tape programs, if will be 040 000 - 100 040 001 - 040 That's because all tape programs start at 040 100. (Remember that the low byte of a word is stored first.) To dump a tape, 3 things must be set. 1. The 040 000 address must be set with the start dump address. 2. The PC reg must be set to 040 100 (the beginning of the program) 3. The memory address on the front panel LEDS is set to the ending address of the tape dump. Hope this helps Carroll Steven Parker wrote: >> Btw, does anyone have detailed information on the PID format? > > > Yea, I posted it last week. Grab the sebhc.0405 file from the > archives, or get the H8-5 manual. But if you are emulating the serial > I/O to the tape, the format will probably be transparent anyway since > PAM takes care of it for you. > >> >Neat, I didn't remember that. I'm guessing that any 11xx1101 would >> be a >> >CALL, and any 1100x011 would be a JMP, and 110x1001 would be RET >> (and of >> >course, all 00xxx000 are NOP). I suppose for accurate emulation all of >> >those would have to be handled. >> >> Yeah - only problem is I do not know exactly what all the >> unimplemented opcodes >> partially decode to .. > > > I believe what I listed above is the complete set. If you add all > those you should have every possible code covered. > >> I loaded hangman and h8demo with the same results - setting PC to >> 040.000 worked fine, then boom. > > > I'm surprised it worked at all. 040.000 is where PAM's ram scratchpad > is. Tape software starts at 040.100! > > Cheers, > > - Steven > > _________________________________________________________________ > Getting married? Find tips, tools and the latest trends at MSN Life > Events. http://lifeevents.msn.com/category.aspx?cid=married > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Thu May 13 10:23:14 2004 From: leeahart at earthlink.net (Lee Hart) Date: Thu, 13 May 2004 08:23:14 -0700 Subject: [sebhc] HASL-8 Bug/Corruption? References: Message-ID: <40A392E2.53DB@earthlink.net> >>...however you can't always just Ignore a bad opcode - $DD .. >> decodes it as a CALL, Steven Parker wrote: > Neat, I didn't remember that. I'm guessing that any 11xx1101 would > be a CALL, and any 1100x011 would be a JMP, and 110x1001 would be > RET (and of course, all 00xxx000 are NOP). I suppose for accurate > emulation all of those would have to be handled. Careful; while they may be "don't cares" for the 8080, they are NOT for the Z80 or 8085! You would wind up with code that wouldn't work on an H89 or Z-100. And it was pretty common to put a Z80 CPU board in the H8. >> NOW - If only I can get my hands on the disk controller specs! >> Also, anyone got H-37/47/67 manuals? I have these for the H89, but not the H8. They "ought" to be the same, since the same code generally works in both. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Thu May 13 10:21:45 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 13 May 2004 15:21:45 +0000 Subject: [sebhc] Re: opcode emulation (was: HASL-8 Bug/Corruption) Message-ID: Lee says (regarding "unimplemented" opcodes): >Careful; while they may be "don't cares" for the 8080, they are NOT for >the Z80 or 8085! You would wind up with code that wouldn't work on an >H89 or Z-100. And it was pretty common to put a Z80 CPU board in the H8. I was definitely not suggesting anyone PROGRAM using these! Only that an 8080 emulator should handle them just like a real chip would. By the way, the DAW emulator models the z80 configuration for the H8 (HA-8-6 CPU). >> >> NOW - If only I can get my hands on the disk controller specs! > >> Also, anyone got H-37/47/67 manuals? >I have these for the H89, but not the H8. They "ought" to be the same, >since the same code generally works in both. They are already in the archives now, thanks to Jack! (including the 89 version of the -37). Cheers, - Steven _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Thu May 13 13:03:34 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 13 May 2004 11:03:34 -0700 (PDT) Subject: [sebhc] Dave Dunfield's H8 emulator Message-ID: <200405131803.i4DI3SuY028197@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 13 May 2004 18:24:29 -0000 >> Basically what is happening is that the H8 turns on the >> buzzer, and is now waiting for a timeout - on a slow machine, >> the interrupts are happening so infrequently that this takes >> a LONG time. >> > >yeah - I've been thinking about upgrading to a 386DX/33 - this may be >the killer app that pushes me over the edge! > >Jack Hi Jack, Don't go blow the bank yet - I found a minor bug - in my effort to not take forever to sync, I kludged the adjustment to be adaptive - ie: if it's way off, it moves more quickly - however a slow machine starts off so far from where I default it, that it moves so far it undershoots 0 and wraps to a very slow value - process repeats with indeteriminate settings fluctuating all over the place and the virtual cpu barely crawls along ... not a problem is the machine is fast enough that the setting is fairly high. Don't have much time today to look further into it, however I will try to get it fixed by the weekend (or implement the real algorithm). 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 Thu May 13 23:03:26 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 14 May 2004 04:03:26 +0000 Subject: [sebhc] Tape images Message-ID: Carroll says: >I copied the original Heath tapes, byte for byte, to my PC, and gave them >the PID extension. So that really is from the tape then, not memory contents dumped back out again? That would explain one curious thing I noticed, too. While the format doesn't define any bytes after the crc, the PID files all contain $FF after it. BUT..if you had dumped them with PAM-8 they would contain a 2nd copy of the CRC instead. I never knew how the tapes were manufactured (on the other hand, I designed the program that manufactured the diskettes). It's nice also to know where the name PID came from too. :-) But.. do the letters stand for anything? Cheers, - Steven _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri May 14 08:49:10 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 14 May 2004 09:49:10 -0400 Subject: [sebhc] Tape images In-Reply-To: References: Message-ID: <40A4CE56.6000407@sc.rr.com> Let me correct myself. I loaded the tapes into the H8. Then changed the NORM INTCG switch to INTHG. Then pressed the dump key on the H8. This sent the tape from memory to my PC just as if I had written another copy of the tape. The H8 recreates the CRC after the data is written (Done by PAM-8) and writes the CRC. About the PID, my memory is a little foggy. I retired from IBM in 92, but I THINK that PID was Program Information Distribution. Program changes or updates came on reels of tape. That is the only reason that I associated the PID with a tape. Also, if you can find a PAM-8 listing, you can find the routines there to read, write, generate, and check the data and CRC. Carroll Steven Parker wrote: > Carroll says: > >> I copied the original Heath tapes, byte for byte, to my PC, and gave >> them the PID extension. > > > So that really is from the tape then, not memory contents dumped back > out again? That would explain one curious thing I noticed, too. > While the format doesn't define any bytes after the crc, the PID files > all contain $FF after it. BUT..if you had dumped them with PAM-8 > they would contain a 2nd copy of the CRC instead. I never knew how > the tapes were manufactured (on the other hand, I designed the program > that manufactured the diskettes). > > It's nice also to know where the name PID came from too. :-) But.. > do the letters stand for anything? > > Cheers, > > - Steven > > _________________________________________________________________ > Is your PC infected? Get a FREE online computer virus scan from > McAfee? Security. > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Fri May 14 09:04:13 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 14 May 2004 07:04:13 -0700 (PDT) Subject: [sebhc] Emulator update Message-ID: <200405141404.i4EE48uY056277@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 14 May 2004 14:12:51 -0000 Hi Guys, I have just posted an updated edition of my H8 emulator to my web site. As before, please point your browser to: http://www.dunfield.com/pub/h8.zip I have fixed up a few minor issues which were reported with the first one. - The MONITOR light should now always be updated correctly - It *SHOULD* run better on a slow machine, although it will still be pokey on anything less than a 486. (I'm still not happy with the slow machine calibration, and will at some point completely redesign it). I have added the ability to mount files for Input and Output via the auxiliary serial port - this allows PAM-8 to read wnd write .PID files. I have added a simple PC mode debugger which lets you get inside the 8080 CPU in ways that PAM-8 can't (You can even debug PAM-8). I have tidied up the user interface, added more status prompts, a simple HELP system etc. Have fun! Regards, Dave Dunfield -- 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 Fri May 14 09:40:10 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 14 May 2004 14:40:10 +0000 Subject: [sebhc] Tape images Message-ID: Carroll says: >I loaded the tapes into the H8. Then changed the NORM INTCG switch to >INTHG. Then pressed the dump key on the H8. This sent the tape from memory >to my PC just as if I had written another copy of the tape. The H8 >recreates the CRC after the data is written (Done by PAM-8) and writes the >CRC. Now I'm really confused. If the files were made from memory, then it's possible that a glitch could alter them but still have a good checksum. But PAM-8 actually writes out the CRC twice. (The 2nd time is just to be sure that the first one gets out cleanly). Your files have it once, followed by $FF. >Also, if you can find a PAM-8 listing, you can find the routines there to >read, write, generate, and check the data and CRC. The listing is in the FTP archives. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Fri May 14 11:14:58 2004 From: waltm22 at comcast.net (Walter Moore) Date: Fri, 14 May 2004 09:14:58 -0700 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: <200405122227.i4CMRtuY005032@gatekeeper.evocative.com> Message-ID: <000101c439ce$9e40f580$0700a8c0@walterp4> When I looked at Dave's offending code sequence, It sure seemed to me that there was a possibility that an extraneous zero byte might have entered the Code at 0x320E when the original tape was last read or maybe when it was written. It was just one of those "programmer" things where you want to take a look at it and double check it. So it was time to get out the old H8-5 card and try and load my copy of HASL-8. After four or five attempts, I actually got something on the tape to load, but the loaded image ended somewhere in the 065.xxx rage. I think it was TED-8. So I tried the next image on the tape (The TED-8 and HASL-8 came on the same tape, with each image written twice). It actually loaded! Wow. It was long enough too! So I poked around to look at the code sequence. The instructions didn't match what Dave reported from the emulator. I did find the "SAVE?" text, followed by some calls and tried to follow them. No such luck. My thoughts were that I had a different version of HASL-8 than what is in the archive. So I decided to hook a terminal up to the card and actually run the program so I could get a version number. That required removing the card to change jumpers. Just to let you know how long it had been since I last used the card, it was jumpered for a 300 baud 20mA current loop from back when I had an H-9 and LA36 Decwriter II, say 1979. After changing the jumpers and hoping I hooked the terminal up correctly, I reinstalled the card and tried to load the tape. No such luck. I haven't been able to load anything since. I plan to run the tests in the manual this weekend and recalibrate the card. Where is all this leading to...? In looking at the archives, there isn't any version information in the file names or anywhere else that I saw. I think we need to have this information available. For example, I have Extended Benton Harbor Basic versions 10.01.00 and 10.02.00 on tape (don't know if they are good). Does anyone have suggestions on filename format? Or do we go with a tree whenever there is more than one version. Now I'll throw in the problem where two people upload the same version, but there is a difference of a couple of bytes. If both copies work, then how is that to be resolved? ..walt -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri May 14 14:05:14 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 14 May 2004 15:05:14 -0400 Subject: [sebhc] HASL-8 Bug/Corruption? In-Reply-To: <000101c439ce$9e40f580$0700a8c0@walterp4> References: <000101c439ce$9e40f580$0700a8c0@walterp4> Message-ID: <40A5186A.50005@sc.rr.com> By the way, if anyone wants a cassette tape with the software in question, I will mail you a physical tape that I am using. Carroll Walter Moore wrote: >When I looked at Dave's offending code sequence, It sure seemed to me that >there was a possibility that an extraneous zero byte might have entered the >Code at 0x320E when the original tape was last read or maybe when it was >written. It was just one of those "programmer" things where you want to >take a look at it and double check it. > >So it was time to get out the old H8-5 card and try and load my copy of >HASL-8. After four or five attempts, I actually got something on the tape >to load, but the loaded image ended somewhere in the 065.xxx rage. I think >it was TED-8. So I tried the next image on the tape (The TED-8 and HASL-8 >came on the same tape, with each image written twice). It actually loaded! >Wow. It was long enough too! > >So I poked around to look at the code sequence. The instructions didn't >match what Dave reported from the emulator. I did find the "SAVE?" text, >followed by some calls and tried to follow them. No such luck. > >My thoughts were that I had a different version of HASL-8 than what is in >the archive. So I decided to hook a terminal up to the card and actually >run the program so I could get a version number. That required removing the >card to change jumpers. Just to let you know how long it had been since I >last used the card, it was jumpered for a 300 baud 20mA current loop from >back when I had an H-9 and LA36 Decwriter II, say 1979. > >After changing the jumpers and hoping I hooked the terminal up correctly, I >reinstalled the card and tried to load the tape. No such luck. I haven't >been able to load anything since. I plan to run the tests in the manual >this weekend and recalibrate the card. > >Where is all this leading to...? > >In looking at the archives, there isn't any version information in the file >names or anywhere else that I saw. I think we need to have this information >available. For example, I have Extended Benton Harbor Basic versions >10.01.00 and 10.02.00 on tape (don't know if they are good). Does anyone >have suggestions on filename format? Or do we go with a tree whenever there >is more than one version. Now I'll throw in the problem where two people >upload the same version, but there is a difference of a couple of bytes. If >both copies work, then how is that to be resolved? > >..walt > > > > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri May 14 14:03:46 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 14 May 2004 15:03:46 -0400 Subject: [sebhc] Tape images In-Reply-To: References: Message-ID: <40A51812.4010803@sc.rr.com> What you suggest is not outside the realm of possibility. As well as memory serves, Heath recommended that you do a load and then a dump to create a working image of the software. The CRC bytes are not stored in memory. They are generated by the monitor program as tape is being loaded or written. Also, I have used this HASL image on my H8 without any trouble. Also again, here are the program version numbers of the PID software that I uploaded. HASL-8 Issue # 04.05.00 TED-8 Issue # 3.05.00 BUG-8 Issue # 02.05.00 BH Basic Issue # 05.01.02 Extended BH Basic Issue # 10.05.00 Hangman Issue # 20.00.00 If I can create any more confusion, don't hesitate to let me know. I'm know far and wide for my confusinating skills. Carroll Steven Parker wrote: > Carroll says: > >> I loaded the tapes into the H8. Then changed the NORM INTCG switch to >> INTHG. Then pressed the dump key on the H8. This sent the tape from >> memory to my PC just as if I had written another copy of the tape. >> The H8 recreates the CRC after the data is written (Done by PAM-8) >> and writes the CRC. > > > Now I'm really confused. If the files were made from memory, then > it's possible that a glitch could alter them but still have a good > checksum. But PAM-8 actually writes out the CRC twice. (The 2nd time > is just to be sure that the first one gets out cleanly). Your files > have it once, followed by $FF. > >> Also, if you can find a PAM-8 listing, you can find the routines >> there to read, write, generate, and check the data and CRC. > > > The listing is in the FTP archives. > > _________________________________________________________________ > Check out the coupons and bargains on MSN Offers! > http://youroffers.msn.com > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Fri May 14 19:04:29 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 14 May 2004 17:04:29 -0700 (PDT) Subject: [sebhc] Updated updated H8 emulator Message-ID: <200405150004.i4F04SuY071486@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 15 May 2004 00:23:48 -0000 If anyone downloaded my updated simulator earlier today, please grab it again. In playing with it this afternoon, I found and corrected a few minor problems: - GO in the debugger would not proceed from a breapoint (It would immediately trap at the same breakpoint). Now GO ignores breakpoints for one instruction, allowing you to continue from a breakpoint. - I discovered that BHBASIC requires DTR to be low or it will not read/write a tape image. This prevented you from loading a .PID file as a basic DUMP/LOAD image. I have modified the virtual serial port so that DTR will be asserted (LOW) if either an input or output file is mounted on the device. This allows you to tell if a file is mounted, and also to tell the end of file on input (since my simulator auto-dismounts the file on EOF). - Fixed a couple of minor places where interactive prompts would leave the cursor in the incorrect state for PANEL/TTY mode. - I have decided to change the default tape image file extension from ".PID" to ".H8T", which stands for "H8 Tape" - this makes more sense to me than "PID" which has no meaning to the H8. I have also renamed my 'L=' load files to ".H8L" from ".PGM". [If/When I do a disk simulator, I will probably call the disk files ".H8D" for "H8 Disk"] - Corrected the copyright notice date in the help file (thats what I get for cut/paste from another file) Just uploaded the revised simulator: http://www.dunfield.com/pub/h8.zip 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 jack.rubin at ameritech.net Sat May 15 00:37:12 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 15 May 2004 00:37:12 -0500 Subject: [sebhc] Updated updated H8 emulator now in archive In-Reply-To: <200405150004.i4F04SuY071486@gatekeeper.evocative.com> Message-ID: <000001c43a3e$aca64e20$1f6fa8c0@eths.k12.il.us> updated in the archive as well Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Friday, May 14, 2004 7:04 PM > To: sebhc at sebhc.org > Subject: [sebhc] Updated updated H8 emulator > > > If anyone downloaded my updated simulator earlier today, > please grab it again. In playing with it this afternoon, I > found and corrected a few minor problems: > > - GO in the debugger would not proceed from a breapoint (It > would immediately > trap at the same breakpoint). Now GO ignores breakpoints > for one instruction, > allowing you to continue from a breakpoint. > > - I discovered that BHBASIC requires DTR to be low or it > will not read/write a > tape image. This prevented you from loading a .PID file as > a basic DUMP/LOAD > image. > I have modified the virtual serial port so that DTR will > be asserted (LOW) if > either an input or output file is mounted on the device. > This allows you to > tell if a file is mounted, and also to tell the end of > file on input (since > my simulator auto-dismounts the file on EOF). > > - Fixed a couple of minor places where interactive prompts > would leave the cursor > in the incorrect state for PANEL/TTY mode. > > - I have decided to change the default tape image file > extension from ".PID" to > ".H8T", which stands for "H8 Tape" - this makes more sense > to me than "PID" > which has no meaning to the H8. I have also renamed my > 'L=' load files to ".H8L" > from ".PGM". [If/When I do a disk simulator, I will > probably call the disk files > ".H8D" for "H8 Disk"] > > - Corrected the copyright notice date in the help file > (thats what I get for > cut/paste from another file) > > Just uploaded the revised simulator: > http://www.dunfield.com/pub/h8.zip > > 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 dave04a at dunfield.com Sat May 15 09:39:57 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sat, 15 May 2004 07:39:57 -0700 (PDT) Subject: [sebhc] YAEU (Yet Another Emulator Update) Message-ID: <200405151439.i4FEdvtK016058@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 15 May 2004 14:50:24 -0000 Hi Guys, Sorry to do this to you again - I'm really going to try and slow down the rate at which I publish updates, however I felt these changes were significant enough to warrant it. - I have added a LOT more help. Most important, I have covered all of the PAM-8 keypad commands. This will make the simulator much more useful to people who are not already familier with the H8. - I have gotten rid of my kludged 'L=' load files, and have replaced them with the ability to load/import standard Intel or Motorola hex download files. This makes it very easy to import data from standard 8080 cross development tools (Such as my C compiler, assembler etc.) As before, point your browser to: http://www.dunfield.com/pub/h8.zip [Jack - Is it possible for me to post updates directly to the sebhc site?] 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 jack.rubin at ameritech.net Sat May 15 09:59:22 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 15 May 2004 09:59:22 -0500 Subject: [sebhc] uploading to the sebhc archives Message-ID: <000001c43a8d$35adaa30$1f6fa8c0@eths.k12.il.us> List members can (and should!) upload items of interest to the archives by pointing your ftp client to archive.sebhc.org/pub/uploads. Remember that anonymous login is not supported - you must logon as heathkit/hdos8bit. After items are put into the uploads folder, the list admin (usually me) will scan and review the material and then move it to the appropriate archive directory. You cannot download items from the uploads directory, nor can you upload items to any other directory. This rigamarole reflects the realities of today's hostile internet environment - open ftp sites are often subverted as relay stations by net punks. Please send notificiation to the list when you post new items. Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sun May 16 15:15:56 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 16 May 2004 13:15:56 -0700 (PDT) Subject: [sebhc] H8 Tape interface debugging? Message-ID: <200405162015.i4GKFu68038726@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 16 May 2004 20:28:44 -0000 Hi Guys, I fired up my H8 today, and for the first time connected a tape recorder and tried to load the software tapes. The good news is that the interface appears to "mostly" work - it detects the tape and walks through memory as it loads - everything looks right. The bad news is that the only tape I could get to load was BUG-8. It loads consistantly, while the other programs TED8, HASL8, BHBASIC all fail. I've tried various tape volume levels and no joy yet. At first I thought this might be because I have only a single 4K memory board in my H8 - at least the manual I have says 4K, and there is only one memory board, however looking at the SP which is initialized by PAM-8 suggests there is 8K (it's set to 077,377 = $3FFF, and since memory starts at 040,000 ($2000) ... $2000-$3FFF is 8K - the schematic for the RAM board calls it a 4k/8k board, so it looks like I have 8K after all. I tried keying in the memory test from the beginning of the operation manual, setting it for 8K, and it ran with no errors - so I'm pretty sure there is 8K of functional RAM in there. I also tried dumping memory out to the tape and restoring it. I was able to dump/load a few small blocks, however if I try to dump/load a large block, it always fails - looks like something is drifting (it's worth noting that Bug-8 is the smallest of the Heathkit images). Anybody got any hints/suggestions/experiences with debugging the H8 tape interface? 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 labomb at rochester.rr.com Sun May 16 15:38:12 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Sun, 16 May 2004 16:38:12 -0400 Subject: [sebhc] H8 Tape interface debugging? References: <200405162015.i4GKFu68038726@gatekeeper.evocative.com> Message-ID: <007201c43b85$b6d57c70$02a8a8c0@IBMD9HY10WBGXB> Hi Dave, Page 40 of the H8-5 manual (posted to the archives) details an alignment procedure that you should execute. It doesn't require any equipment ...only jumpering test points and observing the on-board LED. The procedure sets the space detector and PLL circuits ... essential for proper operation I've discovered in the past. Also, the usual 'cassette caveats' apply ... adjust tone/volume until things works reliably (as reliable as this medium can be :)). You might also try disconnecting from the Record jack (leaving only Play attached) when attempting to load. As you note the circuits could be drifting ... but as likely the tape medium could simply be marginal. Scott ----- Original Message ----- From: "Dave Dunfield" To: Sent: Sunday, May 16, 2004 4:15 PM Subject: [sebhc] H8 Tape interface debugging? > Hi Guys, > > I fired up my H8 today, and for the first time connected a tape recorder > and tried to load the software tapes. > > The good news is that the interface appears to "mostly" work - it detects > the tape and walks through memory as it loads - everything looks right. > > The bad news is that the only tape I could get to load was BUG-8. It > loads consistantly, while the other programs TED8, HASL8, BHBASIC all > fail. I've tried various tape volume levels and no joy yet. > > At first I thought this might be because I have only a single 4K memory > board in my H8 - at least the manual I have says 4K, and there is only > one memory board, however looking at the SP which is initialized by PAM-8 > suggests there is 8K (it's set to 077,377 = $3FFF, and since memory starts > at 040,000 ($2000) ... $2000-$3FFF is 8K - the schematic for the RAM board > calls it a 4k/8k board, so it looks like I have 8K after all. > > I tried keying in the memory test from the beginning of the operation > manual, setting it for 8K, and it ran with no errors - so I'm pretty > sure there is 8K of functional RAM in there. > > I also tried dumping memory out to the tape and restoring it. I was > able to dump/load a few small blocks, however if I try to dump/load a > large block, it always fails - looks like something is drifting (it's > worth noting that Bug-8 is the smallest of the Heathkit images). > > Anybody got any hints/suggestions/experiences with debugging the > H8 tape interface? > > 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 CarrollWaddell at sc.rr.com Sun May 16 16:59:25 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sun, 16 May 2004 17:59:25 -0400 Subject: [sebhc] 64K memory Message-ID: <40A7E43D.200@sc.rr.com> If anyone is interested, I have been designing a 64K memory card for the H8. I'm sending Jack a prototype of the card to try out. I've tested it, but I'd like it tested by someone beside me. If there is enough interest, we could get a PCB fab house like PCBExpress to make the PC boards. If could get 20 or 25 people who wanted one, we could get them for about $55 each. This is a half size (6 x 6) card. PCBExpress boards would be about $35 each, so the card and all parts would be about $55 if you had to buy everything. Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 16 19:11:42 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 16 May 2004 19:11:42 -0500 Subject: [sebhc] 64K memory In-Reply-To: <40A7E43D.200@sc.rr.com> Message-ID: <000201c43ba3$88cf46d0$1f6fa8c0@eths.k12.il.us> Carroll - I'm looking forward to trying it out - with that much real estate, how about adding some additional features? I'd like to see a 16550 or two to allow high speed serial sharing with (yet to be configured) PC disk server. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Sunday, May 16, 2004 4:59 PM > To: sebhc at staunch89er.com > Subject: [sebhc] 64K memory > > > If anyone is interested, I have been designing a 64K memory > card for the > H8. I'm sending Jack a prototype of the card to try out. I've > tested it, > but I'd like it tested by someone beside me. If there is enough > interest, we could get a PCB fab house like PCBExpress to make the PC > boards. If could get 20 or 25 people who wanted one, we could > get them > for about $55 each. This is a half size (6 x 6) card. > PCBExpress boards > would be about $35 each, so the card and all parts would be > about $55 if > you had to buy everything. > Carroll > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sun May 16 19:22:07 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sun, 16 May 2004 20:22:07 -0400 Subject: [sebhc] 64K memory In-Reply-To: <000201c43ba3$88cf46d0$1f6fa8c0@eths.k12.il.us> References: <000201c43ba3$88cf46d0$1f6fa8c0@eths.k12.il.us> Message-ID: <40A805AF.2010706@sc.rr.com> If your speaking about high speed serial on an H8, the only problem I see is that the H8 itself isn't high speed. The next project I want to build is a board that the H8 thinks is the tape interface (H8-5) but can connect to the PC by serial port and let the PC emulate 2 cassette machines. I'm working on a new H19 emulation program, and I plan to include software that will do the cassette emulation. Carroll Jack Rubin wrote: >Carroll - I'm looking forward to trying it out - with that much real >estate, how about adding some additional features? I'd like to see a >16550 or two to allow high speed serial sharing with (yet to be >configured) PC disk server. > >Jack > > > >>-----Original Message----- >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of >>Carroll Waddell >>Sent: Sunday, May 16, 2004 4:59 PM >>To: sebhc at staunch89er.com >>Subject: [sebhc] 64K memory >> >> >>If anyone is interested, I have been designing a 64K memory >>card for the >>H8. I'm sending Jack a prototype of the card to try out. I've >>tested it, >>but I'd like it tested by someone beside me. If there is enough >>interest, we could get a PCB fab house like PCBExpress to make the PC >>boards. If could get 20 or 25 people who wanted one, we could >>get them >>for about $55 each. This is a half size (6 x 6) card. >>PCBExpress boards >>would be about $35 each, so the card and all parts would be >>about $55 if >>you had to buy everything. >>Carroll >> >>-- >>Delivered by the SEBHC Mailing List >> >> >> > >-- >Delivered by the SEBHC Mailing List > > > From jack.rubin at ameritech.net Sun May 16 19:40:16 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 16 May 2004 19:40:16 -0500 Subject: [sebhc] 64K memory In-Reply-To: <40A805AF.2010706@sc.rr.com> Message-ID: <000301c43ba7$86978270$1f6fa8c0@eths.k12.il.us> We're kind of talking about the same thing, except that the board would masquerade as a disk controller instead of a tape controller - and the PC would look like a disk drive instead of a tape deck. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Sunday, May 16, 2004 7:22 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] 64K memory > > > If your speaking about high speed serial on an H8, the only problem I > see is that the H8 itself isn't high speed. > The next project I want to build is a board that the H8 thinks is the > tape interface (H8-5) but can connect to the PC by serial > port and let > the PC emulate 2 cassette machines. I'm working on a new H19 > emulation > program, and I plan to include software that will do the cassette > emulation. > Carroll > > Jack Rubin wrote: > > >Carroll - I'm looking forward to trying it out - with that much real > >estate, how about adding some additional features? I'd like > to see a > >16550 or two to allow high speed serial sharing with (yet to be > >configured) PC disk server. > > > >Jack > > > > > > > >>-----Original Message----- > >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > >>Carroll Waddell > >>Sent: Sunday, May 16, 2004 4:59 PM > >>To: sebhc at staunch89er.com > >>Subject: [sebhc] 64K memory > >> > >> > >>If anyone is interested, I have been designing a 64K memory > >>card for the > >>H8. I'm sending Jack a prototype of the card to try out. I've > >>tested it, > >>but I'd like it tested by someone beside me. If there is enough > >>interest, we could get a PCB fab house like PCBExpress to > make the PC > >>boards. If could get 20 or 25 people who wanted one, we could > >>get them > >>for about $55 each. This is a half size (6 x 6) card. > >>PCBExpress boards > >>would be about $35 each, so the card and all parts would be > >>about $55 if > >>you had to buy everything. > >>Carroll > >> > >>-- > >>Delivered by the SEBHC Mailing List > sebhc-request at sebhc.org. > >> > >> > >> > > > >-- > >Delivered by the SEBHC Mailing List > > > > > > > -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 16 20:40:22 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 17 May 2004 01:40:22 +0000 Subject: [sebhc] serial tape substitute Message-ID: Carroll says: >The next project I want to build is a board that the H8 thinks is the tape >interface (H8-5) but can connect to the PC by serial port and let the PC >emulate 2 cassette machines. Remember that the H8-5 can do that already. There's a "port interchange" switch on it to make the H8 think that the serial port is the cassette port. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sun May 16 21:04:43 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sun, 16 May 2004 22:04:43 -0400 Subject: [sebhc] serial tape substitute In-Reply-To: References: Message-ID: <40A81DBB.4050807@sc.rr.com> You're right. I had forgotten that even though I've been making tapes that way from my PC images. CEW Steven Parker wrote: > Carroll says: > >> The next project I want to build is a board that the H8 thinks is the >> tape interface (H8-5) but can connect to the PC by serial port and >> let the PC emulate 2 cassette machines. > > > Remember that the H8-5 can do that already. There's a "port > interchange" switch on it to make the H8 think that the serial port is > the cassette port. > > _________________________________________________________________ > Check out the coupons and bargains on MSN Offers! > http://youroffers.msn.com > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sun May 16 21:02:21 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sun, 16 May 2004 22:02:21 -0400 Subject: [sebhc] 64K memory In-Reply-To: <000301c43ba7$86978270$1f6fa8c0@eths.k12.il.us> References: <000301c43ba7$86978270$1f6fa8c0@eths.k12.il.us> Message-ID: <40A81D2D.3000803@sc.rr.com> I hadn't thought about that. If we could find out the commands for the H47, might be able to swing it. I've heard that the 47 interface was serial with all the smarts in the 47 drive. Carroll Jack Rubin wrote: >We're kind of talking about the same thing, except that the board would >masquerade as a disk controller instead of a tape controller - and the >PC would look like a disk drive instead of a tape deck. > >Jack > > > >>-----Original Message----- >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of >>Carroll Waddell >>Sent: Sunday, May 16, 2004 7:22 PM >>To: sebhc at sebhc.org >>Subject: Re: [sebhc] 64K memory >> >> >>If your speaking about high speed serial on an H8, the only problem I >>see is that the H8 itself isn't high speed. >>The next project I want to build is a board that the H8 thinks is the >>tape interface (H8-5) but can connect to the PC by serial >>port and let >>the PC emulate 2 cassette machines. I'm working on a new H19 >>emulation >>program, and I plan to include software that will do the cassette >>emulation. >>Carroll >> >>Jack Rubin wrote: >> >> >> >>>Carroll - I'm looking forward to trying it out - with that much real >>>estate, how about adding some additional features? I'd like >>> >>> >>to see a >> >> >>>16550 or two to allow high speed serial sharing with (yet to be >>>configured) PC disk server. >>> >>>Jack >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of >>>>Carroll Waddell >>>>Sent: Sunday, May 16, 2004 4:59 PM >>>>To: sebhc at staunch89er.com >>>>Subject: [sebhc] 64K memory >>>> >>>> >>>>If anyone is interested, I have been designing a 64K memory >>>>card for the >>>>H8. I'm sending Jack a prototype of the card to try out. I've >>>>tested it, >>>>but I'd like it tested by someone beside me. If there is enough >>>>interest, we could get a PCB fab house like PCBExpress to >>>> >>>> >>make the PC >> >> >>>>boards. If could get 20 or 25 people who wanted one, we could >>>>get them >>>>for about $55 each. This is a half size (6 x 6) card. >>>>PCBExpress boards >>>>would be about $35 each, so the card and all parts would be >>>>about $55 if >>>>you had to buy everything. >>>>Carroll >>>> >>>>-- >>>>Delivered by the SEBHC Mailing List >>>> >>>> >>sebhc-request at sebhc.org. >> >> >>>> >>>> >>>> >>>> >>>-- >>>Delivered by the SEBHC Mailing List >>> >>> >> >> >>> >>> >>> >>> >>> > >-- >Delivered by the SEBHC Mailing List > > > From leeahart at earthlink.net Sun May 16 23:47:38 2004 From: leeahart at earthlink.net (Lee Hart) Date: Sun, 16 May 2004 21:47:38 -0700 Subject: [sebhc] 64K memory References: <40A7E43D.200@sc.rr.com> Message-ID: <40A843EA.41C6@earthlink.net> Carroll Waddell wrote: > I have been designing a 64K memory card for the H8... If there is > enough interest, we could get a PCB fab house like PCBExpress to > make the PC boards... This is a half size (6 x 6) card. Carroll, rather than make it a half-size board, I would rather see it a full-size board, and make good use of the space. First, H8 boards have large spacings, so they are easy to build. Clumsy fingers, tired old eyes, and poor soldering skills aren't a problem. Now that *I* am clumsy, old, and poor, these attributes would be most welcome! Second, the speed of a computer is largely set by the CPU-to-memory link. Putting the CPU on one board and the memory on another forces all transfers to be limited by the motherboard. The H8 has a very simple, but slow motherboard. So, I would put the Z80 and memory on the same board. Then the Z80 can run *very* fast (up to 20 MHz with modern chips) when accessing on-board memory. When accessing OFF-board memory or I/O, slow the Z80 back down to its standard 2 MHz. This avoids any problems with motherboard or other board speeds. I did this on my H-1000 design (a replacement CPU board for the H89, and it was very successful. The Z80 could run at 4 MHz or 8 MHz for on-board RAM, but slowed to 2 MHz for ROMs, I/O boards, or accessory memory boards. Every stock accessory board we tried worked perfectly with no cuts or patches. No BIOS patches were needed, unlike all the 4 MHz mods for the H89. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sun May 16 21:56:08 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 16 May 2004 19:56:08 -0700 (PDT) Subject: [sebhc] Different HASL8 - Same bug Message-ID: <200405170256.i4H2u8sY025384@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 03:05:41 -0000 Hi Guys, After aligning my tape interface (thanks for the pointer Scott - My manual says to "See page 53 for the alignment procedure", but it is in fact on Page 40 as you indicated) - looks like the second typo I've found in H8 docs (P44 - 2nd paragraph under "CASSETTE INTERFACE") Anyway, after tweaking this (It's VERY sensitive), I was able to load the HASL8 from the tapes that Jack gave me ... It's an older version (#4.01.01) than the one from Carrol (#4.05.00), but it has the SAME BUG! - It's in a different location (the string has moved), but it still tries to execute the $20 byte at the end of the same "BINARY TAPE Y/N? " string (Now the byte is at $2DB5). The chances of two images getting corrupted in the same string byte at two different locations is so astronomical that I officially declare this a BUG in HASL-8 - you will need to use the /I option with my emulator to run HASL-8 (Perhaps I should make this the default). I had to make a cable, but I was able to get the console port working, and transfer the image to my PC (which is where I actually tested it as the emulator traps invalid opcodes). I will try to load the remaining tapes over the next little while and preserve whatever versions of software I can find on them. The only one I know I won't be able to load is EXBASIC, as it requires 12k and I have only 8. (Hey Carrol - I don't suppose you want to loan ME one of those 64k cards?) Btw, although my manual clearly says "4K memory card", the silkscreen on the board in the computer says "8K STATIC RAM". Which explains why I can see 8K. Also, discovered that the emulator debug mode does not correctly scroll the disassemler back by a page when PgUp is pressed (it does only one line) - this is fixed, but I'll hold off uploading a new one as it is a minor bug. Finally ... Is anyone actually using/testing my emulator? - I haven't gotten any feedback since the very first publication. 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 jack.rubin at ameritech.net Sun May 16 22:36:39 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 16 May 2004 22:36:39 -0500 Subject: [sebhc] Different HASL8 - Same bug In-Reply-To: <200405170256.i4H2u8sY025384@gatekeeper.evocative.com> Message-ID: <000001c43bc0$2a53ef80$1f6fa8c0@eths.k12.il.us> > Btw, although my manual clearly says "4K memory card", the > silkscreen on the board in the computer says "8K STATIC RAM". > Which explains why I can see 8K. > as was not uncommon in the days of expensive RAM, the board was actually sold as a 4K kit with a 4K upgrade - 8 chips, 8 sockets, and a label - available separately. If your board is fully populated with 16 4044 room-warmers, you've got 8K. > > Finally ... Is anyone actually using/testing my emulator? - I > haven't gotten any feedback since the very first publication. sure - I've learned to spell ASTHMA, PSYCHOTHERAPY and ENTERTAINMENT! Jack -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sun May 16 22:44:21 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sun, 16 May 2004 20:44:21 -0700 Subject: [sebhc] Different HASL8 - Same bug In-Reply-To: <200405170256.i4H2u8sY025384@gatekeeper.evocative.com> Message-ID: <000001c43bc1$41ab78a0$0700a8c0@walterp4> The H-8-1 came from Heath with 4K static RAM for $140. You could order the H-8-3 4K chip set for $95 to up the card to 8K. If anybody is interested in price history... 10/77: H-8 - $375 H-9 - $510 H-8-13 Basic cassette - $10 H-8-5 Serial/Cassette interface - $110 Cassette Player - $55 11/78: WH-17 - $675 (notice this was assembled, to get it early!) H-17-1 - $295 extra drive H-8-17 - $100 HDOS 1.5 H-17-2 - $25 10 pack disks 1/79: WH-8-16 - $425 bought from local Heathkit store 5/79: H-8-4 - $150 4 port serial I/O 3/80: H-8-21 - $100 Microsoft Basic W-H-8-16 - $395 Assembled 16K RAM 8/80: H-8-20 - $150 Microsoft Fortran H-8-9 - $20 PAM-8 GO 12/80: PIE version 1.5 - $30 4/81: WH8-47 - $235 Just the controller, no drives HA8-8 - $65 ORG 0 board/ROM WH8-16 - $299 Dropped $96 in a year! I-47 - $2395 This was a clone of the H-47 dual 8" disk system 7/82: H-8-7 - $70 Breadboard card ..walt -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield Sent: Sunday, May 16, 2004 7:56 PM To: sebhc at sebhc.org Subject: [sebhc] Different HASL8 - Same bug Btw, although my manual clearly says "4K memory card", the silkscreen on the board in the computer says "8K STATIC RAM". Which explains why I can see 8K. -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sun May 16 23:07:07 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 17 May 2004 00:07:07 -0400 Subject: [sebhc] 64K memory In-Reply-To: <40A843EA.41C6@earthlink.net> References: <40A7E43D.200@sc.rr.com> <40A843EA.41C6@earthlink.net> Message-ID: <40A83A6B.1000600@sc.rr.com> I heard that. I'm old with gouty fingers and not so great eyesight. (But playing with this stuff is fun,,, even if I am old.) CEW Lee Hart wrote: >Carroll Waddell wrote: > > >>I have been designing a 64K memory card for the H8... If there is >>enough interest, we could get a PCB fab house like PCBExpress to >>make the PC boards... This is a half size (6 x 6) card. >> >> > >Carroll, rather than make it a half-size board, I would rather see it a >full-size board, and make good use of the space. > >First, H8 boards have large spacings, so they are easy to build. Clumsy >fingers, tired old eyes, and poor soldering skills aren't a problem. Now >that *I* am clumsy, old, and poor, these attributes would be most >welcome! > >Second, the speed of a computer is largely set by the CPU-to-memory >link. Putting the CPU on one board and the memory on another forces all >transfers to be limited by the motherboard. The H8 has a very simple, >but slow motherboard. > >So, I would put the Z80 and memory on the same board. Then the Z80 can >run *very* fast (up to 20 MHz with modern chips) when accessing on-board >memory. When accessing OFF-board memory or I/O, slow the Z80 back down >to its standard 2 MHz. This avoids any problems with motherboard or >other board speeds. > >I did this on my H-1000 design (a replacement CPU board for the H89, and >it was very successful. The Z80 could run at 4 MHz or 8 MHz for on-board >RAM, but slowed to 2 MHz for ROMs, I/O boards, or accessory memory >boards. Every stock accessory board we tried worked perfectly with no >cuts or patches. No BIOS patches were needed, unlike all the 4 MHz mods >for the H89. > > From CarrollWaddell at sc.rr.com Sun May 16 23:10:52 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 17 May 2004 00:10:52 -0400 Subject: [sebhc] H17 ROMS Message-ID: <40A83B4C.2050607@sc.rr.com> I bought an H8 from ebay last week to get the H17 controller out of it. Unfortunately, it was missing the H17 ROM (U14). Does anyone know if it's possible to use an EPROM in its place? Which One? Are the ROM contents the one in the archive? This is a strange controller board. One of the IC's (U28) is wire wrapped into place and numerous cuts in the lands have been made. U28 is physically located in the same place as a picture I have of the board. Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 16 23:20:22 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 16 May 2004 23:20:22 -0500 Subject: [sebhc] H17 ROMS In-Reply-To: <40A83B4C.2050607@sc.rr.com> Message-ID: <000301c43bc6$45d77cd0$1f6fa8c0@eths.k12.il.us> The H17 ROM is a 2316 ROM; I haven't checked pin-outs carefully, but I _think_ it can be duplicated with a 2716. My prom programmer (Data I/O System 19) doesn't want to read the 2316, but it can burn a 2716. If nobody responds sooner, I'll verify the compatability (or not) with the 2316 and try to burn a copy from my memory dump (which is what's posted to the archive). Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Sunday, May 16, 2004 11:11 PM > To: sebhc at staunch89er.com > Subject: [sebhc] H17 ROMS > > > I bought an H8 from ebay last week to get the H17 controller > out of it. > Unfortunately, it was missing the H17 ROM (U14). Does anyone know if > it's possible to use an EPROM in its place? Which One? Are the ROM > contents the one in the archive? > This is a strange controller board. One of the IC's (U28) is wire > wrapped into place and numerous cuts in the lands have been > made. U28 is > physically located in the same place as a picture I have of > the board. Carroll > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Mon May 17 01:24:38 2004 From: leeahart at earthlink.net (Lee Hart) Date: Sun, 16 May 2004 23:24:38 -0700 Subject: [sebhc] 64K memory References: <000301c43ba7$86978270$1f6fa8c0@eths.k12.il.us> <40A81D2D.3000803@sc.rr.com> Message-ID: <40A85AA6.795E@earthlink.net> Carroll Waddell wrote: > > I hadn't thought about that. If we could find out the commands for the > H47, might be able to swing it. I've heard that the 47 interface was > serial with all the smarts in the 47 drive. No; it is an 8-bit parallel interface with handshaking -- much like SCSI. In fact, I think the two are (nearly) interchangeable. I have the Heath H47 documentation. I can copy it if anyone needs it. Briefly, the States are: - Master Reset mode computer sets /MRST line low H47 unconditionally ends all operations and enters Ready state - Ready mode /BUSY line high, /DTR line low, /DDOUT line high, and the /ERROR line indicates H47's status. When the computer sets the /DTAK line, the H47 will read the data bus, clear the /DTR line, exit the Ready mode and attempt to execute the given command. - Bootstrap command computer sends command word 0000h H47 sends 2 sectors of data bytes (one byte at a time) from unit 0, track 0, side 0, sectors 0 and 1 - Read Main Status command computer sends command word 0001h H47 sends its ERROR status byte - Read Auxilary Status command computer sends command word 0002h, and side/unit/sector number on the bus. H47 sends its Auxiliary status byte, and sets the next side/unit/sector number to be read/written. - Load Sector Count command computer sends command word 0003h, and number of sectors to be transferred - Read Last Track/Side/Unit/Sector command computer sends command word 0004h H47 sends the last accessed track/side/unit/sector number - Read Unbuffered Data command computer sends 0005h, track# byte, and side/unit/sector byte. H47 finds the requested data and transfers it to the computer, without buffering it (i.e. each byte is sent as it is found, about 1 every 16usec for a double-density disk). - Read Buffered Data command computer sends 0007h, track# byte, and side/unit/sector byte. H47 finds the requested data and transfers it to the computer, buffering it in the H47's RAM (i.e. bytes can be received at any speed the computer can handle). - Write Unbuffered Data command computer sends 0006h, track# byte, and side/unit/sector byte. H47 finds the requested sector, and writes the data to it, using a sector data mark of FBh. Data is transferred without buffering; the computer must be able to transfer a data byte every 16usec for a double-density disk. or computer sends 0009h, track# byte, and side/unit/sector byte. H47 writes as for 0006h, but using sector data mark of F8h. - Write Buffered Data command computer sends 0008h, track# byte, and side/unit/sector byte. H47 finds the requested sector, and writes the data to it, using a sector data mark of FBh. Data is transferred via the H47's RAM buffer, so the computer can transfer at any speed. or computer sends 000Ah, track# byte, and side/unit/sector byte. H47 writes as for 0006h, but using sector data mark of F8h. - Copy command computer sends 000Bh, track# byte and side/unit/sector byte for the start of the source data, and the track# and side/unit/sector byte for the destination. H47 copies sectors from source to destination until the number of sectors specified in the last Load Sector Count command is reached. - Format command computer sends 000Ch, 000Dh, 000Eh, or 000Fh (selects density and sector size), then a byte defining the number of sectors per track, unit#, and side#. H47 formats the specified side/unit with the specified format. There's lots more about the individual bit assignments etc. but this should give you the general idea. This is a pretty high-level format, with very little that needs to be done by the H8/H89 itself. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- 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 Sun May 16 23:39:09 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 17 May 2004 00:39:09 -0400 Subject: [sebhc] 64K memory In-Reply-To: <40A85AA6.795E@earthlink.net> References: <000301c43ba7$86978270$1f6fa8c0@eths.k12.il.us> <40A81D2D.3000803@sc.rr.com> <40A85AA6.795E@earthlink.net> Message-ID: <40A841ED.9010900@sc.rr.com> That would be interesting to try. Meanwhile, my H8 is just taking baby steps. I hope it will learn to run in time. CW Lee Hart wrote: >Carroll Waddell wrote: > > >>I hadn't thought about that. If we could find out the commands for the >>H47, might be able to swing it. I've heard that the 47 interface was >>serial with all the smarts in the 47 drive. >> >> > >No; it is an 8-bit parallel interface with handshaking -- much like >SCSI. In fact, I think the two are (nearly) interchangeable. > >I have the Heath H47 documentation. I can copy it if anyone needs it. >Briefly, the States are: > >- Master Reset mode > computer sets /MRST line low > H47 unconditionally ends all operations and enters Ready state >- Ready mode > /BUSY line high, /DTR line low, /DDOUT line high, and the > /ERROR line indicates H47's status. When the computer sets > the /DTAK line, the H47 will read the data bus, clear the > /DTR line, exit the Ready mode and attempt to execute the > given command. >- Bootstrap command > computer sends command word 0000h > H47 sends 2 sectors of data bytes (one byte at a time) > from unit 0, track 0, side 0, sectors 0 and 1 >- Read Main Status command > computer sends command word 0001h > H47 sends its ERROR status byte >- Read Auxilary Status command > computer sends command word 0002h, and side/unit/sector > number on the bus. > H47 sends its Auxiliary status byte, and sets the next > side/unit/sector number to be read/written. >- Load Sector Count command > computer sends command word 0003h, and number of sectors > to be transferred >- Read Last Track/Side/Unit/Sector command > computer sends command word 0004h > H47 sends the last accessed track/side/unit/sector number >- Read Unbuffered Data command > computer sends 0005h, track# byte, and side/unit/sector byte. > H47 finds the requested data and transfers it to the computer, > without buffering it (i.e. each byte is sent as it is found, > about 1 every 16usec for a double-density disk). >- Read Buffered Data command > computer sends 0007h, track# byte, and side/unit/sector byte. > H47 finds the requested data and transfers it to the computer, > buffering it in the H47's RAM (i.e. bytes can be received at > any speed the computer can handle). >- Write Unbuffered Data command > computer sends 0006h, track# byte, and side/unit/sector byte. > H47 finds the requested sector, and writes the data to it, > using a sector data mark of FBh. Data is transferred without > buffering; the computer must be able to transfer a data byte > every 16usec for a double-density disk. > or computer sends 0009h, track# byte, and side/unit/sector byte. > H47 writes as for 0006h, but using sector data mark of F8h. >- Write Buffered Data command > computer sends 0008h, track# byte, and side/unit/sector byte. > H47 finds the requested sector, and writes the data to it, > using a sector data mark of FBh. Data is transferred via the > H47's RAM buffer, so the computer can transfer at any speed. > or computer sends 000Ah, track# byte, and side/unit/sector byte. > H47 writes as for 0006h, but using sector data mark of F8h. >- Copy command > computer sends 000Bh, track# byte and side/unit/sector byte > for the start of the source data, and the track# and > side/unit/sector byte for the destination. > H47 copies sectors from source to destination until the > number of sectors specified in the last Load Sector Count > command is reached. >- Format command > computer sends 000Ch, 000Dh, 000Eh, or 000Fh (selects density > and sector size), then a byte defining the number of sectors > per track, unit#, and side#. > H47 formats the specified side/unit with the specified format. > >There's lots more about the individual bit assignments etc. but this >should give you the general idea. This is a pretty high-level format, >with very little that needs to be done by the H8/H89 itself. > > From waltm22 at comcast.net Mon May 17 00:31:07 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sun, 16 May 2004 22:31:07 -0700 Subject: [sebhc] 64K memory In-Reply-To: <40A85AA6.795E@earthlink.net> Message-ID: <000501c43bd0$2ee06230$0700a8c0@walterp4> >From what I saw, it is not interchangeable with SCSI, not even close. Did these definitions come from the Remex manual or from some variation Heath made? I Have the Remex service manual for the 4810 and 4820, which also has all this information and much more. I might get this scanned some day if there is any interest. I've taken a quick glance at the PC's parallel port, and I haven't decided if it would be easy to emulate the Remex drive or not. One of the problems is that the Remex drive really wants to control the bus, just as the PC does. Another problem is that the Remex drive wants active LOW while the PC wants active HIGH for the same signals. I still need to figure this out. ..walt -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Lee Hart Sent: Sunday, May 16, 2004 11:25 PM To: sebhc at sebhc.org Subject: Re: [sebhc] 64K memory Carroll Waddell wrote: > > I hadn't thought about that. If we could find out the commands for the > H47, might be able to swing it. I've heard that the 47 interface was > serial with all the smarts in the 47 drive. No; it is an 8-bit parallel interface with handshaking -- much like SCSI. In fact, I think the two are (nearly) interchangeable. I have the Heath H47 documentation. I can copy it if anyone needs it. Briefly, the States are: - Master Reset mode computer sets /MRST line low H47 unconditionally ends all operations and enters Ready state - Ready mode /BUSY line high, /DTR line low, /DDOUT line high, and the /ERROR line indicates H47's status. When the computer sets the /DTAK line, the H47 will read the data bus, clear the /DTR line, exit the Ready mode and attempt to execute the given command. - Bootstrap command computer sends command word 0000h H47 sends 2 sectors of data bytes (one byte at a time) from unit 0, track 0, side 0, sectors 0 and 1 - Read Main Status command computer sends command word 0001h H47 sends its ERROR status byte - Read Auxilary Status command computer sends command word 0002h, and side/unit/sector number on the bus. H47 sends its Auxiliary status byte, and sets the next side/unit/sector number to be read/written. - Load Sector Count command computer sends command word 0003h, and number of sectors to be transferred - Read Last Track/Side/Unit/Sector command computer sends command word 0004h H47 sends the last accessed track/side/unit/sector number - Read Unbuffered Data command computer sends 0005h, track# byte, and side/unit/sector byte. H47 finds the requested data and transfers it to the computer, without buffering it (i.e. each byte is sent as it is found, about 1 every 16usec for a double-density disk). - Read Buffered Data command computer sends 0007h, track# byte, and side/unit/sector byte. H47 finds the requested data and transfers it to the computer, buffering it in the H47's RAM (i.e. bytes can be received at any speed the computer can handle). - Write Unbuffered Data command computer sends 0006h, track# byte, and side/unit/sector byte. H47 finds the requested sector, and writes the data to it, using a sector data mark of FBh. Data is transferred without buffering; the computer must be able to transfer a data byte every 16usec for a double-density disk. or computer sends 0009h, track# byte, and side/unit/sector byte. H47 writes as for 0006h, but using sector data mark of F8h. - Write Buffered Data command computer sends 0008h, track# byte, and side/unit/sector byte. H47 finds the requested sector, and writes the data to it, using a sector data mark of FBh. Data is transferred via the H47's RAM buffer, so the computer can transfer at any speed. or computer sends 000Ah, track# byte, and side/unit/sector byte. H47 writes as for 0006h, but using sector data mark of F8h. - Copy command computer sends 000Bh, track# byte and side/unit/sector byte for the start of the source data, and the track# and side/unit/sector byte for the destination. H47 copies sectors from source to destination until the number of sectors specified in the last Load Sector Count command is reached. - Format command computer sends 000Ch, 000Dh, 000Eh, or 000Fh (selects density and sector size), then a byte defining the number of sectors per track, unit#, and side#. H47 formats the specified side/unit with the specified format. There's lots more about the individual bit assignments etc. but this should give you the general idea. This is a pretty high-level format, with very little that needs to be done by the H8/H89 itself. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 17 05:51:24 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 03:51:24 -0700 (PDT) Subject: [sebhc] 64K memory Message-ID: <200405171051.i4HApOxG033530@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 11:12:34 -0000 >I have the Heath H47 documentation. I can copy it if anyone needs it. >Briefly, the States are: ... >There's lots more about the individual bit assignments etc. but this >should give you the general idea. This is a pretty high-level format, >with very little that needs to be done by the H8/H89 itself. This looks like it would be dead easy to throw into the emulator. What I would need is: - Detailed documentation on the commands - Binary dump of the ROM - A bootable disk image for testing. Anyone want me to persue this? 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 Mon May 17 07:56:28 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 05:56:28 -0700 (PDT) Subject: [sebhc] Speed trials. Message-ID: <200405171256.i4HCuSri035436@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 13:24:45 -0000 I hooked up the other half of the RS-232 PC interface, and was able to load and run software on my H8 and talk to it from the PC... So, I decided to do a speed test, and the emulator comes out just a bit faster than the actual H8. I loaded BHBASIC and run a simple 1-10000 loop: 10 FOR I=1 TO 10000 20 NEXT I In my real H8, I timed this at about 42 seconds. On the emulator: ---------------- P3/733 takes less than one second (had to measure). 486/100 took about 7 seconds. A 386/33 turned in a score of about 50 seconds. So I think even the lowest end 486 (25) it would run faster than real time. When I get a chance, I will add the calibration routines to control the CPU throttle to simulate real time performance on all machines. 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 Mon May 17 07:56:32 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 05:56:32 -0700 (PDT) Subject: [sebhc] Different HASL8 - Same bug Message-ID: <200405171256.i4HCuSRs035435@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 13:24:46 -0000 >> Finally ... Is anyone actually using/testing my emulator? - I >> haven't gotten any feedback since the very first publication. > >sure - I've learned to spell ASTHMA, PSYCHOTHERAPY and ENTERTAINMENT! Ah -- I'm glad to see it's being put to the classical good use (running games). Actually the Hangman game is pretty cool considering the time period. Btw, I have a copy of "Chess Master" for my Altair, which I already have figured out how to relocate to any page address and to patch the I/O functions (did this to make it run on my DMF - OS). Anyone interested in a Chess game for the H8? Regards, -- 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 patrick at vintagecomputermarketplace.com Mon May 17 09:07:21 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 17 May 2004 07:07:21 -0700 Subject: [sebhc] H17 ROMS In-Reply-To: <000301c43bc6$45d77cd0$1f6fa8c0@eths.k12.il.us> Message-ID: <000901c43c18$4564eba0$f300a8c0@berkeley.evocative.com> The 2516 is pin-for-pin replacement EPROM for that ROM, if you can find one. It wouldn't be much work, however, to make a little daughter card for a 2716 or even something more common until you're able to find the Real Thing. --Patrick > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Jack Rubin > Sent: Sunday, May 16, 2004 9:20 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] H17 ROMS > > > The H17 ROM is a 2316 ROM; I haven't checked pin-outs > carefully, but I _think_ it can be duplicated with a 2716. My > prom programmer (Data I/O System 19) doesn't want to read the > 2316, but it can burn a 2716. If nobody responds sooner, I'll > verify the compatability (or not) with the 2316 and try to > burn a copy from my memory dump (which is what's posted to > the archive). > > Jack > > > -----Original Message----- > > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > > Carroll Waddell > > Sent: Sunday, May 16, 2004 11:11 PM > > To: sebhc at staunch89er.com > > Subject: [sebhc] H17 ROMS > > > > > > I bought an H8 from ebay last week to get the H17 controller > > out of it. > > Unfortunately, it was missing the H17 ROM (U14). Does > anyone know if > > it's possible to use an EPROM in its place? Which One? Are the ROM > > contents the one in the archive? > > This is a strange controller board. One of the IC's (U28) is wire > > wrapped into place and numerous cuts in the lands have been > > made. U28 is > > physically located in the same place as a picture I have of > > the board. Carroll > > > > -- > > Delivered by the SEBHC Mailing List > sebhc-request at sebhc.org. > > > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Mon May 17 09:30:25 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 17 May 2004 07:30:25 -0700 Subject: [sebhc] 64K memory In-Reply-To: <40A85AA6.795E@earthlink.net> Message-ID: <003f01c43c1b$7e9edae0$f300a8c0@berkeley.evocative.com> > Carroll Waddell wrote: > > > > I hadn't thought about that. If we could find out the > commands for the > > H47, might be able to swing it. I've heard that the 47 > interface was > > serial with all the smarts in the 47 drive. > > No; it is an 8-bit parallel interface with handshaking -- > much like SCSI. In fact, I think the two are (nearly) interchangeable. Guys, this is all really great, but I have a question/comment/perspective. I'm looking at all this and wondering why Carroll wouldn't build some kind of simple interface on his card, like bi-directional parallel, and simply use a driver in HDOS and/or CP/M to control it and make it look like any other drive? It seems to me that, aside from the coolness factor of using the vintage controller, you can get more performance and surpass any architectural limitations inherent in the old hardware AND software. I worked on a virtual disk subsystem some years ago for a pre-Palm hand-held. It used nibble-mode parallel I/O, and was very fast and reliable, much moreso than serial (although it supported that as well). The control program on the PC was trivial, as was the driver in the hand-held. That company ultimately didn't make it, but I used the same principles a couple of years ago and started to build on them for a CP/M virtual filesystem. It became immediately clear to me that any number and size of virtual disks could be created over this interface. You can even create them on the fly in any size and mount them. I guess what I'm saying is, aside from the coolness factor of running the old controller, writing and installing device drivers isn't that hard. I'll bet _most_ of the software is well-behaved and just uses the defined system APIs for filesystem manipulation, so the particulars of the hardware are not an issue--AutoScribe works the same on the H-47, Z-67, and H-37. The driver provides the abstraction, so my bias is to do what is cheapest, fastest, and creates a lasting, stable solution with the hardware and let the driver do its job. One Z-80 PIO and a little glue on Carroll's board with a simple driver would be all it takes and requires no additional hardware on the PC. The '8/89 won't know if SY.DVD is a driving a 30-year old Siemens drive or a 3Ghz Dell. :-) Just my 2p! Patrick -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Mon May 17 10:12:00 2004 From: leeahart at earthlink.net (Lee Hart) Date: Mon, 17 May 2004 08:12:00 -0700 Subject: [sebhc] 64K memory References: <000501c43bd0$2ee06230$0700a8c0@walterp4> Message-ID: <40A8D640.3031@earthlink.net> Walter Moore wrote: > From what I saw, it is not interchangeable with SCSI, not even close. Hmm... I never compared them, and was just going by what someone said a long time ago. > Did these definitions come from the Remex manual or from some > variation Heath made? They came from the Heath H47 manual, which in turn says they came from the Excello Remex manuals. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Mon May 17 10:34:34 2004 From: leeahart at earthlink.net (Lee Hart) Date: Mon, 17 May 2004 08:34:34 -0700 Subject: [sebhc] 64K memory References: <200405171051.i4HApOxG033530@gatekeeper.evocative.com> Message-ID: <40A8DB8A.C26@earthlink.net> Dave Dunfield wrote: > > >I have the Heath H47 documentation. I can copy it if anyone needs it. > >Briefly, the States are: > > ... > > >There's lots more about the individual bit assignments etc. but this > >should give you the general idea. This is a pretty high-level format, > >with very little that needs to be done by the H8/H89 itself. > > This looks like it would be dead easy to throw into the emulator. > > What I would need is: > > - Detailed documentation on the commands > - Binary dump of the ROM > - A bootable disk image for testing. > > Anyone want me to persue this? Dave, I'd be happy to photocopy what I have and send it to you. Just send me your address (privately, if you like). However, I never really liked the H47. It was cheaply madel, and unreliable (what kind of nitwit makes an 8" disk drive out of molded plastic and sheet metal). They were single-sourced, so when it broke, that was the end of the line. I would think that one of the other options mentioned earlier would be preferable. For example, using the H8's RS-232 or cassette serial ports to communicate with the PC. Longer term, I am attracted to the idea of making a proper disk controller board for the H8. Since the old WD1797 chips are so scarce, and Heath already (sort of) supported SCSI with the H67, maybe the way to do this is by implementing a SCSI board, which could plug into a hard drive from an old Mac or PC, or a 1.44meg floppy drive from a Mac (they were SCSI), or even a PC with SCSI card (two SCSI devices can exchange data directly). -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 17 10:06:36 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 17 May 2004 15:06:36 +0000 Subject: [sebhc] Different HASL8 - Same bug Message-ID: Dave Dunfield said: >I was able to >load the HASL8 from the tapes that Jack gave me ... It's an older >version (#4.01.01) than the one from Carrol (#4.05.00), but it >has the SAME BUG! That is too funny! I wonder how it was coded in source to make the address reference off by one after compilation. >you will need to use the /I option >with my emulator to run HASL-8 (Perhaps I should make this the >default). My preference for the default behavior would be to emulate all opcodes just like a real chip would. Do you still have me previous message where I listed all the codes and functions? >The only one I know I won't be able to load is EXBASIC, as it >requires 12k and I have only 8. You could write a little program to read from the tape and output it in hex or octal to the console, and capture it on your pc "on the fly". >Finally ... Is anyone actually using/testing my emulator? - I haven't >gotten any feedback since the very first publication. It's truly amazing for just a few day's development - your extensive experience in emulators is clearly showing! I tried out most of the cassette software. I think what will really get folks excited is when it emulates floppies. Cheers, - Steven _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 17 10:27:54 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 17 May 2004 15:27:54 +0000 Subject: [sebhc] unpacking and ressurecting... Message-ID: The ressurection saga continues .... My floppy drive's step motor isn't physically stuck .. it moves freely by hand and if moved away from home, it returns to home under program control ... but it won't move AWAY from home. So now I'm guessing there's a blown driver transistor for the other direction. I unpacked "old number 1" (the very first production H8) and have it warming up on the variac. Inside it was the breadboarded D-to-A board I made for a store demo in New Orleans (before I went to work at the factory). A couple of guys saw it and started up a company to make them .. Heath eventually resold them as a 3rd party item (HA-8-2 I think). They later made a color video card using a video-game chip. All I got were samples of the 2 boards. :-) I found a bunch more manuals ... still no floppies, other than a never-opened H-8-21 Microsoft BASIC still in the box. (Does that have a "collector's value"?) :-) I also found a set of HDOS manuals still in cellophane (but not a sealed box). More to come... - Steven _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Mon May 17 11:08:35 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 17 May 2004 09:08:35 -0700 Subject: [sebhc] H17 ROMS In-Reply-To: <000901c43c18$4564eba0$f300a8c0@berkeley.evocative.com> Message-ID: <004501c43c29$355512b0$f300a8c0@berkeley.evocative.com> > > The H17 ROM is a 2316 ROM; I haven't checked pin-outs > > carefully, but I _think_ it can be duplicated with a 2716. My > > prom programmer (Data I/O System 19) doesn't want to read the > > 2316, but it can burn a 2716. If nobody responds sooner, I'll > > verify the compatability (or not) with the 2316 and try to > > burn a copy from my memory dump (which is what's posted to > > the archive). > > > > Jack Jack, continuing our off-line discussion on this very topic, I've made some interesting discoveries. Here's what I've found. The only schematic I had handy that used a 2516 was for the SWTP MP-09 6809 CPU board from Mike Holley's site. Interestingly, the text description of the circuit says at first that the EPROM sockets on the board are 2716 compatible, but the parts listing for the board says those socket positions take 2516 compatible EPROMs. The schematic clearly shows, however, a 2716-compatible pinout. I then started looking at the 2532 and 2732. Unless the schematics I'm looking at are wrong, the 2532 has a different pinout from the 2732--the functions of pins 18 and 21 (a chip enable and A11) are transposed. I used the charts below and the schematics for the AIM-65 and Commodore PET as a reference (2332 consumers). Both circuits show 2332s (masked ROM), but I've used (recently, like this past weekend) a 2532 on an AIM-65 without any issues, so I know the 2532 is a good replacement for the 2332, but using a 2732 takes rework. In looking for the 2316/2516 however, I ran across some interesting information. Apparently a lot of the old pinball games used 2316s and cousin 9316s, so they're a rich source. I found a lot about changing jumpers this way and that, and finally found a site that explained WHY there are so many jumpers on boards that use them. Apparently, both the 2316 and 9316 had manufacture-time customer options for 2 or 3 enable lines and active low or active high enables. It went on to say (correctly?) that the x316A parts are active high enables, and x316B are active low. This makes the x316A parts incompatible (directly) with the 2716. Coincidentally, I'm holding in my hand an interesting little daughterboard that I got in a box of stuff I bought on eBay a couple of weeks ago that was advertised as "Electronic parts for HAM radio operator" (the photo clearly showed many MOS parts including what turned out to be several gold/ceramic 6502s in original packaging, and indeed it's a treasure trove of old computer stuff and few radio parts). That board has a 2716 in a socket with a 7404 next to it, and based on the above discovery, it appears it's a 2316A/9316A adapter. Small world. Following traces, this board inverts plug pin 20 and puts it on pin 18 of the 2716, it pulls pin 21 on the 2716 high, and pin 21 on the plug is inverted and delivered to pin 20 on the 2716. Plug pin 18 is not connected. So, I know the 2332 and 2532 are pin-compatible. If the schematic for the MP-09 is correct, and the pinball site is correct, then (1) the 2516 and 2716 are pin-compatible; (2) the 2532 and 2732 are NOT pin-compatible; and (3) the 2316/9316 and 2516/2716 MAY NOT be compatible due to customer-selectable variations in manufacturing. But I'll bet Heath's choice was to use active low enables, which would make a 2716 work for the 2316. I don't have a schematic here at my office, but maybe someone can confirm that the H-17 ROM has two active low enables on pins 18 and 20, and Vcc on pin 21? FWIW, I found a couple of interesting EPROM cross reference documents on the net somewhere, and saved them. I've uploaded them to the SEBHC site (one is a nicely produced PDF, the other is a GIF scan of someone's hand drawing). The PDF shows the commonality between the 6116/6264/62256 RAMs and the 27xx(x) EPROMs. There are also cool parts like the 28C64 and 28C256 EEPROMs that pin out the same and don't require UV erasure to program. --Patrick -- Delivered by the SEBHC Mailing List From RONALD.S.WEST at saic.com Mon May 17 11:34:59 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Mon, 17 May 2004 12:34:59 -0400 Subject: [sebhc] unpacking and ressurecting... Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C3E@mcl-its-exs03.mail.saic.com> Steven, Don't know about that MS Basic in a box but, "Old number 1" would bring a pretty penny on ebay(tm). Don't ever get rid of it (and call me if you do ;^) ). Do you have any more details on the color video board. That would be interesting. I imagine it was CGA or thereabouts. Ron -----Original Message----- From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Steven Parker Sent: Monday, May 17, 2004 11:28 AM To: sebhc at sebhc.org Subject: [sebhc] unpacking and ressurecting... The ressurection saga continues .... My floppy drive's step motor isn't physically stuck .. it moves freely by hand and if moved away from home, it returns to home under program control ... but it won't move AWAY from home. So now I'm guessing there's a blown driver transistor for the other direction. I unpacked "old number 1" (the very first production H8) and have it warming up on the variac. Inside it was the breadboarded D-to-A board I made for a store demo in New Orleans (before I went to work at the factory). A couple of guys saw it and started up a company to make them .. Heath eventually resold them as a 3rd party item (HA-8-2 I think). They later made a color video card using a video-game chip. All I got were samples of the 2 boards. :-) I found a bunch more manuals ... still no floppies, other than a never-opened H-8-21 Microsoft BASIC still in the box. (Does that have a "collector's value"?) :-) I also found a set of HDOS manuals still in cellophane (but not a sealed box). More to come... - Steven _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Mon May 17 11:39:40 2004 From: waltm22 at comcast.net (Walter Moore) Date: Mon, 17 May 2004 09:39:40 -0700 Subject: [sebhc] unpacking and ressurecting... In-Reply-To: Message-ID: <000001c43c2d$9109a5e0$0700a8c0@walterp4> I had a similar problem with one of the FDD-100-5 drives, and traced it to a bad 75472 (IC 4FB). It could not hold one of the stepper lines low. I would compare the outputs of 4FA and 4FB with the good drive if possible. I have a stack of these drives if you need to borrow one. I haven't done any lubrication to the stepper motors, and I still haven't ordered my alignment disks, but I could loan you one that at least passes the heath diagnostics. I also have a spare 75472 if you determine that is the problem. ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Steven Parker > Sent: Monday, May 17, 2004 8:28 AM > To: sebhc at sebhc.org > Subject: [sebhc] unpacking and ressurecting... > > The ressurection saga continues .... > > My floppy drive's step motor isn't physically stuck .. it moves freely by > hand and if moved away from home, it returns to home under program control > ... but it won't move AWAY from home. So now I'm guessing there's a blown > driver transistor for the other direction. -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 17 13:32:53 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 17 May 2004 11:32:53 -0700 (PDT) Subject: [sebhc] H17 ROMS Message-ID: <200405171832.LAA08505@clulw009.amd.com> >From: "Patrick Rigney" > >> > The H17 ROM is a 2316 ROM; I haven't checked pin-outs >> > carefully, but I _think_ it can be duplicated with a 2716. My >> > prom programmer (Data I/O System 19) doesn't want to read the >> > 2316, but it can burn a 2716. If nobody responds sooner, I'll >> > verify the compatability (or not) with the 2316 and try to >> > burn a copy from my memory dump (which is what's posted to >> > the archive). >> > >> > Jack > >Jack, continuing our off-line discussion on this very topic, I've made some >interesting discoveries. Here's what I've found. > >The only schematic I had handy that used a 2516 was for the SWTP MP-09 6809 >CPU board from Mike Holley's site. Interestingly, the text description of >the circuit says at first that the EPROM sockets on the board are 2716 >compatible, but the parts listing for the board says those socket positions >take 2516 compatible EPROMs. The schematic clearly shows, however, a >2716-compatible pinout. > >I then started looking at the 2532 and 2732. Unless the schematics I'm >looking at are wrong, the 2532 has a different pinout from the 2732--the >functions of pins 18 and 21 (a chip enable and A11) are transposed. I used >the charts below and the schematics for the AIM-65 and Commodore PET as a >reference (2332 consumers). Both circuits show 2332s (masked ROM), but I've >used (recently, like this past weekend) a 2532 on an AIM-65 without any >issues, so I know the 2532 is a good replacement for the 2332, but using a >2732 takes rework. > ---snip--- Hi I'm not sure but I think my H17 board actually has a regular 2716 on it. As Patrick mentioned, there were a lot of optional select levels for the various xx16 ROMs. In my pile of ROM reading stuff, I have a couple of sockets wired such that I can avoid accidentally getting the programming voltage to the chips and inversions for the various selects. I do this with simple jumpers since the programmer is not a real active circuit. In a real circuit, one might need an inverter. It isn't going to hurt anything to try a straight 2716. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 17 13:57:56 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 17 May 2004 18:57:56 +0000 Subject: [sebhc] Power switches, etc. Message-ID: Dang, now I have ANOTHER bad power switch.. anyone know of a source for an exact replacement ? I hate to mess up the case to put a different one in. On those 2716's ... I seem to recall casually replacing the original rom's with them whenever we were trying out custom code or upgrades. Steven P.S. I found my 37 and 47 .. but I never had H8 interfaces for them (they were for my H89, which is yet to be powered up). Plus I'm not sure that 47 ever worked .. I got it 2nd hand. Which is too bad, since I have a bunch of software on 8-inch disks, including, if I remember right, the HDOS source code. _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From melamy at earthlink.net Mon May 17 14:51:43 2004 From: melamy at earthlink.net (Steve Thatcher) Date: Mon, 17 May 2004 15:51:43 -0400 (GMT-04:00) Subject: [sebhc] Power switches, etc. Message-ID: <17844563.1084823504298.JavaMail.root@grover.psp.pas.earthlink.net> a recommendation about power switches - don't use them. Buy a pwoer strip and use that switch to keep from breaking the OLD ones... best regards, Steve Thatcher -----Original Message----- From: Steven Parker Sent: May 17, 2004 2:57 PM To: sebhc at sebhc.org Subject: [sebhc] Power switches, etc. Dang, now I have ANOTHER bad power switch.. anyone know of a source for an exact replacement ? I hate to mess up the case to put a different one in. On those 2716's ... I seem to recall casually replacing the original rom's with them whenever we were trying out custom code or upgrades. Steven P.S. I found my 37 and 47 .. but I never had H8 interfaces for them (they were for my H89, which is yet to be powered up). Plus I'm not sure that 47 ever worked .. I got it 2nd hand. Which is too bad, since I have a bunch of software on 8-inch disks, including, if I remember right, the HDOS source code. _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 17 15:02:22 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 17 May 2004 20:02:22 +0000 Subject: [sebhc] Power switches, etc. Message-ID: Steve Thatcher says: >a recommendation about power switches - don't use them. Buy a pwoer strip >and use that switch to keep from breaking the OLD ones... Good idea. But as far as I can tell, these failed in storage. I know the units were working when boxed, but when unpacked the switch wouldn't close even on the first try. It FEELS like it's working though. Anyway, I'd love to find a source for snap-in replacements that fit the cabinet. _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 17 15:13:31 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 17 May 2004 13:13:31 -0700 (PDT) Subject: [sebhc] Power switches, etc. Message-ID: <200405172013.NAA08559@clulw009.amd.com> >From: "Steven Parker" > >Steve Thatcher says: >>a recommendation about power switches - don't use them. Buy a pwoer strip >>and use that switch to keep from breaking the OLD ones... > >Good idea. But as far as I can tell, these failed in storage. I know the >units were working when boxed, but when unpacked the switch wouldn't close >even on the first try. It FEELS like it's working though. > >Anyway, I'd love to find a source for snap-in replacements that fit the >cabinet. > Hi I've often found that, those switches that don't have a failure in the plastic parts, can often be fixed by cleaning. Of course, one does have to open them up. Usually, there are some metal tabs that can be bent at least once or twice. The other thing to try is to put them in the on position and let them sit for a few days. They often use a grease ( like silicon grease ) to reduce arcing. The oils tend to leave a sticky mess behind, after several years. Leaving them in the on position can help to penetrate the goo. It might also be a good idea to store things with switches set to on. Dwight -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 17 17:31:56 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 15:31:56 -0700 (PDT) Subject: [sebhc] H17 ROMS Message-ID: <200405172231.i4HMVqRe044479@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 22:54:39 -0000 >The only schematic I had handy that used a 2516 was for the SWTP MP-09 6809 >CPU board from Mike Holley's site. Interestingly, the text description of >the circuit says at first that the EPROM sockets on the board are 2716 >compatible, but the parts listing for the board says those socket positions >take 2516 compatible EPROMs. The schematic clearly shows, however, a >2716-compatible pinout. Btw, keep in mind that there are two distinct familes of 2716 devices, and they are not compatible with each other. There's the Intel type 2716 which uses a single 5v supply (not counting programming), and the TI style 2716 which used multiple supplies (-5 etc). Regards, -- 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 Mon May 17 17:31:47 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 15:31:47 -0700 (PDT) Subject: [sebhc] 64K memory Message-ID: <200405172231.i4HMVlV7044477@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 22:54:32 -0000 Hi Lee, >> This looks like it would be dead easy to throw into the emulator. >> >> What I would need is: >> >> - Detailed documentation on the commands >> - Binary dump of the ROM >> - A bootable disk image for testing. >> >> Anyone want me to persue this? > >Dave, I'd be happy to photocopy what I have and send it to you. Just >send me your address (privately, if you like). Thanks - I'll send you my address. >However, I never really liked the H47. It was cheaply madel, and >unreliable (what kind of nitwit makes an 8" disk drive out of molded >plastic and sheet metal). They were single-sourced, so when it broke, >that was the end of the line. These mechanical issues are not a concern in the emulator, as this will be a software only implementation. It will use a file on the PC to emulate the disk drive. I thought it might be interesting because it sounds as if the software interface is fairly simple, and it might be very easy to add it in to my emulator, which would give us a bootable disk. >I would think that one of the other options mentioned earlier would be >preferable. For example, using the H8's RS-232 or cassette serial ports >to communicate with the PC. Although this does not apply to the emulator, it is something that I have been thinking about. It would take very little to modify the H8-5 board to perform direct upload with the PC through the cassette port - this would allow you to use "digital" means without having to constantly having to change the "interchange" switch (which requires you to leave the top off). Assuming your chips are socketed, you could do this without damaging the H8-5 board at all (This is important to me, as I believe in preserving these machines as much as possible). All you need to do is build a little RS-232 driver board (MAX-232?) and switch the IC123 RXD/TXD connections to go to this board. You could also jumper it to run at 9600 bps from the console serial baud rate selector. You can disconnect the existing tape interface just by lifting a couple of IC pins, then tack on wires to the level convertor board, and you should be all set to go "high speed" digital. >Longer term, I am attracted to the idea of making a proper disk >controller board for the H8. Since the old WD1797 chips are so scarce, >and Heath already (sort of) supported SCSI with the H67, maybe the way >to do this is by implementing a SCSI board, which could plug into a hard >drive from an old Mac or PC, or a 1.44meg floppy drive from a Mac (they >were SCSI), or even a PC with SCSI card (two SCSI devices can exchange >data directly). Agreed, we could do our own ROM to make this as transparent as possible. Another possibility for the hard drvie is IDE - I've used IDE drives in a couple of small embedded systems, and they are really quite easy to talk to. Btw, does anyone have the specs for a disk controller ROM - what functions must it provide to be able to boot and run the standard OS's? Regards, -- 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 Mon May 17 17:31:52 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 15:31:52 -0700 (PDT) Subject: [sebhc] unpacking and ressurecting... Message-ID: <200405172231.i4HMVq5T044480@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 22:54:37 -0000 >I unpacked "old number 1" (the very first production H8) and have it warming >up on the variac. Inside it was the breadboarded D-to-A board I made for a >store demo in New Orleans (before I went to work at the factory). A couple >of guys saw it and started up a company to make them .. Heath eventually >resold them as a 3rd party item (HA-8-2 I think). They later made a color >video card using a video-game chip. All I got were samples of the 2 boards. > :-) Oh -- drool drool --- I don't suppose it needs a home :-) Ok - well how about some pictures? I'd love to see the details of the original H8 - is it much different than later ones? 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 Mon May 17 17:31:52 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 17 May 2004 15:31:52 -0700 (PDT) Subject: [sebhc] Different HASL8 - Same bug Message-ID: <200405172231.i4HMVqD7044478@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 17 May 2004 22:54:35 -0000 At 15:06 17/05/2004 +0000, you wrote: >Dave Dunfield said: >>I was able to >>load the HASL8 from the tapes that Jack gave me ... It's an older >>version (#4.01.01) than the one from Carrol (#4.05.00), but it >>has the SAME BUG! > >That is too funny! I wonder how it was coded in source to make the address >reference off by one after compilation. Yeah! I was wondering that too - it's not something that could easily happen "by accident" in any assembly code that I've written - I would love to see the source. >>you will need to use the /I option >>with my emulator to run HASL-8 (Perhaps I should make this the >>default). > >My preference for the default behavior would be to emulate all opcodes just >like a real chip would. Do you still have me previous message where I >listed all the codes and functions? Yes, and I am planning to modify my /I option to work that way. I'm not sure about making /I the default - One thing that I like emulators for is software development (much nicer debugging), and it's really handy to have them trap when something invalid happens... What I may do is modify the simulator to use a ".INI" file to allow you to include your favorite command line options in a file (most of this ability is already there). >>The only one I know I won't be able to load is EXBASIC, as it >>requires 12k and I have only 8. > >You could write a little program to read from the tape and output it in hex >or octal to the console, and capture it on your pc "on the fly". Yeah, I had this thought too - wouldn't even have to output as octal. I can just do a simple read/write loop of the binary data - I can load it into my emulator to check it (CRC's etc.) >>Finally ... Is anyone actually using/testing my emulator? - I haven't >>gotten any feedback since the very first publication. > >It's truly amazing for just a few day's development - your extensive >experience in emulators is clearly showing! I tried out most of the >cassette software. I think what will really get folks excited is when it >emulates floppies. Thanks for the kind words - I am planning to do floppies, but I must confess that my main goal in writing emulators is to allow people to experience the actual vintage machines that I have in my collection - to that end, my H8 simulator is already pretty much there, as I don't think I can do anything on it that I can't in the emulator (in fact the emulator has a lot more memory so it can do more) - I will however add disk support because a few people have expressed interest, although I have not heard much since, so I don't know what the level of interest actually is. (Now if I could find a REAL disk controller for my H8, I'd have a real incentive!). I should also find out the details of the "Zero origin RAM" option, as I would like to add that as well - that way it could boot CP/M (?) 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 leeahart at earthlink.net Mon May 17 19:31:43 2004 From: leeahart at earthlink.net (Lee Hart) Date: Mon, 17 May 2004 17:31:43 -0700 Subject: [sebhc] Power switches, etc. References: Message-ID: <40A9596F.21CA@earthlink.net> Steven Parker wrote: > > Steve Thatcher says: > >a recommendation about power switches - don't use them. Buy a pwoer strip > >and use that switch to keep from breaking the OLD ones... > > Good idea. But as far as I can tell, these failed in storage. I know the > units were working when boxed, but when unpacked the switch wouldn't close > even on the first try. It FEELS like it's working though. > > Anyway, I'd love to find a source for snap-in replacements that fit the > cabinet. Heath was great at using fairly generic multiple-sourced parts, so it's likely we can find a replacement. Can you provide any manufacturer's data off it? -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 17 17:45:33 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 17 May 2004 15:45:33 -0700 (PDT) Subject: [sebhc] ( was: 64K memory ) H17 Routines Message-ID: <200405172245.PAA08676@clulw009.amd.com> >From: "Dave Dunfield" ---snip--- > >Btw, does anyone have the specs for a disk controller ROM - what functions >must it provide to be able to boot and run the standard OS's? > Hi Dave I believe that all of the required operations of the H17 can be accessed through the jump table at the begining of the ROM. Look at the listing for these. This is for HDOS. For CP/M there are similar tables in the BIOS. The only things that might not be obvious are the timeout timers used by many of the operations. Dwight -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Mon May 17 18:12:40 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 17 May 2004 19:12:40 -0400 Subject: [sebhc] Power switches, etc. In-Reply-To: References: Message-ID: <40A946E8.6090602@sc.rr.com> I found one in the All Electronics cat that will probably work. I measured the opening a couple of weeks ago when I was rebuilding it. The opening is 1.1" x .55" (about). All has a lighted rocker switch CAT# LRS-17. Looks like it will fit. Not an exact match, but probably close enough. Carroll Steven Parker wrote: > Dang, now I have ANOTHER bad power switch.. anyone know of a source > for an exact replacement ? I hate to mess up the case to put a > different one in. > > On those 2716's ... I seem to recall casually replacing the original > rom's with them whenever we were trying out custom code or upgrades. > > Steven > > P.S. I found my 37 and 47 .. but I never had H8 interfaces for them > (they were for my H89, which is yet to be powered up). Plus I'm not > sure that 47 ever worked .. I got it 2nd hand. Which is too bad, > since I have a bunch of software on 8-inch disks, including, if I > remember right, the HDOS source code. > > _________________________________________________________________ > Stop worrying about overloading your inbox - get MSN Hotmail Extra > Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Mon May 17 18:15:39 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 17 May 2004 19:15:39 -0400 Subject: [sebhc] Power switches, etc. In-Reply-To: References: Message-ID: <40A9479B.9050004@sc.rr.com> I've been rebuilding some H8's and all the power switches had a greasy mess running out of them. I know it wasn't them when I put them away. I washed the switches out with alcohol, then blew them out with compressed air. (Don't want to start an alchol fire). They worked all right after that. Carroll Steven Parker wrote: > Steve Thatcher says: > >> a recommendation about power switches - don't use them. Buy a pwoer >> strip and use that switch to keep from breaking the OLD ones... > > > Good idea. But as far as I can tell, these failed in storage. I know > the units were working when boxed, but when unpacked the switch > wouldn't close even on the first try. It FEELS like it's working though. > > Anyway, I'd love to find a source for snap-in replacements that fit > the cabinet. > > _________________________________________________________________ > Express yourself with the new version of MSN Messenger! Download today > - it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 17 18:11:59 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 17 May 2004 18:11:59 -0500 Subject: [sebhc] H17 ROMS In-Reply-To: <200405172231.i4HMVqRe044479@gatekeeper.evocative.com> Message-ID: <000001c43c64$5bcb1ad0$1f6fa8c0@eths.k12.il.us> I located a 1980 copy of the TI MOS Memory Data Book, which I take to be an authoritative source, barring misprints. - Things start off pretty clearly - everybody makes a 3 supply 1Kx8 ROM labeled with some version of 2708 (except for the Fujitus MB 8518H) - TMS 2508 is a 5v 1Kx8 ROM - TMS 2758 is a 5v 1Kx8 ROM with the option for pin 19 (array select) to be active high or active low; pin 19 is NC in the 2508 - TMS 2716 is a 3 supply 2Kx8 ROM - TMS 2516 is a 5v 2Kx8 ROM, pin compatible with everyone else's 2716 (including Intel) - TMS 2532 is a 5v 4Kx8 ROM, not pin compatible with the Intel 2732 I've got a couple 2516's in the eraser now; I'll try to copy H17 ROM dump a little later tonight. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Monday, May 17, 2004 5:32 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] H17 ROMS > > > >The only schematic I had handy that used a 2516 was for the > SWTP MP-09 > >6809 CPU board from Mike Holley's site. Interestingly, the text > >description of the circuit says at first that the EPROM > sockets on the > >board are 2716 compatible, but the parts listing for the board says > >those socket positions take 2516 compatible EPROMs. The schematic > >clearly shows, however, a 2716-compatible pinout. > > Btw, keep in mind that there are two distinct familes of 2716 > devices, and they are not compatible with each other. There's > the Intel type 2716 which uses a single 5v supply (not > counting programming), and the TI style 2716 which used > multiple supplies (-5 etc). > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 17 18:25:59 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 17 May 2004 18:25:59 -0500 Subject: [sebhc] emulator resources in the archive In-Reply-To: <200405172231.i4HMVqD7044478@gatekeeper.evocative.com> Message-ID: <000101c43c66$501264d0$1f6fa8c0@eths.k12.il.us> > excited is when it > >emulates floppies. > > Thanks for the kind words - I am planning to do floppies, but > I must confess that my main goal in writing emulators is to > allow people to experience the actual vintage machines that I > have in my collection - to that end, my H8 simulator is > already pretty much there, as I don't think I can do anything > on it that I can't in the emulator (in fact the emulator has > a lot more memory so it can do more) - I will however add > disk support because a few people have expressed interest, > although I have not heard much since, so I don't know what > the level of interest actually is. (Now if I could find a > REAL disk controller for my H8, I'd have a real incentive!). > > I should also find out the details of the "Zero origin RAM" > option, as I would like to add that as well - that way it > could boot CP/M (?) > > Dave, The hardsector floppy controller (H17) docs and ROM, as well as a ROM listing are in the archive, as are docs on the H37/67 soft-sector/hard-disk and H47 8" floppy controllers. There are also dumps and manuals for the XCON (0-org) and PAM37 options. I've got the listing for XCON (not yet uploaded) but not the PAM37 ROM. I think the H17 floppy system was by far the most common setup. The ability to mix-and-match between real and virtual H8s and H17s would be very nice indeed. Jack -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Mon May 17 19:23:00 2004 From: waltm22 at comcast.net (Walter Moore) Date: Mon, 17 May 2004 17:23:00 -0700 Subject: [sebhc] Power switches, etc. In-Reply-To: Message-ID: <000401c43c6e$4b666f50$0700a8c0@walterp4> I currently have 3 of the 8" Remex drives up and running, and could give a shot at transferring the 8" data to a PC or to 5.25" disks once the group order of disks comes in (Are they HDOS format?). If you ever want to sell the 47, I'd gladly help you out :) I'd also gladly take a look at it if you wanted. I've found it very valuable to have extra units to swap when testing. I'd just need the drives, not the entire unit. One thing to note about the Remex 4810 drive is that it really doesn't care if the slave drive is a Remex 4820 or some other drive. It just talks via industry standard control signals. If there is communications to the controller on the 4810, you can take any other 8" drive and make them SY0: and SY1:. I have various 8" drives that I am going to be testing out as soon as I make an adapter cable. ..walt > P.S. I found my 37 and 47 .. but I never had H8 interfaces for them (they > were for my H89, which is yet to be powered up). Plus I'm not sure that > 47 > ever worked .. I got it 2nd hand. Which is too bad, since I have a bunch > of > software on 8-inch disks, including, if I remember right, the HDOS source > code. > > _________________________________________________________________ > Stop worrying about overloading your inbox - get MSN Hotmail Extra > Storage! > http://join.msn.click-url.com/go/onm00200362ave/direct/01/ > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Mon May 17 19:53:50 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Mon, 17 May 2004 17:53:50 -0700 Subject: [sebhc] Power switches, etc. In-Reply-To: <000401c43c6e$4b666f50$0700a8c0@walterp4> Message-ID: <007401c43c72$953eddc0$f300a8c0@berkeley.evocative.com> > One thing to note about the Remex 4810 drive is that it > really doesn't care if the slave drive is a Remex 4820 or > some other drive. It just talks via industry standard > control signals. If there is communications to the > controller on the 4810, you can take any other 8" drive and > make them SY0: and SY1:. I have various 8" drives that I am > going to be testing out as soon as I make an adapter cable. > > ..walt By the way, everyone, there's a Remex drive for sale on VCM (http://marketplace.vintage.org/) for $3.00. I'm not sure the model, but I know Marvin would tell you if you asked (and I'm pretty sure it's not the 4810). Patrick -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 17 21:52:33 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 02:52:33 +0000 Subject: [sebhc] emulator resources in the archive Message-ID: >The hardsector floppy controller (H17) docs and ROM, as well as a ROM >listing are in the archive, FYI - that "H17 ROM listing" in there is only the parts of the ROM that do general utility stuff (like 16-bit math functions). The actual disk functions are NOT in that partial listing. _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 17 22:11:16 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 03:11:16 +0000 Subject: [sebhc] unpacking and ressurecting... Message-ID: >Ok - well how about some pictures? I'd love to see the details of the >original >H8 - is it much different than later ones? I wish I had a digital camera. :-( But this is the first "production" unit .. what they called a "proof" unit. So visibly, it's very similar. Some differences are: The finish on the shield metal is different. The boards don't have that layer of green coating. A lot of the chips (particularly the CPU and memory chips) are the ceramic and gold package, not the black plastic type. P10 was never installed on the bus board. There are a few jumper wires on some boards that later boards wouldn't have (or need). It's current status: After bridging the open power switch, and warming it up on the variac, it came up and ran the memory test successfully. _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 17 23:03:04 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 17 May 2004 23:03:04 -0500 Subject: [sebhc] H17 ROM success Message-ID: <000001c43c8d$05ab8a80$1f6fa8c0@eths.k12.il.us> I was able to successfully burn a memory dump from a Heath H17 ROM (Intel 2316) into a TI 2516 EPROM and boot my system, so there is a series of questions laid to rest. I'm sending a copy off tomorrow to Carroll for his new controller board. Jack -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Tue May 18 01:51:22 2004 From: waltm22 at comcast.net (Walter Moore) Date: Mon, 17 May 2004 23:51:22 -0700 Subject: [sebhc] Power switches, etc. In-Reply-To: <40A946E8.6090602@sc.rr.com> Message-ID: <000c01c43ca4$88d6ad10$0700a8c0@walterp4> While browsing one of the local electronics junk store, I came across a Dreefs switch which fit perfectly. I think I paid about a dollar for it. I was going to pick a few up on the next trip to keep around. Let me know if you want one. I also came across a 10-pin version of the tin plated card edge connector needed for the H8. I bent the pins to 90 degrees and it fit into my H-10 breadboard just fine. I know they aren't the 25 pin version, but they were 8 for $1, and these guys are very flexible in pricing. They probably had 2000 of these. I could get some if there is any interest. ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll > Waddell > Sent: Monday, May 17, 2004 4:13 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] Power switches, etc. > > I found one in the All Electronics cat that will probably work. I > measured the opening a couple of weeks ago when I was rebuilding it. The > opening is 1.1" x .55" (about). All has a lighted rocker switch CAT# > LRS-17. Looks like it will fit. Not an exact match, but probably close > enough. > Carroll > > Steven Parker wrote: > > > Dang, now I have ANOTHER bad power switch.. anyone know of a source > > for an exact replacement ? I hate to mess up the case to put a > > different one in. > > > > On those 2716's ... I seem to recall casually replacing the original > > rom's with them whenever we were trying out custom code or upgrades. > > > > Steven > > > > P.S. I found my 37 and 47 .. but I never had H8 interfaces for them > > (they were for my H89, which is yet to be powered up). Plus I'm not > > sure that 47 ever worked .. I got it 2nd hand. Which is too bad, > > since I have a bunch of software on 8-inch disks, including, if I > > remember right, the HDOS source code. > > > > _________________________________________________________________ > > Stop worrying about overloading your inbox - get MSN Hotmail Extra > > Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ > > > > -- > > Delivered by the SEBHC Mailing List > > > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 18 06:39:13 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 18 May 2004 06:39:13 -0500 Subject: [sebhc] Power switches, etc. In-Reply-To: <000c01c43ca4$88d6ad10$0700a8c0@walterp4> Message-ID: <003b01c43ccc$be9f91a0$1f6fa8c0@eths.k12.il.us> Walt, If there are more available, I'm good for 6 of the power switches. Thanks. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Walter Moore > Sent: Tuesday, May 18, 2004 1:51 AM > To: sebhc at sebhc.org > Subject: RE: [sebhc] Power switches, etc. > > > While browsing one of the local electronics junk store, I > came across a Dreefs switch which fit perfectly. I think I > paid about a dollar for it. I was going to pick a few up on > the next trip to keep around. Let me know if you want one. > > I also came across a 10-pin version of the tin plated card > edge connector needed for the H8. I bent the pins to 90 > degrees and it fit into my H-10 breadboard just fine. I know > they aren't the 25 pin version, but they were 8 for $1, and > these guys are very flexible in pricing. They probably had > 2000 of these. I could get some if there is any interest. > > ..walt > > > -----Original Message----- > > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll > > Waddell > > Sent: Monday, May 17, 2004 4:13 PM > > To: sebhc at sebhc.org > > Subject: Re: [sebhc] Power switches, etc. > > > > I found one in the All Electronics cat that will probably work. I > > measured the opening a couple of weeks ago when I was > rebuilding it. > > The opening is 1.1" x .55" (about). All has a lighted > rocker switch > > CAT# LRS-17. Looks like it will fit. Not an exact match, > but probably > > close enough. Carroll > > > > Steven Parker wrote: > > > > > Dang, now I have ANOTHER bad power switch.. anyone know > of a source > > > for an exact replacement ? I hate to mess up the case to put a > > > different one in. > > > > > > On those 2716's ... I seem to recall casually replacing > the original > > > rom's with them whenever we were trying out custom code > or upgrades. > > > > > > Steven > > > > > > P.S. I found my 37 and 47 .. but I never had H8 > interfaces for them > > > (they were for my H89, which is yet to be powered up). > Plus I'm not > > > sure that 47 ever worked .. I got it 2nd hand. Which is too bad, > > > since I have a bunch of software on 8-inch disks, including, if I > > > remember right, the HDOS source code. > > > > > > _________________________________________________________________ > > > Stop worrying about overloading your inbox - get MSN > Hotmail Extra > > > Storage! > http://join.msn.click-> url.com/go/onm00200362ave/direct/01/ > > > > > > -- > > > 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 CarrollWaddell at sc.rr.com Tue May 18 07:35:56 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Tue, 18 May 2004 08:35:56 -0400 Subject: [sebhc] Power switches, etc. In-Reply-To: <000c01c43ca4$88d6ad10$0700a8c0@walterp4> References: <000c01c43ca4$88d6ad10$0700a8c0@walterp4> Message-ID: <40AA032C.6090209@sc.rr.com> I wouldn't mind getting a couple of switches and some of the connectors. Carroll Walter Moore wrote: >While browsing one of the local electronics junk store, I came across a >Dreefs switch which fit perfectly. I think I paid about a dollar for it. >I was going to pick a few up on the next trip to keep around. Let me know >if you want one. > >I also came across a 10-pin version of the tin plated card edge connector >needed for the H8. I bent the pins to 90 degrees and it fit into my H-10 >breadboard just fine. I know they aren't the 25 pin version, but they were >8 for $1, and these guys are very flexible in pricing. They probably had >2000 of these. I could get some if there is any interest. > >..walt > > > >>-----Original Message----- >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll >>Waddell >>Sent: Monday, May 17, 2004 4:13 PM >>To: sebhc at sebhc.org >>Subject: Re: [sebhc] Power switches, etc. >> >>I found one in the All Electronics cat that will probably work. I >>measured the opening a couple of weeks ago when I was rebuilding it. The >>opening is 1.1" x .55" (about). All has a lighted rocker switch CAT# >>LRS-17. Looks like it will fit. Not an exact match, but probably close >>enough. >>Carroll >> >>Steven Parker wrote: >> >> >> >>>Dang, now I have ANOTHER bad power switch.. anyone know of a source >>>for an exact replacement ? I hate to mess up the case to put a >>>different one in. >>> >>>On those 2716's ... I seem to recall casually replacing the original >>>rom's with them whenever we were trying out custom code or upgrades. >>> >>>Steven >>> >>>P.S. I found my 37 and 47 .. but I never had H8 interfaces for them >>>(they were for my H89, which is yet to be powered up). Plus I'm not >>>sure that 47 ever worked .. I got it 2nd hand. Which is too bad, >>>since I have a bunch of software on 8-inch disks, including, if I >>>remember right, the HDOS source code. >>> >>>_________________________________________________________________ >>>Stop worrying about overloading your inbox - get MSN Hotmail Extra >>>Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ >>> >>>-- >>>Delivered by the SEBHC Mailing List >>> >>> >>> >>-- >>Delivered by the SEBHC Mailing List >> >> > > > >-- >Delivered by the SEBHC Mailing List > > > From CarrollWaddell at sc.rr.com Tue May 18 07:38:37 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Tue, 18 May 2004 08:38:37 -0400 Subject: [sebhc] MORE ROMS Message-ID: <40AA03CD.9090400@sc.rr.com> Does anyone have information about which ROM (CPU ROM) is related to which part number? I believe that 444-13 is the original PAM8. 444-70 seems to be the one that came with XCON. I have one in a CPU board that is 444-74. I'm not sure which one this is? Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 18 07:52:54 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 18 May 2004 07:52:54 -0500 Subject: [sebhc] MORE ROMS In-Reply-To: <40AA03CD.9090400@sc.rr.com> Message-ID: <001201c43cd7$09d1b4f0$1f6fa8c0@eths.k12.il.us> Carroll, Here's my list of ROMs and EPROM equivalents so far: PAM-8 = 444-13 - 2708 (?) H17 = 444-19 - 2316 (EPROM equivalent = TI 2516, Intel 2716) PAMGO = 444-60 - 2716 (?) XCON-8 = 444-70 (alt 444-74) supplied with XCON kit or Z80 cpu PAM-37 = 444-140 (alt 444-144) supplied with H8-37 (TI 2532) I'd be very interested in a dump of your 444-74 ROM to see what's different! Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Tuesday, May 18, 2004 7:39 AM > To: sebhc at staunch89er.com > Subject: [sebhc] MORE ROMS > > > Does anyone have information about which ROM (CPU ROM) is related to > which part number? I believe that 444-13 is the original PAM8. 444-70 > seems to be the one that came with XCON. I have one in a CPU > board that > is 444-74. I'm not sure which one this is? > Carroll > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Tue May 18 08:17:41 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Tue, 18 May 2004 09:17:41 -0400 Subject: [sebhc] MORE ROMS In-Reply-To: <001201c43cd7$09d1b4f0$1f6fa8c0@eths.k12.il.us> References: <001201c43cd7$09d1b4f0$1f6fa8c0@eths.k12.il.us> Message-ID: <40AA0CF5.6020602@sc.rr.com> I thought I got that ROM when I installed XCON and H17 years ago. By the way, I'm going into Sumter in a few minutes, and I'll put the memory cards in the mail. Carroll Jack Rubin wrote: >Carroll, > >Here's my list of ROMs and EPROM equivalents so far: > >PAM-8 = 444-13 - 2708 (?) >H17 = 444-19 - 2316 (EPROM equivalent = TI 2516, Intel 2716) >PAMGO = 444-60 - 2716 (?) >XCON-8 = 444-70 (alt 444-74) supplied with XCON kit or Z80 cpu >PAM-37 = 444-140 (alt 444-144) supplied with H8-37 (TI 2532) > >I'd be very interested in a dump of your 444-74 ROM to see what's >different! > >Jack > > > >>-----Original Message----- >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of >>Carroll Waddell >>Sent: Tuesday, May 18, 2004 7:39 AM >>To: sebhc at staunch89er.com >>Subject: [sebhc] MORE ROMS >> >> >>Does anyone have information about which ROM (CPU ROM) is related to >>which part number? I believe that 444-13 is the original PAM8. 444-70 >>seems to be the one that came with XCON. I have one in a CPU >>board that >>is 444-74. I'm not sure which one this is? >>Carroll >> >>-- >>Delivered by the SEBHC Mailing List >> >> >> > >-- >Delivered by the SEBHC Mailing List > > > From sp11 at hotmail.com Tue May 18 12:43:27 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 17:43:27 +0000 Subject: [sebhc] archive update Message-ID: >Does anyone have information about which ROM (CPU ROM) is related to which >part number? I've updated the archives so if you use the web interface most items will have something in the "description" column. Generally this will be the heath part number, such as for the ROMs. In the case of the HUG software, which was only identified by part number, it's a text description. Cheers, - Steven _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 18 13:15:16 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 18:15:16 +0000 Subject: [sebhc] Power switches, etc. Message-ID: >Dreefs switch which fit perfectly. I think I paid about a dollar for it. >I was going to pick a few up on the next trip to keep around. Let me know >if you want one. 2 for me. By the way, anyone got any spare 4044's or 4104's? I need one of each. _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Tue May 18 15:37:36 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 18 May 2004 13:37:36 -0700 (PDT) Subject: [sebhc] New uploads Message-ID: <200405182037.i4IKba1Y066032@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 18 May 2004 21:06:10 -0000 I've just posted three files to my web site (I'm sure Jack will copy em to sebhc): www.dunfield.com/pub/h8.zip - Slightly updated emulator - couple of very minor bugs fixed. www.dunfield.com/pub/h8tools.zip - Some handy tools for the H8: H8T : H8 Translate/Transfer utility This allows you to easily and instantly translate files between any of the following types, and also to upload/download files of these types to/from the H8 without having to translate them first (Very handly utility!): .H8T - H8 Tape image (same as .PID) .HEX - Intel or Motorola ASCII/HEX download format (used by most dev tools) .BIN - Raw binary image SERIO.ASM : A small "Stub" I wrote to perform interrupt driven serial I/O to the H8 console. Makes it very easy to port existing code into the H8. Provides a 64 byte FIFO buffer on receive. ASM80 - My 8080 cross assembler DIS80 - My 8080 cross disassembler MACRO - Macro processor for ASM80 www.dunfield.com/pub/h8chess.zip - A chess game which I relocated and got running on the H8 (plays a decent game). Enjoy, 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 Tue May 18 16:55:00 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 21:55:00 +0000 Subject: [sebhc] New uploads Message-ID: > .H8T - H8 Tape image (same as .PID) Eeek... another extension for the same thing? I was thinking about just calling these ".tape", since its more descriptive (and the other emulator uses it already). Likewise, I was going to call pure disk images ".disk". I'm already starting to create some and will put them in the archives shortly. What'll be REALLY fun is when we can boot these in the emulator. :-) Cheers, - Steven _________________________________________________________________ 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 dwight.elvey at amd.com Tue May 18 17:05:43 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 18 May 2004 15:05:43 -0700 (PDT) Subject: [sebhc] New uploads Message-ID: <200405182205.PAA10357@clulw009.amd.com> >From: "Steven Parker" > >> .H8T - H8 Tape image (same as .PID) > >Eeek... another extension for the same thing? I was thinking about just >calling these ".tape", since its more descriptive (and the other emulator >uses it already). Likewise, I was going to call pure disk images ".disk". >I'm already starting to create some and will put them in the archives >shortly. > >What'll be REALLY fun is when we can boot these in the emulator. :-) > >Cheers, > >- Steven Hi Steve Three letter extensions for DOS. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 18 17:06:56 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 22:06:56 +0000 Subject: [sebhc] software request Message-ID: Does anyone have the "chase LEDs" demo game? It was cute because it was a game you could play on the H-8 without a terminal. Oh, I created an animated H-8 logo for the web site .. check it out! _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 18 17:20:56 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 18 May 2004 17:20:56 -0500 Subject: [sebhc] New uploads In-Reply-To: <200405182037.i4IKba1Y066032@gatekeeper.evocative.com> Message-ID: <000001c43d26$648dc240$1f6fa8c0@eths.k12.il.us> done - I've started naming your releases with date codes so we can keep track of them! > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Tuesday, May 18, 2004 3:38 PM > To: sebhc at sebhc.org > Subject: [sebhc] New uploads > > > I've just posted three files to my web site (I'm sure Jack > will copy em to sebhc): > > www.dunfield.com/pub/h8.zip > - Slightly updated emulator - couple of very minor bugs fixed. > > www.dunfield.com/pub/h8tools.zip - Some handy tools for the H8: H8T : H8 Translate/Transfer utility This allows you to easily and instantly translate files between any of the following types, and also to upload/download files of these types to/from the H8 without having to translate them first (Very handly utility!): .H8T - H8 Tape image (same as .PID) .HEX - Intel or Motorola ASCII/HEX download format (used by most dev tools) .BIN - Raw binary image SERIO.ASM : A small "Stub" I wrote to perform interrupt driven serial I/O to the H8 console. Makes it very easy to port existing code into the H8. Provides a 64 byte FIFO buffer on receive. ASM80 - My 8080 cross assembler DIS80 - My 8080 cross disassembler MACRO - Macro processor for ASM80 www.dunfield.com/pub/h8chess.zip - A chess game which I relocated and got running on the H8 (plays a decent game). Enjoy, 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 dave04a at dunfield.com Tue May 18 17:42:35 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 18 May 2004 15:42:35 -0700 (PDT) Subject: [sebhc] New uploads Message-ID: <200405182242.i4IMgY7f068236@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 18 May 2004 22:53:31 -0000 At 21:55 18/05/2004 +0000, you wrote: >> .H8T - H8 Tape image (same as .PID) > >Eeek... another extension for the same thing? I was thinking about just >calling these ".tape", since its more descriptive (and the other emulator >uses it already). Likewise, I was going to call pure disk images ".disk". >I'm already starting to create some and will put them in the archives >shortly. > >What'll be REALLY fun is when we can boot these in the emulator. :-) Hi Steven, Well ... I can't find any solid description of what "PID" means in relation to an H8 - from what I read here, it was the extension used by a company for an unrelated program image file... I know I could not figure what it ment when I first ran across it. I don't like ".tape" and ".disk" for two reasons: #1 - it's incompatible with DOS 8.3 naming conventions, and since my emulator is a DOS based program, it would not be able to use them. #2 - It does not tell you what machine it's for. I have a number of emulators, and it's nice if you can tell what machine a file is for ... ".DSK" could be for any one. so -- I chose ".H8T" which stands for "H8 Tape", if I do a disk emulation, the disk file will be called ".H8D" which will stand for "H8 Disk". If someone can present a good H8 related reason for the extension "PID", I will be happy to switch it all back. Btw, the emulator allows you to specify an alternate extension if you really want to use "PID" -- Also, if anyone feels really strongly about it, I can modify H8T to recognize the PID extensions as an H8 tape as well. You can already load .H8T files into the emulator. I downloaded the H17 document today, however I cannot read it with my version of Adobe, and I don't want to trash my full-up Adobe-4 install by putting on 5 or 6 reader or whatever the version is this week - did that once before. So ... not sure how I will proceed, but for now it will have to wait until I can find a paper copy of the document or a readable download file. [Turns out that 1/2 or more of the documents in the archive are unreadable to me, which is VERY annoying - I've not seen this anywhere else - and I download a fair number of PDF's in my line of work] 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 Tue May 18 17:46:26 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 22:46:26 +0000 Subject: [sebhc] dos files Message-ID: >>I was thinking about just calling these ".tape", [and] pure disk images >>".disk". > Three letter extensions for DOS. Gee, how old is that DOS? But anyway, ".tape" truncates nicely to ".tap". Perhaps ".dis" isn't quite as nice but we could say it stands for "diskette image software". :-) _________________________________________________________________ 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 dave04a at dunfield.com Tue May 18 18:07:43 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 18 May 2004 16:07:43 -0700 (PDT) Subject: [sebhc] New uploads Message-ID: <200405182307.i4IN7bLm068763@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 18 May 2004 23:14:00 -0000 At 17:20 18/05/2004 -0500, you wrote: >done - I've started naming your releases with date codes so we can keep >track of them! Probably a good idea - although I don't think there's any reason to keep older versions around while it's still in it's infancy. If you look, you will see that the emulator displays the time and date that it was compiled when it starts up - This is automatically done my my C preprocessor, so I don't even have to think about it - I find this muchmore reliable than version numbers, and most everrything new that I've written in the past few years uses this technique. 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 Tue May 18 18:21:23 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 23:21:23 +0000 Subject: [sebhc] New uploads Message-ID: >done - I've started naming your releases with date codes so we can keep >track of them! My guess would be that since this is a work-in-progress, we only need to store the latest one, as Dave does on his own site. Right? _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 18 18:46:49 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 18 May 2004 23:46:49 +0000 Subject: [sebhc] naming conventions Message-ID: >I don't like ".tape" and ".disk" ... > #2 - It does not tell you what machine it's for. I have a number of >emulators, and > it's nice if you can tell what machine a file is for ... ".DSK" >could be for > any one. I was just assuming one would keep separate emulators and their associated software in different locations (folders). :-) >so -- I chose ".H8T" which stands for "H8 Tape", if I do a disk emulation, >the >disk file will be called ".H8D" which will stand for "H8 Disk". It's your emulator .. you win ! :-) >If someone can present a good H8 related reason for the extension "PID", I >will be >happy to switch it all back. Hey, I was only lobbying for "tape". :-) >[Turns out that 1/2 or more of the documents in the archive are unreadable >to me, > which is VERY annoying - I've not seen this anywhere else - and I >download a fair > number of PDF's in my line of work] My version5 reads them but always gives the warning "may contain newer information than this browser can support." I don't think these have anything fancy in them ... I wonder - is there a simple way to convert them to a more universal format? Cheers, - Steven _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 18 19:05:35 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 18 May 2004 19:05:35 -0500 Subject: [sebhc] New uploads In-Reply-To: <200405182307.i4IN7bLm068763@gatekeeper.evocative.com> Message-ID: <000001c43d35$02f61820$1f6fa8c0@eths.k12.il.us> > > At 17:20 18/05/2004 -0500, you wrote: > >done - I've started naming your releases with date codes so > we can keep > >track of them! > > If you look, you will see that the emulator displays the time > and date that it was compiled when it starts up - This is > automatically done my my C preprocessor, so I don't even have I'm really just adding dates as my own sanity check - I figure I'll keep the current and the last working old one on file, kinda like the real world. Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Tue May 18 22:42:52 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 18 May 2004 20:42:52 -0700 (PDT) Subject: [sebhc] Tape recovery Message-ID: <200405190342.i4J3gmVZ072735@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 19 May 2004 04:10:37 -0000 I've been recovering data from the Tapes that Jack sent to me. They are very brittle - the tape comes off the leader very easily, and I have had to cur a few open and repair them. So far I have: BUG-8 2.01.01 BUG-8 2.05.00 TED-8 3.01.01 TED-8 3.05.00 HASL-8 4.01.01 HASL-8 4.05.00 BHBASIC 5.01.01 BHBASIC 5.01.02 EXBASIC 10.05.00 I still have a number of tapes marked "memory images" to go - a couple of slips of paper indicating that they have memory test and led display programs. I'm guessing that the first digit is an identifier of the program? and that perhaps the 01.01 files are original first versions (?) So far I have NOT been able to recover EXBASIC from the tapes - I don't have enough memory to load it. I have a couple of different EXBASIC tapes - one says 10.02.02 on the tape, and 10.02.01 on the drawer it's in - the other does not mention a version. I've been trying for several hours to figure out a way to read the tape and output to the console port on the fly, however no matter what I try I do not see any data from the Cassette port within my H8 program. PAM-8 can load the tapes fine - but I read the Tape status port ($F9) and test the RX-READY bit (02 mask) and I never see a data indication. I have initialized the ports EXACTLY the way PAM-8 does (I patched the emulator to record all I/O events and looked to see exactly what PAM-8 does) ... but I still cannot see any data (and YES - I remembered to set the interchange switch back to normal). The program works under the emulator - if I mount an input file on the tape port and run the program, it dutifully barfs it out to the console, however on the real H8 with the tape running - I get nothing! I still have a number of tapes marked "memory images" to go - a couple of slips of paper indicating that they have memory test and led display programs. Anyone know what I have to do to read the cassette interface? 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 May 19 06:12:59 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 19 May 2004 04:12:59 -0700 (PDT) Subject: [sebhc] naming conventions Message-ID: <200405191113.i4JBCxto081182@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 19 May 2004 11:25:17 -0000 >> #2 - It does not tell you what machine it's for. I have a number of >>emulators, and it's nice if you can tell what machine a file is for ... >>".DSK" could be for any one. > >I was just assuming one would keep separate emulators and their associated >software in different locations (folders). :-) While this is generally true, it's not uncommon (for me anyway) to come across a .DSK file on a floppy diskette that I've saved or transported ... It's also not uncommon to send/receive disk images by email, and if I don't get a "round tuit" for a while, I may have difficulty recalling what the file was for. >>[Turns out that 1/2 or more of the documents in the archive are unreadable >>to me, which is VERY annoying - I've not seen this anywhere else - and I >>download a fair number of PDF's in my line of work] > >My version5 reads them but always gives the warning "may contain newer >information than this browser can support." I don't think these have >anything fancy in them ... I wonder - is there a simple way to convert them >to a more universal format? I sacrificed one of my P166 test machines this morning, and loaded the Acrobloat 5 reader on it - it reads the file but complains that it may have information that it can't understand - It takes about 1 munite to respond to any click, which means it takes a munite to switch to "full page view", then another minute to get past the title page, another minute to get past each page. Add 3 munites for any page you want to read (one to zoom in to top, one to go to bottom, and one to go back to full page display). Since it's a 30+ (IIRC) page document, it would take several hours just to scroll through the document once - Clearly I cannot use this. So I decided to print it. In all, I allowed it to print 4 pages - it took over 1/2 hour per page (yes, over 2 hours to do the four pages): The four pages I got were: 1 - top half of title page - looks normal (except that it cuts off 1/2 way down, just as the image starts). 2 - top half: = top corner of disk unit picture from title page, maginified perhaps 100 times (All you can see is a bit of the label) bottom: grey "blotch", probably another part of the picture. 3 - Word "PAGE 2" about 1.5 inch high. Part of the into, letters about 1 inch high, but overlaid on top of each other all in all about 12 lines overlapped - just a jumble. 3 - 1st half of heathkit logo, about 2" high. The about another 8-10 lines of huge text / overlapped. So - clearly I cannot view or print it. Btw, I normally run Acro-4 on this same machine with no trouble - in fact it has my sheet fed scanner attached and it's where I've scanned and printed many documents - I also download and print lots of data sheets and other info - never have I run into this before. All of the files I've scanned with Adobe 4 can be read with 3, 4 and 5 (and presumably 6 but I don't have it to test). Earlier this year I raised concerns about the readability of the documents, but I was told to "get in the game". I find it somewhat funny that a group of people who are dedicated to preserving and using a computer from the 70's have arranged the archived information so that it is inaccessable to anyone with a computer or software more than a few weeks old. Many/most of the people I communicate with regarding "vintage computing equipment" seem to (like me) have a distain for winblows, especially the more recent offerings, however you guys appear to be embracing it with arms wide open. Ok - enough flogging the dead horse - The emulator has reached the point where it meets my requirements (It simulates capabilities of the actual H8 in my collection), so I can live without a disk. 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 jack.rubin at ameritech.net Wed May 19 06:42:10 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 19 May 2004 06:42:10 -0500 Subject: [sebhc] download and printing problems? In-Reply-To: <200405191113.i4JBCxto081182@gatekeeper.evocative.com> Message-ID: <002501c43d96$5284a530$1f6fa8c0@eths.k12.il.us> Dave said: > So I decided to print it. > > In all, I allowed it to print 4 pages - it took over 1/2 hour > per page (yes, over 2 hours to do the four pages): > > The four pages I got were: > > 1 - top half of title page - looks normal (except that it > cuts off 1/2 way down, > just as the image starts). > > 2 - top half: = top corner of disk unit picture from title > page, maginified perhaps > 100 times (All you can see is a bit of the label) > bottom: grey "blotch", probably another part of the picture. > > 3 - Word "PAGE 2" about 1.5 inch high. > Part of the into, letters about 1 inch high, but overlaid > on top of each > other all in all about 12 lines overlapped - just a jumble. > > 3 - 1st half of heathkit logo, about 2" high. The about > another 8-10 lines of > huge text / overlapped. > what file was this? anybody else having similar (or other) problems? (or anybody else downloading and printing with no problems?) Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed May 19 07:28:02 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 19 May 2004 05:28:02 -0700 (PDT) Subject: [sebhc] download and printing problems? Message-ID: <200405191228.i4JCS1bs082128@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 19 May 2004 12:36:57 -0000 >what file was this? >anybody else having similar (or other) problems? >(or anybody else downloading and printing with no problems?) It's the H17 floppy disk controller document. I doub't its a problem with the file - it seems that Acrobat 5 doesn't run very well under Win98. I haven't tried printing any other files from the archives, as I don't normally use AB5 (way too slow to be useful), and they just show page sized "grey boxes" under AB4 (no images). Regards, -- 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 cfandt at netsync.net Wed May 19 08:24:13 2004 From: cfandt at netsync.net (Christian Fandt) Date: Wed, 19 May 2004 09:24:13 -0400 Subject: [sebhc] download and printing problems? In-Reply-To: <200405191228.i4JCS1bs082128@gatekeeper.evocative.com> Message-ID: <5.2.1.1.2.20040519083720.0223aae0@pop3.norton.antivirus> Dave (and all), As you likely know, your machine is underpowered for that bloatware application. I believe you wrote in the earlier part of this thread, which I didn't keep, that you use a P166 machine. I use windoze98SE and the latest Acrobat Reader ver. 6 (not the complete Acrobat app.) and I have acceptable results. However, my machine is an AMD Athlon XP 1800+ with 512 Meg of RAM and a moderately fast mo'board. Even with this higher horsepower, it STILL takes around ten seconds or so just to load the .dll's and crap and START the danged Reader before anything begins to display. But, I can view and print in a normal manner the H17 manual you are discussing Dave, as well as any other .pdf I've worked with. Nevertheless, I can't blame you at all for your disdain of M$ windoze stuff and its associated bloatware. I still resist leaving windoze98SE but fear that I'll have to break down and load up win 2k sometime soon :-/ Certainly not winXP, if ever. By then, I'll have settled into Linux. Can you imagine what it would be like if we *only* had uProcessors like the 8-bit Z80 (but at least with huge amounts of cheap memory available) and *had* to use bloatware like this??! Hospitals would be chock full of suicidal patients and newly-minted lunatics. Anxiety attacks would abound. Office anarchy everywhere! All this discussion on this new list (new for me) is very slowly prodding me into hauling out my good ol' H8/H37/H19 system to play with once again. Thanks much! And I was originally thinking of getting out one of my H11/H27/H9 systems first to see if an RT-11 distribution I had could fire up . . . Jeeeze, just what I need. Yet *another* project to tinker with around here! ;-) Regards, Chris NNNN Upon the date 05:28 AM 5/19/04 -0700, Dave Dunfield said something like: > >what file was this? > >anybody else having similar (or other) problems? > >(or anybody else downloading and printing with no problems?) > >It's the H17 floppy disk controller document. > >I doub't its a problem with the file - it seems that Acrobat 5 doesn't >run very well under Win98. > >I haven't tried printing any other files from the archives, as I don't >normally use AB5 (way too slow to be useful), and they just show page >sized "grey boxes" under AB4 (no images). > >Regards, >-- >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 Christian Fandt, Electronic/Electrical Historian Jamestown, NY USA cfandt at netsync.net Member of Antique Wireless Association URL: http://www.antiquewireless.org/ -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Wed May 19 09:30:26 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Wed, 19 May 2004 10:30:26 -0400 Subject: [sebhc] download and printing problems? In-Reply-To: <200405191228.i4JCS1bs082128@gatekeeper.evocative.com> References: <200405191228.i4JCS1bs082128@gatekeeper.evocative.com> Message-ID: <40AB6F82.50809@sc.rr.com> Dave, I run acro 5 with windows 98, but I haven't run across your problem. It seems to work OK for me. I DO get the warning about newer items. Carroll Dave Dunfield wrote: >>what file was this? >>anybody else having similar (or other) problems? >>(or anybody else downloading and printing with no problems?) >> >> > >It's the H17 floppy disk controller document. > >I doub't its a problem with the file - it seems that Acrobat 5 doesn't >run very well under Win98. > >I haven't tried printing any other files from the archives, as I don't >normally use AB5 (way too slow to be useful), and they just show page >sized "grey boxes" under AB4 (no images). > >Regards, > > From sp11 at hotmail.com Wed May 19 10:21:30 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 19 May 2004 15:21:30 +0000 Subject: [sebhc] emulating disks Message-ID: >The emulator has reached the point where it >meets my requirements (It simulates capabilities of the actual H8 in my >collection), >so I can live without a disk. Really? It's pretty cool so far, but disk emulation is what would truly make it interesting for me. I'd guess that may be true for a lot of the other folks as well. If you don't have any more recent hardware, I'd bet you could view and/or print those pdf's at your local library. But the description section of the H-17 manual is mostly about the controller hardware and not much about programming. It may be more useful to look over the sources for the disk driver code. I just put the contents of two disks of HDOS source material in the archives under software/sources/... You'll probably be most interested in sydvd and it's associated header files. Let me know if you have any specific questions remaining and I'll try to find answers. Cheers, - Steven _________________________________________________________________ Get 200+ ad-free, high-fidelity stations and LIVE Major League Baseball Gameday Audio! http://radio.msn.click-url.com/go/onm00200491ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed May 19 10:39:15 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 19 May 2004 15:39:15 +0000 Subject: [sebhc] Tape recovery Message-ID: >PAM-8 can load the tapes fine - but I read the Tape status port ($F9) and >test the RX-READY bit (02 mask) and I never see a data indication. I have >initialized the ports EXACTLY the way PAM-8 does (I patched the emulator to >record all I/O events and looked to see exactly what PAM-8 does) ... but I >still cannot see any data Two guesses .. PAM-8 inits the port immediately after a hard reset .. sending the init sequence again may have unexpected results. Try just doing I/O in your program assuming the port is already set up. Another idea I had was that perhaps in the process of getting your program in, an interrupt vector got installed and was still live, and the interrupt service routine is stealing the caracters before you can see them. Either of those help? Cheers, - Steven _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed May 19 11:32:37 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 19 May 2004 09:32:37 -0700 (PDT) Subject: [sebhc] download and printing problems? Message-ID: <200405191632.JAA11067@clulw009.amd.com> Hi I've been reading the files on acrobat reader 5.0 under solaris. It does flage the warning but otherwise works OK. The paging is slow but not more than other pdf's. The pages seem to print file. I also have a linux machine but haven't tried it there. Dwight >From: "Dave Dunfield" > > >>what file was this? >>anybody else having similar (or other) problems? >>(or anybody else downloading and printing with no problems?) > >It's the H17 floppy disk controller document. > >I doub't its a problem with the file - it seems that Acrobat 5 doesn't >run very well under Win98. > >I haven't tried printing any other files from the archives, as I don't >normally use AB5 (way too slow to be useful), and they just show page >sized "grey boxes" under AB4 (no images). > >Regards, >-- >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 dave04a at dunfield.com Wed May 19 18:18:26 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 19 May 2004 16:18:26 -0700 (PDT) Subject: [sebhc] Tape recovery Message-ID: <200405192318.i4JNIPc0091950@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 19 May 2004 23:27:36 -0000 Hi Steven, Thanks for the suggestions. >>PAM-8 can load the tapes fine - but I read the Tape status port ($F9) and >>test the RX-READY bit (02 mask) and I never see a data indication. I have >>initialized the ports EXACTLY the way PAM-8 does (I patched the emulator to >>record all I/O events and looked to see exactly what PAM-8 does) ... but I >>still cannot see any data >Two guesses .. PAM-8 inits the port immediately after a hard reset .. >sending the init sequence again may have unexpected results. Try just >doing I/O in your program assuming the port is already set up. I thought of this, and tried two approachs: 1) I did the whole long initialization: - Write dummy command word with out RESET to insure you are not in command state - Write command word with RESET bit set to insure software reset - Write mode word - Write operating command word I also added an I/O trace to the emulator, and looked at EXACTLY what PAM-8 does - It writes the mode word out of reset, but not a command word. The command word gets written when you invoke the Load or Dump function. I tried this same approach - let PAM-8 write the mode word, and then write the command word in my code. I verified under the emulator that the values written to the UART are exactly the same (and no extra ones) Still no joy - I don't see what is going wrong. As noted in my orignal email, it works on the emulator. Ie: If I mount a file as input, the program does read it and dump to the console - since the emulator uses only the addresses and bit of the load/dump 8251, it suggests the program "logically" works (and yes, the emulators implementation works with PAM-8). It appears that something is blocking the Cassette data before it hits the Uart - I'm going to drag out the scope sometime this weekend and look directly and the RxD and RxC pins to see what it happening. >Another idea I had was that perhaps in the process of getting your program >in, an interrupt vector got installed and was still live, and the interrupt >service routine is stealing the caracters before you can see them. Nope - verified this one too - There is no interrupt enabled on the load/dump uart, and there are no vectors set up (yes, I checked). I even tried running the program with interrupts disabled (which kills the front panel, so I know they are indeed disabled) - Still no joy. Will dig into it more when I get some time. Gotta pressing hardware/manufacturing problem with one of my main products, so I'm going to be tied up for the next few days. (Also gotta PDP rescue happening this weekend, so it's going to be busy :-) 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 May 19 22:10:12 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 19 May 2004 20:10:12 -0700 (PDT) Subject: [sebhc] More Tape recovery Message-ID: <200405200310.i4K3ACmQ099277@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 20 May 2004 03:24:09 -0000 Ok - I got the transparent "passthrough" program working, so I can read tapes directly from the H8 into my H8T program on the PC. Using this I was able to recover all of the software from the tapes that Jack sent to me. It took a bit of searching, but I was able to find unconfigured version of all the early H8 Software. Here is a list of the H8 Tape software I've collected so far: Name Version Description ------------------------------ BHBASIC1 05.01.01 Benton Harbor Basic BHBASIC2 05.01.02 "" BUG8-1 02.01.01 H8 Console Debugger BUG8-2 02.05.00 "" TED8-1 3.01.01 H8 Text Editor TED8-2 3.05.00 "" HASL8-1 4.01.01 H8 Assembly Language HASL8-2 04.05.00 "" EXBASIC1 10.01.01 Extended Benton Harbor Basic EXBASIC2 10.02.01 "" EXBASIC3 10.05.00 "" H8HANGM 20.00.00 H8 Hangman game H8CRAPS 21.00.00 H8 Craps game H8NIM 22.00.00 H8 NIM game H8HEXPAW 23.00.00 H8 Hexpawn game H8CHESS --.--.-- H8 Chess game H8DEMO --.--.-- H8 Front Panel DEMO program BHBCONS --.--.-- Benton Harbor Basic Console functions (from tape label) LED1/2/3 --.--.-- These appear to be LED test programs ??? UNKNOWN --.--.-- No Idea - crashes! I've just sent all these to Jack in a ZIP file, which he will hopefully make available in the archive. 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 garlangr at verizon.net Wed May 19 22:24:46 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Wed, 19 May 2004 22:24:46 -0500 Subject: [sebhc] download and printing problems? References: <200405191632.JAA11067@clulw009.amd.com> Message-ID: <02c301c43e1a$00694fb0$a301010a@gr390> Hi David, I tried a Acrobat Reader 6.0 on a P200MMX/Win98SE/64M machine and it was slow but no where near 1 click per minute. It was about 10-15 secs per click. And since the machine is headless, I was even connecting over the network through VNC. So it sounds like the comment about Win98 and version 5.0 not playing well togather might be the issue. Another thing to look at is whether or not the machine has enough memory. Although the file is only 1.2M, each uncompressed page is going to be large. If windows starts swapping you could easily see the slow times you reported. Also with the printing taking even more time, it appears that it could be a memory issue. Printing is going to take up more memory for spooling, printer driver, etc. Was the hard drive light constantly on during your attempt? Mark ----- Original Message ----- From: "Dwight K. Elvey" To: Sent: Wednesday, May 19, 2004 11:32 AM Subject: Re: [sebhc] download and printing problems? > Hi > I've been reading the files on acrobat reader 5.0 under solaris. > It does flage the warning but otherwise works OK. The paging > is slow but not more than other pdf's. The pages seem to print file. > I also have a linux machine but haven't tried it there. > Dwight > > > >From: "Dave Dunfield" > > > > > >>what file was this? > >>anybody else having similar (or other) problems? > >>(or anybody else downloading and printing with no problems?) > > > >It's the H17 floppy disk controller document. > > > >I doub't its a problem with the file - it seems that Acrobat 5 doesn't > >run very well under Win98. > > > >I haven't tried printing any other files from the archives, as I don't > >normally use AB5 (way too slow to be useful), and they just show page > >sized "grey boxes" under AB4 (no images). > > > >Regards, > >-- > >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 garlangr at verizon.net Wed May 19 22:30:57 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Wed, 19 May 2004 22:30:57 -0500 Subject: [sebhc] CVS on sebhc.org Message-ID: <02cc01c43e1a$dd3052e0$a301010a@gr390> Who ever was working on getting CVS going on the sebhc server should be aware of the security problem just posted on news.com: http://news.com.com/Flaws+found+in+database+apps/2100-1002_3-5216353.html?tag=nefd.lede It apparently affects ALL versions released before May 19th (today). Mark From dave04a at dunfield.com Thu May 20 06:48:49 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 20 May 2004 04:48:49 -0700 (PDT) Subject: [sebhc] unpacking and ressurecting... Message-ID: <200405201148.i4KBmnUt010035@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 20 May 2004 11:58:20 -0000 Hi Steven, >>Ok - well how about some pictures? I'd love to see the details of the >>original H8 - is it much different than later ones? > >I wish I had a digital camera. :-( A regular camera will do - just scan the photos afterward. If you don't have a scanner, send them to me and I'll scan them. >But this is the first "production" unit .. what they called a "proof" unit. >So visibly, it's very similar. Some differences are: > The finish on the shield metal is different. > The boards don't have that layer of green coating. > A lot of the chips (particularly the CPU and memory chips) are the ceramic >and gold package, not the black plastic type. > P10 was never installed on the bus board. > There are a few jumper wires on some boards that later boards wouldn't >have (or need). This sounds like a very unique and interesting H8. Were there differing revisions of production H8's? If so, how can you tell which one you have, and where it fits into the production history. >It's current status: After bridging the open power switch, and warming it >up on the variac, it came up and ran the memory test successfully. Excellent! 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 jack.rubin at ameritech.net Thu May 20 07:36:24 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 20 May 2004 07:36:24 -0500 Subject: [sebhc] More Tape recovery In-Reply-To: <200405200310.i4K3ACmQ099277@gatekeeper.evocative.com> Message-ID: <000201c43e67$10b55790$1f6fa8c0@eths.k12.il.us> Thanks Dave! The tapes are archived under /software/H8-tapes/H8-tapes-dd - another overloaded operator, but I think it will work. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Wednesday, May 19, 2004 10:10 PM > To: sebhc at sebhc.org > Subject: [sebhc] More Tape recovery > > > Ok - I got the transparent "passthrough" program working, so > I can read tapes directly from the H8 into my H8T program on > the PC. Using this I was able to recover all of the software > from the tapes that Jack sent to me. It took a bit of > searching, but I was able to find unconfigured version of all > the early H8 Software. > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 20 23:01:24 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 20 May 2004 23:01:24 -0500 Subject: [sebhc] image test files Message-ID: <000001c43ee8$48f83f60$1f6fa8c0@eths.k12.il.us> Please take a look at the various files in the directory called "image-test" and let me know what you think about quality and speed of access. I'm looking at several alternatives to Adobe Acrobat 6.0 for creating documents. I'm especially interested in hearing from people on older, slower platforms. Thanks. Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Fri May 21 00:09:55 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 21 May 2004 05:09:55 +0000 Subject: [sebhc] image test files Message-ID: The t2p and both TiffPlotX's didn't give me that "may contain newer information than this viewer can support. But the TiffPlot's had some kind of unregistered version banner covering the top of each page. So the t2p was my favorite (if you don't count the images being upside down). Oddly, the t2p180 DID give that "newer information" message. So did the others. _________________________________________________________________ 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 dave04a at dunfield.com Fri May 21 05:19:38 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 03:19:38 -0700 (PDT) Subject: [sebhc] Emulating H17 Message-ID: <200405211019.i4LAJc2U033533@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 21 May 2004 10:38:40 -0000 Ok - I ripped the drive out of my document processing station (Athlon 1200), put in a new drive, installed winblows, installed Acrobloat 5 and gave it a go. Still took nearly a minute per page, but I managed to print the H17 document. Only to discover that it contains almost no useful information. If anyone is interested in having the H17 included in my emulator, here is what I need. Probably some of this material is already in the archive, but please give pointers, as my free time has dropped to almost 0. - Detailed register description for the disk controller hardware. What register addresses does it use? What is the meaning of each bit that is read/written from each register? Samples for format/read/write code would be handy. - H17 ROM image to install in the emulators address space. - Full ROM listing would be nice. - Details of the H17 ROM image entry points. What addresses to you call to issue disk commands? How do you pass various parameters to the drivers? How do you receive results back? - Image of a bootable HDOS diskette. This should be a file which is exactly 102400 bytes in size, containing a raw binary dump of the disk from track-0,sector-0 to track-39,sector-9 (256 byte sector x 10 sectors/track x 40 tracks/disk = 102400). The OS on the disk image must come up on the standard H8 console. - Details on how to BOOT the system. I assume you execute a routine in the H17 ROM. I could find no mention of this in the H17 document. Under "Operation" all they have is "here's how to open the drive door and slide in a disk". 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 Fri May 21 07:14:33 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 21 May 2004 12:14:33 +0000 Subject: [sebhc] Emulating H17 Message-ID: Dave, you must've missed my message about the source files - I had put them in the archves with you in mind. :-) >Only to discover that it contains almost no useful information. I gave that caveat in the same message. :-) >- Detailed register description for the disk controller hardware. > What register addresses does it use? That was in my message of May 10 .. but now you can get the same info and more from the files in the source directories in the archives: software/sources/HDOS_2.0_Software_Tools_890-103 and software/sources/HDOS_2.0_Driver_Source_890-104 Of particular interest would be sydvd.asm (the H17 device driver) and the header files it uses. > What is the meaning of each bit that is read/written from each register? > Samples for format/read/write code would be handy. Those source files should cover it. >- H17 ROM image to install in the emulators address space. In the archives: software/H8-ROMs/H17.ROM > - Full ROM listing would be nice. I don't think its been posted yet. But a partial listing has: software/H8-ROMs/H17ROM-listing.pdf >- Details of the H17 ROM image entry points. What addresses to you call to >issue > disk commands? How do you pass various parameters to the drivers? How >do you > receive results back? You can probably glean that from the sources. >- Image of a bootable HDOS diskette. software/disks/HDOS/HDOS_2.0_Issue_#50.06.00_890-64.disk >- Details on how to BOOT the system. I assume you execute a routine in the >H17 ROM. Yes, at location 030.000, which is the starting location of the ROM. Cheers, - Steven _________________________________________________________________ Watch LIVE baseball games on your computer with MLB.TV, included with MSN Premium! http://join.msn.click-url.com/go/onm00200439ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Fri May 21 07:31:17 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 05:31:17 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405211231.i4LCVH62035606@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 21 May 2004 12:53:40 -0000 I've been disassembling the H17 ROM (found it in the archive), As far as I can tell, it has very little to do with the disk hardware - it appears to be chock full of various utility subroutines (like divides etc.) but almost no disk functions. Just a little boot stub at the end. I had been assuming that the ROM would contain all the disk functions, so that the operating system could access the disk no matter which controller/drive you had installed - ie: it would provide a level of abstraction. Poking through the Mac emulator documentation it looks as if HDOS has it's own drivers for the hardware. So: How does HDOS handle the different disk controllers? Do you need a differently configured HDOS diskette for the different controllers? 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 RONALD.S.WEST at saic.com Fri May 21 08:43:29 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Fri, 21 May 2004 09:43:29 -0400 Subject: [sebhc] H17 ROM ? Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C56@mcl-its-exs03.mail.saic.com> Dave, Look in the PAM-37 Panel Monitor Operation/service Manual. That book contains a listing with routines for and references to all the disk types. Ron > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Friday, May 21, 2004 8:31 AM > To: sebhc at sebhc.org > Subject: [sebhc] H17 ROM ? > > > I've been disassembling the H17 ROM (found it in the archive), > > As far as I can tell, it has very little to do with the disk > hardware - it appears to be chock full of various utility > subroutines (like divides etc.) but almost no disk functions. > Just a little boot stub at the end. > > I had been assuming that the ROM would contain all the disk > functions, so that the operating system could access the disk > no matter which controller/drive you had installed - ie: it > would provide a level of abstraction. > > Poking through the Mac emulator documentation it looks as if > HDOS has it's own drivers for the hardware. > > So: How does HDOS handle the different disk controllers? > Do you need a differently configured HDOS diskette for the > different controllers? > > 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 dave04a at dunfield.com Fri May 21 09:54:45 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 07:54:45 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405211454.i4LEsjfX037572@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 21 May 2004 15:24:59 -0000 At 09:43 21/05/2004 -0400, you wrote: >Dave, > >Look in the PAM-37 Panel Monitor Operation/service Manual. That book >contains a listing with routines for and references to all the disk types. > >Ron Hi Ron, I could only find one PAM37 manual in the archives, which is entitled something like "Using your H8 computer with PAM-37 - OPERATION". It consists only of infomation on how to use the front panel commands. The only disk information is under "booting" it describes how to use the monitor to boot, and mentions the I/O addresses where the boards normally go - I could find no references to ROM subroutines for disk access or any other detailed technical material. >From disassembly of the ROM, and some of the source code that Steven has posted, I've get a bit of information as to the H17 control registers, and the names of most of the bits in them - no details at all on timing requirements etc. - have to reverse engineer from above materials to find this. I am very suprised that Heathkit did not provide technical documents on the H8 cards - For the S-100 cards that I have from that era, I have detailed technical manuals which tell you exactly how to comminocate with the device at the I/O port level. With this documentation you can easily sit down and write a drive (or an emulator) - everything you need to know is there. It looks like Heath may have created the first "Application" personal computer - no need to know technical details - just use our software! Seems odd for the time period. If anyone knows of any material in the Archive which gives a clear and concice description of how software controls the disk controller at the register level, please let me know. 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 patrick at vintagecomputermarketplace.com Fri May 21 11:50:00 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Fri, 21 May 2004 09:50:00 -0700 Subject: [sebhc] H17 ROM ? In-Reply-To: <200405211231.i4LCVH62035606@gatekeeper.evocative.com> Message-ID: <003301c43f53$a80baf30$f300a8c0@berkeley.evocative.com> > As far as I can tell, it has very little to do with the disk > hardware - it appears to be chock full of various utility > subroutines (like divides etc.) but almost no disk functions. > Just a little boot stub at the end. Dave, for me the most useful resource in playing directly with the H17 hardware has been the CP/M BIOS listing, which contains nearly line-by-line comments in its functions. > Poking through the Mac emulator documentation it looks as if > HDOS has it's own drivers for the hardware. Correct. > So: How does HDOS handle the different disk controllers? > Do you need a differently configured HDOS diskette for the > different controllers? Different drivers. Which disk subsystems your machine supports is a function of which drivers (.DVD files) are on the diskette from which you booted. Patrick -- Delivered by the SEBHC Mailing List From cfandt at netsync.net Fri May 21 13:27:07 2004 From: cfandt at netsync.net (Christian Fandt) Date: Fri, 21 May 2004 14:27:07 -0400 Subject: [sebhc] HDOS 3 ?? Message-ID: <5.2.1.1.2.20040521140842.025413e0@pop3.norton.antivirus> Well, it's been years since I've been active with my H8 system. I ran CP/M 2.2 with an H37 dual floppy and Heath's Z80 CPU option and 64K of RAM. Learned Wordstar, Turbo Pascal (version 1.0, the CP/M release (!)) and Assembler programming on her. Was fun and I miss it. However, last I knew when I last used the H8, lo these many years ago, HDOS 3 had been just released or was about to be. Can anybody bring me (us?) up-to-date on what's transpired since version 3 had started to be released? Is it available anywhere? Available in soft-sector format? Has it been updated and maintained since ~1985/86 or so? I'm really curious on this. My latest notes from around '85/86 are deeply buried in an unknown location within the dark, vast depths of my library archive in this house. Thanks for the info! -Chris F. NNNN Christian Fandt, Electronic/Electrical Historian Jamestown, NY USA cfandt at netsync.net Member of Antique Wireless Association URL: http://www.antiquewireless.org/ -- Delivered by the SEBHC Mailing List From RONALD.S.WEST at saic.com Fri May 21 14:29:10 2004 From: RONALD.S.WEST at saic.com (West, Ronald S.) Date: Fri, 21 May 2004 15:29:10 -0400 Subject: [sebhc] HDOS 3 ?? Message-ID: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C5F@mcl-its-exs03.mail.saic.com> -snip- > -Chris F. > > NNNN > > Christian Fandt, Electronic/Electrical Historian > Jamestown, NY USA cfandt at netsync.net > Member of Antique Wireless Association > URL: http://www.antiquewireless.org/ > -snip- Hmmm interesting EOM on that message. Where did that come from? I haven't seen that since I worked for Western Union on the AUTODIN communications system. Oh yeah, on the HDOS 3. They pretty much dropped the ball on all that stuff when the IBM PC's hit the scene. Don't recall what year that was. They switched to compatible PC's and MS-DOS and the rest, they say, is history. Ron [WB4OUM] -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Fri May 21 15:39:13 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 21 May 2004 20:39:13 +0000 Subject: [sebhc] H17 ROM ? Message-ID: Dave says: >I've been disassembling the H17 ROM (found it in the archive), >As far as I can tell, it has very little to do with the disk >hardware - it appears to be chock full of various utility >subroutines (like divides etc.) but almost no disk functions. >Just a little boot stub at the end. Are you looking at your disassembly, or just that partial listing in the archives? (That listing only shows the very beginning of the ROM). Disk-related entry points in the H17 ROM include: R.SYDD EQU 033316A ROM device driver R.MOUNT EQU 033345A Mount new device R.ABORT EQU 033366A Abort any active I/O R.XOK EQU 033374A Exit with OK status R.XIT EQU 033375A Exit R.READ EQU 034077A Read from disk R.READR EQU 034321A Read regardless of protection R.WRITE EQU 034336A Process disk write R.CDE EQU 035136A Count disk errors R.DTS EQU 035172A Decode track and sector R.SDT EQU 035225A Seek desired track R.MAI EQU 035251A Move arm in R.MAO EQU 035254A Move arm out R.DLY EQU 035303A Delay by clock R.LPS EQU 035321A Locate proper sector R.RDB EQU 036044A Read disk byte R.SDP EQU 036062A Set device parameters R.STS EQU 036165A Skip this sector R.WHD EQU 036235A Wait for hole detect R.STZ EQU 036254A Seek track zero R.WNH EQU 036271A Wait for no hole R.UDLY EQU 036302A Microsecond delay loop R.WSC EQU 036307A Wait for sync character R.WSP EQU 036343A Write sync pattern R.WNB EQU 036373A Write next byte BOOT EQU 037014A Boot disk system DDIAG EQU 037262A Disk diagnostic As you see, the ROM has an entire device driver - but it may be easier to look over the source for the HDOS driver (sydvd.asm) that I mentioned in my last message. >I had been assuming that the ROM would contain all the disk >functions, so that the operating system could access the disk >no matter which controller/drive you had installed Different controllers had different ROMs. The H17 ROM only addresses its own controller. Ron said: >Look in the PAM-37 Panel Monitor Operation/service Manual. That book >contains a listing with routines for and references to all the disk types. I don't think the PAM-37 listing has made it into the archives - I've been looking for it myself. Ironically, even though I am the author of PAM-37, I don't have a copy of the listing! But yes, PAM-37 was the only monitor ROM able to boot from all the disk flavors, and that was a major objective of the development project. However, as I recall, it still relied on the code in the controller ROMs. Cheers, - Steven _________________________________________________________________ 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 dwight.elvey at amd.com Fri May 21 16:01:08 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 21 May 2004 14:01:08 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405212101.OAA15734@clulw009.amd.com> Hi The other file he should look at, if he is going to trap I/O is H17def.acm. Also, one of the two, u8250.acm or u8251.acm. I forget which was on the H17 card. I think it was the 8251. There was one thing that I recall. There was a timing error in the original H17 ROM. It had something to do with action when writing the last sector of a track. I think it was a head load timing issue. The normal driver on the HDOS disk patched this but for someone doing direct calls to the ROM, one should be aware of this. Dwight >From: "Steven Parker" > >Dave says: >>I've been disassembling the H17 ROM (found it in the archive), >>As far as I can tell, it has very little to do with the disk >>hardware - it appears to be chock full of various utility >>subroutines (like divides etc.) but almost no disk functions. >>Just a little boot stub at the end. > >Are you looking at your disassembly, or just that partial listing in the >archives? (That listing only shows the very beginning of the ROM). >Disk-related entry points in the H17 ROM include: > >R.SYDD EQU 033316A ROM device driver >R.MOUNT EQU 033345A Mount new device >R.ABORT EQU 033366A Abort any active I/O >R.XOK EQU 033374A Exit with OK status >R.XIT EQU 033375A Exit >R.READ EQU 034077A Read from disk >R.READR EQU 034321A Read regardless of protection >R.WRITE EQU 034336A Process disk write >R.CDE EQU 035136A Count disk errors >R.DTS EQU 035172A Decode track and sector >R.SDT EQU 035225A Seek desired track >R.MAI EQU 035251A Move arm in >R.MAO EQU 035254A Move arm out >R.DLY EQU 035303A Delay by clock >R.LPS EQU 035321A Locate proper sector >R.RDB EQU 036044A Read disk byte >R.SDP EQU 036062A Set device parameters >R.STS EQU 036165A Skip this sector >R.WHD EQU 036235A Wait for hole detect >R.STZ EQU 036254A Seek track zero >R.WNH EQU 036271A Wait for no hole >R.UDLY EQU 036302A Microsecond delay loop >R.WSC EQU 036307A Wait for sync character >R.WSP EQU 036343A Write sync pattern >R.WNB EQU 036373A Write next byte > >BOOT EQU 037014A Boot disk system >DDIAG EQU 037262A Disk diagnostic > >As you see, the ROM has an entire device driver - but it may be easier to >look over the source for the HDOS driver (sydvd.asm) that I mentioned in my >last message. > >>I had been assuming that the ROM would contain all the disk >>functions, so that the operating system could access the disk >>no matter which controller/drive you had installed > >Different controllers had different ROMs. The H17 ROM only addresses its >own controller. > >Ron said: >>Look in the PAM-37 Panel Monitor Operation/service Manual. That book >>contains a listing with routines for and references to all the disk types. > >I don't think the PAM-37 listing has made it into the archives - I've been >looking for it myself. Ironically, even though I am the author of PAM-37, I >don't have a copy of the listing! > >But yes, PAM-37 was the only monitor ROM able to boot from all the disk >flavors, and that was a major objective of the development project. >However, as I recall, it still relied on the code in the controller ROMs. > >Cheers, > >- Steven > >_________________________________________________________________ >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 > -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Fri May 21 16:34:56 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 14:34:56 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405212134.i4LLYsQp044309@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 21 May 2004 22:04:37 -0000 Hi Steven, >Are you looking at your disassembly, or just that partial listing in the >archives? (That listing only shows the very beginning of the ROM). >Disk-related entry points in the H17 ROM include: > ... Very helpful list deleted for brevity. Yes, that was a preliminary comment, based on some of my disassembly, the listing from the archive, and some comments from the Mac emulator documentation which indcated that the driver entry points were in the HDOS RAM area (I expected them to be in the ROM) - I've since discovered that the ROM fills in a vector table in the HDOS area with many references to itself, some of which I have worked out (will be much easier now with your list). >>I had been assuming that the ROM would contain all the disk >>functions, so that the operating system could access the disk >>no matter which controller/drive you had installed > >Different controllers had different ROMs. The H17 ROM only addresses its >own controller. I realize that - my point was that if the entire driver was in the ROM, then the same OS image could work if booted on any controller - calls would filter down to the ROM - I see now that it could work this way, however allowance has been made for replacement of the ROM drivers. >Ron said: >>Look in the PAM-37 Panel Monitor Operation/service Manual. That book >>contains a listing with routines for and references to all the disk types. > >I don't think the PAM-37 listing has made it into the archives - I've been >looking for it myself. Ironically, even though I am the author of PAM-37, I >don't have a copy of the listing! Hows your memory - with my disassmbler, you can add symbols, block definitions, comments etc. as an ongoing work - makes it fairly easy to recover source code if you have a good understanding of what the program is doing... I spent a couple of hours looking at the material today ... I'm pretty sure I can make the system perform physcal reads and writes, however I have hit a stumbling block - according to the Mac emulator documenation, the disk system keeps a "header" on each sector which identifies the volume and sector - It does not give details on how this is organized. The images that I have are exactly 102400 bytes in size, meaning that they contain the data portion only. I would have to recrate the header on the fly - but without details on exactly how it is formatted, the possibilities are endless - Can't proceed without this information. I've found sections of the code that "look" like they could be loading in extra information (more than 256 sectors), but I don't completely understand it yet. Here is an example, which looks like it would only load 256 bytes, yet it "could" load more: 1C6E 0E 00 .. MVI C,$00 C=0 1C70 41 A MOV B,C B=0 1C71 CD 91 20 .. CALL WSYNC Does not modify B/C 1C74 DA B1 1C ... JC $1CB1 No sync 1C77 CD 82 20 .. CALL REDATA Read data byte 1C7A 77 w MOV M,A Save 1C7B 23 # INX H Next 1C7C 05 . DCR B Reduce count 1C7D C2 77 1C .w. JNZ $1C77 Read all 1C80 79 y MOV A,C This will be Zero 1C81 A7 . ANA A So this sets 'Z' 1C82 CA 8C 1C ... JZ $1C8C And no more data read 1C85 CD 82 20 .. CALL REDATA ?Keep reading? 1C88 0C . INR C ?Advance to 256 1C89 C2 85 1C ... JNZ $1C85 ?And then stop 1C8C 42 B MOV B,D get computed BCC 1C8D CD 82 20 .. CALL REDATA Read disk BCC 1C90 B8 . CMP B Match 1C91 C2 BA 1C ... JNZ $1CBA No - error As you can see the 0 in C prevents the second loop from running - At first I thought there might be places which call 1C71 after loading B and C independantly, however I have not indentified any such calls. Some of the code does crafty things which may obscure some instructions until I actually get to that function and figure it out - here is an example where an XRA A instruction is hidden: 19AB 3E 01 >. MVI A,$01 19AD FE AF .. CPI $AF 19AF CD 58 20 .X CALL $2058 19B2 D0 . RNC 19B3 F5 . PUSH PSW 19B4 3A 31 21 :1! LDA $2131 19B7 A7 . ANA A 19B8 CC 0B 21 ..! CZ $210B 19BB F1 . POP PSW 19BC C9 . RET The CPI at 19AD serves no purpose other than to "eat" the AF, so that A can remain at 1 - at other points in the code, address 19AE is called, which results in XRA A / CALL ... -- tricks like this can make it hard to follow some of the code. If anyone can provide details on the complete disk sector format (including SYNC bytes and BCC would be nice), that would help a lot. 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 Fri May 21 16:49:27 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 21 May 2004 21:49:27 +0000 Subject: [sebhc] H17 ROM ? Message-ID: Dwight says: > The other file he should look at, if he is going to trap >I/O is H17def.acm. That's one of the "associated header files" I was referring to. :-) >Also, one of the two, u8250.acm or u8251.acm. >I forget which was on the H17 card. I think it was the 8251. No, those are both I/O card chips (8250 in the H8-4, 8251 in the H8-5). The H17 uses a S2350 USRT. Those are the ports defined in h17def.acm. >There was a timing error >... for someone doing direct calls to >the ROM, one should be aware of this. Yea, if you were writing 8080 code to USE the disk. Not if you're writing PC code to EMULATE the disk. :-) Cheers, - Steven _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri May 21 17:02:15 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 21 May 2004 15:02:15 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405212202.PAA15787@clulw009.amd.com> >From: "Steven Parker" > >Dwight says: >> The other file he should look at, if he is going to trap >>I/O is H17def.acm. > >That's one of the "associated header files" I was referring to. :-) > >>Also, one of the two, u8250.acm or u8251.acm. >>I forget which was on the H17 card. I think it was the 8251. > >No, those are both I/O card chips (8250 in the H8-4, 8251 in the H8-5). >The H17 uses a S2350 USRT. Those are the ports defined in h17def.acm. Yep, now I remember. > >>There was a timing error >>... for someone doing direct calls to >>the ROM, one should be aware of this. > >Yea, if you were writing 8080 code to USE the disk. Not if you're writing >PC code to EMULATE the disk. :-) I guess an emulator wouldn't have this problem. Later Dwight > >Cheers, > >- Steven -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri May 21 16:59:59 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 21 May 2004 14:59:59 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405212159.OAA15781@clulw009.amd.com> >From: "Dave Dunfield" > ---snip--- Hi Dave When disassembling, look out for a couple of places where they optimized the code by entering from a jump or call into the middle of an inline code sequence. I forget exactly where this happens but it was a case that they used a LXI to a register that the routine didn't use and the 16 bit value was actually code to set one of the 8 bit registers. Otherwise, the code is relatively clean. Dwight -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Fri May 21 20:16:28 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 21 May 2004 20:16:28 -0500 Subject: [sebhc] H17 ROM ? In-Reply-To: <200405212134.i4LLYsQp044309@gatekeeper.evocative.com> Message-ID: <000001c43f9a$69262ec0$1f6fa8c0@eths.k12.il.us> I've got the HDOS source listings which should include all this info, but they are hard to read in the original and may be illegible in when scanned. I'm hoping to load the H17 ROM tonight and then I can look at the INIT program, which is the formatting utility. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Friday, May 21, 2004 4:35 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] H17 ROM ? > > > Hi Steven, > > >Are you looking at your disassembly, or just that partial > listing in the > >archives? (That listing only shows the very beginning of > the ROM). > >Disk-related entry points in the H17 ROM include: > > ... Very helpful list deleted for brevity. > > Yes, that was a preliminary comment, based on some of my > disassembly, the listing from the archive, and some comments > from the Mac emulator documentation which indcated that the > driver entry points were in the HDOS RAM area (I expected > them to be in the > ROM) - I've since discovered that the ROM fills in a vector > table in the HDOS area with many references to itself, some > of which I have worked out (will be much easier now with your list). > > > >>I had been assuming that the ROM would contain all the disk > functions, > >>so that the operating system could access the disk no matter which > >>controller/drive you had installed > > > >Different controllers had different ROMs. The H17 ROM only > addresses > >its > >own controller. > > I realize that - my point was that if the entire driver was > in the ROM, then the same OS image could work if booted on > any controller - calls would filter down to the ROM - I see > now that it could work this way, however allowance has been > made for replacement of the ROM drivers. > > > >Ron said: > >>Look in the PAM-37 Panel Monitor Operation/service Manual. > That book > >>contains a listing with routines for and references to all the disk > >>types. > > > >I don't think the PAM-37 listing has made it into the > archives - I've > >been > >looking for it myself. Ironically, even though I am the > author of PAM-37, I > >don't have a copy of the listing! > > Hows your memory - with my disassmbler, you can add symbols, > block definitions, comments etc. as an ongoing work - makes > it fairly easy to recover source code if you have a good > understanding of what the program is doing... > > > I spent a couple of hours looking at the material today ... > I'm pretty sure I can make the system perform physcal reads > and writes, however I have hit a stumbling block - according > to the Mac emulator documenation, the disk system keeps a > "header" on each sector which identifies the volume and > sector - It does not give details on how this is organized. > The images that I have are exactly 102400 bytes in size, > meaning that they contain the data portion only. I would have > to recrate the header on the fly - but without details on > exactly how it is formatted, the possibilities are endless - > Can't proceed without this information. > > I've found sections of the code that "look" like they could > be loading in extra information (more than 256 sectors), but > I don't completely understand it yet. Here is an example, > which looks like it would only load 256 bytes, yet it "could" > load more: > > 1C6E 0E 00 .. MVI C,$00 C=0 > 1C70 41 A MOV B,C B=0 > 1C71 CD 91 20 .. CALL WSYNC Does not modify B/C > 1C74 DA B1 1C ... JC $1CB1 No sync > 1C77 CD 82 20 .. CALL REDATA Read data byte > 1C7A 77 w MOV M,A Save > 1C7B 23 # INX H Next > 1C7C 05 . DCR B Reduce count > 1C7D C2 77 1C .w. JNZ $1C77 Read all > 1C80 79 y MOV A,C This will be Zero > 1C81 A7 . ANA A So this sets 'Z' > 1C82 CA 8C 1C ... JZ $1C8C And no more data read > 1C85 CD 82 20 .. CALL REDATA ?Keep reading? > 1C88 0C . INR C ?Advance to 256 > 1C89 C2 85 1C ... JNZ $1C85 ?And then stop > 1C8C 42 B MOV B,D get computed BCC > 1C8D CD 82 20 .. CALL REDATA Read disk BCC > 1C90 B8 . CMP B Match > 1C91 C2 BA 1C ... JNZ $1CBA No - error > > As you can see the 0 in C prevents the second loop from > running - At first I thought there might be places which call > 1C71 after loading B and C independantly, however I have not > indentified any such calls. > > Some of the code does crafty things which may obscure some > instructions until I actually get to that function and figure > it out - here is an example where an XRA A instruction is hidden: > > 19AB 3E 01 >. MVI A,$01 > 19AD FE AF .. CPI $AF > 19AF CD 58 20 .X CALL $2058 > 19B2 D0 . RNC > 19B3 F5 . PUSH PSW > 19B4 3A 31 21 :1! LDA $2131 > 19B7 A7 . ANA A > 19B8 CC 0B 21 ..! CZ $210B > 19BB F1 . POP PSW > 19BC C9 . RET > > The CPI at 19AD serves no purpose other than to "eat" the AF, > so that A can remain at 1 - at other points in the code, > address 19AE is called, which results in XRA A / CALL ... -- > tricks like this can make it hard to follow some of the code. > > > If anyone can provide details on the complete disk sector > format (including SYNC bytes and BCC would be nice), that > would help a lot. > > 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 dave04a at dunfield.com Fri May 21 20:45:03 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 18:45:03 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405220145.i4M1j2gw048297@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 02:01:03 -0000 >I've got the HDOS source listings which should include all this info, >but they are hard to read in the original and may be illegible in when >scanned. I'm hoping to load the H17 ROM tonight and then I can look at >the INIT program, which is the formatting utility. Hi Jack, If you can figure it out, that would help me a lot - I'm a a bit of a standstill on the disk emulation until I get the "non-data" portion of the disk sectors figured out. I've found that if you scan in 1-bit (B&W) and carefully adjust the contrast control, you would be amazed at what you can get to come out - often looking much better than the original - it's tedious work however, as you often have to preview, adjust and scan every page individually. The type of work best done a few pages at a time over a long calendar period. 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 Fri May 21 20:52:15 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 22 May 2004 01:52:15 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: >Hows your memory - with my disassmbler, you can add symbols,... Ouch! I'm sure someone will eventually upload a PDF of the listing. And if I can ever get to where I can read my 8-inch disks, I'm pretty sure the source is one one of them. ...(portion of read routine disassembly omitted)... >As you can see the 0 in C prevents the second loop from running - At first >I >thought there might be places which call 1C71 after loading B and C >independantly, >however I have not indentified any such calls. No, not a call, but a JZ instruction just above what you listed. What's happening there is that a 16-bit count of bytes is being read, one sector at a time. On the last sector, the value left in c (because of the jump around the mvi c,0) controls calling the read routine additional times past the byte count to get to the end of the sector so the check byte can be tested. >Some of the code does crafty things... That's a common tactic in firmware where space is a premium. Another common programming practice that will confuse a disassembler is function calls with inline parameters. >If anyone can provide details on the complete disk sector format (including >SYNC bytes and BCC would be nice), that would help a lot. Immediately after a hole detect: Bytes Contents 10 leader bytes (zero) 1 sync (375Q) 1 volume number * 1 track number 1 sector number 1 check byte 10 leader bytes (zero) 1 sync (375Q) 256 data bytes 1 check byte The volume number can be found in the disk image file at byte 2304 (beginning of the label sector). Hope that helps! - Steven _________________________________________________________________ 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 dave04a at dunfield.com Fri May 21 22:00:05 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 20:00:05 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405220300.i4M305XX000654@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 03:12:11 -0000 Hi Steven, >No, not a call, but a JZ instruction just above what you listed. What's >happening there is that a 16-bit count of bytes is being read, one sector at >a time. On the last sector, the value left in c (because of the jump around >the mvi c,0) controls calling the read routine additional times past the >byte count to get to the end of the sector so the check byte can be tested. I guess it was something like that - looked like variable read code to me. >>Some of the code does crafty things... > >That's a common tactic in firmware where space is a premium. Another common >programming practice that will confuse a disassembler is function calls with >inline parameters. Yeah - I've done a lot worse that that in my years (been writing embedded firmware for a long time), however I've seen several places in the code where a few bytes could have been saved in a less tricky manner. >>If anyone can provide details on the complete disk sector format (including >>SYNC bytes and BCC would be nice), that would help a lot. > >Immediately after a hole detect: > >Bytes Contents > 10 leader bytes (zero) > 1 sync (375Q) > 1 volume number * > 1 track number > 1 sector number > 1 check byte > > 10 leader bytes (zero) > 1 sync (375Q) > 256 data bytes > 1 check byte > >The volume number can be found in the disk image file at byte 2304 >(beginning of the label sector). Wow - you are just a wealth of information - have you ever thought about writing some of this down? A few questions/clairifications: #1 - Just to make sure I understand this. The first "short" label sector is just after the index hole, ie: the first sector on a track - so in effect, there are 11 sectors/track, but the first one is this short "hidden" sector, which the driver does not present to the upper levels, so when software thinks of sectors 0-9 (or 1-10) of a 10 sector track, it is really seeing 1-10 (or 2-11) of an 11 sector track, given that the very first sector is this "special" short sector. Right? #2 - What is the purpose of the "sector number" entry in this short sector? Would it not alwys be zero (or 1)? - There is only one special sector/track right? #3 - Are the sectors numbred from 1 or 0? And does this include ths short sector? #4 - If I understood the documents correctly, the sectors on track-0 always report volume=0 (so they can be read before mounting) - right? #5 - The check byte is calculated as: - Begin with zero - For each data byte: Check = Check XOR Data Check = Check RRC (Rotate Left) 1 = Right? = Is check performed on ALL bytes from 1st after SYNC to end of data? 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 Fri May 21 22:25:10 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 20:25:10 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405220325.i4M3P6ZJ000984@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 03:46:50 -0000 Steven, >R.SYDD EQU 033316A ROM device driver >R.MOUNT EQU 033345A Mount new device >R.ABORT EQU 033366A Abort any active I/O >R.XOK EQU 033374A Exit with OK status >R.XIT EQU 033375A Exit >R.READ EQU 034077A Read from disk >R.READR EQU 034321A Read regardless of protection >R.WRITE EQU 034336A Process disk write >R.CDE EQU 035136A Count disk errors >R.DTS EQU 035172A Decode track and sector >R.SDT EQU 035225A Seek desired track >R.MAI EQU 035251A Move arm in >R.MAO EQU 035254A Move arm out >R.DLY EQU 035303A Delay by clock >R.LPS EQU 035321A Locate proper sector >R.RDB EQU 036044A Read disk byte >R.SDP EQU 036062A Set device parameters >R.STS EQU 036165A Skip this sector >R.WHD EQU 036235A Wait for hole detect >R.STZ EQU 036254A Seek track zero >R.WNH EQU 036271A Wait for no hole >R.UDLY EQU 036302A Microsecond delay loop >R.WSC EQU 036307A Wait for sync character >R.WSP EQU 036343A Write sync pattern >R.WNB EQU 036373A Write next byte > >BOOT EQU 037014A Boot disk system >DDIAG EQU 037262A Disk diagnostic This list fills in all of the holes in the RAM vector table, except for one - this is a vector at $209A (040,232) which calls a function at $1F68 (037,150) - all this does in INR M / RET - Can you put a name to this one? Also, can you give me the calling conventions for the SYDD routine? 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 Fri May 21 22:25:06 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Fri, 21 May 2004 20:25:06 -0700 (PDT) Subject: [sebhc] H17 ROM ? Message-ID: <200405220325.i4M3P6KY000985@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 03:55:23 -0000 Steven, I'm assuming you are getting this information from a listing --- (otherwise your memory is REALLY good) - if so, could I prevail upon you to also give me a list of the names for the RAM locations along with a short description - I don't need the JMP vector locations, as their description is the same as the routine they jump to, but the various control values would be most helpful. 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 jack.rubin at ameritech.net Fri May 21 22:48:07 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 21 May 2004 22:48:07 -0500 Subject: [sebhc] H17 ROM ? In-Reply-To: <200405220325.i4M3P6KY000985@gatekeeper.evocative.com> Message-ID: <000001c43faf$98bbfce0$1f6fa8c0@eths.k12.il.us> Dave and Steven - Good news/bad news - I've scanned and uploaded the H17 ROM assembly listing which includes all the equates and XTEXT references lacking from the .asm versions. Bad news is the size - 66 pages of listing/3188K - but I'm figuring it will take Dave less time to download and print it than it will for him to noodle it all out (or alternatively, he could sleep/eat/?? while the file is printing). What's the next most important module to scan? I expect to get through it all eventually, but the stack of printed listings is about 7" thick. SY.DVD in listing form is 38 pages and SYINIT is roughly the same size. Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Friday, May 21, 2004 10:25 PM > To: sebhc at sebhc.org > Subject: RE: [sebhc] H17 ROM ? > > > Steven, > > I'm assuming you are getting this information from a listing > --- (otherwise your memory is REALLY good) - if so, could I > prevail upon you to also give me a list of the names for the > RAM locations along with a short description - I don't need > the JMP vector locations, as their description is the same as > the routine they jump to, but the various control values > would be most helpful. > > 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 sp11 at hotmail.com Sat May 22 00:58:05 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 22 May 2004 05:58:05 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: >Wow - you are just a wealth of information - have you ever thought about >writing >some of this down? I just did! :-) >#1 - Just to make sure I understand this. > The first "short" label sector is just after the index hole, ie: the >first > sector on a track - so in effect, there are 11 sectors/track, ... No, just 10. By "hole detect" I meant one of the sector holes. The extra index hole does NOT constitute the beginning of a sector. The label sector is the last one on the outside track .. and the same size as all the others. >#3 - Are the sectors numbred from 1 or 0? And does this include ths short >sector? >From 0 (to 9), there's no "short sector". >#4 - If I understood the documents correctly, the sectors on track-0 always >report > volume=0 (so they can be read before mounting) - right? Yes! Good catch ... I forgot to mention that. > Check = Check XOR Data > Check = Check RRC (Rotate Left) 1 > = Right? > = Is check performed on ALL bytes from 1st after SYNC to end of >data? Yes, and yes. "ALL" bytes are just 3 for the header and the 256 data bytes for the data section. >(037,150) - all this does in INR M / RET - Can you put a name to this one? R.ERRT "Error test loop" >Also, can you give me the calling conventions for the SYDD routine? Function code in A (see dddef.acm), other registers as needed for function being called. Looks like Jack scanned in the listing to answer your RAM vector questions (but I'm not sure why you'd need that just to emulate the device I/O). Cheers, - Steven _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sat May 22 05:55:21 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sat, 22 May 2004 03:55:21 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405221055.i4MAtL5K010969@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 11:05:20 -0000 Hi Steven, Thanks again for much useful information. >>#1 - Just to make sure I understand this. >> The first "short" label sector is just after the index hole, ie: the >>first ector on a track - so in effect, there are 11 sectors/track, ... > >No, just 10. By "hole detect" I meant one of the sector holes. The extra >index hole does NOT constitute the beginning of a sector. The label sector >is the last one on the outside track .. and the same size as all the others. Ok - so there is a "header" with every sector. So I will essentially read two physical blocks for every hole (not counting the index hole) - one short "header", and one long "data" block, each with their own SYNC and CHECK bytes. Question: Does any H8 software ever do anything "funny" with these values? (Copy protection etc.) - would it be worthwhile to include the header in the disk data file, or do you think it would be OK to just swallow it on writes and regenerate it on reads. >>(037,150) - all this does in INR M / RET - Can you put a name to this one? > >R.ERRT "Error test loop" thanks. >>Also, can you give me the calling conventions for the SYDD routine? > >Function code in A (see dddef.acm), other registers as needed for function >being called. > >Looks like Jack scanned in the listing to answer your RAM vector questions >(but I'm not sure why you'd need that just to emulate the device I/O). Because I have no specs for the interface, so I have to figure it out by what the software is doing. That will be much easier if I can have an idea what the values the codes is loading/storing contain. 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 Sat May 22 09:11:07 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 22 May 2004 14:11:07 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: >Question: Does any H8 software ever do anything "funny" with these values? HDOS doesn't. I'm not entirely sure what other parties may have done with them. >...would it be worthwhile to include the header in the >disk data file, or do you think it would be OK to just swallow it on writes >and regenerate it on reads. Theoretically, another OS could have an entirely different format on all tracks other than track zero, but so far, I'm not aware of anything that can't be reconstructed from the data using the format already described. So at this point I don't see that the added complexity in storage format (and emulator coding) for strictly generic emulation is justified. I'm not even sure how to be purely generic about it anyway, since an OS (or a custom driver) could change stuff like the number of sectors, the size/format/presence of sector headers, the relationship between sectors and holes, or even disregard holes entirely. >Because I have no specs for the interface, so I have to figure it out by >what >the software is doing. That will be much easier if I can have an idea what >the >values the codes is loading/storing contain. I wasn't expecting that you'd need to spend any time with the parameter-driven driver to figure out how to handle emulation. I think the low-level functions (that it calls anyway) should show you everything important. I was thinking the trickiest part of the emulation would be satisfying the timing expectations in the driver (time between holes, holes and data, etc). Cheers, - Steven _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sat May 22 11:20:31 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sat, 22 May 2004 09:20:31 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405221620.i4MGKVdL015454@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 16:44:33 -0000 Hi Steven, You didn't mention my original question/confirmation, so I assume it is correct that are basically 2 blocks (with SYNC & CRC) for every physical sector on the disk? >I'm not even sure how to be purely generic about it anyway, since an OS (or >a custom driver) could change stuff like the number of sectors, the >size/format/presence of sector headers, the relationship between sectors and >holes, or even disregard holes entirely. Yeah - it would be touch. You would have to basically record "tracks" which would be the longest series of data that you could place on a physical track, and include hold indications at the set spacing ... For most applciations, the software would not actually use all of the possible bytes between holes, and some would be wasted - but it would emulate the physical disk quite well. >I wasn't expecting that you'd need to spend any time with the >parameter-driven driver to figure out how to handle emulation. I think the >low-level functions (that it calls anyway) should show you everything >important. I was thinking the trickiest part of the emulation would be >satisfying the timing expectations in the driver (time between holes, holes >and data, etc). I wanted parameter info so that I could figure out the parameters to the individual functions, so I have a better understanding of what they are doing as I try to reverse engineer them - but I can probably get that from the listing - Assuming it downloaded OK - I left it downloading this morning and have not checked on it yet (will do now). Again, thanks for all your help. 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 Sat May 22 15:31:03 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 22 May 2004 20:31:03 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: Oh, one more thing... >... or do you think it would be OK to just swallow it on writes and >regenerate it on reads. Remember that generally only "init" would write both the header and data. Otherwise the header would be read and the data written. That's why every sector has two separate leader/sync/data/check groups with a small gap in between. I put a couple of test programs from the H17 service manual in the tape software area. One checks the on-board write-protectable memory and the other is for checking/adjusting rotational speed. At ideal speed, there should be a "200" displayed in the memory location on the front panel. Cheers, - Steven _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sat May 22 15:55:46 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sat, 22 May 2004 13:55:46 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405222055.i4MKtkvX019223@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 22 May 2004 21:19:45 -0000 Hi Steven, >Remember that generally only "init" would write both the header and data. >Otherwise the header would be read and the data written. That's why every >sector has two separate leader/sync/data/check groups with a small gap in >between. It occured to me that it probably works this way - and I was going to ask you. >I put a couple of test programs from the H17 service manual in the tape >software area. One checks the on-board write-protectable memory and the >other is for checking/adjusting rotational speed. At ideal speed, there >should be a "200" displayed in the memory location on the front panel. Thanks, I'll check 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 waltm22 at comcast.net Sat May 22 15:54:44 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sat, 22 May 2004 13:54:44 -0700 Subject: [sebhc] H17 ROM and disk info In-Reply-To: <200405221620.i4MGKVdL015454@gatekeeper.evocative.com> Message-ID: <000d01c4403f$09f7d250$0700a8c0@walterp4> I may be about ready to put my foot in my mouth, but after another almost sleepless night waiting for a mare to foal, here it goes... What is the goal of having "H-17" emulation in the emulator? Is it to allow any application which may have been written to run under the emulator, even if it does some really weird stuff with the disk controller, or is it to be able to read disk images and have some form of disk I/O under the emulator? Speaking for HDOS 2.0, the only reason to have support for the H17 is to boot an H-17 disk. The H-17 boot disk will have for its SY.DVD the H-17 specific device driver, which HDOS will go looking for upon boot up. For those of us with H-47 drives instead, the SY.DVD will be specific to the H-47, and that is what will be looked for. Now, I can tell you from personal experience that HDOS 2.0 will run without an H-17 installed in the system. That implies no dependence on all those little extra functions which they were nice enough to tell you about in the partial source code they gave out. It even implies no dependence on anything in the ROM. Heck, throw out the ROM image! You don't need it! What you do need is enough of a driver to read bytes and write bytes. Examples of this were supplied on the HDOS 2.0 distribution disks. (This is where I need to power the system back up and look at the files supplied with HDOS 2.0 to see what all was on the disk. I remember making a version of the SY.DVD without all the extra disk initialization baggage. It saved me space on the boot disk by not carrying it around! I think I built it from the source supplied, I just don't remember.) Anyway, by having an emulator specific boot disk image made by replacing SY.DVD with one named, say ED.SYS (emulator disk), you could have the emulator recognize the read/write sector program execution addresses and do the appropriate "disk I/O" (e.g. read/write bytes into/from a disk image). This is how HDOS does it. It simply asks for a certain number of bytes to be read/written. The boot sector might need some modification, but that would also be easy to do (I would have to look at some code to check that out, easy to do). You could also have up to something like seven disks mounted under this guy if you wanted to. I would not worry about writing initialization code for such a driver. Just keep a blank image around and allow a way to change the volume number (remember, on the 8" disks it isn't written in each sector header). These blank images can have the H-17 boot sector on them. If they are never booted from, it just doesn't mater. Anyway, from my perspective I want to run HDOS 2.0 and have disk I/O available. I don't want to do fancy tricks with the disk controller. I also don't currently care about HDOS 1.5 and 1.6. I just want to read and write disk images. This can be done the quickest with a small system device driver were the emulator can recognize a couple of addresses to trap on and perform a sector read/write, or even through a couple of unused I/O port address which are emulated. Very simple. Remember, HDOS proper only cares about reading/writing disks sectors. It doesn't care where they come from. They can even come from the ether! ..walt -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sat May 22 17:15:45 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 22 May 2004 22:15:45 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: I was already thinking about having a custom driver for a large capacity pc-hard-disk. But using one to operate on H17 disk images is intriguing! >What is the goal of having "H-17" emulation in the emulator? Well, to be able to boot and run original, unmodified software. :-) >Now, I can tell you from personal experience that HDOS 2.0 will run without >an H-17 installed in the system. How did you boot it? Or are you just talking about a system with a DIFFERENT controller, like a -47? >...I need to power the system back up and look at the files supplied with >HDOS 2.0 Or .. check the HDOS 2.0 sources in the "sources" section of the archives. :-) >This can be done the quickest with a small system device >driver were the emulator can recognize a couple of addresses to trap on and >perform a sector read/write, or even through a couple of unused I/O port >address which are emulated. So you're still emulating a controller ... just a very smart "virtual" one. :-) Cheers, - Steven _________________________________________________________________ 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 patrick at vintagecomputermarketplace.com Sat May 22 22:36:59 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Sat, 22 May 2004 20:36:59 -0700 Subject: [sebhc] Test -- Please Ignore (#3) Message-ID: <000901c44077$34005760$f300a8c0@berkeley.evocative.com> Test #3 please ignore -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 22 18:11:46 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 22 May 2004 19:11:46 -0400 Subject: [sebhc] ZIP? Message-ID: <40AFDE32.5060904@sc.rr.com> I had a strange thought. For anyone trying to build an actual machine (H8 / H89). The 100 meg Zip Drive is available in a model that connects to a parrallel port. I wonder if it would be possible to use one to replace Floppy/Hard disks. It would be a lot of storage for CPM / HDOS, etc. Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sat May 22 22:39:33 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 22 May 2004 22:39:33 -0500 Subject: [sebhc] Test -- Please Ignore (#3) In-Reply-To: <000901c44077$34005760$f300a8c0@berkeley.evocative.com> Message-ID: <000101c44077$90b93800$1f6fa8c0@eths.k12.il.us> ok - never saw #1 or #2 > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Patrick Rigney > Sent: Saturday, May 22, 2004 10:37 PM > To: sebhc at sebhc.org > Subject: [sebhc] Test -- Please Ignore (#3) > > > Test #3 please ignore > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sat May 22 19:10:37 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sat, 22 May 2004 17:10:37 -0700 Subject: [sebhc] H17 ROM and disk info In-Reply-To: Message-ID: <001001c4405a$61138500$0700a8c0@walterp4> > I was already thinking about having a custom driver for a large capacity > pc-hard-disk. But using one to operate on H17 disk images is intriguing! As long as you don't physically boot from the H-17, there is no problem mounting/reading/writing them. Just get the interleave correct! As for your "pc-hard-disk", I was going to write a quick block device driver which would transfer sectors between the PC and my H-8 (or H89). I don't really care about speed; I just want to have the PC be another disk. I was going to do this over one of the serial ports. 9600 baud would be good enough for me (see note at bottom). It would be very easy to have the disk be any size that fits within HDOS' limits for maximum tracks, sectors, sides. I was even thinking of making every sector just another file, part of some big tree. It would be easy to have a PC-side app which could combine "sectors" into files, and turn files into "sectors" on the disk. Another approach would be to simply have a "cluster" which would be HDOS' max, so that each directory entry could map to a real file in the PC space. Lots of ways to do it. > >What is the goal of having "H-17" emulation in the emulator? > > Well, to be able to boot and run original, unmodified software. :-) 99.99% of software should run unmodified. If the software was written to run on an H-8, H-89 or H-90 with any of the controllers (including second source products), it will run. The only thing that cannot run would be an original HDOS distribution disk. You could get one to run by trapping the actual device vectors and performing the appropriate action. Then you wouldn't even have to write a small device driver. Just trap the read vector and do a read. If control never gets into the H-17 ROM code, you don't have to emulate the device. I like the thought of trapping the dispatch vectors - it's even easier. > >Now, I can tell you from personal experience that HDOS 2.0 will run > without > >an H-17 installed in the system. > > How did you boot it? Or are you just talking about a system with a > DIFFERENT controller, like a -47? Exactly. The H-47 doesn't depend on an H-17 and it doesn't supply ROM routines either. I believe HDOS patched the vectors to those routines like multiply (not positive) so that they were there. > >...I need to power the system back up and look at the files supplied with > >HDOS 2.0 > > Or .. check the HDOS 2.0 sources in the "sources" section of the archives. > :-) I have the source listings; they just are not convenient right now. Plus I want to see what came on the distribution disks. > >This can be done the quickest with a small system device > >driver were the emulator can recognize a couple of addresses to trap on > and > >perform a sector read/write, or even through a couple of unused I/O port > >address which are emulated. > > So you're still emulating a controller ... just a very smart "virtual" > one. Yep, I guess so - One a lot easier to emulate. ..walt A long time ago I was trying to run a couple of serial ports at I believe 19.2K. I was having problems missing interrupts. Turns out that even if you turn off front panel updating, all the tick handling on the H-8 took something on the order of 700 clock cycles. If the front panel update was enabled, every 32nd tick took 2000 (more?) cycles. No way you could do fast serial I/O. I wrote a stub to do the minimum possible for the tick counter which was pretty small. Note that this disabled the front panel. Just a note for anyone wanting really fast serial I/O -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sun May 23 04:51:12 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 23 May 2004 02:51:12 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405230951.i4N9pBTN058582@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 23 May 2004 10:10:15 -0000 Hi Walt, >What is the goal of having "H-17" emulation in the emulator? Is it to allow >any application which may have been written to run under the emulator, even >if it does some really weird stuff with the disk controller, or is it to be >able to read disk images and have some form of disk I/O under the emulator? I think the main goal is to provide a virtual environment as close to a real H8 as possible, but not necessarily accomodating software that does "weird stuff" - in other words, to be able to boot and use unmodified HDOS images. >Heck, throw out the ROM image! You don't need it! Um - you need something to boot! >What you do need is enough of a driver to read bytes and write bytes. >Anyway, from my perspective I want to run HDOS 2.0 and have disk I/O >available. I don't want to do fancy tricks with the disk controller. >I also don't currently care about HDOS 1.5 and 1.6. I just want to >read and write disk images. This can be done the quickest with a small >system device driver were the emulator can recognize a couple of addresses >to trap on and perform a sector read/write, or even through a couple of >unused I/O port address which are emulated. Very simple. > >Remember, HDOS proper only cares about reading/writing disks sectors. It >doesn't care where they come from. They can even come from the ether! I have considered this - I've done both approaches in the past. For my Altair emulator, I implemented the NorthStar single-density disk controller right down to the register level - the system boots using the original unmodified ROM from the NorthStar controller and runs using the original unmodified disk drivers for both the NorthStar DOS and my own DMF OS. I was able to do this for three reasons: 1) The register interface is very well documented. 2) I had already had a lot of experience with the interface (wrote my own OS for the machine. 3) The interface is simpler than the H17 - it consists of a single 256 byte data sector per hole - no header etc. In other words, all you need to understand to implement it is the hardware - there is no software component to the disk format that has to be emulated. For the D6809 emulator, I decided that the 765 disk contrller was going to be too much work to implement. In this case, all disk I/O was done in the ROM, so updating the ROM with new drivers allowed me to transparently add a very simple virtual disk controller. This device has 8 registers: 0 = Command/Status 1 = Data 2 = Drive select 3 = Current Cylinder 4 = Current Head 5 = Current Sector 6 = # Heads \_ For geometry -> file index calculations 7 = # Sectors / If you don't need to support multiple disk geometries, then the last two are not required. To read/write a sector, all you do is set the Sector/Head/Cylinder values, then issue a READ or WRITE command - then do 512 reads or writes to the data port (this was a DD system with 512 bytes/sector). The commands are: INITIALIZE, RESET, READ, WRITE and FORMAT This interface also allows you to support up to 256*256*256 sectors, which makes for a fairly large disk (8G for 512 byte sectors). I could implement such a disk controller in the emulator in less than an hour - and I could easily provide a boot ROM, however I would need someone with HDOS experience (and probably a working HDOS system) to configure the system disk to work with it. I am also a bit concerned that the H17 ROM provides quite a few vectors which are entry points for very low level/H17 specific functions (Move ARM in/out, wait for Hole, wait for Sync etc.) - These function would make no sense on the virtual disk contrller described above - Does HDOS use any of these functions? 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 Sun May 23 13:27:40 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 23 May 2004 18:27:40 +0000 Subject: [sebhc] ZIP drive? Message-ID: >I had a strange thought. For anyone trying to build an actual machine (H8 / >H89). The 100 meg Zip Drive is available in a model that connects to a >parrallel port. I wonder if it would be possible to use one to replace >Floppy/Hard disks. It would be a lot of storage for CPM / HDOS, etc. >From what we were just discusing about emulation, it sounds like all you'd need would be a driver for it. I think there may be some unit storage limits inherent in HDOS though .. but perhaps the driver could address one cartridge as if it were several units. _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 23 14:15:30 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 23 May 2004 19:15:30 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: Walter says: >I have the source listings; they just are not convenient right now. Plus I >want to see what came on the distribution disks. That's what I was talking about. I've put all the sources that came with the HDOS distribution in the software/sources/HDOS.../... sections of the archives. These are from disks 2 and 3 of the 3-disk set. The disk images themselves are in software/disks/HDOS/... _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sun May 23 17:47:26 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sun, 23 May 2004 15:47:26 -0700 Subject: [sebhc] Can I have BBQ Sauce with my foot... In-Reply-To: Message-ID: <002901c44117$efb9c900$0700a8c0@walterp4> I told you I might be putting my foot in my mouth, so here it goes... Who supplies the code at 030.000 when you only have an H-47 installed? Heathkit wasn't explicit about this. They tell you that you must have the HA8-8 extended configuration board installed to run the H-47. What they don't mention in the manual is that you must also have implemented the ORG-0 functionality - both the new ROM on the motherboard and RAM at 000.000. Why? Because the ROM is actually 4K, and contains the H-17 ROM at address 010.000. When there is RAM present at 000.000, the ROM image at 010.000 is copied to RAM at 030.000. When there is no RAM at 000.000, no copy is done, none of the 030.xxx routines get installed, no booting occurs, on either the H-47 or the H-17 (from my tests). So there are some dependencies on the H-17 ROMs to boot; now I need to find them. I still believe that it would be easy to trap at the read/write vectors and not have to emulate the disk at the I/O level, I just need to figure out how. Jack - I guess the 444-70 ROM image in the archives is incorrect since it only contains the XCON/RAM8GO code, and not the 030.000 binary. I am also very curious about any differences between the H-17 ROM and the version contained with the XCON/RAM8GO ROM. ..walt -- Delivered by the SEBHC Mailing List From ab31 at juno.com Sun May 23 18:45:26 2004 From: ab31 at juno.com (ab31 at juno.com) Date: Sun, 23 May 2004 19:45:26 -0400 Subject: [sebhc] what's this emulator? Message-ID: <20040523.194529.4494.0.ab31@juno.com> Hi, this is Andy Becker. I helped Dave Shaw test and tune up his "Project 8080" H8 emulator for the Macintosh a while ago. It was much too slow for my Macintosh 7100/80 when I first tried it. The Power PC Versions run a little faster than a real H8 for me. I never owned an H8 but a few years ago a bought an H89 and an H100 (or is it HZ1000?). The H89 came with a lot of books and disks. Neither works quite right. The H89 seems to have a mismatch between the serial parameters of the CPU board and the terminal board after it boots a disk. It has some kind of fast replacement motherboard. The H100 has a hard disk and it boots ZDOS (like MS-DOS) but I think it had one bad letter key and I was not able to use the floppy drive. Some day I intend to fix them. I moved recently and they are packed up. I am familiar with some of the older computers. I learned about BASIC in high school on some kind of minicomputer (maybe a PDP-8) and later a Radio Shack TRS-80 Model 1. Later my Dad bought a TI-99/4A and I made lots of BASIC programs with it. Then I collected lots of other older popular Models. Lately I've been trying to write a word processor in BASIC, and learn about internet security, Javascript and HTML. I've tried some other languages including Fortran, Pascal, assembly language (three versions), Forth and C. I'm only confident with BASIC. I see Dave Dunfield is working on an emulator for PC computers. Is this a version of the emulator for the Macintosh or something completely original? What are the requirements for it? Does it need Windows? I have a Compaq Pressario 2200 which has a 180 MHz 486 (actually a MediaGX) and 32 MB RAM. It works nicely with the Altair emulator, about five times as fast as a real Altair. Dave, if you're converting "Project 8080" you should know that there were some minor problems left in the CPU. I think a flag register bit called "auxiliary carry" was not always set right. Most software doesn't use that so it didn't make much difference. I have some books about the 8080 and Z80 processors which I used as a guide when making segments of code for the CPU. I'm not sure if I could find them quickly or not. I remember having some ideas to make the CPU run a little faster that didn't get into the emulator. I'll try to download that emulator (assuming it's available by internet) and give it a try. I plan to visit the library and download it to a floppy disk. I don't trust the internet on my PC right now. Strange things are happening, like certain files getting corrupted, the recycle bin no longer storing deleted files, and hard disk activity when I read certain spam e-mail messages. I decided to downgrade to an old version of the Juno e-mail software that doesn't understand attachments and HTML. After examining the messages that cause disk activity, I decided that the cause is probably something in the e-mail header called "X-MAIL-INFO" with a long string of hexadecimal digits after it. My guess is that it has meaning only to the Juno program. I hope I can find some kind of virus scanner or spybot scanner that will identify the problem. Andy ________________________________________________________________ The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sun May 23 19:31:23 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sun, 23 May 2004 17:31:23 -0700 Subject: [sebhc] Unbuilt H-8 on eBay In-Reply-To: <20040523.194529.4494.0.ab31@juno.com> Message-ID: <002e01c44126$7551e300$0700a8c0@walterp4> For only $1500 Buy-it-now, $500 opening bid otherwise! Too expensive for my tastes! Well, maybe. It is tempting! ..walt -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 23 20:38:40 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 01:38:40 +0000 Subject: [sebhc] Emulation.. and XCON8 Message-ID: Walter says: >I still believe that it would be easy to trap at the read/write >vectors and not have to emulate the disk at the I/O level, I just need to >figure out how. Dunno about "easy" .. maybe "possible". :-) But still any user code wanting to play with the ports wouldn't work. >I guess the 444-70 ROM image in the archives is incorrect since it >only contains the XCON/RAM8GO code, and not the 030.000 binary. Good catch. I temporarily reconstructed it by appending the H17 rom to it, but would whomever originally uploaded it (or anyone with a system running it) send me a fresh dump so I can confirm it? >very curious about any differences between the H-17 ROM and the version >contained with the XCON/RAM8GO ROM. I'm assuming no difference - but I'll let you know when I get the chance to compare. Cheers, - Steven _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sun May 23 21:06:41 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 23 May 2004 19:06:41 -0700 (PDT) Subject: [sebhc] 1st Boot attempt! Message-ID: <200405240206.i4O26fKb098495@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 02:35:55 -0000 Well... it kinda boots: When I boot the "HDOS16.H8D" image on my emulator, I get this: ----------------------------------------------- ACTION? BOOT <= I pressed ENTER here SYSTEM HAS 56K OF RAM Volume 255, Mounted On SY0: Label: HDOS 1.6 Master Distribution for Mac H8 Emulator HDOS Version 1.6 Issue # 50.05.00 ?01 Disk Structure is Corrupt. Contact HEATH Technical Correspondence for Assistance. Boot Aborted. Will Restart ... ACTION? -------------------------------------------------- Wading through my disk register access logs, it looks like: (format is TRACK:SECTOR) - Immediately after hitting GO, the ROM reads 0:0-0:8 into RAM at #2280 and launches it. The loaded code reads 0:9 and then issues the ACTION? prompt. - The system then read: 0:9 (Again) 22:2 22:3 1:2 to 1:9 2:0 to 2:9 3:0 to 3:8 0:9 (again) 1:0 23:8 22:2 22:3 0:0 to 0:9 And this is where I get ACTION? again. As far as I can tell from my logs, the data from each requested sector was read from the right place and returned with the right values.... Can anyone give me details of what HDOS is doing when it starts up which might help be determine where it thinks the disk structure has been corrupted? I really need some insight - just these operations generates over a megabyte of regster access log... 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 Sun May 23 21:06:38 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 23 May 2004 19:06:38 -0700 (PDT) Subject: [sebhc] what's this emulator? Message-ID: <200405240206.i4O26cU9098496@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 02:35:57 -0000 >I see Dave Dunfield is working on an emulator for PC computers. Is this a >version of the emulator for the Macintosh or something completely >original? What are the requirements for it? Does it need Windows? I have >a Compaq Pressario 2200 which has a 180 MHz 486 (actually a MediaGX) and >32 MB RAM. It works nicely with the Altair emulator, about five times as >fast as a real Altair. Dave, if you're converting "Project 8080" you >should know that there were some minor problems left in the CPU. I think >a flag register bit called "auxiliary carry" was not always set right. >Most software doesn't use that so it didn't make much difference. I have >some books about the 8080 and Z80 processors which I used as a guide when >making segments of code for the CPU. I'm not sure if I could find them >quickly or not. I remember having some ideas to make the CPU run a little >faster that didn't get into the emulator. Is that my Altair emulator you are running? If so, the H8 emulator should run equally well. It's not based on any other emulator, except that I did borrow the 8080 engine from my Altair one, however it was originally my own design - neither emulator is based on anyone else's code. You can download a preliminary version of my H8 emulator from: http://www.dunfield.com/pub/h8.zip I believe Jack has also make it available in the sebhc archives. The emulator will run on anything from DOS 3 up. Regards, -- 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 cfandt at netsync.net Sun May 23 21:41:42 2004 From: cfandt at netsync.net (Christian Fandt) Date: Sun, 23 May 2004 22:41:42 -0400 Subject: [sebhc] Unbuilt H-8 on eBay In-Reply-To: <002e01c44126$7551e300$0700a8c0@walterp4> References: <20040523.194529.4494.0.ab31@juno.com> Message-ID: <5.2.1.1.2.20040523224010.026923d0@pop3.norton.antivirus> Did this drop off the listings because of a "Buy It Now" thing? What was the item number? Just curious. I've got my own I built back in '82. -Chris F. NNNN Upon the date 05:31 PM 5/23/04 -0700, Walter Moore said something like: >For only $1500 Buy-it-now, $500 opening bid otherwise! Too expensive for my >tastes! Well, maybe. It is tempting! > >..walt > > > > >-- >Delivered by the SEBHC Mailing List Christian Fandt, Electronic/Electrical Historian Jamestown, NY USA cfandt at netsync.net Member of Antique Wireless Association URL: http://www.antiquewireless.org/ -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 23 21:52:15 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 23 May 2004 21:52:15 -0500 Subject: [sebhc] Can I have BBQ Sauce with my foot... In-Reply-To: <002901c44117$efb9c900$0700a8c0@walterp4> Message-ID: <000001c4413a$1f7dc020$1f6fa8c0@eths.k12.il.us> > > I told you I might be putting my foot in my mouth, so here it goes... Don't start chewing yet - you're quite right, the XCON8 is a 4K ROM (both my 444-70 parts are labeled Motorola SCM91639P - I'm hoping this crosses to a TMS2532). My old Data I/O seems to be kind of fussy about reading some ROMs, but I'll give it a shot tonight or tomorrow. > Who supplies the code at 030.000 when you only have an H-47 > installed? Heathkit wasn't explicit about this. They tell > you that you must have the HA8-8 extended configuration board > installed to run the H-47. As I read the manual, they state that you need the HA8-8 only if you want to _boot_ from the H-47; without it you must boot from the H-17, at which point the dddvd driver is loaded and you can access the H-47 drives. My H-47 controller is only functioning as a serial port at this point, so I can't confirm. > When there is no RAM at 000.000, no copy is > done, yes, but... > none of the 030.xxx routines get installed, no booting > occurs, on either the H-47 or the H-17 (from my tests). if you have the H-17 in place, there is ROM at 030.xxx and the system should boot from the H-17 drives as advertised. > Jack - I guess the 444-70 ROM image in the archives is > incorrect since it only contains the XCON/RAM8GO code, and > not the 030.000 binary. I am also very curious about any > differences between the H-17 ROM and the version contained > with the XCON/RAM8GO ROM. > so am I - I'm not quite ready to join Dave in calling the H8 an "appliance computer" but there sure does seem to be a lot hidden beneath the covers! Jack -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Sun May 23 23:51:13 2004 From: leeahart at earthlink.net (Lee Hart) Date: Sun, 23 May 2004 21:51:13 -0700 Subject: [sebhc] what's this emulator? References: <20040523.194529.4494.0.ab31@juno.com> Message-ID: <40B17F41.107B@earthlink.net> Andy Becker ab31 at juno.com wrote: > bought an H89 and an H100 (or is it HZ1000?)... The H89 seems to > have a mismatch between the serial parameters of the CPU board and > the terminal board after it boots a disk. On power-up, there are DIP switches on both the CPU and TLB boards that set the baud rate of the computer and terminal respectively. They have to be set for matching baud rates. So, if the CPU and terminal work together, these DIP switches are both set to match. When you boot an operating system, it has its own independent baud rate settings. Most Heath software came configured for 9600 baud, but you could use the SET options in HDOS or CONFIGUR in CP/M to change it to whatever you like. To figure out what is going on, turn on the computer. If you get the "H:" prompt, then CPU and TLB are set to the same baud rate. Press the OFF LINE key, then ESC x L, then the OFFLINE key again so it pops back up. This ESC command sets the TLB to 9600 baud (but leaves the CPU board baud rate unchanged). If the computer still works (i.e. you can type things like the B boot command), then the DIP switches are both set for 9600 baud. If you *lose* communication with the terminal, then the CPU and TLB DIP switches are probably set to 19200 baud. Press the OFFLINE key, then ESC x M, then the OFFLINE key again so it pops back up. This ESC command sets the TLB to 19200 baud. If the computer still works, then the CPU and TLB were set to 19200 baud. Now reset the computer, and boot your operating system disk. If the operating system baud rate it wrong, it will print gibberish where the sign-on message should be, and it won't respond properly to keystrokes. To verify, use OFFLINE ESC x L or OFFLINE ESC x M to change the TLB baud rate. Press OFFLINE so it pops back up, and try "dir ". If it works, then you know all that is wrong is that the software baud rate doesn't match. Use SET or CONFIGUR to change the operating system baud rate to match the actual DIP switch baud rate. > It has some kind of fast replacement motherboard. The two possibilities are the D-G Super89 or TMSI H-1000. The Super89 basically adds a 4 MHz Z80 and extra RAM. The H-1000 adds this, plus an 8 MHz 8086 which can run MS-DOS. Hope this helps! -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- 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 May 23 22:12:38 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 23 May 2004 22:12:38 -0500 Subject: [sebhc] HDOS 3 ?? In-Reply-To: <5.2.1.1.2.20040521140842.025413e0@pop3.norton.antivirus> Message-ID: <000001c4413c$f868d6c0$1f6fa8c0@eths.k12.il.us> > > However, last I knew when I last used the H8, lo these many > years ago, HDOS > 3 had been just released or was about to be. > > Can anybody bring me (us?) up-to-date on what's transpired > since version 3 > had started to be released? > > Is it available anywhere? Available in soft-sector format? Chris, Source and docs are in the SEBHC archives - I've got several "should be" bootable disks around here (and yes, I do know where they are!) that I need to test out with an appropriate "booting" machine. Real Soon Now. Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sun May 23 22:19:23 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 23 May 2004 22:19:23 -0500 Subject: [sebhc] file naming conventions Message-ID: <000101c4413d$e9686540$1f6fa8c0@eths.k12.il.us> I've been kicking file naming conventions around with Steven for a couple of days - the specific topic is the use of "." and "_" to increase clarity in file names. By strict ARPA protocol, filenames are limited to true alphanumeric characters and the hyphen "-". I'm definitely opposed to the use of the dot (".") since it's caught me out more than once going from one system to another, but what about the underscore? I agree with Steven that it definitely aids readability, but what about the downside? Can anyone come up with a good reason why we shouldn't use it? Jack -- Delivered by the SEBHC Mailing List From garlangr at verizon.net Sun May 23 22:12:27 2004 From: garlangr at verizon.net (Mark Garlanger) Date: Sun, 23 May 2004 22:12:27 -0500 Subject: [sebhc] Unbuilt H-8 on eBay References: <20040523.194529.4494.0.ab31@juno.com> <5.2.1.1.2.20040523224010.026923d0@pop3.norton.antivirus> Message-ID: <008f01c4413c$f14aa260$6501010a@BUSTER> Nope, currently still there: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=294&item=5701411182&rd=1&ssPageName=WDVW Someone did bid the opening $500, but since reserve is not been met, someone could still 'buy now' at $1500. Mark ----- Original Message ----- From: "Christian Fandt" To: Sent: Sunday, May 23, 2004 9:41 PM Subject: Re: [sebhc] Unbuilt H-8 on eBay > Did this drop off the listings because of a "Buy It Now" thing? What was > the item number? Just curious. I've got my own I built back in '82. > > -Chris F. > > NNNN > > Upon the date 05:31 PM 5/23/04 -0700, Walter Moore said something like: > >For only $1500 Buy-it-now, $500 opening bid otherwise! Too expensive for my > >tastes! Well, maybe. It is tempting! > > > >..walt > > > > > > > > > >-- > >Delivered by the SEBHC Mailing List > > Christian Fandt, Electronic/Electrical Historian > Jamestown, NY USA cfandt at netsync.net > Member of Antique Wireless Association > URL: http://www.antiquewireless.org/ > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Mon May 24 00:43:29 2004 From: leeahart at earthlink.net (Lee Hart) Date: Sun, 23 May 2004 22:43:29 -0700 Subject: [sebhc] HDOS 3 ?? References: <6A47CB4A48D1EA49A6F7AB618490D6490AEA9C5F@mcl-its-exs03.mail.saic.com> Message-ID: <40B18B81.7414@earthlink.net> West, Ronald S. wrote: > On HDOS 3. They pretty much dropped the ball on all that stuff > when the IBM PC's hit the scene. Don't recall what year that was. > They switched to compatible PC's and MS-DOS and the rest, they say, > is history. Heath developed HDOS 1 and 2. HDOS 3 was developed independently by dedicated hobbyists. Rick Lutowski, Rick Streeter, and Kirk Thompson come to mind, but I'm sure there are others. It was a very impressive job, much more powerful than HDOS 2. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 23 23:31:07 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 04:31:07 +0000 Subject: [sebhc] RE: 1st Boot attempt! Message-ID: >Well... it kinda boots: Woohoo! :-) >When I boot the "HDOS16.H8D" image on my emulator, >Label: HDOS 1.6 Master Distribution for Mac H8 Emulator ^^^^^^^^^^^^^^^^^^^^^ This is clearly not a pristine distribution image. Just to be sure you have a good image, try it with HDOS_2.0_Issue_#50.06.00_890-64.disk in the archives under software/disk-images/HDOS. I know that one to be from a bootable distribution disk. You can call it HDOS20.H8D if you want :-) >?01 Disk Structure is Corrupt. >Contact HEATH Technical Correspondence for Assistance. I guess that would be me. :-) (I actually WAS "HEATH Technical Correspondence"). So .. assuming you still get that on the other image ... Most "corruption" had to do with mangled directories or GRT's, but the ones in the image should be good (certainly in the 2.0 image). The GRT is stored and manipulated in the write-protectable controller RAM (024.000-027.377). Are you emulating that RAM area? Are you also handling the write-protect control via the port and making it unwritable unless enabled by the control? >>- Immediately after hitting GO, the ROM reads 0:0-0:8 > into RAM at #2280 and launches it. Yea, that's "Boot" >The loaded code > reads 0:9 That's the label sector >- The system then read: > 0:9 (Again) > 22:2 > 22:3 Probably the first group of the directory (DIRECT.SYS) > 1:2 to 1:9 > 2:0 to 2:9 > 3:0 to 3:8 HDOS itself, read from a special contiguous allocation (so no GRT reference is needed). > 0:9 (again) > 1:0 RGT > 23:8 The GRT > 22:2 > 22:3 Directory again. This is probably the point at which the GRT is first used to find another file's position on the disk (perhaps the SY driver). And thus the "corruption" is detected. So if I guessed right, you should be HDOS'ing momentarily. Can't wait to try it out! Let me know if that's not it and I'll try to think of another possibility. Cheers, - Steven _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 23 23:53:11 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 04:53:11 +0000 Subject: [sebhc] Archive changes Message-ID: After discussion with Jack, I've done some re-organization in the archives with the intention of making things easier to find. But it may require a little re-discovery if you were already familar with it. In particular, the "software" section now should be JUST software, any listings that were there should now be found in the "documents" section. We will probably be making some name changes shortly after we make a determination on the underscore issue. In case you missed it before, you can access the archives via HTTP now, and most files have a short description that will appear that way that you won't see in FTP. (however, I do recommend FTP over HTTP for actual downloading). The HTTP interface is: http://heathkit:hdos8bit at www.sebhc.org/archive Also, I just added a few more disk images (in software/disk-images) and the PAM8GO.ROM image (software/ROMs). Cheers, - Steven _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Mon May 24 00:58:47 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sun, 23 May 2004 22:58:47 -0700 Subject: [sebhc] Can I have BBQ Sauce with my foot... In-Reply-To: <000001c4413a$1f7dc020$1f6fa8c0@eths.k12.il.us> Message-ID: <000001c44154$37b1e440$0700a8c0@walterp4> > As I read the manual, they state that you need the HA8-8 only if you > want to _boot_ from the H-47; without it you must boot from the H-17, at > which point the dddvd driver is loaded and you can access the H-47 > drives. My H-47 controller is only functioning as a serial port at this > point, so I can't confirm. I missed that. I might try it to confirm it. But I believe it. > > > When there is no RAM at 000.000, no copy is > > done, > > yes, but... > > > none of the 030.xxx routines get installed, no booting > > occurs, on either the H-47 or the H-17 (from my tests). > > if you have the H-17 in place, there is ROM at 030.xxx and the system > should boot from the H-17 drives as advertised. I tried this, and the system did not boot. Looking at 030.000, I only read 0's. With or without the extended configuration card, it came back 0's. It might be that there is something not right with my H-17, I don't know. I would have expected the modifications made to the H-17 when the XCON card was installed were to make it respond to the ROM disable line on the bus, not totally disable it. I'm not seeing that. Anybody want to power up a system with XCON, without RAM at 000.000 and tell me if they still have their H-17 controller ROM visible? ..walt -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 24 05:51:57 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 03:51:57 -0700 (PDT) Subject: [sebhc] It BOOTS! - but something odd Message-ID: <200405241051.i4OApvMv007470@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 11:07:14 -0000 >Are you emulating that RAM area? Are you also handling the write-protect >control via the port and making it unwritable unless enabled by the control? Ahem -- well -- yes -- I *THOUGHT* that when I implemented the emulator I allowd RAM writes from 0400-FFFF. I hadn't bothered to do anything special for the H17 ROM or RAM at this point. I just used the L=imagefile option to load the H17 ROM image. Turns out that I had disallowed writes below 2000, which means that the H17 RAM was PERMANENTLY write protected - I'm suprised it got as far as it did. With the H17 RAM implemented properly, HDOS boots just fine! But, in testing this, I noticed something REALLY ODD - perhaps you can shed some light! With the H17 RAM write protection implemented (ie: you can only write to the RAM with bit7 of Port7F at 1), then I can see only 5 files on the disk. However, with the H17 RAM write protection disabled (ie: you can write the H17 RAM at any time), then I can see 9 files on the disk! In both cases, HDOS does not complain about any errors, and if you look at the output below, you will see that it thinks there are no free sectors in the "write protect enabled" version... ??? ??? ??? ==== This is what I get with Write Protect ENABLED ==== HDOS Version 1.6 Issue # 50.05.00 Date (DD-MMM-YY)? 24-may-99 >dir Name .Ext Size Date Flags 24-May-99 ASM .ABS 28 10-Jun-91 BASIC .ABS 42 10-Jun-91 DBUG .ABS 15 10-Jun-91 EDIT .ABS 17 10-Jun-91 HDOS .ACM 2 10-Jun-91 5 Files, Using 104 Sectors (0 Free) > ==== This is what I get with Write Protect DISABLED ==== HDOS Version 1.6 Issue # 50.05.00 Date (DD-MMM-YY)? 24-may-99 >dir Name .Ext Size Date Flags 24-May-99 ASM .ABS 28 10-Jun-91 BASIC .ABS 42 10-Jun-91 DBUG .ABS 15 10-Jun-91 EDIT .ABS 17 10-Jun-91 HDOS .ACM 2 10-Jun-91 INIT .ABS 20 10-Jun-91 PATCH .ABS 11 10-Jun-91 SYSGEN .ABS 14 10-Jun-91 TEST .ABS 22 10-Jun-91 9 Files, Using 171 Sectors (30 Free) > ================================================ Does the write protect bit cover the entire 1K (1400-17FF) H17 RAM area? Any other explaination? 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 Mon May 24 06:16:56 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 04:16:56 -0700 (PDT) Subject: [sebhc] It BOOTS! - fixed oddity Message-ID: <200405241116.i4OBGufX008212@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 11:26:19 -0000 >But, in testing this, I noticed something REALLY ODD - >perhaps you can shed some light! Never mind (my bug - fixed). 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 Mon May 24 07:06:59 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 05:06:59 -0700 (PDT) Subject: [sebhc] Emulator H17 progress Message-ID: <200405241207.i4OC6wrb008932@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 12:29:44 -0000 Ok - I've just implemented the ability to write to the drive. I can boot HDOS, run programs, execute BASIC, save a program to disk, exit the simulator, re-enter the simulator, boot, load basic, load my saved program and run it - so it looks pretty good! Unfortunately, due to the way the H17 drives work, I have to simulate the speed of the floppy as well - basically, if the holes come too fast, the skip sector function will not skip single sectors correctly. This driver uses a raw binary image of the disk data only, it regenerates the header as required following each sector hole. This means that it may not work with non-HDOS formats or programs which do "tricks" with the disk format. I have to clean up the driver a bit, add some "fluff" to let you mount/unmount drives, but it's basically there - might even have a version to release by the end of the day (depends on what else I have going on). Whew! - getting this working has been harder than writing the rest of the emulator. 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 jack.rubin at ameritech.net Mon May 24 07:15:11 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 24 May 2004 07:15:11 -0500 Subject: [sebhc] Can I have BBQ Sauce with my foot... In-Reply-To: <000001c44154$37b1e440$0700a8c0@walterp4> Message-ID: <000001c44188$c36f5e70$1f6fa8c0@eths.k12.il.us> > > > > > When there is no RAM at 000.000, no copy is > > > done, > > > > yes, but... > > > > > none of the 030.xxx routines get installed, no booting occurs, on > > > either the H-47 or the H-17 (from my tests). > > > > if you have the H-17 in place, there is ROM at 030.xxx and > the system > > should boot from the H-17 drives as advertised. > > Anybody want to power up a system with XCON, without RAM at > 000.000 and tell me if they still have their H-17 controller > ROM visible? > There were several "optional" system mods to the H17 controller and the CPU card in addition to replacing the PAM ROM with XCON to allow org-0 booting - essentially setting up ROM shadowing for the lower 8k. If you are presently booting a 64K (ie. org-0) system, you would need to reverse the ROM de-select mods as well. I'll try to set up a 56K XCON system and report back to you. Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 24 07:35:25 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 24 May 2004 07:35:25 -0500 Subject: [sebhc] 1st Boot attempt! In-Reply-To: <200405240206.i4O26fKb098495@gatekeeper.evocative.com> Message-ID: <000101c4418b$96e7cdd0$1f6fa8c0@eths.k12.il.us> Hey Dave - how long does it take you to do something _really_ difficult? ;>) Nice work! Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 24 07:57:10 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 24 May 2004 07:57:10 -0500 Subject: [sebhc] HDOS 3 ?? In-Reply-To: <40B18B81.7414@earthlink.net> Message-ID: <000001c4418e$a0bf0050$1f6fa8c0@eths.k12.il.us> > Heath developed HDOS 1 and 2. HDOS 3 was developed > independently by dedicated hobbyists. Rick Lutowski, Rick > Streeter, and Kirk Thompson come to mind, but I'm sure there > are others. It was a very impressive job, much more powerful > than HDOS 2. HDOS 3.0 was originally proposed to Heath by Bill Parrott, Dave Carroll and Dale Wilson (I have the proposal around here somewhere; I'll upload a scan next time it goes by). Dave and Dale didn't take part in the actual development - Richard Musgrave joined Bill for the 3.0 release, and Richard continued to refine the system for the 3.02 release. Others who contributed code to the initial release included Dean Gibson, Bruce Denton, Dale Lamm, Andy Dessler and Wayne Parnin. All of HDOS 3.0 is public domain - the docs and source are in the archives. When things settle down on a share-able disk image format, I'll add some disks. Jack -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 24 08:27:37 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 24 May 2004 09:27:37 -0400 Subject: [sebhc] Archive changes In-Reply-To: (sp11@hotmail.com) References: Message-ID: <1085360854@rothfus.com> Cool more disk images! However, it looks like we've landed on a generic (read "non-distinquishable") disk image format. Even the extension is generic ".disk". Far be it from me to b*tch :-), but how about a just a simple header with the following (as an example): H8,40,10\n This format identifies it as an H8 disk with 40 tracks and 10 sectors. You can get rid of the header line by discarding everything up to the newline. Put it in binary format if you like. Again, the goal is simply to allow intelligent software (as well as historians 100 years from now) to tell that this image was meant to run on a Heathkit H8 and that it can be decoded with 40 tracks of 10 sectors. Sure, I've drawn an arbitrary line about how much information is necessary...but we need something! Hopefully, in the not too distant future, a much larger integrated archive of software images will assemble itself, and the H8/H89 images will be part of that. Fortunately, most other image formats have some distinguishing characteristics. Let's keep with that philosophy. Dave - can you live with a header on the binary file for the H17 part of the emulator? Eric -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 24 09:12:04 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 07:12:04 -0700 (PDT) Subject: [sebhc] Busted something - help! Message-ID: <200405241412.i4OEC3DW010682@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 14:24:25 -0000 I broke something - I can't for the life of me figure out what. I can boot fine, I can run the assembler and the debugger, but if I run BASIC or the editor, I get: ========================================================== HDOS Version 1.6 Issue # 50.05.00 Date (DD-MMM-YY)? 24-may-90 >basic Extended Benton Harbor BASIC #110.05.00 ?02 FATAL SYSTEM ERROR ? ========================================================== At which point the system executes a HLT instruction. Anyone got any ideas? What is a ?02 error? 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 Mon May 24 10:02:03 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 08:02:03 -0700 (PDT) Subject: [sebhc] Need test on real H17 (anyone?) Message-ID: <200405241502.i4OF22kb011457@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 15:16:45 -0000 Could someone with a real H8/H17 combo please try booting a write protected diskette, and verify for me that both BASIC and EDIT will fail to run with a fatal system error if the disk is write protected? 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 Mon May 24 11:10:04 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 16:10:04 +0000 Subject: [sebhc] Emulator H17 progress Message-ID: >?02 FATAL SYSTEM ERROR ? >At which point the system executes a HLT instruction. >Anyone got any ideas? What is a ?02 error? According to errormsg.sys, it's "No Free Space on Media". But I'm surprised that would be cause for a halt rather than just a return to HDOS. Unless...(wild guess here)... it was suddenly unable to write the swap file after already having used it. Do you have it ready for download? I could try it and see if I come with something else. >I can boot HDOS, run programs, execute BASIC, save a program >to disk, exit the simulator, re-enter the simulator, boot, >load basic, load my saved program and run it - so it looks >pretty good! Oh yea? So what did you change before that halt started? >Unfortunately, due to the way the H17 drives work, I have to >simulate the speed of the floppy as well - basically, if the >holes come too fast, the skip sector function will not skip >single sectors correctly. Yea, timing is an issue with seeks .. but you can read and write as fast as you want! (Just be sure to skip ahead to "no hole" condition after a read or write that starts on a hole). >Whew! - getting this working has been harder than writing the >rest of the emulator. I suspected that would be the case .. but still, quick work indeed! Cheers, - Steven _________________________________________________________________ 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 dwight.elvey at amd.com Mon May 24 11:27:20 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 09:27:20 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405241627.JAA18441@clulw009.amd.com> >From: "Steven Parker" > >>Question: Does any H8 software ever do anything "funny" with these values? > >HDOS doesn't. I'm not entirely sure what other parties may have done with >them. > ---snip--- Hi I wrote a FIG Forth for the H89 a number of years ago. I didn't keep the convention of placing the volume number on sector 9 as HDOS does and all my volumes are all 0. I know now why HDOS did this volume stuff. My understanding was that it was so that one couldn't accidentally overwrite another volume with data from a previous volume that had not been properly dismounted. I was wondering, has anyone see a utility to overwrite the HDOS volume number. While we are exchanging images, we will most likely create disk that have the same volume number. It would be good to be able to modify the volume number of a disk to be consistant with the personal library of disk. This would help keep the protections that HDOS has built in. I could add this to my image transfer program because it would be trivial to add. Dwight -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 24 11:38:56 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 24 May 2004 09:38:56 -0700 (PDT) Subject: fast read/write - was RE: [sebhc] Emulator H17 progress In-Reply-To: Message-ID: <20040524163856.35073.qmail@web50206.mail.yahoo.com> > Yea, timing is an issue with seeks .. but you can > read and write as fast as > you want! (Just be sure to skip ahead to "no hole" > condition after a read > or write that starts on a hole). > Am I right in thinking that this could be a real speed enhancer for a serial-serial H8 to PC connection? I'm really looking forward to being able to intechange "disks" between real and virtual machines - it doesn't seem like Dave, Dwight, Steven and Eric are too far apart. Can you guys iron out the differences before things start to diverge? Jack -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 24 12:01:24 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 10:01:24 -0700 (PDT) Subject: [sebhc] H17 ROM and disk info Message-ID: <200405241701.KAA18462@clulw009.amd.com> >From: "Dave Dunfield" ---snip--- > >I am also a bit concerned that the H17 ROM provides quite a few vectors which >are entry points for very low level/H17 specific functions (Move ARM in/out, wait >for Hole, wait for Sync etc.) - These function would make no sense on the virtual >disk contrller described above - Does HDOS use any of these functions? > Hi Dave I think these still can be dealt with in the emulator. Moving the heads is just moving the offest in the simulated disk's file. I believe one can determine ccomplete actions from the port activity. One should even need to know what routine called them in the ROM, OS or application. One could make a simulated disk with complete sectors and headers. Went looking at how the H17 controller talks to the disk, One can recognize track stepping and also searches for sector holes. Don't try to understand the software of the ROM, just look at the port hardware and don't assume that there is anything other than a maximum of XX number of bytes allowable between index marks. Also that index marks are spaced timewise around the disk, as well as bit spacewise. This way, you should eb able to handle any kind of funny software protect or whatever might be on any particular disk image. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 24 12:26:55 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 10:26:55 -0700 (PDT) Subject: [sebhc] Archive changes Message-ID: <200405241726.KAA18472@clulw009.amd.com> >From: "Eric J. Rothfus" > >Cool more disk images! However, it looks like we've landed >on a generic (read "non-distinquishable") disk image format. >Even the extension is generic ".disk". > >Far be it from me to b*tch :-), but how about a just a simple >header with the following (as an example): > > H8,40,10\n > >This format identifies it as an H8 disk with 40 tracks and >10 sectors. You can get rid of the header line by discarding >everything up to the newline. Put it in binary format if you >like. > >Again, the goal is simply to allow intelligent software (as >well as historians 100 years from now) to tell that this image >was meant to run on a Heathkit H8 and that it can be decoded >with 40 tracks of 10 sectors. Sure, I've drawn an arbitrary >line about how much information is necessary...but we need >something! > >Hopefully, in the not too distant future, a much larger >integrated archive of software images will assemble itself, >and the H8/H89 images will be part of that. Fortunately, >most other image formats have some distinguishing >characteristics. Let's keep with that philosophy. > >Dave - can you live with a header on the binary file for >the H17 part of the emulator? > >Eric > Hi Why not put the text at a tail to the file. Those programs that load an image size chunk will still work while the extra bytes at the end won't make much difference. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 24 12:26:03 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 17:26:03 +0000 Subject: [sebhc] Archive disk images/formats Message-ID: Eric says: >Cool more disk images! However, it looks like we've landed >on a generic (read "non-distinquishable") disk image format. >Even the extension is generic ".disk". I wanted to get stuff out there quickly to support Dave's work, and get the collection started. >... how about a just a simple header ... Let's not rush it .. particularly not until we have an idea of what kind of info we REALLY want. I'm sure we'd want a bit more, like number of sides and bytes per sector. On the other hand, I'm still not sure any formats exist that can't be identified purely by file size. But it's worth more investigation first. In the meantime, the pure data is what we get from the existing dump utilities, and what Dave needed. I just added descriptions and a readme file to the archives to indicate that the disk images (at the moment) are all pure data images of Single sided, 40 track, 10 sectors per track, 256 bytes per sector disks. >Hopefully, in the not too distant future, a much larger >integrated archive of software images will assemble itself, >and the H8/H89 images will be part of that. What are you anticipating having BESIDES H8/H89 disks? Jack says: >When things settle down on a share-able disk image format, I'll add some >disks. Please don't wait .. I've never seen HDOS 3 myself! I promise to convert everything we have when we decide on another format. I just don't want to do it more than once! To help us in deciding on an eventual format, would everyone please post any existing formats that you know of. To start things off: H17: 1 side, 40 track, 10 sector, 256 byte (5 1/4 inch, hard sector) 1 side, 80 track, 10 sector, 256 byte (5 1/4 inch, hard sector) 2 side, 80 track, 10 sector, 256 byte (5 1/4 inch, hard sector) H37: 2 side, 40 track, 9 sector, 512 byte (5 1/4 inch) 2 side, 80 track, 15 sector, 512 byte (5 1/4 inch) H47: 1 side, 77 track, 26 sector, 128 byte (8 inch) Additions? Corrections? - Steven _________________________________________________________________ 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 sp11 at hotmail.com Mon May 24 12:35:31 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 17:35:31 +0000 Subject: [sebhc] Archive changes Message-ID: Dwight says: > Why not put the text at a tail to the file. Those >programs that load an image size chunk will still >work while the extra bytes at the end won't make much >difference. Except at the moment, I'm considering the file size to identify the format. I suggest keeping the data pristine until we decide on another format. What kind of tool would make rational use of such text unless it ALREADY knew the size of the file? :) _________________________________________________________________ Get 200+ ad-free, high-fidelity stations and LIVE Major League Baseball Gameday Audio! http://radio.msn.click-url.com/go/onm00200491ave/direct/01/ -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 24 12:57:27 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 24 May 2004 17:57:27 +0000 Subject: [sebhc] H17 ROM and disk info Message-ID: Dwight said: >...HDOS did this volume stuff... >... so that one couldn't accidentally overwrite another >volume with data from a previous volume that had not been >properly dismounted. That was the idea, but it was only partly effective, as at best you'd stil have a 1/256 chance of mis-identifying the disk; and in practice it was much lower as they were assigned by operator choice. > I could add this to my image transfer program because it >would be trivial to add. It would be a handy option, but in some cases it might be desirable to re-create the source disk exactly, including it's volume number. Jack says: > > ...read and write as fast as you want! Am I right in thinking that this >could be a real speed >enhancer for a serial-serial H8 to PC connection? I expect the serial rate itself will be the bottleneck in such a connection. >I'm really looking forward to being able to intechange >"disks" between real and virtual machines I do it now using "dump" (aka "suprdump", etc) via a console connection to the other machine. But it can certainly be made more convenient! Cheers, - Steven _________________________________________________________________ Watch LIVE baseball games on your computer with MLB.TV, included with MSN Premium! http://join.msn.click-url.com/go/onm00200439ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 24 15:27:17 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 13:27:17 -0700 (PDT) Subject: [sebhc] H8/H17 emulator available to prelim. trials Message-ID: <200405242027.i4OKRHd1017291@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 20:43:34 -0000 I've posted a copy of my (very preliminary) H8 emulator with H17 support at: http://www.dunfield.com/pub/H8H17.ZIP This appears to boot the HDOS 1.6 disk fine. I found one image in my collection which tries to boot HDOS 2.0 (sorry, don't know what is was originally as the long filenames dissapate when I download - but I'm sure it came from the SEBHC archive). It boots, prompts for the date, and then appears to "hang". I have discovered that if you type like crazy to fill the console input buffer until it begins to beep, then hit BACKSPACE a few times while it is still beeping, it unlocks, continues with the HDOS startup prompt, and everything appears to work normally after that... I can't really tell what is happening, because it hangs in a loop between several subroutines up in high memory, and I do not have any listings for that ... If anyone can offer some light as to what is happening, that would be most helpful. 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 Mon May 24 16:25:19 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 14:25:19 -0700 (PDT) Subject: fast read/write - was RE: [sebhc] Emulator H17 progress Message-ID: <200405242125.OAA18604@clulw009.amd.com> Hi Most timing is done relative to the 2ms timer registers these can be altered by the emulator. Most code loops will not be as big an issue. Still, for a first level, keeping things happening on a time scale based on instruction cycle times isn't too bad. As for disk image formats, I'm flexable. If things are done as binaries, using tailer instead of headers makes sense. If it is in an ASCII format, headers make sense. As far as the simulator goes, it wouldn't take but a second or two to convert a sector binary to a full track type binary. This would make it so that the disk truely looked like a real floppy to the software. We can make simple converters. I do think using one archiving method is a good idea. There are many reasons to have something that is in human readable format. Octal is wasteful but HEX is better here. Still, it is a format that already exist. Dwight >From: "Jack Rubin" > >> Yea, timing is an issue with seeks .. but you can >> read and write as fast as >> you want! (Just be sure to skip ahead to "no hole" >> condition after a read >> or write that starts on a hole). >> > >Am I right in thinking that this could be a real speed >enhancer for a serial-serial H8 to PC connection? > >I'm really looking forward to being able to intechange >"disks" between real and virtual machines - it doesn't >seem like Dave, Dwight, Steven and Eric are too far >apart. Can you guys iron out the differences before >things start to diverge? > >Jack >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 24 16:45:22 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 14:45:22 -0700 (PDT) Subject: [sebhc] Archive disk images/formats Message-ID: <200405242145.OAA18617@clulw009.amd.com> >From: "Steven Parker" > >Eric says: >>Cool more disk images! However, it looks like we've landed >>on a generic (read "non-distinquishable") disk image format. >>Even the extension is generic ".disk". > >I wanted to get stuff out there quickly to support Dave's work, and get the >collection started. > >>... how about a just a simple header ... > >Let's not rush it .. particularly not until we have an idea of what kind of >info we REALLY want. I'm sure we'd want a bit more, like number of sides >and bytes per sector. On the other hand, I'm still not sure any formats >exist that can't be identified purely by file size. But it's worth more >investigation first. > >In the meantime, the pure data is what we get from the existing dump >utilities, and what Dave needed. > >I just added descriptions and a readme file to the archives to indicate that >the disk images (at the moment) are all pure data images of Single sided, 40 >track, 10 sectors per track, 256 bytes per sector disks. The current .disk is compatable with my .img format. What ever someone wants that could convey more information would be fine. I like the thought that there be a human readble header. This could be a combination human ASCII with a machine binary or the Header fields could be defined so that a machine could read it from the ASCII. Having tailers makes sense for binaries. This way the size of the tailer could change over time as more info was needed. If placed at the head, one would need a count to skip over to find the actual image. There are good reasons why each of us would want to convert the image to a particular format for particular purposes, locally. Writing converters is usually trivial. We should agree on a standardized format for exchange. Any header should have enough description in it that a computer could read the header and be able to convert it to the desired format and back. I think the header( tailer ) should be human as well as machine readable. Dwight > >>Hopefully, in the not too distant future, a much larger >>integrated archive of software images will assemble itself, >>and the H8/H89 images will be part of that. > >What are you anticipating having BESIDES H8/H89 disks? > >Jack says: >>When things settle down on a share-able disk image format, I'll add some >>disks. > >Please don't wait .. I've never seen HDOS 3 myself! I promise to convert >everything we have when we decide on another format. I just don't want to >do it more than once! > >To help us in deciding on an eventual format, would everyone please post any >existing formats that you know of. To start things off: > >H17: > 1 side, 40 track, 10 sector, 256 byte (5 1/4 inch, hard sector) > 1 side, 80 track, 10 sector, 256 byte (5 1/4 inch, hard sector) > 2 side, 80 track, 10 sector, 256 byte (5 1/4 inch, hard sector) >H37: > 2 side, 40 track, 9 sector, 512 byte (5 1/4 inch) > 2 side, 80 track, 15 sector, 512 byte (5 1/4 inch) >H47: > 1 side, 77 track, 26 sector, 128 byte (8 inch) > >Additions? Corrections? > >- Steven > >_________________________________________________________________ >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 > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 24 16:52:01 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 14:52:01 -0700 (PDT) Subject: [sebhc] H8/H17 emulator available to prelim. trials Message-ID: <200405242152.OAA18622@clulw009.amd.com> >From: "Dave Dunfield" > >I've posted a copy of my (very preliminary) H8 emulator with >H17 support at: > > http://www.dunfield.com/pub/H8H17.ZIP > >This appears to boot the HDOS 1.6 disk fine. > >I found one image in my collection which tries to boot HDOS 2.0 >(sorry, don't know what is was originally as the long filenames >dissapate when I download - but I'm sure it came from the SEBHC >archive). > >It boots, prompts for the date, and then appears to "hang". > >I have discovered that if you type like crazy to fill the console >input buffer until it begins to beep, then hit BACKSPACE a few >times while it is still beeping, it unlocks, continues with the >HDOS startup prompt, and everything appears to work normally >after that... > >I can't really tell what is happening, because it hangs in a loop >between several subroutines up in high memory, and I do not have any >listings for that ... > >If anyone can offer some light as to what is happening, that would >be most helpful. > >Regards, >Dave Hi Dave It seems like they did an auto baud but I'm not sure. Dwight -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 24 17:32:18 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 15:32:18 -0700 (PDT) Subject: [sebhc] H8/H17 emulator available to prelim. trials Message-ID: <200405242232.i4OMWIV5019342@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 24 May 2004 22:48:25 -0000 >Hi Dave > It seems like they did an auto baud but I'm not sure. >Dwight Hi Dwight, that occuired to me - I do recall reading somewhere that an configured disk auto-bauds, however this "should" with my emulated serial port (it will of course lock onto the first baudrate that it tries). IIRC, it was supposed to autobaud on a SPACE character - I tried typing LOTS of spaces --- no dice.. Hopefully Steven or someone else imtimately familier with the Heath systems will be able to tell me exactly what it's doing ... 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 waltm22 at comcast.net Mon May 24 18:01:05 2004 From: waltm22 at comcast.net (Walter Moore) Date: Mon, 24 May 2004 16:01:05 -0700 Subject: [sebhc] H8/H17 emulator available to prelim. trials In-Reply-To: <200405242232.i4OMWIV5019342@gatekeeper.evocative.com> Message-ID: <000a01c441e3$01ebd1b0$0700a8c0@walterp4> The "SPACE" feature used underruns and framing errors to determine what the next baud rate to try was. I don't know how you would emulate this. Bit 6 of I/O port 362Q (from the XCON card) allowed the baud rate to be set to 9600 by default. Emulating the XCON card might be easier if you haven't. ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dave Dunfield > Sent: Monday, May 24, 2004 3:32 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] H8/H17 emulator available to prelim. trials > > > >Hi Dave > > It seems like they did an auto baud but I'm not sure. > >Dwight > > Hi Dwight, > > that occuired to me - I do recall reading somewhere that an configured > disk auto-bauds, however this "should" with my emulated serial port (it > will of course lock onto the first baudrate that it tries). > > IIRC, it was supposed to autobaud on a SPACE character - I tried typing > LOTS of spaces --- no dice.. Hopefully Steven or someone else imtimately > familier with the Heath systems will be able to tell me exactly what it's > doing ... > > 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 waltm22 at comcast.net Mon May 24 18:05:32 2004 From: waltm22 at comcast.net (Walter Moore) Date: Mon, 24 May 2004 16:05:32 -0700 Subject: [sebhc] Archive disk images/formats In-Reply-To: Message-ID: <000b01c441e3$a1053070$0700a8c0@walterp4> > H47: > 1 side, 77 track, 26 sector, 128 byte (8 inch) also: 1 side, 77 track, 26 sector, 256 byte 2 side, 77 track, 26 sector, 128 byte 2 side, 77 track, 26 sector, 256 byte I would have to do a little research to see if heath allowed a single density track 0 on a double density disk. Remex allowed it, along with different densities for each side of track 0. ..walt -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 24 19:12:22 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 24 May 2004 17:12:22 -0700 (PDT) Subject: [sebhc] H8/H17 emulator available to prelim. trials Message-ID: <200405250012.i4P0CMtK020923@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 00:36:49 -0000 >The "SPACE" feature used underruns and framing errors to determine what the >next baud rate to try was. I don't know how you would emulate this. Bit 6 >of I/O port 362Q (from the XCON card) allowed the baud rate to be set to >9600 by default. Emulating the XCON card might be easier if you haven't. As the console serial port gets it data from the PC keyboard buffer, it will bever get a framing error - underruns do not occur on a async port, however the virtual uart will not see framing errors or parity errors either --- however --- I would assume that if the first baud rate tried results in a SPACE character with no errors, then the driver would assume it has it righ. Also, the standard H5 serial card can only do two baudrates under software control, x16 (9600) and x64 (2400) - depending on the baud rate clock jumper settings - so there would only be two possible settings to try (the x1 setting is invalid unless you have a clock synced to the data) - since there is no speed associated with the PC keyboard/video display, my driver ignores this control bit - so every single attempt by the H8 side driver to obtain an error free "SPACE" should be successful - no matter what it has the baud rate programmed to... I'll have to dig into it more at some point. Btw, I forgot to mention in my original post, the H17 emulation currently supports only 40 track, 10 sectors single density, single sided - the disk image file should be exactly 102400 bytes in size, and is simply a raw binary dump of the disk data sectors only - additional formats may come "later". 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 eric at rothfus.com Mon May 24 20:28:39 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 24 May 2004 21:28:39 -0400 Subject: [sebhc] Archive disk images/formats In-Reply-To: <000b01c441e3$a1053070$0700a8c0@walterp4> (waltm22@comcast.net) References: <000b01c441e3$a1053070$0700a8c0@walterp4> Message-ID: <1085405232@rothfus.com> >> H47: >> 1 side, 77 track, 26 sector, 128 byte (8 inch) > > also: > > 1 side, 77 track, 26 sector, 256 byte > 2 side, 77 track, 26 sector, 128 byte > 2 side, 77 track, 26 sector, 256 byte Only the H17 formats Steven listed were labeled as hard-sectored. Are all of the other above formats soft-sectored? How about recording density and/or format? The H17 hard-sectored format is rather distinct FM. I don't know the others. FM? MFM? Does anyone know the spec for soft-sectored disks (or the controller)? Does it use simply the Western Digital 1771/1791/1793 controller? And thanks, Steven, for volunteering to be the conversion-meister when we get to a settled format! Eric -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Mon May 24 21:36:15 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 19:36:15 -0700 (PDT) Subject: [sebhc] H8/H17 emulator available to prelim. trials Message-ID: <200405250236.TAA18757@clulw009.amd.com> >From: "Dave Dunfield" > > >>Hi Dave >> It seems like they did an auto baud but I'm not sure. >>Dwight > >Hi Dwight, > >that occuired to me - I do recall reading somewhere that an configured >disk auto-bauds, however this "should" with my emulated serial port (it >will of course lock onto the first baudrate that it tries). > >IIRC, it was supposed to autobaud on a SPACE character - I tried typing >LOTS of spaces --- no dice.. Hopefully Steven or someone else imtimately >familier with the Heath systems will be able to tell me exactly what it's >doing ... It might be that it is waiting for delays before running the disk. Does your emulator run the 2ms interrupt? If not, this might be a problem. It could also be that it is looking to see if there is a disk in the drive by waiting for index holes. This again is related to the timer interrupts. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 24 21:57:17 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 02:57:17 +0000 Subject: [sebhc] H8/H17 emulator available to prelim. trials Message-ID: >I have discovered that if you type like crazy to fill the console >input buffer until it begins to beep, then hit BACKSPACE a few >times while it is still beeping, it unlocks, continues with the >HDOS startup prompt, and everything appears to work normally >after that... Boy, you got a wierd one here! It did exactly the same for me using the 2.0 distribution disk (maybe thats what you were using). This isn't sensing behavior - that occurs before the first console I/O. The sensing process is not only to detect baud rate (only on the 8250), but to determine which port your console is connected to (it could be either on the 8251 at 370 or the 8250 at 350). If an 8250 is present, it would display SPACE on the led's and wait for you to hit spaces on your console. I'm guessing you don't currently emulate the 8250 so it went past that to the "action?" prompt. I don't recall ever having any tech inquiries regarding this particular hangup on real H8's. But I do know that the console gets re-initialized at that point, because on my real H8 I have to manually turn on RTS then for my serial connection to continue talking to it (proper RTS management was obviously overlooked in the driver). So, just a guess at this point .. but take a look at how your emulation handles re-initialzation of the chip after it's been in use. Particularly in regard to interrupt handling. Meanwhile... In honor of your achievements so far, I've changed the disk images in the archives to all have "h8d" extensions. :-) (This also resolves some concerns recently expressed about long extensions). Cheers, - Steven _________________________________________________________________ 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 dwight.elvey at amd.com Mon May 24 22:04:03 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Mon, 24 May 2004 20:04:03 -0700 (PDT) Subject: [sebhc] My H8 Systems Message-ID: <200405250304.UAA18770@clulw009.amd.com> Hi With all of the talk about H8's I decided this weekend to actually power one up( I do have a working H89 ). I have two of the H8's. One is the older type with the 8080 and the other is the newer type with the Z80. I only brought up the Z80 one. I used my variac and brought the voltage up slowly over about 1 hour time. At first it was flakey. I removed the first RAM card and switched the next to start at address 0. It then booted fine. I gave the card a quick ohm meter check and there didn't seem to be any issues with it. I reconfigured the addresses back to the original and it was then working. It boots to the monitor just fine. I guess the connector needed a little wiping action. I've not done much in the way of a RAM test yet. I'll most likely write a 13n march for it. It has a H17 controller so I can try booting a disk. I should note that the controller has both the ROM and the two RAMs missing. I suspect that this is what one does when there is the XCOM8 with a full 64K of RAM. I have another controller board with the RAM and ROM. I expect to run this on the 8080 machine. This box doesn't have a full complement of RAM. It has only 4 8K boards installed but I have 3 other 8K boards ( one not fully populated ). The 8080 has the combination cassette/serial board ( H8-5 ) while the Z80 machine has the 4 port serial board ( H8-4 ). I only have the one H17 drive box so I'll need to share that between machines. I have a H19 but I'm not sure what its status is yet. All good fun. Dwight -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Mon May 24 22:29:23 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 24 May 2004 22:29:23 -0500 Subject: [sebhc] Archive disk images/formats In-Reply-To: Message-ID: <000001c44208$7985f410$1f6fa8c0@eths.k12.il.us> > H17: > 1 side, 40 track, 10 sector, 256 byte (5 1/4 inch, hard sector) > 1 side, 80 track, 10 sector, 256 byte (5 1/4 inch, hard sector) > 2 side, 80 track, 10 sector, 256 byte (5 1/4 inch, hard sector) > H37: > 2 side, 40 track, 9 sector, 512 byte (5 1/4 inch) > 2 side, 80 track, 15 sector, 512 byte (5 1/4 inch) > H47: > 1 side, 77 track, 26 sector, 128 byte (8 inch) > > Additions? Corrections? how about the H67 - 10 mb hard drive, able to support up to 5 mb partitions (?); including HDOS, CP/M and UCSD Pascal! and how about arbitrarily sized file "globs" on a connected host, up to the limits of the O/S? -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 24 23:59:01 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 04:59:01 +0000 Subject: [sebhc] various topics Message-ID: Dwight says: >I've not done much in the way of a RAM test yet. Remember the H-17 has the standard RAM test built-in. Just set PC to 030.003 and hit go 2 times. >The current .disk is compatable with my .img format Great! But I abandoned the ".disk" name in favor of .h8d. >There are many reasons to have something that is in human readable format. I don't see that. If someone wanted to "see" the binary data, any platform is going to have a handy hex and/or octal dump program. But making it "readable" still doesn't make it intelligible. :-) Eric says: >Are all of the other above formats soft-sectored? Yes. >Does [the soft-sector controler] use the Western Digital 1771/1791/1793 >controller? It uses the 1797. The manual is in the archives! Jack says: >>Additions? Corrections? >how about the H67 - 10 mb hard drive, I don't think this was ever a software distribution format! We won't need to accomodate that one in the archives. :-) Cheers, - Steven P.S. Hey Dave .. now that you emulate H17's .. why not exchange the PAM8 for PAM8GO (it's in the ROM section of the archives)? _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Tue May 25 07:42:51 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 05:42:51 -0700 (PDT) Subject: [sebhc] HDOS 2 boot problem identified. Message-ID: <200405251242.i4PCgp5X033092@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 13:01:45 -0000 Hi Steven, >Boy, you got a wierd one here! It did exactly the same for me using the >2.0 distribution disk (maybe thats what you were using). > >This isn't sensing behavior - that occurs before the first console I/O. The >sensing process is not only to detect baud rate (only on the 8250), but to >determine which port your console is connected to (it could be either on the >8251 at 370 or the 8250 at 350). If an 8250 is present, it would display >SPACE on the led's and wait for you to hit spaces on your console. I'm >guessing you don't currently emulate the 8250 so it went past that to the >"action?" prompt. > >I don't recall ever having any tech inquiries regarding this particular >hangup on real H8's. But I do know that the console gets re-initialized at >that point, because on my real H8 I have to manually turn on RTS then for my >serial connection to continue talking to it (proper RTS management was >obviously overlooked in the driver). > >So, just a guess at this point .. but take a look at how your emulation >handles re-initialzation of the chip after it's been in use. Particularly >in regard to interrupt handling. I have identified the problem - the HDOS 2 driver in high memory uses a software timeout based on the CPU speed while looking for sector holes - on a moderately fast PC, this loop breaks, and times out before sector holes are found. If you hit F9 while the boot is hung, you can step through the code and see where it is using BC as a timer while looking for the hold detect bit. Lots of console interrupts apparently slow it down enough that it sometimes passes the test - I think when the buffer is full, they are sitting in a polling loop while timing the beep - this takes a lot of time away from the hole detect loop - and it becomes slow enough not to time out. As a quick test, I implemented a manual setting for the CPU throttle, which allows me to set the speed of the emulated CPU - with it slowed down, HDOS 2 boots just fine! So - looks like I will have to implement the auto-calibration function to set the CPU speed when the emulator starts. Btw, my original implementation would not have broken in this case, since most of the disk timing is based on instruction cycles - however I had to specifically slow down the arrival of the next sector, because the H17 ROM "skip sector" function uses the PAM-8 500hz interrupt to time the holes - That one is basd on real-time in the emulator, because otherwise all the PAM-8 function run way to fast! 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 Tue May 25 08:07:46 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 06:07:46 -0700 (PDT) Subject: [sebhc] various topics Message-ID: <200405251307.i4PD7k9N033530@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 13:28:10 -0000 >P.S. Hey Dave .. now that you emulate H17's .. why not exchange the PAM8 >for PAM8GO (it's in the ROM section of the archives)? Whats 'PAM8GO' is his a PAM8 modified to automatically boot? I'm not real keen to replace the ROM image, because that would make it different from my real H8 - currently the emulator emulates my H8, although it adds a couple of extra cards (H17 and Memory). It is however still essentially the same machine. Changing the ROM would make it not representative of the H8 in my collection, which is my whole reason for doing the emulator. However: You can easily do it yourself. It may not be obvious, but the L= command line option can load code/data anywhere, even in ROM space. All you need to do to replace PAM8 with another image is: 1) Use my H8T utility to convert the ROM image to a .HEX download file (doesn't matter if it's Motorola or Intel) - I'm not sure about the H8T I currently have posted - my latest one recognizes ".ROM" as a binary file, however you might have to rename it to ".BIN" with the posted one. Also, don't forget to set the A= address to zero - so the output .HEX file will be origined at 0 - otherwise H8T assumes the default H8 run address of $2040 (040 100). 2) Use the L=filename option to load the ROM image when you launch H8. 3) If you want to make it "permanent", put the L= option in an H8.INI file located in emulator home directory. 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 CarrollWaddell at sc.rr.com Tue May 25 08:16:11 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Tue, 25 May 2004 09:16:11 -0400 Subject: [sebhc] My H8 Systems In-Reply-To: <200405250304.UAA18770@clulw009.amd.com> References: <200405250304.UAA18770@clulw009.amd.com> Message-ID: <40B3471B.7040500@sc.rr.com> Dwight, Thanks for this information. I purchased an H17 controller board, but the ROM and RAM chips are missing. Perhaps I won't need them to use it. Carroll Dwight K. Elvey wrote: >Hi > With all of the talk about H8's I decided this weekend >to actually power one up( I do have a working H89 ). I have two >of the H8's. One is the older type with the 8080 and the >other is the newer type with the Z80. I only brought up the >Z80 one. I used my variac and brought the voltage up slowly over >about 1 hour time. At first it was flakey. I removed the first >RAM card and switched the next to start at address 0. It then >booted fine. I gave the card a quick ohm meter check and there >didn't seem to be any issues with it. I reconfigured the >addresses back to the original and it was then working. It boots >to the monitor just fine. > I guess the connector needed a little wiping action. >I've not done much in the way of a RAM test yet. I'll most >likely write a 13n march for it. It has a H17 controller >so I can try booting a disk. I should note that the controller >has both the ROM and the two RAMs missing. I suspect that this >is what one does when there is the XCOM8 with a full 64K of RAM. > I have another controller board with the RAM and ROM. I expect >to run this on the 8080 machine. This box doesn't have a full complement >of RAM. It has only 4 8K boards installed but I have 3 other >8K boards ( one not fully populated ). The 8080 has the >combination cassette/serial board ( H8-5 ) while the Z80 machine >has the 4 port serial board ( H8-4 ). > I only have the one H17 drive box so I'll need to share that between >machines. I have a H19 but I'm not sure what its status is yet. > All good fun. >Dwight > > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 25 09:30:23 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 25 May 2004 09:30:23 -0500 Subject: [sebhc] HDOS 2 boot problem identified. In-Reply-To: <200405251242.i4PCgp5X033092@gatekeeper.evocative.com> Message-ID: <000001c44264$d13830e0$1f6fa8c0@eths.k12.il.us> Dave said: > I have identified the problem - the HDOS 2 driver in high > memory uses a software timeout based on the CPU speed while > looking for sector holes - on a moderately fast PC, this loop > breaks, and times out before sector holes are found. If you > hit F9 while the boot is hung, you can step through the code > and see where it is using BC as a timer while looking for the > hold detect bit. > This reminds me of another question I wanted to ask you earlier - I think when you first started the emulator you had a problem with the system looping off the top of the 8080 64K address space and coming back into the ROM at 0. Didn't you add a "control" to prevent that? By fixing that I think you've created a new device - an 8080 machine with 64K of ROM/RAM and the ability to run HDOS 1.6. I don't have the right combination of RAM cards and disks to test that in the real world right now, but my 1.6 system stopped booting when I took RAM to the top of the address space, though 2.0 runs fine in the same configuration. IIRC, 2.0 changed the test algorithm used by 1.6 to locate the top of memory before relocating itself to avoid this problem. Jack -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Tue May 25 09:35:55 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 25 May 2004 09:35:55 -0500 Subject: [sebhc] various topics In-Reply-To: <200405251307.i4PD7k9N033530@gatekeeper.evocative.com> Message-ID: <000101c44265$96be4ac0$1f6fa8c0@eths.k12.il.us> Neat - I'll give it a shot! How modular is the rest of the system? Can you load/unload various cards (e.g. memory, i/o)? Could you go so far as to emulate Carroll's system - an H17 controller with no ROM but XCON installed? Is there a "bus api" so that new interfaces can be prototyped? Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Dave Dunfield > Sent: Tuesday, May 25, 2004 8:08 AM > To: sebhc at sebhc.org > Subject: Re: [sebhc] various topics > > > >P.S. Hey Dave .. now that you emulate H17's .. why not exchange the > >PAM8 > >for PAM8GO (it's in the ROM section of the archives)? > > Whats 'PAM8GO' is his a PAM8 modified to automatically boot? > > I'm not real keen to replace the ROM image, because that > would make it different from my real H8 - currently the > emulator emulates my H8, although it adds a couple of extra > cards (H17 and Memory). It is however still essentially the > same machine. Changing the ROM would make it not > representative of the H8 in my collection, which is my whole > reason for doing the emulator. > > However: You can easily do it yourself. > > It may not be obvious, but the L= command line option can > load code/data anywhere, even in ROM space. All you need to > do to replace PAM8 with another image is: > > 1) Use my H8T utility to convert the ROM image to a .HEX > download file (doesn't > matter if it's Motorola or Intel) - I'm not sure about > the H8T I currently have > posted - my latest one recognizes ".ROM" as a binary > file, however you might > have to rename it to ".BIN" with the posted one. Also, > don't forget to set the > A= address to zero - so the output .HEX file will be > origined at 0 - otherwise > H8T assumes the default H8 run address of $2040 (040 100). > > 2) Use the L=filename option to load the ROM image when you > launch H8. > > 3) If you want to make it "permanent", put the L= option in > an H8.INI file > located in emulator home directory. > > 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 dave04a at dunfield.com Tue May 25 09:47:50 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 07:47:50 -0700 (PDT) Subject: [sebhc] various topics Message-ID: <200405251447.i4PElohM034938@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 14:58:42 -0000 >However: You can easily do it yourself. > >It may not be obvious, but the L= command line option can load code/data anywhere, >even in ROM space. All you need to do to replace PAM8 with another image is: Sorry - I just realized that I never rearrange the code to allow this (had planned to) - currently the PAM-8 and H17 images get loaded into the 8080 address space AFTER user files are loaded, which means that they cannot be replaced - I have changed this, and the next version of the emulator will allow the ROMs to be replaced. 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 jack.rubin at ameritech.net Tue May 25 09:48:12 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Tue, 25 May 2004 09:48:12 -0500 Subject: [sebhc] other image formats In-Reply-To: Message-ID: <000001c44267$4e696050$1f6fa8c0@eths.k12.il.us> > > Jack says: > >>Additions? Corrections? > >how about the H67 - 10 mb hard drive, > > I don't think this was ever a software distribution format! I don't see any reason to be limited to historical formats. It would be very useful to create a "partition" based on contents such as editor, assembler, linker, debugger, etc. as a single image that wouldn't necessarily conform to an existing media size. I'm looking forward to (new) mass storage devices supported via a true HDOS driver that could directly mount such images. In the case of such an image, size would not be predetermined and some sort of header would be necessary. Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 25 11:33:46 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 16:33:46 +0000 Subject: [sebhc] Emulator evolution Message-ID: >I have identified the problem - the HDOS 2 driver in high memory uses a >software >timeout based on the CPU speed while looking for sector holes How rude! :-) This appears to be a new function Greg added when creating the modular driver (the modular drivers are being loaded at that point in the boot - thus the console re-init also). I wonder if another fix for this would be to just change SY.DVD. I see in the source where the routine "SYREDY" is checking for a full rotation (12 holes) to occur in a specific time. It would be easy to make it clock-based instead of count-based. Another cool driver mod would be to lower the step time minimum to 0 and make motor delay also settable to 0. >So - looks like I will have to implement the auto-calibration function to >set the CPU speed when the emulator starts. Darn. It's nice having an extra-fast H8. :-) Maybe that could be switchable, so you could turn on "max speed" after boot, or start up that way if your disk image has the new driver? >Whats 'PAM8GO' is his a PAM8 modified to automatically boot? Not quite. It's a one-button boot. The only difference between PAM8 and PAM8GO is that after reset, the latter presets the value of PC to 030.000. So just hitting the "go" button (thus the name) causes it to boot. Actual autoboot was first available on the HA-8-6 (Z80) cpu as a switch-selectable option. >I'm not real keen to replace the ROM image, because that would make it >different >from my real H8 You could burn one for your H8. :-) >It may not be obvious, but the L= command line option can load code/data >anywhere, even in ROM space. That works too! I wonder if you'd be willing to do one thing in your emulator that would diverge from reality? Add a stub so that a device driver could get access to files in a specific folder on the PC. This would effectively create a virtual HD on the PC. What do you think? :-) Cheers, - Steven _________________________________________________________________ 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 sp11 at hotmail.com Tue May 25 12:16:12 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 17:16:12 +0000 Subject: [sebhc] other image formats Message-ID: Jack says: > > >>Additions? Corrections? > > >how about the H67 - 10 mb hard drive, > > I don't think this was ever a software distribution format! >I don't see any reason to be limited to historical formats. But.... I was asking for a list of historical formats! :-) Ones actually used to distribute software. >I'm looking forward to >(new) mass storage devices supported via a true HDOS driver that could >directly mount such images. Do you mean from a PC? If so, why not build the driver so that it accesses PC files directly? That would greatly simplify both the driver and file sharing. You not only eliminate size limits, but also any dependency on defined formats. Cheers, - Steven _________________________________________________________________ Watch LIVE baseball games on your computer with MLB.TV, included with MSN Premium! http://join.msn.click-url.com/go/onm00200439ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Tue May 25 13:07:57 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 11:07:57 -0700 (PDT) Subject: [sebhc] Emulator evolution (& new download avail) Message-ID: <200405251807.i4PI7vIt016706@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 18:25:59 -0000 >How rude! :-) Yeah - I though so! >>So - looks like I will have to implement the auto-calibration function to >>set the CPU speed when the emulator starts. > >Darn. It's nice having an extra-fast H8. :-) Maybe that could be >switchable, so you could turn on "max speed" after boot, or start up that >way if your disk image has the new driver? I have decided to completely change the way I do my clock simulation - instead of letting the 8080 run "wild" and regulating the frequency of interrupts to approximate real time, I now generate the clock interrupts based on the number of 8080 instructions executed, and now I regulate the speed of the 8080 to approximate real time. This has a distinct advantage that the virtual envuironment always sees correct "real time", even if this has nothing to do with the outside world. Thus you can speed up or slow down the entire system (I have also provided a performance tuning parameters to let you adjust the interrupt frequency relative to the simulated CPU speed so you can basically tweak it any way you like). I have uploaded a new version of the simulator to: http://www.dunfield.com/pub/H8H17.ZIP This version will self-calibrate to a reasonable CPU speed - see the HELP info. for details on the new options. This version boots HDOS 2.0 with no trouble. To test the speed regulator, I ran it on a 286 - it took a while, but HDOS booted just fine. Btw1: if you want to see a FAST H8, try: H8 XS=0 XT=0 ... Btw2: I notice that the HDOS 1.6 disk contains text to the effect that it has a special driver for the Macintosh emulator? - do anyone know what this is about? >>It may not be obvious, but the L= command line option can load code/data >>anywhere, even in ROM space. > >That works too! This new version has this fixed so that it does work - you can use L= to load your own ROM. I have also included my latest H8T in the ZIP. >I wonder if you'd be willing to do one thing in your emulator that would >diverge from reality? Add a stub so that a device driver could get access >to files in a specific folder on the PC. This would effectively create a >virtual HD on the PC. What do you think? :-) Does HDOS support the concept of accessing files on a device (not through the HDOS filesystem?) - this would be similar to the redirector support in DOS, and I would be suprised of HDOS had this. Otherwise HDOS will want to read and write directory entries, allocation blocks etc. from the device. If your goal is to move files in and out of the HDOS disk images, then why not write a utility like my ADI that I include with the Altair simulator to read and write files from the PC into/outof a disk image. Is there clear documentation available on the format of an HDOS disk image? (I can guess the answer to that one). I have to be careful --- too many more features, and the emulator will grow out of TINY model! 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 Tue May 25 14:05:08 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 25 May 2004 12:05:08 -0700 (PDT) Subject: [sebhc] HDOS 2 boot problem identified. Message-ID: <200405251905.MAA19419@clulw009.amd.com> >From: "Dave Dunfield" > >Hi Steven, > >>Boy, you got a wierd one here! It did exactly the same for me using the >>2.0 distribution disk (maybe thats what you were using). >> >>This isn't sensing behavior - that occurs before the first console I/O. The >>sensing process is not only to detect baud rate (only on the 8250), but to >>determine which port your console is connected to (it could be either on the >>8251 at 370 or the 8250 at 350). If an 8250 is present, it would display >>SPACE on the led's and wait for you to hit spaces on your console. I'm >>guessing you don't currently emulate the 8250 so it went past that to the >>"action?" prompt. >> >>I don't recall ever having any tech inquiries regarding this particular >>hangup on real H8's. But I do know that the console gets re-initialized at >>that point, because on my real H8 I have to manually turn on RTS then for my >>serial connection to continue talking to it (proper RTS management was >>obviously overlooked in the driver). >> >>So, just a guess at this point .. but take a look at how your emulation >>handles re-initialzation of the chip after it's been in use. Particularly >>in regard to interrupt handling. > >I have identified the problem - the HDOS 2 driver in high memory uses a software >timeout based on the CPU speed while looking for sector holes - on a moderately >fast PC, this loop breaks, and times out before sector holes are found. If you >hit F9 while the boot is hung, you can step through the code and see where it >is using BC as a timer while looking for the hold detect bit. > ---snip--- Hi Dave It would seem that if you want to get things working right, you need to make index holes appear to your emulator, based on the instruction cycles executed. There are two possible choices here. You can attempt to add each instruction cycle time exactly or you can simply average the instruction count. I don't recall there being wait states on things but I don't think it would be an issue. Emulating the index holes and the 2 ms interrupt based on instruction count would mean that the emulator should work for all disk without any code modifications. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Tue May 25 14:15:20 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 25 May 2004 12:15:20 -0700 (PDT) Subject: [sebhc] Emulator evolution (& new download avail) Message-ID: <200405251915.MAA19426@clulw009.amd.com> >From: "Dave Dunfield" > >>How rude! :-) > >Yeah - I though so! > >>>So - looks like I will have to implement the auto-calibration function to >>>set the CPU speed when the emulator starts. >> >>Darn. It's nice having an extra-fast H8. :-) Maybe that could be >>switchable, so you could turn on "max speed" after boot, or start up that >>way if your disk image has the new driver? > >I have decided to completely change the way I do my clock simulation - instead >of letting the 8080 run "wild" and regulating the frequency of interrupts to >approximate real time, I now generate the clock interrupts based on the number >of 8080 instructions executed, and now I regulate the speed of the 8080 to >approximate real time. Hi I see you stole my thoughts before I entered them. One thing you might look into is being able to change the 2ms interrupt back to a true 2ms for code running in different areas of memory. This might be useful for games and such. It is a pain that the disk I/O uses both timer delays and code execution delays. Dwight > >This has a distinct advantage that the virtual envuironment always sees correct >"real time", even if this has nothing to do with the outside world. Thus you >can speed up or slow down the entire system (I have also provided a performance >tuning parameters to let you adjust the interrupt frequency relative to the >simulated CPU speed so you can basically tweak it any way you like). > >I have uploaded a new version of the simulator to: > http://www.dunfield.com/pub/H8H17.ZIP > >This version will self-calibrate to a reasonable CPU speed - see the HELP info. >for details on the new options. > >This version boots HDOS 2.0 with no trouble. To test the speed regulator, I >ran it on a 286 - it took a while, but HDOS booted just fine. > >Btw1: if you want to see a FAST H8, try: H8 XS=0 XT=0 ... > >Btw2: I notice that the HDOS 1.6 disk contains text to the effect that it has a > special driver for the Macintosh emulator? - do anyone know what this is > about? > > >>>It may not be obvious, but the L= command line option can load code/data >>>anywhere, even in ROM space. >> >>That works too! > >This new version has this fixed so that it does work - you can use L= >to load your own ROM. I have also included my latest H8T in the ZIP. > > >>I wonder if you'd be willing to do one thing in your emulator that would >>diverge from reality? Add a stub so that a device driver could get access >>to files in a specific folder on the PC. This would effectively create a >>virtual HD on the PC. What do you think? :-) > >Does HDOS support the concept of accessing files on a device (not through >the HDOS filesystem?) - this would be similar to the redirector support in >DOS, and I would be suprised of HDOS had this. Otherwise HDOS will want to >read and write directory entries, allocation blocks etc. from the device. > >If your goal is to move files in and out of the HDOS disk images, then why not >write a utility like my ADI that I include with the Altair simulator to read >and write files from the PC into/outof a disk image. > >Is there clear documentation available on the format of an HDOS disk image? >(I can guess the answer to that one). > >I have to be careful --- too many more features, and the emulator will grow >out of TINY model! > >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 dave04a at dunfield.com Tue May 25 14:23:02 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 12:23:02 -0700 (PDT) Subject: [sebhc] HDOS 2 boot problem identified. Message-ID: <200405251923.i4PJMxmb018017@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 19:48:14 -0000 >Hi Dave > It would seem that if you want to get things working right, you >need to make index holes appear to your emulator, based on the >instruction cycles executed. There are two possible choices here. >You can attempt to add each instruction cycle time exactly >or you can simply average the instruction count. I don't recall >there being wait states on things but I don't think it would be >an issue. > Emulating the index holes and the 2 ms interrupt based on instruction >count would mean that the emulator should work for all disk without >any code modifications. >Dwight Hi Dwight, Thats exactly what I did - it's already posted at: http://www.dunfield.com/pub/H8H17.ZIP If you want to try it out. It works not no matter what the actual speed of the virtual 8080 is. I have now fully implemented the CPU throttle, so that it runs at a reasonable speed by default, however you can now disengage the throttle at let the H8 run like a bat out of H*** and everything still works - however PAM-8 can get a bit "fast" with its clock interrupt speeded up - (Interesting multiplexing effect on the rotating dots - at certain speeds they appeare to go backwards!) 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 Tue May 25 14:36:45 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 25 May 2004 12:36:45 -0700 (PDT) Subject: [sebhc] My H8 Systems Message-ID: <200405251936.MAA19452@clulw009.amd.com> Hi Carroll I was just looking at the pdf for the HA-8-6 Z80. It describes using the controller card without the ROM and the modifications needed. It says that this allows the use of CP/M with this setup since the ROM's are copied to RAM and then run from RAM. It mentions that it only works with 2.0 HDOS and above. Anyway, take a look at the pdf from the web site. Dwight >From: "Carroll Waddell" > >Dwight, >Thanks for this information. I purchased an H17 controller board, but >the ROM and RAM chips are missing. Perhaps I won't need them to use it. >Carroll > >Dwight K. Elvey wrote: > >>Hi >> With all of the talk about H8's I decided this weekend >>to actually power one up( I do have a working H89 ). I have two >>of the H8's. One is the older type with the 8080 and the >>other is the newer type with the Z80. I only brought up the >>Z80 one. I used my variac and brought the voltage up slowly over >>about 1 hour time. At first it was flakey. I removed the first >>RAM card and switched the next to start at address 0. It then >>booted fine. I gave the card a quick ohm meter check and there >>didn't seem to be any issues with it. I reconfigured the >>addresses back to the original and it was then working. It boots >>to the monitor just fine. >> I guess the connector needed a little wiping action. >>I've not done much in the way of a RAM test yet. I'll most >>likely write a 13n march for it. It has a H17 controller >>so I can try booting a disk. I should note that the controller >>has both the ROM and the two RAMs missing. I suspect that this >>is what one does when there is the XCOM8 with a full 64K of RAM. >> I have another controller board with the RAM and ROM. I expect >>to run this on the 8080 machine. This box doesn't have a full complement >>of RAM. It has only 4 8K boards installed but I have 3 other >>8K boards ( one not fully populated ). The 8080 has the >>combination cassette/serial board ( H8-5 ) while the Z80 machine >>has the 4 port serial board ( H8-4 ). >> I only have the one H17 drive box so I'll need to share that between >>machines. I have a H19 but I'm not sure what its status is yet. >> All good fun. >>Dwight >> >> >>-- >>Delivered by the SEBHC Mailing List >> >> >> > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 25 15:54:02 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 20:54:02 +0000 Subject: [sebhc] Emulator timing Message-ID: >I have now fully implemented the CPU throttle, >so that it runs at a reasonable speed by default, however you can now >disengage the throttle at let the H8 run like a bat out of H*** and >everything still works - however PAM-8 can get a bit "fast" with its >clock interrupt speeded up - (Interesting multiplexing effect on the >rotating dots - at certain speeds they appeare to go backwards!) Would it be reasonable to have three modes: 1. your existing instruction (and clock) throttle 2. accurate clock interrupts but unthrottled instructions <--(new) 3. "bat out of H***" mode (nothing throttled) _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 25 16:02:59 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 21:02:59 +0000 Subject: [sebhc] available disk images Message-ID: >Btw2: I notice that the HDOS 1.6 disk contains text to the effect that it >has a > special driver for the Macintosh emulator? - do anyone know what >this is > about? I still haven't found my original 1.6 distribution disk, so for the moment I posted the one that was packaged with Dave Shaw's emulator. I don't know what's different besides the label. Anyone got a real 1.6 dist to upload? Any other distribution s/w that's not in the archives yet? (I'm still looking for a "TMI loader" package and "chase leds"). It's fun running adventure on my PC ... :-) _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Tue May 25 16:10:59 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 25 May 2004 14:10:59 -0700 (PDT) Subject: [sebhc] available disk images Message-ID: <200405252110.OAA19512@clulw009.amd.com> Hi Steven I have a disk that boots to 1.6 but I don't think it is a distribution disk. It is the only one like this I have. I can send you a copy. The web page lets me into everything except the uploads dirctory. It is a raw image file. Dwight >From: "Steven Parker" > >>Btw2: I notice that the HDOS 1.6 disk contains text to the effect that it >>has a >> special driver for the Macintosh emulator? - do anyone know what >>this is >> about? > >I still haven't found my original 1.6 distribution disk, so for the moment I >posted the one that was packaged with Dave Shaw's emulator. I don't know >what's different besides the label. > >Anyone got a real 1.6 dist to upload? Any other distribution s/w that's not >in the archives yet? (I'm still looking for a "TMI loader" package and >"chase leds"). > >It's fun running adventure on my PC ... :-) -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 25 16:39:09 2004 From: sp11 at hotmail.com (Steven Parker) Date: Tue, 25 May 2004 21:39:09 +0000 Subject: [sebhc] uploading Message-ID: >The web page lets me into everything >except the uploads dirctory. Oh. Hmm.. You have to use FTP for uploads. Okay, I fixed the web interface so it will take you to the ftp for uploading. However, it breaks when I first click on it .. but comes up okay if I refresh at that point! (so I added a comment in case it does the same for you). Beats me why it would fail the first time but reliably come up on a refresh! Cheers, - Steven _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Tue May 25 18:33:11 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 16:33:11 -0700 (PDT) Subject: [sebhc] Emulator timing Message-ID: <200405252333.i4PNXBAp000930@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 25 May 2004 23:45:37 -0000 Hi Steven, >Would it be reasonable to have three modes: > >1. your existing instruction (and clock) throttle >2. accurate clock interrupts but unthrottled instructions <--(new) >3. "bat out of H***" mode (nothing throttled) I'll think about it, however I really don't want to mess with the throttle system any more right now - you have to understand that almost every "dos compatible" environment supports the 55ms clock tick, however changing the interval is an entirely different matter, so to maintain the widest compatibility, I use only the 55ms tick as my "hard real time indicator" Everything else is extrapolation done by the emulator, and it's a real pain in the a** to get it right. Mode 1 is currently implemented. Mode 2 is also currently implemented, just set the option XS=0 to tell the emulator that you do not want any speed throttling - in this case, the clock interrupts will occur every 1000 instructions, unless you specify a different inteval with XI= -- this means that all of the software sees a "reasonable" real-time environment, but on a fast machine, it may seem to the outside observer to be happening at a rather quick pace - on my P3/733 I get in the order of 18,000 interrupts/second - thats right, about 18mips from the virtual 8080 CPU. Mode 3 can be accomplished with XS=0, and choosing a value for XI= which gives the desired interrupt rate - on my system, an interval just under 40,000 instructions per interrupt gives me a fairly nice 500hz tick. - This will take some experimentation. - NOTE that you cannot boot HDOS 2.0 in this mode due to the software timing loops. Under pure DOS this is very stable - under winblows or any other multitasking system, it will drift if you have background activity. When the throttle is engaged it will automatically self-calibrate and maintain reasonable accuracy even when system performance drifts. For reasons of controlling overflow conditions, I set the limit that you can specify with XS= to 9999 (x1000 = 10mips) If your system is fast enough, why not just use this value in Mode 1 which allows the throttle to automatically maintain a 500hz clock - is a 10mip 8080 not fast enough? If you want to fool around with the interrupt rate - I have just uploaded a updated improved version of the emulator (same location) which outputs more debug information when you press Control-HOME. Most of this will be meangless to anyone but me :-), however the second line "I:", last entry "F=" gives the actual frequency of clock interrupts being generated on the virtual machine. 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 Tue May 25 18:58:08 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Tue, 25 May 2004 16:58:08 -0700 (PDT) Subject: [sebhc] available disk images Message-ID: <200405252358.i4PNw8EM001279@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 26 May 2004 00:10:25 -0000 At 21:02 25/05/2004 +0000, you wrote: >>Btw2: I notice that the HDOS 1.6 disk contains text to the effect that it >>has a >> special driver for the Macintosh emulator? - do anyone know what >>this is >> about? > >I still haven't found my original 1.6 distribution disk, so for the moment I >posted the one that was packaged with Dave Shaw's emulator. I don't know >what's different besides the label. There are several places where the image contains text indicating that it has special drivers for the MAC emulator.. Most of the text seems to be referring to an AT: driver and an LP: driver. Here are a couple of examples: 00A020: 34DA8923 CDEC3D11 2F3F21CD 5E190A48 [4..#..=./?!.^..H] 00A030: 3820456D 756C6174 6F722041 543A2044 [8 Emulator AT: D] 00A040: 72697665 72207631 2E310A62 79204461 [river v1.1.by Da] 00A050: 76696420 412E2053 6861770A 0A536574 [vid A. Shaw..Set] 00A060: 204F7074 696F6E73 3A0A0A54 68657265 [ Options:..There] 00A070: 20415245 206E6F20 73657420 6F707469 [ ARE no set opti] 00A080: 6F6E7321 0A0A5468 69732064 72697665 [ons!..This drive] 00A090: 72207761 73207370 65636966 6963616C [r was specifical] 00A0A0: 6C792077 72697474 656E2074 6F20776F [ly written to wo] 00A0B0: 726B2077 6974680A 74686520 4D616369 [rk with.the Maci] 00A0C0: 6E746F73 68204838 20456D75 6C61746F [ntosh H8 Emulato] 00A0D0: 722E2054 68657265 20617265 206E6F20 [r. There are no ] 00A0E0: 6F707469 6F6E730A 74686174 20796F75 [options.that you] 00A0F0: 2063616E 20736574 20617420 74686520 [ can set at the ] 00A100: 64726976 6572206C 6576656C 2E0A8AB7 [driver level....] 00A820: 34DA8923 CDEC3D11 2F3F21CD 5E190A48 [4..#..=./?!.^..H] 00A830: 3820456D 756C6174 6F72204C 503A2044 [8 Emulator LP: D] 00A840: 72697665 72207631 2E300A62 79204461 [river v1.0.by Da] 00A850: 76696420 412E2053 6861770A 0A536574 [vid A. Shaw..Set] 00A860: 204F7074 696F6E73 3A0A0A54 68657265 [ Options:..There] 00A870: 20415245 206E6F20 73657420 6F707469 [ ARE no set opti] 00A880: 6F6E7321 0A0A5468 69732064 72697665 [ons!..This drive] 00A890: 72207761 73207370 65636966 6963616C [r was specifical] 00A8A0: 6C792077 72697474 656E2074 6F20776F [ly written to wo] 00A8B0: 726B2077 6974680A 74686520 4D616369 [rk with.the Maci] 00A8C0: 6E746F73 68204838 20456D75 6C61746F [ntosh H8 Emulato] 00A8D0: 722E2054 68657265 20617265 206E6F20 [r. There are no ] 00A8E0: 6F707469 6F6E730A 74686174 20796F75 [options.that you] 00A8F0: 2063616E 20736574 20617420 74686520 [ can set at the ] 00A900: 64726976 6572206C 6576656C 2E0A8AB7 [driver level....] >Anyone got a real 1.6 dist to upload? Any other distribution s/w that's not >in the archives yet? (I'm still looking for a "TMI loader" package and >"chase leds"). I would very much like to get original disk images for any and all HDOS versions which were available. >It's fun running adventure on my PC ... :-) Is this in the archive? 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 Tue May 25 19:04:49 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Tue, 25 May 2004 17:04:49 -0700 (PDT) Subject: [sebhc] available disk images Message-ID: <200405260004.RAA19667@clulw009.amd.com> Hi Dave There was one thing I remember. Many of the Heath printers had an inverted status signal from what everyone else had. I recall patching the software to solve this. One has to remember, I did this years ago so I don't even remember where or how this was done. I just remember how frustrated I was that their printer drivers couldn't be generally used for generic serial printers. I suspect it was some sales guy that thought it was clever. They did have examples of their drivers so one could write their own. Dwight >From: "Dave Dunfield" > >At 21:02 25/05/2004 +0000, you wrote: >>>Btw2: I notice that the HDOS 1.6 disk contains text to the effect that it >>>has a >>> special driver for the Macintosh emulator? - do anyone know what >>>this is >>> about? >> >>I still haven't found my original 1.6 distribution disk, so for the moment I >>posted the one that was packaged with Dave Shaw's emulator. I don't know >>what's different besides the label. > >There are several places where the image contains text indicating that it has >special drivers for the MAC emulator.. Most of the text seems to be referring >to an AT: driver and an LP: driver. Here are a couple of examples: > >00A020: 34DA8923 CDEC3D11 2F3F21CD 5E190A48 [4..#..=./?!.^..H] >00A030: 3820456D 756C6174 6F722041 543A2044 [8 Emulator AT: D] >00A040: 72697665 72207631 2E310A62 79204461 [river v1.1.by Da] >00A050: 76696420 412E2053 6861770A 0A536574 [vid A. Shaw..Set] >00A060: 204F7074 696F6E73 3A0A0A54 68657265 [ Options:..There] >00A070: 20415245 206E6F20 73657420 6F707469 [ ARE no set opti] >00A080: 6F6E7321 0A0A5468 69732064 72697665 [ons!..This drive] >00A090: 72207761 73207370 65636966 6963616C [r was specifical] >00A0A0: 6C792077 72697474 656E2074 6F20776F [ly written to wo] >00A0B0: 726B2077 6974680A 74686520 4D616369 [rk with.the Maci] >00A0C0: 6E746F73 68204838 20456D75 6C61746F [ntosh H8 Emulato] >00A0D0: 722E2054 68657265 20617265 206E6F20 [r. There are no ] >00A0E0: 6F707469 6F6E730A 74686174 20796F75 [options.that you] >00A0F0: 2063616E 20736574 20617420 74686520 [ can set at the ] >00A100: 64726976 6572206C 6576656C 2E0A8AB7 [driver level....] > >00A820: 34DA8923 CDEC3D11 2F3F21CD 5E190A48 [4..#..=./?!.^..H] >00A830: 3820456D 756C6174 6F72204C 503A2044 [8 Emulator LP: D] >00A840: 72697665 72207631 2E300A62 79204461 [river v1.0.by Da] >00A850: 76696420 412E2053 6861770A 0A536574 [vid A. Shaw..Set] >00A860: 204F7074 696F6E73 3A0A0A54 68657265 [ Options:..There] >00A870: 20415245 206E6F20 73657420 6F707469 [ ARE no set opti] >00A880: 6F6E7321 0A0A5468 69732064 72697665 [ons!..This drive] >00A890: 72207761 73207370 65636966 6963616C [r was specifical] >00A8A0: 6C792077 72697474 656E2074 6F20776F [ly written to wo] >00A8B0: 726B2077 6974680A 74686520 4D616369 [rk with.the Maci] >00A8C0: 6E746F73 68204838 20456D75 6C61746F [ntosh H8 Emulato] >00A8D0: 722E2054 68657265 20617265 206E6F20 [r. There are no ] >00A8E0: 6F707469 6F6E730A 74686174 20796F75 [options.that you] >00A8F0: 2063616E 20736574 20617420 74686520 [ can set at the ] >00A900: 64726976 6572206C 6576656C 2E0A8AB7 [driver level....] > >>Anyone got a real 1.6 dist to upload? Any other distribution s/w that's not >>in the archives yet? (I'm still looking for a "TMI loader" package and >>"chase leds"). > >I would very much like to get original disk images for any and all HDOS >versions which were available. > > >>It's fun running adventure on my PC ... :-) > >Is this in the archive? > >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 sp11 at hotmail.com Tue May 25 19:37:15 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 26 May 2004 00:37:15 +0000 Subject: [sebhc] available disk images Message-ID: >There are several places where the image contains text indicating that it >has >special drivers for the MAC emulator.. As soon as someone uploads a prstine dist image (or I find mine) we'll replace that one. >I would very much like to get original disk images for any and all HDOS >versions which were available. I was hoping for a complete collection of ALL software distributions for the H8. :-) The HDOS 2.0 I uploaded is issue #50.06.00 - but I notice one of the documents mentions a 50.07.00. Does anyone know what the LAST issue number of HDOS was? Got a copy? > >It's fun running adventure on my PC ... :-) >Is this in the archive? You bet. It's software/disk-images/HUG/885-1010_Adventure.h8d, one of several HUG distributions Jack diskdump'ed for us (and I converted to image). We still only have a fraction of the HUG catalog, though. Speaking of which, I uploaded a HUG catalog (documents/software/HUG/hug-catalog.txt) that I created from two sources. But I'm sure it's still not comprehensive. Anyone have info on other HUG offerings that aren't listed in there? (or better yet .. the disks?) Cheers, - Steven _________________________________________________________________ Get 200+ ad-free, high-fidelity stations and LIVE Major League Baseball Gameday Audio! http://radio.msn.click-url.com/go/onm00200491ave/direct/01/ -- Delivered by the SEBHC Mailing List From eric at rothfus.com Tue May 25 20:19:38 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Tue, 25 May 2004 21:19:38 -0400 Subject: [sebhc] H88 WD 1797 Controller Chip Datasheet References: Message-ID: <1085448487@rothfus.com> Anyone have one? Or have a pointer to it? I've looked, and I've looked, but I can't find it anywhere! BTW, finally took the time to fire-up "dosemu" on my Linux (Mandrake 8.0) box. It is quite cool to see the emulator up and running. Nice work Dave! Eric -- Delivered by the SEBHC Mailing List From uban at ubanproductions.com Tue May 25 21:00:44 2004 From: uban at ubanproductions.com (Tom Uban) Date: Tue, 25 May 2004 21:00:44 -0500 Subject: [sebhc] H88 WD 1797 Controller Chip Datasheet In-Reply-To: <1085448487@rothfus.com> References: Message-ID: <5.2.0.9.0.20040525205948.0336bcb0@mail.ubanproductions.com> It will be in one of these: www.bitsavers.org/pdf/westernDigital/_dataBooks --tom At 09:19 PM 5/25/2004 -0400, you wrote: >Anyone have one? Or have a pointer to it? >I've looked, and I've looked, but I can't >find it anywhere! > >BTW, finally took the time to fire-up "dosemu" >on my Linux (Mandrake 8.0) box. It is quite >cool to see the emulator up and running. Nice >work Dave! > >Eric > >-- >Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Tue May 25 21:31:26 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 26 May 2004 02:31:26 +0000 Subject: [sebhc] archive addition Message-ID: I added pam8go.hex to the archives under software/ROMs. It works great on the emulator with the L=pam8go.hex option! _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Wed May 26 00:08:31 2004 From: leeahart at earthlink.net (Lee Hart) Date: Tue, 25 May 2004 22:08:31 -0700 Subject: [sebhc] H88 WD 1797 Controller Chip Datasheet References: <1085448487@rothfus.com> Message-ID: <40B4264F.503@earthlink.net> Eric J. Rothfus wrote: > Anyone have one? Or have a pointer to it? > I've looked, and I've looked, but I can't > find it anywhere! What do you need? The datasheet, or the chip itself? -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From eric at rothfus.com Wed May 26 07:03:37 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Wed, 26 May 2004 08:03:37 -0400 Subject: [sebhc] H88 WD 1797 Controller Chip Datasheet In-Reply-To: <40B4264F.503@earthlink.net> (message from Lee Hart on Tue, 25 May 2004 22:08:31 -0700) References: <1085448487@rothfus.com> <40B4264F.503@earthlink.net> Message-ID: <1085534941@rothfus.com> > What do you need? The datasheet, or the chip itself? I just needed the datasheet. In a previous message, Tom sent: > It will be in one of these: > > www.bitsavers.org/pdf/westernDigital/_dataBooks > > --tom And indeed it was, along with all of the other WD controllers! Thanks, Eric -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed May 26 08:43:35 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 26 May 2004 06:43:35 -0700 (PDT) Subject: [sebhc] Emulator future? Message-ID: <200405261343.i4QDhZ4t014089@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 26 May 2004 14:01:19 -0000 NOTE: I discovered that in the last couple of versions I posted, I had trashed the context sensitive help indexs ... so when you are in various debugger functions the help that pops up has nothing to do with where you are ... This has been fixed, and posted to: htttp://www.dunfield.com/pub/H8.ZIP Note that I have changed the name back to H8.ZIP - I am no longer maintaining a diskless version of the emulator. ---- With this release of the H8 emulator, I am officially "slowing down" the development - I need to get back to some other projects, however development will probably still continue at a pretty good pace - just don't expect daily updates like you have seen in the past week :-) Jack: Would you update the archive version from the file above and remove any old ones. ---- So --- Where does everyone want the emulator to go from here? What changes and enhancements are desired? Here are a few I can think of: - H19 terminal emulation - Ability to redirect H8 serial ports to PC serial ports. - Additional disk controllers. - Ability to write-protect blocks in the expansion range so that you can truly simulate additional ROMs (currently, you can load them, but they can be overwritten by the application code). - Ability to load I/O port handlers, so that you can install your own virtual hardware in the H8 (for an example of this, look at my EMILY52 8051/80522 simulator). Anyone have anything else to add? Once we get a complete list, I will need votes on the priority of the items, so that I can undertake them in turn. Any other thoughts & ideas (now is the time)? 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 May 26 10:40:27 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 26 May 2004 15:40:27 +0000 Subject: [sebhc] Emulator future? Message-ID: Dave asks: > What changes and enhancements are desired? >- Additional disk controllers. My top choice would be the "fantasy" controller that reads/writes PC files in a "mounted" folder. >Anyone have anything else to add? Two optional configurations (both support 0-org memory and dynamic rom enable-disable): The ability to have an HA-8-8 extended configuration "board" (with associated mods). The ability to have an HA-8-6 (z80) CPU board. Also, think I found another bug .. with the /I option, I was expecting it to act like a real H8. But when I tried the H17-rom memory test, (pc=030.003, hit go twice) it threw me into the debugger when it encountered the HLT rather than just returning to panel monitor mode and waiting on the 2nd press of "go". And... it was not possible to continue by hitting 'enter', since the monitor never got a chance to advance the PC. Actually, perhaps it should not even require /I for this to work right.. as "hlt" is a defined opcode. Anyway .. great job, no matter how much further it goes or not! Cheers, - Steven _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed May 26 11:13:40 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 26 May 2004 09:13:40 -0700 (PDT) Subject: [sebhc] Emulator future? Message-ID: <200405261613.i4QGDeNl016248@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 26 May 2004 16:30:58 -0000 >> What changes and enhancements are desired? >>- Additional disk controllers. > >My top choice would be the "fantasy" controller that reads/writes PC files >in a "mounted" folder. I'm still waiting on your answer on HDOS's ability to support a network (ie foreign) file system. Without this ability, what you are requesting is very difficult (you have to present a valid filesystem to HDOS, meaning you have to "lay out" the PC files into a virtual disk, and maintain translation back and forth - ugh!) >Two optional configurations (both support 0-org memory and dynamic rom >enable-disable): >The ability to have an HA-8-8 extended configuration "board" (with >associated mods). What does this do? >The ability to have an HA-8-6 (z80) CPU board. Perhaps someday - thats a major change, mostly to the debugger. >Also, think I found another bug .. with the /I option, I was expecting it >to act like a real H8. But when I tried the H17-rom memory test, >(pc=030.003, hit go twice) it threw me into the debugger when it encountered >the HLT rather than just returning to panel monitor mode and waiting on the >2nd press of "go". And... it was not possible to continue by hitting >'enter', since the monitor never got a chance to advance the PC. Actually, >perhaps it should not even require /I for this to work right.. as "hlt" is a >defined opcode. This has nothing to do with /I - the emulators response to the virtual CPU executing HLT is to trap to the debugger. If you want to proceed with the next instruction after the HLT, you can manually increment the PC with the register editor and then hit ENTER (run). I'm not sure how this is supposed to work - normally, if you HLT an 8080 with interrupts disabled, it never starts again (short of a reset). If you HLT it with interrupts enabled, it will wake up to service the interrupt and then proceed on it's merry way (still in the application). So as far as I can see, executing HLT would simply wait for the next clock interrupt and then proceed "where it is" --- how does it get back to PAM-8? 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 leeahart at earthlink.net Wed May 26 13:18:52 2004 From: leeahart at earthlink.net (Lee Hart) Date: Wed, 26 May 2004 11:18:52 -0700 Subject: [sebhc] Emulator future? References: Message-ID: <40B4DF8C.67B3@earthlink.net> Steven Parker wrote: > > Dave asks: > > What changes and enhancements are desired? > >- Additional disk controllers. > > My top choice would be the "fantasy" controller that reads/writes PC files > in a "mounted" folder. Peter Shkabara's "CPC" program provides this capability with the H8-37 or Z89-37 soft-sector controllers. Running CP/M, it lets you configure one of your 5.25" floppies as a PC-DOS format drive, so you could read, write, and format PC disks on your H8 or H89. I have a copy, and still use it occasionally. Since I don't have a PC with 5.25" drives any more, my H89 with CPC is the only way I can read such disks! -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From leeahart at earthlink.net Wed May 26 13:27:56 2004 From: leeahart at earthlink.net (Lee Hart) Date: Wed, 26 May 2004 11:27:56 -0700 Subject: [sebhc] Emulator future? References: <200405261613.i4QGDeNl016248@gatekeeper.evocative.com> Message-ID: <40B4E1AC.3F2B@earthlink.net> Dave Dunfield wrote: > I'm still waiting on your answer on HDOS's ability to support a > network (ie foreign) file system. Without this ability, what you > are requesting is very difficult (you have to present a valid > filesystem to HDOS, meaning you have to "lay out" the PC files > into a virtual disk, and maintain translation back > and forth - ugh!) TMSI implemented a RAM disk for HDOS, that used high memory as if it were a disk drive. We named it GH.DVD, and it could be as large as 958k on an H-1000 with 1 meg of RAM. Man, does HDOS fly without the speed limitation of a physical disk drive! I would think that a similar device driver could be written to use a PC connected via a serial port as if it were a disk drive. GH.DVD was written by Tom Snoblen, whom I'm still in contact with. Between us, we probably have the source code for it somewhere. -- "Never doubt that a small group of committed people can change the world. Indeed, it's the only thing that ever has!" -- Margaret Meade -- Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed May 26 15:56:21 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 26 May 2004 20:56:21 +0000 Subject: [sebhc] Emulator fixes / additions Message-ID: > >The ability to have an HA-8-8 extended configuration "board" (with > >associated mods). > >What does this do? It came with a new montor (XCON8) to replace PAM8. It adds an i/o port control to disable the roms (both XCON8 and H17) along with H17's protectable RAM, simultaneously enabling a regualar memory page at location 0. XCON8 also adds vector compatibility with MTR-89, a boot routine for the H47, and an improved one for the H17. > > .. with the /I option, I was expecting it to act like a real H8. > >This has nothing to do with /I - the emulators response to the virtual CPU >executing HLT is to trap to the debugger. If you want to proceed with the >next instruction after the HLT, you can manually increment the PC with the >register editor and then hit ENTER (run). But that's not what a real H8 does. Try it on yours! >--- how does it get back to PAM-8? On the next clock interrupt. PAM8's service routine checks to see if it's in user mode (mon led is out), and if so, it checks to see if the interrupted opcode is a halt, or if the RTM key combination is being pressed. In either case, it beeps and returns to monitor mode. Remember, PAM8 itself is designed to be a debugger! Anyway, to work like a real H8, you shouldn't jump into your debugger on a HLT unless it occurs while interrupts are disabled. Cheers, - Steven _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Wed May 26 16:09:28 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 26 May 2004 21:09:28 +0000 Subject: [sebhc] Emulator future? Message-ID: Lee says: >TMSI implemented a RAM disk for HDOS, Between us, we probably have the >source code for it somewhere. Sounds like a nice addition for the archives. >I would think that a similar device driver could be written to use a PC >connected via a serial port as if it were a disk drive. Yea I think that's what Jack was talking about. So your real H8 could use a PC as a disk. What I was proposing for the emulator could be much simplerand faster - just a virtual i/o port that you write to when you have paramater/data block ready to be serviced, and another one to read from to tell you it's done (the latter only necessary if you want asynchronous processing). >Peter Shkabara's "CPC" program provides this capability with the H8-37 >or Z89-37 soft-sector controllers. Running CP/M, it lets you configure >one of your 5.25" floppies as a PC-DOS format drive, so you could read, >write, and format PC disks on your H8 or H89. I have a copy, and still >use it occasionally. Since I don't have a PC with 5.25" drives any more, >my H89 with CPC is the only way I can read such disks! Can we add that to the archives also? For those with real H8's, of course... I don't think we'd want to emulate that! Cheers, - Steven _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed May 26 16:20:32 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 26 May 2004 14:20:32 -0700 (PDT) Subject: [sebhc] Soft sectored vrs hard sectored Message-ID: <200405262120.OAA20582@clulw009.amd.com> Hi We've been mostly looking at the hard sectored formats lately. One of the things that was done on these was that the tracks other than track 0 had the volume number embedded in the header. I was wondering how they dealed with this for soft sectored disk? I don't think any of the 17xx parts allowed a simple way to do special headers. Does anyone have a soft sectored controller? It would be good to get the ROM code from one of these to help with the emulation efforts. Dwight -- Delivered by the SEBHC Mailing List From melamy at earthlink.net Wed May 26 16:41:02 2004 From: melamy at earthlink.net (melamy at earthlink.net) Date: Wed, 26 May 2004 14:41:02 -0700 Subject: [sebhc] Soft sectored vrs hard sectored Message-ID: <260504147.52846@webbox.com> I think the volume info would be a proprietary thing for Heath. The disk format certainly doesn't need the information there whether it is soft or hard sectored. The only info in a soft sectored record (aka IBM standard) is the sector starting at 1 and track starting at 0. best regards, Steve Thatcher >--- Original Message --- >From: "Dwight K. Elvey" >To: sebhc at sebhc.org >Date: 5/26/04 4:20:32 PM > Hi > We've been mostly looking at the hard sectored >formats lately. One of the things that was done >on these was that the tracks other than track 0 >had the volume number embedded in the header. I was >wondering how they dealed with this for soft sectored >disk? I don't think any of the 17xx parts allowed >a simple way to do special headers. > Does anyone have a soft sectored controller? It >would be good to get the ROM code from one of these >to help with the emulation efforts. >Dwight > > >-- >Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Wed May 26 17:28:56 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Wed, 26 May 2004 15:28:56 -0700 (PDT) Subject: [sebhc] Emulator fixes / additions Message-ID: <200405262228.i4QMSuBm023149@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 26 May 2004 22:50:03 -0000 Aaarrrgghhh... I just can't put this thing down! >On the next clock interrupt. PAM8's service routine checks to see if it's >in user mode (mon led is out), and if so, it checks to see if the >interrupted opcode is a halt, or if the RTM key combination is being >pressed. In either case, it beeps and returns to monitor mode. Remember, >PAM8 itself is designed to be a debugger! > >Anyway, to work like a real H8, you shouldn't jump into your debugger on a >HLT unless it occurs while interrupts are disabled. OK - I have implemented this - a HLT with interrupt disabled just freezes until another PAM-8 interrupt - this does indeed go back to PAM-8. HLT with interrupts disabled will trap to the debugger. I have also added a /H option to cause the simulator to trap ALL halts. Put in a few other goodies as well: - The simulator now maintains a 32 entry map, and can selectively write protect any 256 byte page in the first 8k (0000-1FFF). This means: PAM-8 and H17 ROM are now write protected by this method, meaning that we could easily turn them OFF, and allow all of memory to be RAM - currently no I/O port for doing this, but it could be easily added. [Unfortuntely, you can't do this when starting the simulator because PAM-8 dies if all memory is RAM - its "find end of memory" test wraps to 0000 and it continues forever] I've added a 'LR=' option to load a HEX file "READ ONLY" (if it's in the bottom 8k) - this allows you to install true ROM's into the expansion area. I've added a WP= option to let you specifically write protect pages - Not sure why you would want to do this, but if you need to eliminate some RAM from the expansion area, this will let you do it. - I've made the H17 optional. Basically, the H17 ROM and I/O ports will not appear in the virtual 8080 environment until you have performed at least one disk MOUNT function (eiher by command line argument or Mount function key) - this allows me to exactly simulate my H8 - which has no H17 :-( [Dosn't anyone out there have an extra H17?] - I've added the ability to load a user supplied 80x86 code module into the simulator to handle IN and OUT requests. Such modules can also set and clear pending interrupts. This allows you to "write" your own custom hardware and attach it to the virtual H8. At some point I'll create a custom library for my Micro-C/PC compiler which will let you write virtual I/O devices in 'C'. New version is available at: http://www.dunfield.com/pub/H8.ZIP 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 May 26 18:52:17 2004 From: sp11 at hotmail.com (Steven Parker) Date: Wed, 26 May 2004 23:52:17 +0000 Subject: [sebhc] Emulator fixes / additions Message-ID: Before I forget, Dwight found a pristine HDOS 1.0 image .. I put it in the disk-images. He also sent me 2 bootable images with basic games .. they are chase.h8d and bgames.h8d under "other". Anyway, Dave was saying: >OK - I have implemented this - a HLT with interrupt disabled just freezes I assume you mean "enabled". It does seem to work now. > we could easily turn them OFF, and allow all of memory to be RAM - > currently no I/O port for doing this, but it could be easily added. Wow, you are really close to having the XCON configuration implemented. > [Unfortuntely, you can't do this when starting the simulator because >PAM-8 > dies if all memory is RAM - its "find end of memory" test wraps to 0000 > and it continues forever] 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. > Not why you would want to do this, but if you need to eliminate some RAM > from the expansion area, this will let you do it. Well, it lets you prove the distribution sw really runs in minimal memory configurations. :-) >- I've made the H17 optional. Basically, the H17 ROM and I/O ports ... ...and the H17 write-protectable RAM? > At some point I'll create a custom library for my Micro-C/PC compiler >which > will let you write virtual I/O devices in 'C'. How cool! And will it also have access to the H8 memory (DMA)? Doesn't need to get invoked on access, but just read/write it when it DOES run. Cheers, - Steven ========================================================== ** 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 ========================================================== _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Wed May 26 20:46:07 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Wed, 26 May 2004 20:46:07 -0500 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <200405261343.i4QDhZ4t014089@gatekeeper.evocative.com> Message-ID: <000001c4438c$61a7dd10$1f6fa8c0@eths.k12.il.us> > > With this release of the H8 emulator, I am officially > "slowing down" the development - I need to get back to some > other projects, however development will probably still > continue at a pretty good pace - just don't expect daily > updates like you have seen in the past week :-) > > Jack: Would you update the archive version from the file > above and remove any > old ones. I think I'll hold off on that for another day or two - I'm having a little trouble telling "slowing down" from "full speed ahead" ! ;>) > - Ability to redirect H8 serial ports to PC serial ports. > Hooking up a printer or a real H19 would be cool To me, the next big step would be finding a "transparent" way to read/write to a PC, whether block, file or disk-image oriented. Seems to me that the most natural way would be to "mount" it as a drive, though not constrained by the "classic" media sizes. BTW, HDOS 3.02 claims to support 38,400 baud serial connections, though I'm not sure if that could be done on an H8. I've lost my 0-org system for the moment so I'm not quite ready to see if my disks will boot. I may have to fall back to an H89 to find out. SLIGHTLY OFF TOPIC, BUT CLEARLY RELATED - The other thing I would find most helpful seems to already exist, though perhaps not collected in one place. This would be a toolkit that allows conversion among the various image formats that we have - many of you seem to be able to move between binary, hex and .h17 formats, but I'm not clear on the processes or tools used to do so. I can create an .h17 file using diskdump on the H8 or dump a hex or binary ROM file to the PC from my PROM burner, but I don't have conversion tools to interchange the formats (or I have the tools and don't know how to use them!). I'd greatly appreciate it if you all could reduce this to a cookbook level. Thanks! Jack -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Wed May 26 21:48:33 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Wed, 26 May 2004 19:48:33 -0700 (PDT) Subject: [sebhc] Emulator future? + request for tools Message-ID: <200405270248.TAA20910@clulw009.amd.com> >From: "Jack Rubin" ---snip--- > >The other thing I would find most helpful seems to already exist, though >perhaps not collected in one place. This would be a toolkit that allows >conversion among the various image formats that we have - many of you >seem to be able to move between binary, hex and .h17 formats, but I'm >not clear on the processes or tools used to do so. I can create an .h17 >file using diskdump on the H8 or dump a hex or binary ROM file to the PC >from my PROM burner, but I don't have conversion tools to interchange >the formats (or I have the tools and don't know how to use them!). I'd >greatly appreciate it if you all could reduce this to a cookbook level. > Hi Jack I'm not sure what the .h17 format is but I have a couple of home made tools to convert from Intel Hex to binary and back. There are surely some of these on the web someplace. There isn't much to them. The prom programmer I have will read and write several different formats to and from its buffer as well. I know it is a little difficult right now but soon enough, we should settle in on something. I consider writing converters to be straight forward: Open the input file create an output file begin loop read in a logical chunk ( line, 16 bytes or what ever ) translate to the new output format Write to the output file. When out of input end loop close them all. I could show you some of my code but you'd need to be proficient in Forth. It can be a little confusing to someone used to infixed notation( C, Pascal, modula2 etc. ). Dwight -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Thu May 27 05:34:22 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 27 May 2004 03:34:22 -0700 (PDT) Subject: [sebhc] Emulator future? + request for tools Message-ID: <200405271034.i4RAYMmh035334@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 27 May 2004 10:47:44 -0000 >I think I'll hold off on that for another day or two - I'm having a >little trouble telling "slowing down" from "full speed ahead" ! ;>) Arg - yeah - grumble - grumble - I am trying... >> - Ability to redirect H8 serial ports to PC serial ports. >> > >Hooking up a printer or a real H19 would be cool Vote recorded. >To me, the next big step would be finding a "transparent" way to >read/write to a PC, whether block, file or disk-image oriented. Seems to >me that the most natural way would be to "mount" it as a drive, though >not constrained by the "classic" media sizes. BTW, HDOS 3.02 claims to >support 38,400 baud serial connections, though I'm not sure if that >could be done on an H8. I've lost my 0-org system for the moment so I'm >not quite ready to see if my disks will boot. I may have to fall back to >an H89 to find out. I can easily provide an I/O port to allow direct access to PC files, it would have to have some sort of protocol allowing you to open a file, close a file and read/write the file ... But how would HDOS know about this. Does HDOS support a non-native filesystem (aka: network redirector functionality)? I think an easier way to import/export individual files would be to write a utility which can read/write the .H8D disk images. If someone can provide me with details on the disk structure, directory, allocation tables etc. I can probably do this in fairly short order. This would give you a command which you can run on the PC, to list directories, extract and inject files in a .H17 image file. For an example, look at the ADI (Altair Disk Image) command that I include with my Altair emulator. >SLIGHTLY OFF TOPIC, BUT CLEARLY RELATED - > >The other thing I would find most helpful seems to already exist, though >perhaps not collected in one place. This would be a toolkit that allows >conversion among the various image formats that we have - many of you >seem to be able to move between binary, hex and .h17 formats, but I'm >not clear on the processes or tools used to do so. I can create an .h17 >file using diskdump on the H8 or dump a hex or binary ROM file to the PC >from my PROM burner, but I don't have conversion tools to interchange >the formats (or I have the tools and don't know how to use them!). I'd >greatly appreciate it if you all could reduce this to a cookbook level. I don't have anything for .H17 (.H8D?) images yet, but take a look at my H8T.COM (H8 Transfer/Translate) utility, which I have been bundling with recent versions of the simulator. H8T can copy and translate between three file formats: .H8T / .PID = H8 Tape image file .HEX = Intel or Motorola HEX download files .BIN / .ROM = Raw binary image It also recognizes COM(1-4) as a serial port operating in H8 tape image format, so it allows you to load any of the above filetypes directly into the (real) H8 without having to translate it first. For example, lets suppose you have MYPROG.HEX (Intel or Motorola format) and you want to turn it into a MYPROG.H8T tape image file. all you need to do is: H8T MYPROG.HEX MYPROG.H8T Btw, what exactly is a .H17 file - I assume this ia a disk image? 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 Thu May 27 05:34:20 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 27 May 2004 03:34:20 -0700 (PDT) Subject: [sebhc] Rather serious H8/PAM-8 design flaw. Message-ID: <200405271034.i4RAYK1f035332@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 27 May 2004 10:47:39 -0000 >>--- how does it get back to PAM-8? >On the next clock interrupt. PAM8's service routine checks to see if it's >in user mode (mon led is out), and if so, it checks to see if the >interrupted opcode is a halt, or if the RTM key combination is being >pressed. In either case, it beeps and returns to monitor mode. Remember, >PAM8 itself is designed to be a debugger! This is a rather serious design flaw! After interrupting ANY instruction (including HLT), the PC is advanced to the byte afterward .. this means that to "examine" the instruction, PAM-8 has to backup the stacked PC by one byte, and look for a $76 (HLT opcode). Problem is - there's lots of mylti-byte instructions which end with $76. Eg: LDA $76xx <= Or STA LHLD $76xx <= Or SHLD MVI A,$76 <= Or any register CPI $76 ANI $76 <= Or ORI, XRI LXI H,$76xx <= Any register JMP $76xx <= Any Jxx inst CALL $76xx <= Any Cxx inst PAM-8 has no way of knowing that the instruction just interrupted was HLT or a multi-byte instruction ending with $76 Try this program on your real H8 (or the emulator - but It does happen on the real H8 also - I have verified this): ORG $2040 loop: MVI A,$75 JMP LOOP As expected, it runs "forever". Now, change the second line to: MVI A,$76 Volia - the program will immediately exit to PAM-8 - in fact, you CANNOT keep it running with interrupts enabled. Any code which occupies the $76xx block of memory is almost certain to have Jxx and/or Cxx instructions ending with $76 - If there's any data stored in that page, there is very likely to be LDA/STA/LHLD/SHLD/LXI instructions which end in $76. Plus - even in non-$76xx blocks, there are plenty of immediate instructions which might end in $76 for any program of significant complexity. This is basically a time-bomb waiting to go off - if an interrupt happens at just the right time in a program containing ANY instruction ending with $76, PAM-8 will halt the program and re-enter the monitor. Wow! 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 Thu May 27 05:34:17 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 27 May 2004 03:34:17 -0700 (PDT) Subject: [sebhc] Emulator fixes / additions Message-ID: <200405271034.i4RAYHYW035333@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 27 May 2004 10:47:41 -0000 At 23:52 26/05/2004 +0000, you wrote: >Before I forget, Dwight found a pristine HDOS 1.0 image .. I put it in the >disk-images. He also sent me 2 bootable images with basic games .. they are >chase.h8d and bgames.h8d under "other". Cool - have you tried booting it in the emulator? >>OK - I have implemented this - a HLT with interrupt disabled just freezes >I assume you mean "enabled". It does seem to work now. Yeah - typo - see my previous post about why this is not a great feature! >>- I've made the H17 optional. Basically, the H17 ROM and I/O ports ... > >...and the H17 write-protectable RAM? The write protected RAM defaults to "writeable" at startup (why protect it, it contains 0's on the emulator, or garbage on the H8) - it will not be write protected until the write protect bit is written to the control port - since the control port does not appear in the map until the H17 is "installed", the RAM is writeable if the H17 is not installed. >> At some point I'll create a custom library for my Micro-C/PC compiler >>which >> will let you write virtual I/O devices in 'C'. > >How cool! And will it also have access to the H8 memory (DMA)? Doesn't >need to get invoked on access, but just read/write it when it DOES run. There's a lot more interesting values available via the ES:BX handler data pointer than I have currently documented, One of which is the segment address of the virtual 8080 64K address space - I am going to rearrange the area to put the more useful (to IO handlers) values first, then I will document them, allowing access to 8080 Memory as well as certain other siulator internals. >> we could easily turn them OFF, and allow all of memory to be RAM - >> currently no I/O port for doing this, but it could be easily added. >Wow, you are really close to having the XCON configuration implemented. > >> [Unfortuntely, you can't do this when starting the simulator because >>PAM-8 >> dies if all memory is RAM - its "find end of memory" test wraps to 0000 >> and it continues forever] > >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. >========================================================== > >** 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 How do the "Single Step" and "Clock Enable" bits work in conjunction with the existing H8 bits of the same function in port $F0 (360)? >** 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 What do these mean? >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 How is the baud rate set in hardware - on the H5, you can't select beween 9600 and 19200 in software, choices are x16 or x64, normally 9600 & 2400. >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 Is there a "ORG 0" option which works with PAM-8? 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 eric at rothfus.com Thu May 27 07:08:55 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Thu, 27 May 2004 08:08:55 -0400 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <200405271034.i4RAYMmh035334@gatekeeper.evocative.com> (message from Dave Dunfield on Thu, 27 May 2004 03:34:22 -0700 (PDT)) References: <200405271034.i4RAYMmh035334@gatekeeper.evocative.com> Message-ID: <1085572990@rothfus.com> > I think an easier way to import/export individual files would be to write > a utility which can read/write the .H8D disk images. If someone can provide > me with details on the disk structure, directory, allocation tables etc. I > can probably do this in fairly short order. This would give you a command > which you can run on the PC, to list directories, extract and inject files > in a .H17 image file. For an example, look at the ADI (Altair Disk Image) > command that I include with my Altair emulator. I built such a utility recently for HDOS. It fits into the framework that I use for the SVD. I handles CP/M as well (as well as a few other file systems like the TRS-80 line). It allows listing of the files on the filesystem, and extracting, adding, and deleting files from it. For example: $ fstool -F hdos -E diskdump.asm This command tells fstool that the filesystem is hdos. It will "guess" the format of the incoming image. "-E" extracts the given file from the image writing it into the local directory with the same filename. You can use "-A" to add and "-D" to delete. CP/M'ing is just as easy: $ fstool -F hcpm -A floopy.asm In this case, a new image is generated with the given file added. Note that the parameters for CP/M are buried within a particular named format, in this case "hcpm" standing for Heathkit CP/M. However, I'm not a DOS person, so it is written to Linux, running on Windoze with the cygwin package. The basic idea is that a front-end parses the file format, gets it into an internal memory-based image, then operates on the file system given a hint was to WHAT file system is on the thing...including, for CP/M, appropriate blocking information. I haven't had the time yet, but I'll put the source up somewhere within the next few days so you can play with it if you like....converting it to (gulp) DOS. :-) I have an HTML man page in the works for fstool as well. > Btw, what exactly is a .H17 file - I assume this ia a disk image? The original .H17 is an (unpopular :-) ASCII representation of an H8/H89 compatible disk image. Besides being in ASCII, it is basically a sector by sector, track by track dump of a disk. Note that it is QUITE distinguishable from any other format on the planet. :-) Eric -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 11:21:10 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 09:21:10 -0700 (PDT) Subject: [sebhc] Emulator future? + request for tools Message-ID: <200405271621.JAA21432@clulw009.amd.com> >From: "Dave Dunfield" > ---snip--- > >I think an easier way to import/export individual files would be to write >a utility which can read/write the .H8D disk images. If someone can provide >me with details on the disk structure, directory, allocation tables etc. I >can probably do this in fairly short order. This would give you a command >which you can run on the PC, to list directories, extract and inject files >in a .H17 image file. For an example, look at the ADI (Altair Disk Image) >command that I include with my Altair emulator. Hi Dave There is a site someplace that I downloaded info on the H17 and it also had infor on the HDOS disk structure. There is some header info at the start of the disk that describes where to find things like the directory and the sector useage tables. The site was another emulator for the H89 as I recall. I wish I'd written it down on the listings. I'd looked at them just last night. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Thu May 27 11:57:39 2004 From: sp11 at hotmail.com (Steven Parker) Date: Thu, 27 May 2004 16:57:39 +0000 Subject: [sebhc] Emulator future? + request for tools Message-ID: Jack says: >The other thing I would find most helpful seems to already exist, though >perhaps not collected in one place. This would be a toolkit ... That's what the "utilities" area in the archives is for .. the top-level one, not the one under "sources" (the latter is for stuff that would run on the H8). Emulators themselves fall into this category, but because of their significance they got their own :-) Dave asks: >Does HDOS support a non-native filesystem (aka: network redirector >functionality)? I thought it was up to the driver, but now I think not. But if the H17 emulation is totally generic, perhaps we can create large "fantasy floppies" and use Eric's fstool to move files in and out. >Btw, what exactly is a .H17 file - I assume this ia a disk image? Yea, as Jack explained, basically a dump. Do we still want to keep those in the archive, now that they have all been converted to images? >PAM-8 has no way of knowing that the instruction just interrupted was HLT >or a multi-byte instruction ending with $76 I guess a testament to the accuracy of an emulator is it's ability to model a system's eccentricities as well as it's defaults. :-) It's interesting that this pretty much never happens on HDOS, which leaves the panel on. I believe CPM turned it off. > >Before I forget, Dwight found a pristine HDOS 1.0 image .. Cool - have >you tried booting it in the emulator? Yes, seems to work fine. > >...and the H17 write-protectable RAM? >- it will not be >write protected until the write protect bit is written to the control port >- since the control port does not appear in the map until the H17 is > "installed", the RAM is writeable if the H17 is not installed. I believe the actual behavior is to be write-protected on reset (I guess "when installed" too?). But I agree it's not a practical issue because in niether case would it contain anything yet. Cheers, - Steven _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu May 27 12:56:03 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Thu, 27 May 2004 10:56:03 -0700 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <200405271621.JAA21432@clulw009.amd.com> Message-ID: <003901c44413$e0d465e0$f300a8c0@berkeley.evocative.com> > There is a site someplace that I downloaded info on the H17 > and it also had infor on the HDOS disk structure. There is > some header info at the start of the disk that describes > where to find things like the directory and the sector useage > tables. The site was another emulator for the H89 as I > recall. I wish I'd written it down on the listings. I'd > looked at them just last night. Dwight Dwight, I think that's here: http://home.comcast.net/~davidwallace2000/h8/project8080_archive/design_h17. html Right? Patrick -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 15:08:08 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 13:08:08 -0700 (PDT) Subject: [sebhc] Emulator future? + request for tools Message-ID: <200405272008.NAA21657@clulw009.amd.com> Hi Patrick That's it. It doesn't make everything absolutely clear but looking at one of the image files with as a hex dump helps tie things together. I use the hex mode in xtree. Dwight >From: "Patrick Rigney" > >> There is a site someplace that I downloaded info on the H17 >> and it also had infor on the HDOS disk structure. There is >> some header info at the start of the disk that describes >> where to find things like the directory and the sector useage >> tables. The site was another emulator for the H89 as I >> recall. I wish I'd written it down on the listings. I'd >> looked at them just last night. Dwight > >Dwight, I think that's here: > >http://home.comcast.net/~davidwallace2000/h8/project8080_archive/design_h17. >html > >Right? >Patrick > > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From me at patswayne.com Thu May 27 16:28:54 2004 From: me at patswayne.com (Pat Swayne) Date: Thu, 27 May 2004 17:28:54 -0400 Subject: [sebhc] H19 terminal emulator In-Reply-To: <003901c44413$e0d465e0$f300a8c0@berkeley.evocative.com> References: <200405271621.JAA21432@clulw009.amd.com> <003901c44413$e0d465e0$f300a8c0@berkeley.evocative.com> Message-ID: <6.1.0.6.2.20040527172021.030b34b8@mail.patswayne.com> I have uploaded a new version of my Heath Terminal Emulator to the SEBHC archive FTP site. When it becomes available, someone please test it for me. I don't have a way to test it right now. It runs on a PC with VGA or higher video, and uses character remapping in the text mode to make H19 graphics, so you don't have to run in the monocrome 640x200 mode like the old HTE to get them. HTE is based on another program I did, ZEMulator, which lets you run H/Z-100 programs on a PC. When I get the package together, I am going to upload this. Back in my HUG days, you may recall I made a program called HRUN that would let you run HDOS programs under CP/M, and CP/Emulator, that would let you run 8-bit CP/M program on an 80x86 machine. Well, by stacking HRUN, CP/Emulator, and ZEMulator, I was able to run HDOS programs on a PC. If I ever find copies of these emulators in my stuff, I'll upload them. I moved recently, and am still unpacking. -- Pat Hm... Imagine being able to play "The Wizards of Zeedle-Deet" on a PC... -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 27 18:12:18 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 27 May 2004 18:12:18 -0500 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: Message-ID: <000001c44440$0ec62980$1f6fa8c0@eths.k12.il.us> > That's what the "utilities" area in the archives is for .. > the top-level > one, not the one under "sources" (the latter is for stuff > that would run on > the H8). Emulators themselves fall into this category, but > because of their > significance they got their own :-) Unfortunately, with the exception of Dave's H8T contribution, it is quite empty. What are _you_ using to do all the file transformations you've contributed? How are you getting from HDOS disk to uploaded image and vice versa? > > >Btw, what exactly is a .H17 file - I assume this ia a disk image? > > Yea, as Jack explained, basically a dump. Do we still want > to keep those in > the archive, now that they have all been converted to images? > Until SVD learns to read binary files, .h17 is the only way I have to get files to and from my H8. Jack -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Thu May 27 18:25:17 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Thu, 27 May 2004 19:25:17 -0400 Subject: [sebhc] SCANS Message-ID: <40B678DD.50109@sc.rr.com> I see some of you have been scanning manuls, etc to upload. What software are you using to scan them? I have some info and a scanner. Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 27 18:26:16 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 27 May 2004 18:26:16 -0500 Subject: [sebhc] H19 terminal emulator In-Reply-To: <6.1.0.6.2.20040527172021.030b34b8@mail.patswayne.com> Message-ID: <000001c44442$029d73a0$1f6fa8c0@eths.k12.il.us> thanks Pat! > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Pat Swayne > Sent: Thursday, May 27, 2004 4:29 PM > To: sebhc at sebhc.org > Subject: [sebhc] H19 terminal emulator > > > I have uploaded a new version of my Heath Terminal Emulator > to the SEBHC > archive FTP site. When it becomes available, someone please > test it for me. > I don't have a way to test it right now. > It runs on a PC with VGA or higher video, and uses character > remapping in > the text mode to make H19 graphics, so you don't have to run in the > monocrome 640x200 mode like the old HTE to get them. > HTE is based on another program I did, ZEMulator, which lets you run > H/Z-100 programs on a PC. When I get the package together, I > am going to > upload this. Back in my HUG days, you may recall I made a > program called > HRUN that would let you run HDOS programs under CP/M, and > CP/Emulator, that > would let you run 8-bit CP/M program on an 80x86 machine. > Well, by stacking > HRUN, CP/Emulator, and ZEMulator, I was able to run HDOS > programs on a PC. > If I ever find copies of these emulators in my stuff, I'll > upload them. I > moved recently, and am still unpacking. > -- Pat > Hm... Imagine being able to play "The Wizards of Zeedle-Deet" > on a PC... > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 18:38:43 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 16:38:43 -0700 (PDT) Subject: [sebhc] Emulator future? + request for tools Message-ID: <200405272338.QAA21966@clulw009.amd.com> >From: "Jack Rubin" > >> That's what the "utilities" area in the archives is for .. >> the top-level >> one, not the one under "sources" (the latter is for stuff >> that would run on >> the H8). Emulators themselves fall into this category, but >> because of their >> significance they got their own :-) > >Unfortunately, with the exception of Dave's H8T contribution, it is >quite empty. What are _you_ using to do all the file transformations >you've contributed? How are you getting from HDOS disk to uploaded image >and vice versa? Hi Jack I have a tool that I've not released yet that I use. It transfers an image between the H89/90 and a PC through the serial ports. The problem is that it has never been tested on a H8 yet. I just got my H8 w/ Z80 running. I suspect that the code I have will work fine with those that have the 4 port serial card ( H8-4 ). On the H89, I use the LP port ( 340Q, w/ least hardware configuration changes ). This board uses 8250 chips. I'll be checking this configuration out this weekend if my H27 is functional. I have enough boards and such to do the same for a H8 with 8080, H8-5 and a H17 board. In this particular case, there is no H8-4. Instead it has a H8-5 serial/cassette board. I know my code is not compatable here since this board uses a 8251 and I'm not initializing or talking correctly to this part. I need to know how to configure this setup since I suspect that there is an address conflict with this board and the H17 board. Now, remember that my code was actually written primarily to boot strap a machine from ground zero with only blank disks and the images on a PC. It can be used to transfer images to and from the H8x machine, as well. I'd like to check it out on at least the H8-4 configuration before making the first release. I'll then make another release for those that are restricted to talking through only a H8-5 board. Patience please. I didn't intend to take as long as I have but it should be ready soon. Dwight ---snip--- -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 18:43:32 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 16:43:32 -0700 (PDT) Subject: [sebhc] H8 configuration Message-ID: <200405272343.QAA21973@clulw009.amd.com> Hi I'm going to be setting up my older H8 to have the H17 board installed. The problem is that this machine has only the serial/cassette board ( H8-5 ) and not the H8-4 serial board. Is this configuration possible? I know that on the H89, the cassette and H17 are on conficting addresses. Can one configure this older setup to run without using the H8-4 board? Is there a way to share or disable the cassette address on the H8-5 board? Thanks Dwight -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 27 18:49:10 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 27 May 2004 18:49:10 -0500 Subject: [sebhc] SCANS In-Reply-To: <40B678DD.50109@sc.rr.com> Message-ID: <000001c44445$353f7580$1f6fa8c0@eths.k12.il.us> > > I see some of you have been scanning manuls, etc to upload. What > software are you using to scan them? I have some info and a > scanner. Carroll > I use Adobe Acrobat 6.0 which lets me scan directly into a .pdf using a TWAIN driver. In my case, I have an Epson Expression 800 scanner with an auto document feeder :>) which I set for "line art" (2-bit black and white) at 400 dpi resolution. The major problems with this setup are the size of the output image and impolite messages from earlier Acrobat readers (sorry, Dave) but the seamless workflow and the ability to truly duplicate the original are important to me. Another approach is to scan the originals as .tif files (here I use SilverFast AI from LaserSoft which replaces the TWAIN driver) and then combine the individual images into a .pdf with something like tumble (linux) or t2p (Windows). This makes for much faster scanning (the Epson TWAIN driver is not exactly highly tuned) but for me it would also mean buying new software and following a multi-step conversion process. Final output file size is about the same. The .tif format also allows "cleaning" of the images which can't be done in a .pdf; in fact if I have to remove stains/spills/tears from a .pdf, I convert to and from .tif to do the work. For this process, I work in PhotoShop. Finally, you could OCR the docs, converting scanned images back into text files. This is great if you need to be able to search the file contents or use the text for another function (e.g. scanning an assembly listing and then reassembling it), but it requires a lot of post-scan work to proof and reformat the output. Preserving non-text material (like the Heath logo on manual pages) requires additional steps. If you want to go this route, I've had great results with OmniPage Pro 12. Note that these files are _much_ smaller than .pdf images. Given that the quantity of material I have to scan is measured boxes rather than pages, a fully automated workflow is best for me. Jack > > I see some of you have been scanning manuls, etc to upload. What > software are you using to scan them? I have some info and a > scanner. Carroll > -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Thu May 27 19:04:21 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Thu, 27 May 2004 20:04:21 -0400 Subject: [sebhc] H8 configuration In-Reply-To: <200405272343.QAA21973@clulw009.amd.com> References: <200405272343.QAA21973@clulw009.amd.com> Message-ID: <40B68205.90007@sc.rr.com> Dwight, I'm working on the same configuration, but I plan to have both the H8-5 and the H8-4 in the machine. The cassette interface is port 370Q, the H8-5 terminal address is 372Q, and the H17 is 170Q-174Q. You can remove the 8251 on the cassette board to disable the interface. I'm pretty sure that if you don't have an H8-4, the software will use the 372Q port on the H8-5. The H17 board that I bought was missing the H17 ROM and the 2114 memory chips. When I locate them, I'm going to set up a similiar system. Carroll Dwight K. Elvey wrote: >Hi > I'm going to be setting up my older H8 to have the >H17 board installed. The problem is that this machine >has only the serial/cassette board ( H8-5 ) and not >the H8-4 serial board. Is this configuration possible? >I know that on the H89, the cassette and H17 are on >conficting addresses. Can one configure this older >setup to run without using the H8-4 board? Is there >a way to share or disable the cassette address on the >H8-5 board? >Thanks >Dwight > > >-- >Delivered by the SEBHC Mailing List > > > -- Delivered by the SEBHC Mailing List From labomb at rochester.rr.com Thu May 27 19:19:07 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Thu, 27 May 2004 20:19:07 -0400 Subject: [sebhc] H8 configuration References: <200405272343.QAA21973@clulw009.amd.com> Message-ID: <00b001c44449$64713a60$02a8a8c0@IBMD9HY10WBGXB> Hi Dwight, One of my H8's is configured with an H8-5 and an H-17 controller. It works just fine ... The default port configuration for the H8-5 has the serial port at 372Q/373Q, and the cassette port at 370Q/371Q. The H-17 default (as I recall) is at 174Q-177Q ...there is no conflict to my knowledge (I haven't pulled out the docs to verify)... Scott ----- Original Message ----- From: "Dwight K. Elvey" To: Sent: Thursday, May 27, 2004 7:43 PM Subject: [sebhc] H8 configuration > Hi > I'm going to be setting up my older H8 to have the > H17 board installed. The problem is that this machine > has only the serial/cassette board ( H8-5 ) and not > the H8-4 serial board. Is this configuration possible? > I know that on the H89, the cassette and H17 are on > conficting addresses. Can one configure this older > setup to run without using the H8-4 board? Is there > a way to share or disable the cassette address on the > H8-5 board? > Thanks > Dwight > > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Thu May 27 19:26:20 2004 From: patrick at vintagecomputermarketplace.com (Patrick Rigney) Date: Thu, 27 May 2004 17:26:20 -0700 Subject: [sebhc] SCANS In-Reply-To: <40B678DD.50109@sc.rr.com> Message-ID: <006301c4444a$6643bb00$f300a8c0@berkeley.evocative.com> Carrol, for most of the ones I uploaded, they were scanned on an HP OfficeJet d145 with a duplexing document feeder. I use Adobe Acrobat's "import" facility to scan directly to Acrobat. For the rare occasions that I bother to OCR, I use OmniPage. I don't usually scan the documents in their original form. I make a single-sided copy, making any contrast adjustments I feel necessary for a good quality result. For small documents I do that on my office copier; for large document, I go to Kinkos where they have fast machines with good high-capacity document feeders. If the document is fragile, I'll happily spend hours copying it page by page. I then put the original document back together (if disassembled) and store it away. The single-sided copy is what gets scanned, and then I put THAT away as well, using the PDF to produce whatever further paper copies I need from there. I keep working prints of most of the documents I have in binders for each machine, printed 2-up and double-sided (four document pages per printed page) with lots of Post-It markers and reminders. :-) I just saw Jack's message as well. He and I have almost identical procedures, except that I typically use 300dpi one-bit mode for documents that are mostly text, or even 200dpi for documents that are very large, and I use Acrobat 5 instead of 6. My objective is not to make the PDF an archival quality document, but rather to make it a readable working document, and either resolution produces what I feel is an acceptable result for this purpose. For some documents I'll use 8-bit grayscale, but only for schematics with fine print. For archiving, I rely on careful handling of the original document and its new single-sided copy. --Patrick > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Thursday, May 27, 2004 4:25 PM > To: sebhc at staunch89er.com > Subject: [sebhc] SCANS > > > I see some of you have been scanning manuls, etc to upload. What > software are you using to scan them? I have some info and a > scanner. Carroll > > -- > Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 19:38:08 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 17:38:08 -0700 (PDT) Subject: [sebhc] H8 configuration Message-ID: <200405280038.RAA21998@clulw009.amd.com> Hi Carroll The ROM can just be a 2716 with code from the site as I recall. I don't think you need any special mods to use the 2716's. I think Anchor Electronics still has 2114's. There are also some board modifications that you'll need to make. Look at the pdf for the XCON8 to see what was modified ( I think it is just a jumper or two and a cap/resistor ). You need to undo these modifications as your board was configured for the XCON8 setup and not the PAM8( unless, of course that is what you have ). If you have the Z80 board you don't need either the ROM or RAM chips. I suspect that HDOS will find the serial port, it is just that my code is a complete bootstrap. My code runs before any thing else runs so I needs to initialize the serial port and specifically talk to it. It is not an application that runs under HDOS. The ROM only has code to talk to the cassette, not the serial. Remember, this is a bootstrap from ground zero. I do have code to write out the main code that I use for bootstrapping to the disk but, again, this is not a HDOS disk. It is just a disk that boots to the transfer program. I don't get all the HDOS calls to play with. This way, one only needs to enter the bootstrap code once from the front panel. Thanks for the port info. How many people out there have a PAM8 with the disk connected and running? What does your setup look like? Dwight >From: "Carroll Waddell" > >Dwight, >I'm working on the same configuration, but I plan to have both the H8-5 >and the H8-4 in the machine. The cassette interface is port 370Q, the >H8-5 terminal address is 372Q, and the H17 is 170Q-174Q. You can remove >the 8251 on the cassette board to disable the interface. >I'm pretty sure that if you don't have an H8-4, the software will use >the 372Q port on the H8-5. The H17 board that I bought was missing the >H17 ROM and the 2114 memory chips. When I locate them, I'm going to set >up a similiar system. >Carroll > >Dwight K. Elvey wrote: > >>Hi >> I'm going to be setting up my older H8 to have the >>H17 board installed. The problem is that this machine >>has only the serial/cassette board ( H8-5 ) and not >>the H8-4 serial board. Is this configuration possible? >>I know that on the H89, the cassette and H17 are on >>conficting addresses. Can one configure this older >>setup to run without using the H8-4 board? Is there >>a way to share or disable the cassette address on the >>H8-5 board? >>Thanks >>Dwight >> >> >>-- >>Delivered by the SEBHC Mailing List >> >> >> > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 27 19:41:36 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 27 May 2004 19:41:36 -0500 Subject: [sebhc] SCANS In-Reply-To: <006301c4444a$6643bb00$f300a8c0@berkeley.evocative.com> Message-ID: <000001c4444c$88ca9e80$1f6fa8c0@eths.k12.il.us> Patrick said: > I just saw Jack's message as well. He and I have almost > identical procedures, except that I typically use 300dpi > one-bit mode for documents that are mostly text, or even > 200dpi for documents that are very large, and I use Acrobat 5 and of course, I should have said "1-bit", not "2-bit" in my descripton... I also often work off copies of the original, especially if it is bound or fragile - it is much easier and faster to work with a copier than a scanner on a page-by-page basis and then bulk scan the output. At 1-bit, there is no perceptible information loss. The copiers I have access to also allow image reduction from A size drawings or smaller, whereas my scanner has an 8.5 x 14 inch bed. The big Heath pictorials are still a bear and I copy/scan them in sections. Color work goes to Kinkos. We just got a new network-connected Konica copier with the ability to scan (via TWAIN interface)as well as copy - I'm looking forward to trying it out in both roles later this summer. Jack -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 19:41:36 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 17:41:36 -0700 (PDT) Subject: [sebhc] H8 configuration Message-ID: <200405280041.RAA22002@clulw009.amd.com> Hi Scott Thanks, I just remember that my H89 wouldn't allow both at the same time. I guess the H89 used other addresses for the ports. I just need to make my bootstrap program H8-5 friendly. Dwight >From: "Scott LaBombard" > >Hi Dwight, > >One of my H8's is configured with an H8-5 and an H-17 >controller. It works just fine ... > >The default port configuration for the H8-5 has the serial >port at 372Q/373Q, and the cassette port at 370Q/371Q. > >The H-17 default (as I recall) is at 174Q-177Q ...there is >no conflict to my knowledge (I haven't pulled out the docs >to verify)... > > >Scott > >----- Original Message ----- >From: "Dwight K. Elvey" >To: >Sent: Thursday, May 27, 2004 7:43 PM >Subject: [sebhc] H8 configuration > > >> Hi >> I'm going to be setting up my older H8 to have the >> H17 board installed. The problem is that this machine >> has only the serial/cassette board ( H8-5 ) and not >> the H8-4 serial board. Is this configuration possible? >> I know that on the H89, the cassette and H17 are on >> conficting addresses. Can one configure this older >> setup to run without using the H8-4 board? Is there >> a way to share or disable the cassette address on the >> H8-5 board? >> Thanks >> Dwight >> >> >> -- >> Delivered by the SEBHC Mailing List >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 27 19:43:34 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 27 May 2004 19:43:34 -0500 Subject: [sebhc] H8 configuration In-Reply-To: <40B68205.90007@sc.rr.com> Message-ID: <000101c4444c$cea416c0$1f6fa8c0@eths.k12.il.us> The H17 board that I bought was > missing the > H17 ROM and the 2114 memory chips. When I locate them, I'm > going to set > up a similiar system. > Carroll > Carroll - I've got a PAM8 ROM going out to you in the mail this weekend. Jack -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Thu May 27 21:15:51 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Thu, 27 May 2004 22:15:51 -0400 Subject: [sebhc] H8 configuration In-Reply-To: <000101c4444c$cea416c0$1f6fa8c0@eths.k12.il.us> References: <000101c4444c$cea416c0$1f6fa8c0@eths.k12.il.us> Message-ID: <40B6A0D7.4090003@sc.rr.com> Jack, I have the XCON8 ROM. I haven't check it yet, but it looks like it has the H17 ROM code in it. Carroll Jack Rubin wrote: > The H17 board that I bought was > > >>missing the >>H17 ROM and the 2114 memory chips. When I locate them, I'm >>going to set >>up a similiar system. >>Carroll >> >> >> > >Carroll - I've got a PAM8 ROM going out to you in the mail this weekend. >Jack > >-- >Delivered by the SEBHC Mailing List > > > From CarrollWaddell at sc.rr.com Thu May 27 21:17:55 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Thu, 27 May 2004 22:17:55 -0400 Subject: [sebhc] H8 configuration In-Reply-To: <200405280038.RAA21998@clulw009.amd.com> References: <200405280038.RAA21998@clulw009.amd.com> Message-ID: <40B6A153.60308@sc.rr.com> I found some 2114's in my OLD STUFF drawer a little bit ago. The XCON8 ROM may have the H17 code on it. If not, I'll try burning an EPROM. I still have the H17 ROM code from years ago. Carroll Dwight K. Elvey wrote: >Hi Carroll > The ROM can just be a 2716 with code from the site as I recall. >I don't think you need any special mods to use the 2716's. >I think Anchor Electronics still has 2114's. There are also >some board modifications that you'll need to make. Look at >the pdf for the XCON8 to see what was modified ( I think it >is just a jumper or two and a cap/resistor ). You need to >undo these modifications as your board was configured >for the XCON8 setup and not the PAM8( unless, of course that >is what you have ). If you have the Z80 board you don't need >either the ROM or RAM chips. > I suspect that HDOS will find the serial port, it is just that >my code is a complete bootstrap. My code runs before any >thing else runs so I needs to initialize the serial port >and specifically talk to it. It is not an application >that runs under HDOS. The ROM only has code to talk to >the cassette, not the serial. > Remember, this is a bootstrap from ground zero. I do have >code to write out the main code that I use for bootstrapping >to the disk but, again, this is not a HDOS disk. It is >just a disk that boots to the transfer program. I don't get >all the HDOS calls to play with. This way, one only needs >to enter the bootstrap code once from the front panel. > Thanks for the port info. > > How many people out there have a PAM8 with the disk connected >and running? What does your setup look like? >Dwight > > > > >>From: "Carroll Waddell" >> >>Dwight, >>I'm working on the same configuration, but I plan to have both the H8-5 >>and the H8-4 in the machine. The cassette interface is port 370Q, the >>H8-5 terminal address is 372Q, and the H17 is 170Q-174Q. You can remove >>the 8251 on the cassette board to disable the interface. >>I'm pretty sure that if you don't have an H8-4, the software will use >>the 372Q port on the H8-5. The H17 board that I bought was missing the >>H17 ROM and the 2114 memory chips. When I locate them, I'm going to set >>up a similiar system. >>Carroll >> >>Dwight K. Elvey wrote: >> >> >> >>>Hi >>>I'm going to be setting up my older H8 to have the >>>H17 board installed. The problem is that this machine >>>has only the serial/cassette board ( H8-5 ) and not >>>the H8-4 serial board. Is this configuration possible? >>>I know that on the H89, the cassette and H17 are on >>>conficting addresses. Can one configure this older >>>setup to run without using the H8-4 board? Is there >>>a way to share or disable the cassette address on the >>>H8-5 board? >>>Thanks >>>Dwight >>> >>> >>>-- >>>Delivered by the SEBHC Mailing List >>> >>> >>> >>> >>> >>-- >>Delivered by the SEBHC Mailing List >> >> >> > > >-- >Delivered by the SEBHC Mailing List > > > From CarrollWaddell at sc.rr.com Thu May 27 21:18:37 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Thu, 27 May 2004 22:18:37 -0400 Subject: [sebhc] THANKS Message-ID: <40B6A17D.3020508@sc.rr.com> Thanks Walter If I can return the favor, let me know. Carroll -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Thu May 27 21:37:26 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Thu, 27 May 2004 21:37:26 -0500 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <200405272338.QAA21966@clulw009.amd.com> Message-ID: <000001c4445c$b7173d10$1f6fa8c0@eths.k12.il.us> > > Hi Jack > I have a tool that I've not released yet that I use. It > transfers an image between the H89/90 and a PC through the > serial ports. ... > It can be used to transfer images to and from the > H8x machine, as well. I'd like to check it out on at least > the H8-4 configuration before making the first release. I'll > then make another release for those that are restricted to > talking through only a H8-5 board. Patience please. I didn't > intend to take as long as I have but it should be ready soon. Dwight > I'm looking forward to it - do you need to borrow an 8-4 board for testing? Jack -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Thu May 27 21:48:21 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 19:48:21 -0700 (PDT) Subject: [sebhc] H8 configuration Message-ID: <200405280248.TAA22237@clulw009.amd.com> Hi You may have a problem reading the XCON8 on a programmer. They are using pin 21 as a CS so A11 has to be on one of the other pins for the ROM. I've only been able to dump the lower part of the ROM with the 2732 setup ( vpp=5 ) as the higher half of the 4K dump. The lower half reads 0ffh's. You may have to play with which line is A11. It does have the H17 code on it because I can clearly see it on my H8. Anyway, the H17 rom image is on the web site. You can just load that file into a 2716. That that you have from years ago should be the same as well. Dwight >From: "Carroll Waddell" > >I found some 2114's in my OLD STUFF drawer a little bit ago. The XCON8 >ROM may have the H17 code on it. If not, I'll try burning an EPROM. I >still have the H17 ROM code from years ago. >Carroll > >Dwight K. Elvey wrote: > >>Hi Carroll >> The ROM can just be a 2716 with code from the site as I recall. >>I don't think you need any special mods to use the 2716's. >>I think Anchor Electronics still has 2114's. There are also >>some board modifications that you'll need to make. Look at >>the pdf for the XCON8 to see what was modified ( I think it >>is just a jumper or two and a cap/resistor ). You need to >>undo these modifications as your board was configured >>for the XCON8 setup and not the PAM8( unless, of course that >>is what you have ). If you have the Z80 board you don't need >>either the ROM or RAM chips. >> I suspect that HDOS will find the serial port, it is just that >>my code is a complete bootstrap. My code runs before any >>thing else runs so I needs to initialize the serial port >>and specifically talk to it. It is not an application >>that runs under HDOS. The ROM only has code to talk to >>the cassette, not the serial. >> Remember, this is a bootstrap from ground zero. I do have >>code to write out the main code that I use for bootstrapping >>to the disk but, again, this is not a HDOS disk. It is >>just a disk that boots to the transfer program. I don't get >>all the HDOS calls to play with. This way, one only needs >>to enter the bootstrap code once from the front panel. >> Thanks for the port info. >> >> How many people out there have a PAM8 with the disk connected >>and running? What does your setup look like? >>Dwight >> >> >> >> >>>From: "Carroll Waddell" >>> >>>Dwight, >>>I'm working on the same configuration, but I plan to have both the H8-5 >>>and the H8-4 in the machine. The cassette interface is port 370Q, the >>>H8-5 terminal address is 372Q, and the H17 is 170Q-174Q. You can remove >>>the 8251 on the cassette board to disable the interface. >>>I'm pretty sure that if you don't have an H8-4, the software will use >>>the 372Q port on the H8-5. The H17 board that I bought was missing the >>>H17 ROM and the 2114 memory chips. When I locate them, I'm going to set >>>up a similiar system. >>>Carroll >>> >>>Dwight K. Elvey wrote: >>> >>> >>> >>>>Hi >>>>I'm going to be setting up my older H8 to have the >>>>H17 board installed. The problem is that this machine >>>>has only the serial/cassette board ( H8-5 ) and not >>>>the H8-4 serial board. Is this configuration possible? >>>>I know that on the H89, the cassette and H17 are on >>>>conficting addresses. Can one configure this older >>>>setup to run without using the H8-4 board? Is there >>>>a way to share or disable the cassette address on the >>>>H8-5 board? >>>>Thanks >>>>Dwight >>>> >>>> >>>>-- >>>>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 dwight.elvey at amd.com Thu May 27 21:53:56 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Thu, 27 May 2004 19:53:56 -0700 (PDT) Subject: [sebhc] Emulator future? + request for tools Message-ID: <200405280253.TAA22242@clulw009.amd.com> Hi Jack No, I have that with my Z80 H8 machine. I expect it'll work right away with the H8-4 since the ports are the same as on the H89 for the LP serial. The LP port on the H89 connects with a straight serial cable. I expect the H8 to do the same. If not, I do have a gender changer and jumper box. I just have to look up my 8251 init code for the H8-5 board. I can make another bootstrap for that quick enough. 8251's are tricky to get initialized. Dwight >From: "Jack Rubin" > >> >> Hi Jack >> I have a tool that I've not released yet that I use. It >> transfers an image between the H89/90 and a PC through the >> serial ports. >... >> It can be used to transfer images to and from the >> H8x machine, as well. I'd like to check it out on at least >> the H8-4 configuration before making the first release. I'll >> then make another release for those that are restricted to >> talking through only a H8-5 board. Patience please. I didn't >> intend to take as long as I have but it should be ready soon. Dwight >> > >I'm looking forward to it - do you need to borrow an 8-4 board for >testing? > >Jack > >-- >Delivered by the SEBHC Mailing List > -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Thu May 27 22:14:53 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Thu, 27 May 2004 20:14:53 -0700 (PDT) Subject: [sebhc] H8 configuration Message-ID: <200405280314.i4S3Eriv053168@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 28 May 2004 03:33:48 -0000 At 19:48 27/05/2004 -0700, you wrote: >Hi > You may have a problem reading the XCON8 on a programmer. >They are using pin 21 as a CS so A11 has to be on one >of the other pins for the ROM. I've only been able to dump >the lower part of the ROM with the 2732 setup ( vpp=5 ) >as the higher half of the 4K dump. The lower half reads >0ffh's. You may have to play with which line is A11. >It does have the H17 code on it because I can clearly >see it on my H8. > Anyway, the H17 rom image is on the web site. You can >just load that file into a 2716. That that you have from >years ago should be the same as well. >Dwight If you can see it on your H8, then you can dump it to the serial port (assuming you have an H5) using the PAM-8 DUMP command. You can use my H8T to capture it into a .HEX file just as if you had read it from a programmer: H8T COM1 ROMDATA.HEX [/I if you want Intel format HEX] 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 labomb at rochester.rr.com Thu May 27 22:26:06 2004 From: labomb at rochester.rr.com (Scott LaBombard) Date: Thu, 27 May 2004 23:26:06 -0400 Subject: [sebhc] Emulator future? + request for tools References: <200405280253.TAA22242@clulw009.amd.com> Message-ID: <00ee01c44463$832c34e0$02a8a8c0@IBMD9HY10WBGXB> Hi, The 8251 is indeed tricky to initialize. Somewhere in my travels (perhaps the spec sheet) I've found that delays between initialization commands are often necessary. Here is my 8251A init routine that seems to work quite reliably: CONSTAT EQU 0FBH ;IO STATUS PORT (H8-5) CONDATA EQU 0FAH ;IO DATA PORT (H8-5) CONRST EQU 040H ;8251A UART RESET CONMODE EQU 04EH ;8251A MODE WORD (16x clk,8,N,1) CONINIT EQU 035H ;8251A COMMAND WORD SETUP URTINI: MVI C,003H ;SEND 3 0's TO CLEAR UART (PER SPEC SHT) URT1: MVI A,000H OUT CONSTAT DCR C JNZ URT1 MVI A,CONRST ;UART INTERNAL RESET COMMAND OUT CONSTAT NOP ;DELAY MVI A,CONMODE ;SEND MODE COMMAND TO UART OUT CONSTAT NOP ;DELAY MVI A,CONINIT ;INITIALIZE UART OUT CONSTAT RET Scott ----- Original Message ----- From: "Dwight K. Elvey" To: Sent: Thursday, May 27, 2004 10:53 PM Subject: RE: [sebhc] Emulator future? + request for tools > Hi Jack > No, I have that with my Z80 H8 machine. I expect it'll > work right away with the H8-4 since the ports are the same > as on the H89 for the LP serial. The LP port on the H89 > connects with a straight serial cable. I expect the H8 > to do the same. If not, I do have a gender changer and > jumper box. > I just have to look up my 8251 init code for the H8-5 > board. I can make another bootstrap for that quick enough. > 8251's are tricky to get initialized. > Dwight > > > >From: "Jack Rubin" > > > >> > >> Hi Jack > >> I have a tool that I've not released yet that I use. It > >> transfers an image between the H89/90 and a PC through the > >> serial ports. > >... > >> It can be used to transfer images to and from the > >> H8x machine, as well. I'd like to check it out on at least > >> the H8-4 configuration before making the first release. I'll > >> then make another release for those that are restricted to > >> talking through only a H8-5 board. Patience please. I didn't > >> intend to take as long as I have but it should be ready soon. Dwight > >> > > > >I'm looking forward to it - do you need to borrow an 8-4 board for > >testing? > > > >Jack > > > >-- > >Delivered by the SEBHC Mailing List > > > > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From eric at rothfus.com Thu May 27 23:28:27 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Fri, 28 May 2004 00:28:27 -0400 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <000001c44440$0ec62980$1f6fa8c0@eths.k12.il.us> (jack.rubin@ameritech.net) References: <000001c44440$0ec62980$1f6fa8c0@eths.k12.il.us> Message-ID: <1085659707@rothfus.com> > Until SVD learns to read binary files, .h17 is the only way I have to > get files to and from my H8. Make you a deal...put a simple header, ANY header, on the binary images that can be recognized as a H8 image and the SVD will know how to read the file in less than 24 hours. :-) How about "6a 61 63 6b 20 72 75 62 69 6e 0a"? I bet Patrick can tell you what that header means... :-) Eric -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Fri May 28 00:17:38 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Fri, 28 May 2004 00:17:38 -0500 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <1085659707@rothfus.com> Message-ID: <000001c44473$18455020$1f6fa8c0@eths.k12.il.us> > > How about "6a 61 63 6b 20 72 75 62 69 6e 0a"? I bet Patrick > can tell you what that header means... :-) > I'm still a DOS guy - I'll need an 0d as well!! Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Fri May 28 00:46:45 2004 From: sp11 at hotmail.com (Steven Parker) Date: Fri, 28 May 2004 05:46:45 +0000 Subject: [sebhc] Emulator future? + request for tools Message-ID: > > That's what the "utilities" area in the archives is for .. >Unfortunately, with the exception of Dave's H8T contribution, it is >quite empty. I'm sure that's just the beginning of a collection. :-) >What are _you_ using to do all the file transformations >you've contributed? How are you getting from HDOS disk to uploaded image >and vice versa? I was building a program in linux, but it's incomplete. Since there's a complete one out there already, I'm just waiting to see that one posted! >Until SVD learns to read binary files, .h17 is the only way I have to >get files to and from my H8. If you make an octal dump and stick a one-line header in front of it you essentially have SVD format, right? Cheers, - Steven _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Delivered by the SEBHC Mailing List From eric at rothfus.com Fri May 28 08:15:54 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Fri, 28 May 2004 09:15:54 -0400 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <000001c44473$18455020$1f6fa8c0@eths.k12.il.us> (jack.rubin@ameritech.net) References: <000001c44473$18455020$1f6fa8c0@eths.k12.il.us> Message-ID: <1085718478@rothfus.com> >> >> How about "6a 61 63 6b 20 72 75 62 69 6e 0a"? I bet Patrick >> can tell you what that header means... :-) >> > > I'm still a DOS guy - I'll need an 0d as well!! > Jack :-) LOL -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Fri May 28 10:29:51 2004 From: patrick at vintagecomputermarketplace.com (Patrick) Date: Fri, 28 May 2004 08:29:51 -0700 Subject: [sebhc] Emulator future? + request for tools References: <000001c44473$18455020$1f6fa8c0@eths.k12.il.us> Message-ID: <003a01c444c8$9eceafb0$650fa8c0@Sol> > I'm still a DOS guy - I'll need an 0d as well!! > Jack ...and a 1a at the end of data? :-) --01010000011000010111010001110010011010010110001101101011 -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri May 28 14:04:45 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 28 May 2004 15:04:45 -0400 Subject: [sebhc] Hardware emulation Message-ID: <40B78D4D.2080802@sc.rr.com> I saw that someone had posted an H19 emulator program. I was currently working on an emulation program, and I was wondering if there were enough interest to continue. What I had in mind was this. An emulation program running on a PC, connected to an H8 by up to 3 serial ports. On the PC, COM1 would serve as the H19 emulation port. COM2 would emulate 2 cassette machines to emulate the tape system. COM3 would act as though it were a serial printer, then send printed information to a PC printer. Therefore, the PC would emulate an H19, 2 cassette machines, and a printer. What do you think? If there is enough interest, I will continue. If no one is interested, I will put my time toward something else. Carroll -- Delivered by the SEBHC Mailing List From me at patswayne.com Fri May 28 14:11:01 2004 From: me at patswayne.com (Pat Swayne) Date: Fri, 28 May 2004 15:11:01 -0400 Subject: [sebhc] Hardware emulation In-Reply-To: <40B78D4D.2080802@sc.rr.com> References: <40B78D4D.2080802@sc.rr.com> Message-ID: <6.1.0.6.2.20040528150731.030c8820@mail.patswayne.com> Carroll wrote: >Therefore, the PC would emulate an H19, 2 cassette machines, and a >printer. What do you think? >If there is enough interest, I will continue. If no one is interested, I >will put my time toward something else. Well, that's a bit more than mine, which is just a terminal emulator, so I'd say go ahead based on that. However, since no one has said that they have even tested mine, I don't know if anyone needs one. -- Pat -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Fri May 28 14:13:00 2004 From: waltm22 at comcast.net (Walter Moore) Date: Fri, 28 May 2004 12:13:00 -0700 Subject: [sebhc] Emulator future? + request for tools In-Reply-To: <003a01c444c8$9eceafb0$650fa8c0@Sol> Message-ID: <004c01c444e7$cef9ad60$0700a8c0@walterp4> > > I'm still a DOS guy - I'll need an 0d as well!! > > Jack > > ...and a 1a at the end of data? :-) > > --01010000011000010111010001110010011010010110001101101011 I guess I think of it as 11-1 12-1 12-3 11-2 (skip) 11-9 0-4 12-2 12-9 11-5 11-9-5, but if you insist on lower case, 12-11-1 12-0-1 12-0-3 12-11-2 (skip) 12-11-9 11-0-4 12-0-2 12-0-9 12-11-5 11-9-5 (this really hurt my brain to remember!). I guess this is worth about 12-0-1-8-9. ..walt -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Fri May 28 15:59:54 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Fri, 28 May 2004 16:59:54 -0400 Subject: [sebhc] Of ROMS and Things Message-ID: <40B7A84A.6070304@sc.rr.com> I just found out something I didn't know. The XCON8 ROM does contain the H17 ROM code. If your first memory card is above the ROM area (ie 040 000), then XCON8 does nothing with the H17 code. It is still in the ROM but not at the correct address, therefore, it won't conflict with the actual ROM on the H17 controller. If you have 0 org memory, XCON8 will remap the H17 ROM code into the correct address (starting at 030 000). It would seem then that the H17 disk system will work without the actual H17 ROM chip. I haven't tried it yet, but will as soon as I can get another big table in my shop. I've run out of room to spread things out. Carroll -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Fri May 28 17:22:42 2004 From: waltm22 at comcast.net (Walter Moore) Date: Fri, 28 May 2004 15:22:42 -0700 Subject: [sebhc] Of ROMS and Things In-Reply-To: <40B7A84A.6070304@sc.rr.com> Message-ID: <004d01c44502$4f716860$0700a8c0@walterp4> This is what I was reporting after putting my foot in my mouth. My H-17 never responds to the ROM addresses at 030.000 but since XCON put an image in RAM at 030.000, it all just works. Make sure your H-17 ROM logic was properly disabled per the XCON instructions, or it might still try and drive the bus for those addresses??? ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll > Waddell > Sent: Friday, May 28, 2004 2:00 PM > To: sebhc at staunch89er.com > Subject: [sebhc] Of ROMS and Things > > I just found out something I didn't know. The XCON8 ROM does contain the > H17 ROM code. If your first memory card is above the ROM area (ie 040 > 000), then XCON8 does nothing with the H17 code. It is still in the ROM > but not at the correct address, therefore, it won't conflict with the > actual ROM on the H17 controller. If you have 0 org memory, XCON8 will > remap the H17 ROM code into the correct address (starting at 030 000). > It would seem then that the H17 disk system will work without the actual > H17 ROM chip. I haven't tried it yet, but will as soon as I can get > another big table in my shop. I've run out of room to spread things out. > Carroll > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri May 28 18:18:57 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 28 May 2004 16:18:57 -0700 (PDT) Subject: [sebhc] My H8 Systems Message-ID: <200405282318.QAA23214@clulw009.amd.com> Hi Well, I finally connected everything up to see if it would boot from disk. As one might expect, no luck :( It is close. It selects the disk and turns on the motor but it is failing to step to track zero. The stepper motors seem OK. It is free with power off and locked with power on. I tried swapping the drives and also the controller card. Neither seemed to help. I started it both from the XCON8 routine ( that times out ) and I also started the disk init from 030.000. Both with the same results. The code seems to hange at 035.311 This seems to be waiting for some RAM to be updated by an interrupt. Does anyone have a pointer to the floppy connector diagram on the webb for a 5-1/4 drive? I have this around someplace ( even have an original manual ) but I never seem to find this stuff when needed. I get it running this weekend. Dwight -- Delivered by the SEBHC Mailing List From eric at rothfus.com Fri May 28 19:25:40 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Fri, 28 May 2004 20:25:40 -0400 Subject: [sebhc] My H8 Systems In-Reply-To: <200405282318.QAA23214@clulw009.amd.com> (dwight.elvey@amd.com) References: <200405282318.QAA23214@clulw009.amd.com> Message-ID: <1085789872@rothfus.com> Hey Dwight, I have ALL of this stuff at home, but am away with the family for the weekend. Fortunately, the interface is quite standard, and the following links seem to be correct: http://www.phm.lu/documentation/connectors/FDD.asp http://www.ctips.com/floppy.html Eric -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri May 28 19:24:24 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 28 May 2004 17:24:24 -0700 (PDT) Subject: [sebhc] My H8 Systems Message-ID: <200405290024.RAA23290@clulw009.amd.com> >From: "Dwight K. Elvey" > >Hi > Well, I finally connected everything up to see if >it would boot from disk. As one might expect, no luck :( >It is close. It selects the disk and turns on the motor >but it is failing to step to track zero. The stepper >motors seem OK. It is free with power off and locked >with power on. I tried swapping the drives and also >the controller card. Neither seemed to help. I started >it both from the XCON8 routine ( that times out ) and >I also started the disk init from 030.000. Both with >the same results. The code seems to hange at 035.311 >This seems to be waiting for some RAM to be updated >by an interrupt. > Does anyone have a pointer to the floppy connector >diagram on the webb for a 5-1/4 drive? I have this >around someplace ( even have an original manual ) >but I never seem to find this stuff when needed. I >get it running this weekend. >Dwight Hi I found the pinouts. Dwight -- Delivered by the SEBHC Mailing List From dwight.elvey at amd.com Fri May 28 13:37:50 2004 From: dwight.elvey at amd.com (Dwight K. Elvey) Date: Fri, 28 May 2004 11:37:50 -0700 (PDT) Subject: [sebhc] My H8 Systems Message-ID: <200405281837.LAA23095@clulw009.amd.com> Hi Well, I finally connected everything up to see if it would boot from disk. As one might expect, no luck :( It is close. It selects the disk and turns on the motor but it is failing to step to track zero. The stepper motors seem OK. It is free with power off and locked with power on. I tried swapping the drives and also the controller card. Neither seemed to help. I started it both from the XCON8 routine ( that times out ) and I also started the disk init from 030.000. Both with the same results. The code seems to hange at 035.311 This seems to be waiting for some RAM to be updated by an interrupt. Does anyone have a pointer to the floppy connector diagram on the webb for a 5-1/4 drive? I have this around someplace ( even have an original manual ) but I never seem to find this stuff when needed. I get it running this weekend. Dwight -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Fri May 28 23:20:23 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sat, 29 May 2004 04:20:23 +0000 Subject: [sebhc] My H8 Systems Message-ID: Dwight says: >The code seems to hange at 035.311 >This seems to be waiting for some RAM to be updated >by an interrupt. That's the generic delay routine, watching the TICCNT value. The step motor routine uses it to pace head motions. If it's trying to move the head to home and not making it, it would make sense that it spends a lot of time in this routine. If you've got more than one drive and none step, perhaps the controller board isn't asserting the step line properly in response to the I/O port commands. On my own status: Thanks to Walt, all the power swtiches work now. :-) I also replaced the blown cap on the 3rd H8's CPU board and now it comes up .. sortof. Sometimes it comes up and looks normal, other times it seems to come up running in user mode (the pc is displayed, and changing). Even when it comes up and looks normal something else is odd. If I try the memory test it crashes with lights out and continuous tone. I'll have to do some more testing on that one. Still haven't done anything yet with the drive that steps one way only. Cheers, - Steven _________________________________________________________________ Learn to simplify your finances and your life in Streamline Your Life from MSN Money. http://special.msn.com/money/0405streamline.armx -- Delivered by the SEBHC Mailing List From cfandt at netsync.net Sat May 29 07:36:54 2004 From: cfandt at netsync.net (Christian Fandt) Date: Sat, 29 May 2004 08:36:54 -0400 Subject: The "Sort-of" H8 (WAS:Re: [sebhc] My H8 Systems) In-Reply-To: Message-ID: <5.2.1.1.2.20040529075808.0254d1f0@pop3.norton.antivirus> Upon the date 04:20 AM 5/29/04 +0000, Steven Parker said something like: -- snip -- >On my own status: > >Thanks to Walt, all the power swtiches work now. :-) I also replaced the >blown cap on the 3rd H8's CPU board and now it comes up .. sortof. >Sometimes it comes up and looks normal, other times it seems to come up >running in user mode (the pc is displayed, and changing). Even when it >comes up and looks normal something else is odd. If I try the memory test >it crashes with lights out and continuous tone. I'll have to do some more >testing on that one. Since there was a blown cap on the CPU board, there may be another which is exhibiting a too high ESR and as a result, is not doing its job. That is to say, electrical noise filtering or ripple suppression on the particular +5V line going to whatever chip or set of chips the suspected high ESR cap serves to filter is not being done as well as designed. That noise probably makes the logic in that area unstable. Figure as much as a quarter volt ripple riding on the DC supply could cause logic timing to be affected. The DC supply should be rather clean. Check the voltage levels with a meter. A high ESR (Effective Series Resistance) can be caused by the electrolyte literally drying out of an electrolytic capacitor. The cap's dielectric breaks down under voltage, things heat up, and pow! You should see what that is like with a large main filter cap when that happens! Something you will NOT forget if you were there to witness it. If you have an oscilloscope you should check the +5V supply all the way from the main filter caps in the power supply and all the way through the CPU board. Check other boards too if the main supply caps are okay. You will be looking for too high ripple or other trash noise on the supply line. Should be, I figure, ten to twenty millivolts or so maximum ripple for a nice clean DC supply on something like this. Preferably less. Just a strong suspicion based upon past experiences . . . Good luck, Chris F. NNNN Christian Fandt, Electronic/Electrical Historian Jamestown, NY USA cfandt at netsync.net Member of Antique Wireless Association URL: http://www.antiquewireless.org/ -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 29 12:57:32 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 13:57:32 -0400 Subject: [sebhc] Congrats Message-ID: <40B8CF0C.80409@sc.rr.com> I just wanted to congratulate myself. I now have a fully restored H8 tape system, complete with 2 REAL cassette machines, and an H19 terminal. It's fun to play hangman just like I did 20 years ago. Carroll -- Delivered by the SEBHC Mailing List From melamy at earthlink.net Sat May 29 13:23:42 2004 From: melamy at earthlink.net (melamy at earthlink.net) Date: Sat, 29 May 2004 11:23:42 -0700 Subject: [sebhc] Congrats Message-ID: <290504150.41019@webbox.com> Hi Carroll, do you find twenty years of wisdom has increased or decreased your chances of winning at hangman??? :) comgrats on the resurrection! best regards, Steve Thatcher >--- Original Message --- >From: Carroll Waddell >To: sebhc at staunch89er.com >Date: 5/29/04 12:57:32 PM > I just wanted to congratulate myself. I now have a fully restored H8 >tape system, complete with 2 REAL cassette machines, and an H19 >terminal. It's fun to play hangman just like I did 20 years ago. >Carroll > >-- >Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From patrick at vintagecomputermarketplace.com Sat May 29 13:29:38 2004 From: patrick at vintagecomputermarketplace.com (Patrick) Date: Sat, 29 May 2004 11:29:38 -0700 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 Message-ID: <008701c445aa$e6d21120$650fa8c0@Sol> Sorry if this ends up being a repeat... I sent from the wrong address... Does anyone have the instructions necessary to modify an ET-3400 for use with the ETA-3400 expansion accessory? I have everything but those instructions. Thanks! Patrick -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sat May 29 13:54:35 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 29 May 2004 13:54:35 -0500 Subject: [sebhc] Congrats In-Reply-To: <40B8CF0C.80409@sc.rr.com> Message-ID: <000001c445ae$62fb02e0$1f6fa8c0@eths.k12.il.us> > I just wanted to congratulate myself. I now have a fully restored H8 > tape system, complete with 2 REAL cassette machines, and an H19 > terminal. It's fun to play hangman just like I did 20 years > ago. Carroll > Carroll, I've been saving this for a special occasion - looks like you earned it --- >From the January, 1988 issue of H-SCOOP - FOR SALE--Three H8 computers, 8080 CPU cards, Trionyx 64K memory, three 8K cards, one 16K card, H8-5 tape/serial cards, H8-4 serial card, H17 hard sector controller, H17 cabinet with three 5.25 inch drives, H8 wire wrap cards, miscellaneous parts for H8, H9 terminal, H19 terminal, H25 printer with extra ribbons, Epson MX-80 printer, CP/M operating system, Microsoft Basic-80, Basic-80 compiler, Nevada Fortran, manuals, cassette tape programs, tape recorder, Eliza Al program, many diskettes, miscellaneous programs, assorted parts, IC's, capacitors if you want them. EICO 3570 stereo amp if you want it. $850 or make an offer. Carroll E. Waddell/ 16 Parish Street/ Sumter, S.C. 29150/ (803) 773-4076 after 5:00 p.m. (Eastern time). :>) Jack -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 29 14:33:03 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 15:33:03 -0400 Subject: [sebhc] Congrats In-Reply-To: <290504150.41019@webbox.com> References: <290504150.41019@webbox.com> Message-ID: <40B8E56F.1020806@sc.rr.com> I still lose....only much faster. CW melamy at earthlink.net wrote: >Hi Carroll, do you find twenty years of wisdom has increased >or decreased your chances of winning at hangman??? :) > >comgrats on the resurrection! > >best regards, Steve Thatcher > > > >>--- Original Message --- >>From: Carroll Waddell >>To: sebhc at staunch89er.com >>Date: 5/29/04 12:57:32 PM >> >> >> >I just wanted to congratulate myself. I now have a fully restored >H8 > > >>tape system, complete with 2 REAL cassette machines, and an >> >> >H19 > > >>terminal. It's fun to play hangman just like I did 20 years >> >> >ago. > > >>Carroll >> >>-- >>Delivered by the SEBHC Mailing List >> >> > > >-- >Delivered by the SEBHC Mailing List > > > From CarrollWaddell at sc.rr.com Sat May 29 14:40:50 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 15:40:50 -0400 Subject: [sebhc] H17 DRIVES Message-ID: <40B8E742.9050400@sc.rr.com> Has anyone found an H17 diskette drive for sale. I just tried the H17 controller board (the one without the ROM or RAM), with XCON8. It says PRI H 17 , it is trying to boot, but it doesn't. Of course one problem is that I don't have a boot diskette, but I also don't have a diskette drive. I had a number of old 5 1/4 drives, but none that I've tried will work. It will turn on the motor when it tries to boot, but the drive is not selected, the drive select light never comes on. The old IBM PC drives I have do not have jumper for DS selection. If anyone has a copy of the CPM boot diskette, I sure would like to borrow it for a while. (Assuming I ever get a drive.) And by the way Jack, that H8 stuff did not sell. And I still have that EICO amp that I built in 1968. Carroll -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sat May 29 14:58:54 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sat, 29 May 2004 12:58:54 -0700 Subject: [sebhc] H17 DRIVES In-Reply-To: <40B8E742.9050400@sc.rr.com> Message-ID: <005701c445b7$62c47370$0700a8c0@walterp4> Are you sure that the drives are properly selected? Remember that for the H-17 drives, the DS select lines on the programming shunt are backwards. A jumper on DS3 selects device 0. For the 96 tpi drives, it is normal (how did they manage that?). I've not had any problems missing a termination resistor, but I may have been lucky. Depending on how the drives are jumpered, the motor will come on regardless of which drive is selected. You can also try register A = 1 for drive 1 and A = 2 for drive 2 to see if the drive is jumpered other than drive 0. I've got a stack of these drives here, I can send you one or two that work reasonable well if you need them. I'll also look at the others if you want. I've manage to resurrect a lot of these drives. I think all my CP/M disks are soft-sectored. ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll > Waddell > Sent: Saturday, May 29, 2004 12:41 PM > To: sebhc at staunch89er.com > Subject: [sebhc] H17 DRIVES > > Has anyone found an H17 diskette drive for sale. I just tried the H17 > controller board (the one without the ROM or RAM), with XCON8. It says > PRI H 17 , it is trying to boot, but it doesn't. Of course one problem > is that I don't have a boot diskette, but I also don't have a diskette > drive. I had a number of old 5 1/4 drives, but none that I've tried will > work. It will turn on the motor when it tries to boot, but the drive is > not selected, the drive select light never comes on. The old IBM PC > drives I have do not have jumper for DS selection. If anyone has a copy > of the CPM boot diskette, I sure would like to borrow it for a while. > (Assuming I ever get a drive.) > And by the way Jack, that H8 stuff did not sell. And I still have that > EICO amp that I built in 1968. > Carroll > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From jack.rubin at ameritech.net Sat May 29 15:16:47 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 29 May 2004 15:16:47 -0500 Subject: [sebhc] H17 DRIVES In-Reply-To: <40B8E742.9050400@sc.rr.com> Message-ID: <000001c445b9$de992020$1f6fa8c0@eths.k12.il.us> > > Has anyone found an H17 diskette drive for sale. I just tried the H17 > controller board (the one without the ROM or RAM), with > XCON8. It says > PRI H 17 , it is trying to boot, but it doesn't. Of course > one problem that's good - you've proven that you don't need the PAM8 ROM - > is that I don't have a boot diskette, but I also don't have a > diskette > drive. I had a number of old 5 1/4 drives, but none that I've > tried will > work. It will turn on the motor when it tries to boot, but > the drive is > not selected, the drive select light never comes on. The old IBM PC > drives I have do not have jumper for DS selection. If anyone > has a copy > of the CPM boot diskette, I sure would like to borrow it for a while. Make sure you have the jumpers on the drive configured correctly - the H17 controller works "backwards" - you need to setup SYS0: as DS3; SYS2: is configured as DS1; HS should be strapped and MX must be open - check out the drive strapping illustrations in the H17 manual. I'm using a Tandon drive (with the IBM logo) with a hard sector controller in my H89 which is set up the same way - your "old" IBM drives may not be old enough! If I can stop breaking my H8 long enough to copy a boot disk for you, I'll be glad to provide one, but if somebody else can help out, please chime in! Jack -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 29 15:18:25 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 16:18:25 -0400 Subject: [sebhc] H17 DRIVES In-Reply-To: <005701c445b7$62c47370$0700a8c0@walterp4> References: <005701c445b7$62c47370$0700a8c0@walterp4> Message-ID: <40B8F011.7070502@sc.rr.com> Yes. I would be interested. I've only started working with the diskettes. I was going to look at the schematic of the controller, and the schematic for the IBM drives and see what I could do. Thanks again for the switches. When I started working with the H17 drive enclosure, the power switch was bad. This is an old 3 drive enclosure that I bought many years ago. I'll pay you for whatever you want to sell. Carroll Walter Moore wrote: >Are you sure that the drives are properly selected? Remember that for the >H-17 drives, the DS select lines on the programming shunt are backwards. >A jumper on DS3 selects device 0. For the 96 tpi drives, it is normal (how >did they manage that?). I've not had any problems missing a termination >resistor, but I may have been lucky. Depending on how the drives are >jumpered, the motor will come on regardless of which drive is selected. You >can also try register A = 1 for drive 1 and A = 2 for drive 2 to see if the >drive is jumpered other than drive 0. > >I've got a stack of these drives here, I can send you one or two that work >reasonable well if you need them. I'll also look at the others if you want. >I've manage to resurrect a lot of these drives. > >I think all my CP/M disks are soft-sectored. > >..walt > > > >>-----Original Message----- >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll >>Waddell >>Sent: Saturday, May 29, 2004 12:41 PM >>To: sebhc at staunch89er.com >>Subject: [sebhc] H17 DRIVES >> >>Has anyone found an H17 diskette drive for sale. I just tried the H17 >>controller board (the one without the ROM or RAM), with XCON8. It says >>PRI H 17 , it is trying to boot, but it doesn't. Of course one problem >>is that I don't have a boot diskette, but I also don't have a diskette >>drive. I had a number of old 5 1/4 drives, but none that I've tried will >>work. It will turn on the motor when it tries to boot, but the drive is >>not selected, the drive select light never comes on. The old IBM PC >>drives I have do not have jumper for DS selection. If anyone has a copy >>of the CPM boot diskette, I sure would like to borrow it for a while. >>(Assuming I ever get a drive.) >>And by the way Jack, that H8 stuff did not sell. And I still have that >>EICO amp that I built in 1968. >>Carroll >> >>-- >>Delivered by the SEBHC Mailing List >> >> > > > >-- >Delivered by the SEBHC Mailing List > > > From jack.rubin at ameritech.net Sat May 29 15:20:18 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sat, 29 May 2004 15:20:18 -0500 Subject: [sebhc] H17 DRIVES In-Reply-To: <005701c445b7$62c47370$0700a8c0@walterp4> Message-ID: <000101c445ba$5c93f310$1f6fa8c0@eths.k12.il.us> > Are you sure that the drives are properly selected? Remember > that for the H-17 drives, the DS select lines on the > programming shunt are backwards. A jumper on DS3 selects > device 0. For the 96 tpi drives, it is normal (how did they > manage that?). I've not had any problems missing a > termination resistor, but I may have been lucky. I can't boot without a termination resistor in place, but I have fairly long cables (about 24"). If you are running your 96 tpi drives off the soft-sector controller, then they are strapped like the rest of the world for any controller other than the hard-sectored cards in either the H8 or H89. Jack -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sat May 29 15:24:40 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sat, 29 May 2004 13:24:40 -0700 Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 In-Reply-To: <008701c445aa$e6d21120$650fa8c0@Sol> Message-ID: <005801c445bb$02183bc0$0700a8c0@walterp4> 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. I compared an unmodified ET-3400 (no 'A', no 'Series') with one that was modified and found the following differences: 1) A 40 pin connector added (OK, I had to say that :) ) 2) D0-D7 connected on said 40 pin connector. If you examine the back of the board, you will find 8 solder pads for D0-D7 below the 40 pin connector. Each of these was soldered to the corresponding via (is that what those holes are called???) next to IC9 and IC10 (to the side on an ET-3400, below on a 3400 "Series"). 3) Pins 6 & 35 of the 40 pin connector (NC on the schematic) connected to IC10 pin 1, soldered at the first via as the trace moves towards the top of the board. 4) Pins 15 & 20 (also NC on the schematic) connected to ?2 near IC4. Looking at the X-Ray layout picture, this was confusing to me. It wire was connected to the right pin of the 4x2 breadboard socket. From the front, this looks like it is labeled "?2", from the X-Ray it looks like "?2" is the 3rd pin). 5) The RAMs were removed. This system was purchased on eBay, and at least powers up. I've never hooked up a terminal or tape deck to try anything else out. Do you have the Software Reference Manual (595-2271) for the ETA-3400? ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Patrick > Sent: Saturday, May 29, 2004 11:30 AM > To: sebhc at sebhc.org > Subject: [sebhc] The 8-bit Runt of the Litter: ET-3400 > > Sorry if this ends up being a repeat... I sent from the wrong address... > > Does anyone have the instructions necessary to modify an ET-3400 for use > with the ETA-3400 expansion accessory? I have everything but those > instructions. > > Thanks! > Patrick > > -- > Delivered by the SEBHC Mailing List -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 29 18:02:01 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 19:02:01 -0400 Subject: [sebhc] H17 DRIVES In-Reply-To: <000001c445b9$de992020$1f6fa8c0@eths.k12.il.us> References: <000001c445b9$de992020$1f6fa8c0@eths.k12.il.us> Message-ID: <40B91669.90303@sc.rr.com> I drug out my old IBM documentation and did a little soldering on the circuit board. Now the drive will select properly, speed test is ok, write gate test is OK, but the overall test described in the H17 manual doesn't run right. Comes to 037 306 instead of 037 365. The only thing it says is test the speed and write gate. Both are correct. It might actually work if I had a boot diskette. I bought some through ebay, but they look like they were in someones junk box. No sleeves, dirty, etc. I do have 3 or 4 that looked good. BTW, this drive does have the termination resistor pack in it, and it is the last one on the cable. Jumpered as SY0. When my old system was working, I had 3 drives. I can't tell which lines were used to select drive c, but I remember having drives A, B, and C when I was running CPM. Maybe someone has the documentation for the three drive enclosure. Carroll Jack Rubin wrote: >>Has anyone found an H17 diskette drive for sale. I just tried the H17 >>controller board (the one without the ROM or RAM), with >>XCON8. It says >>PRI H 17 , it is trying to boot, but it doesn't. Of course >>one problem >> >> > >that's good - you've proven that you don't need the PAM8 ROM - > > > >>is that I don't have a boot diskette, but I also don't have a >>diskette >>drive. I had a number of old 5 1/4 drives, but none that I've >>tried will >>work. It will turn on the motor when it tries to boot, but >>the drive is >>not selected, the drive select light never comes on. The old IBM PC >>drives I have do not have jumper for DS selection. If anyone >>has a copy >>of the CPM boot diskette, I sure would like to borrow it for a while. >> >> > >Make sure you have the jumpers on the drive configured correctly - the >H17 controller works "backwards" - you need to setup SYS0: as DS3; SYS2: >is configured as DS1; HS should be strapped and MX must be open - check >out the drive strapping illustrations in the H17 manual. I'm using a >Tandon drive (with the IBM logo) with a hard sector controller in my H89 >which is set up the same way - your "old" IBM drives may not be old >enough! > >If I can stop breaking my H8 long enough to copy a boot disk for you, >I'll be glad to provide one, but if somebody else can help out, please >chime in! > >Jack > >-- >Delivered by the SEBHC Mailing List > > > From CarrollWaddell at sc.rr.com Sat May 29 18:17:21 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 19:17:21 -0400 Subject: [sebhc] BOOT DISKETTE Message-ID: <40B91A01.4070105@sc.rr.com> I'm not sure if I made it clear, when I said I needed a boot diskette, I prefer a CP/M 2.2 boot diskette. That's what I used to have. Of course, anything that will boot will let me test the drives. Carroll -- Delivered by the SEBHC Mailing List From waltm22 at comcast.net Sat May 29 18:28:51 2004 From: waltm22 at comcast.net (Walter Moore) Date: Sat, 29 May 2004 16:28:51 -0700 Subject: [sebhc] H17 DRIVES In-Reply-To: <40B91669.90303@sc.rr.com> Message-ID: <005f01c445d4$b437de00$0700a8c0@walterp4> What model number is the drive? ..walt > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll > Waddell > Sent: Saturday, May 29, 2004 4:02 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] H17 DRIVES > > I drug out my old IBM documentation and did a little soldering on the > circuit board. Now the drive will select properly, speed test is ok, > write gate test is OK, but the overall test described in the H17 manual > doesn't run right. Comes to 037 306 instead of 037 365. The only thing > it says is test the speed and write gate. Both are correct. It might > actually work if I had a boot diskette. I bought some through ebay, but > they look like they were in someones junk box. No sleeves, dirty, etc. I > do have 3 or 4 that looked good. BTW, this drive does have the > termination resistor pack in it, and it is the last one on the cable. > Jumpered as SY0. When my old system was working, I had 3 drives. I > can't tell which lines were used to select drive c, but I remember > having drives A, B, and C when I was running CPM. Maybe someone has the > documentation for the three drive enclosure. > Carroll -- Delivered by the SEBHC Mailing List From CarrollWaddell at sc.rr.com Sat May 29 18:49:53 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Sat, 29 May 2004 19:49:53 -0400 Subject: [sebhc] H17 DRIVES In-Reply-To: <005f01c445d4$b437de00$0700a8c0@walterp4> References: <005f01c445d4$b437de00$0700a8c0@walterp4> Message-ID: <40B921A1.9080904@sc.rr.com> If you're referring to the IBM drive, I don't recall, but it is the original 360K drive that came in the early IBM PC. The old H17 drives I used to have were the Siemens FD100. CEW Walter Moore wrote: >What model number is the drive? > >..walt > > > >>-----Original Message----- >>From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Carroll >>Waddell >>Sent: Saturday, May 29, 2004 4:02 PM >>To: sebhc at sebhc.org >>Subject: Re: [sebhc] H17 DRIVES >> >>I drug out my old IBM documentation and did a little soldering on the >>circuit board. Now the drive will select properly, speed test is ok, >>write gate test is OK, but the overall test described in the H17 manual >>doesn't run right. Comes to 037 306 instead of 037 365. The only thing >>it says is test the speed and write gate. Both are correct. It might >>actually work if I had a boot diskette. I bought some through ebay, but >>they look like they were in someones junk box. No sleeves, dirty, etc. I >>do have 3 or 4 that looked good. BTW, this drive does have the >>termination resistor pack in it, and it is the last one on the cable. >>Jumpered as SY0. When my old system was working, I had 3 drives. I >>can't tell which lines were used to select drive c, but I remember >>having drives A, B, and C when I was running CPM. Maybe someone has the >>documentation for the three drive enclosure. >>Carroll >> >> > > > >-- >Delivered by the SEBHC Mailing List > > > From dave04a at dunfield.com Sun May 30 06:56:48 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 30 May 2004 04:56:48 -0700 (PDT) Subject: [sebhc] H8 Emulator update Message-ID: <200405301156.i4UBulpf012501@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 30 May 2004 12:18:54 -0000 I have just posted to my web site the version of the emulator that I will be releasing to my museum site the next time I do an update. http://www.dunfield.com/pub/H8.ZIP As this will be independant of SEBHC, I have included images of the oldest Tape software that I have, as well as an HDOS boot image - in other words, it's a complete package that should let anyone experience the H8. I have added some background information to the help file, improved the README, and (probably of most interest to some of you guys): extended the virtual I/O device interface, and documented more simulator data areas, allowing much more capability in user installed virtual devices. Please forward any comments, change/addition requests etc. ASAP. Enjoy, 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 Sun May 30 10:25:27 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 30 May 2004 15:25:27 +0000 Subject: [sebhc] H8 Emulator update Message-ID: Dave says: >Please forward any comments, change/addition requests etc. ASAP. > >I've provided ... a bootable HDOS disk image in the file HDOS16.H8D. Why not provide HDOS 2.0 instead? It's the last of the (Heath) HDOS releases. >You can use the /I command option force the simulator to ignore the bad >instruction,... Does it still just ignore? Or does it cause all opcodes to behave like a real 8080? (like the other codes for jmp, ret, call, etc). It would be nice to have a "real 8080" mode if /I doesn't do it. (and you're missing the word "to" between "option" and "force") >!PAM-8 GO monitor >S123000011F903210A20C33B00CD5A001600C38100CD5A001AC3A401C325202618C3230030 >S1230020C328206BE30ED2E9C32B20F5AFC36302C32E203ED0C39D01C331201A772B1CC292 >... This format is different from the other .HEX's. I don't recognize it, what is it? Cheers, - Steven _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sun May 30 11:31:55 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 30 May 2004 09:31:55 -0700 (PDT) Subject: [sebhc] H8 Emulator update Message-ID: <200405301631.i4UGVsH6016263@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 30 May 2004 16:53:11 -0000 Hi Stevem. >>I've provided ... a bootable HDOS disk image in the file HDOS16.H8D. >Why not provide HDOS 2.0 instead? It's the last of the (Heath) HDOS >releases. Two reasons: 1) The HDOS1.6 disk has the assembler on it (as well as edit and BASIC) - since the disks are big I don't want to have to include too many of them. 2) The HDOS 2.0 drivers have the softare timing loop issue which prevents booting it in "bat out of heck" mode. >>You can use the /I command option force the simulator to ignore the bad >>instruction,... > >Does it still just ignore? Or does it cause all opcodes to behave like a >real 8080? (like the other codes for jmp, ret, call, etc). It would be >nice to have a "real 8080" mode if /I doesn't do it. Not currently - it's doable, but why are you so concerned about invalid opcodes? - I won't think this should be an issue (except of course for the HASL thing - which is a NOP in disguise). Did Heath use the other undoced opcodes? >(and you're missing the word "to" between "option" and "force") Thanks. >>!PAM-8 GO monitor >>S123000011F903210A20C33B00CD5A001600C38100CD5A001AC3A401C325202618C3230030 >>S1230020C328206BE30ED2E9C32B20F5AFC36302C32E203ED0C39D01C331201A772B1CC292 >>... > >This format is different from the other .HEX's. I don't recognize it, what >is it? It's Motorola hex download format - My tools (and H8) accept either format, and produce either, however Motorola format by default due to the fact that I've spent a lot more time working with Motorola MCU's, and also I think it's a bit cleaner. 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 jack.rubin at ameritech.net Sun May 30 12:23:57 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 30 May 2004 12:23:57 -0500 Subject: [sebhc] H8 Emulator update In-Reply-To: <200405301156.i4UBulpf012501@gatekeeper.evocative.com> Message-ID: <000001c4466a$e4668c20$1f6fa8c0@eths.k12.il.us> > > I have added some background information to the help file, > improved the README, and (probably of most interest to some > of you guys): extended the virtual I/O device interface, and > documented more simulator data areas, allowing much more > capability in user installed virtual devices. > > Please forward any comments, change/addition requests etc. ASAP. Dave, this just keeps getting better - I'm having a lot more trouble breaking it! ;>) - here's the only way I could do it this time around - my normal ini file looks like this: L=pam8go.hex W1=hdos20.h8d XS=0 However, if I start with an .ini file that _only_ loads the rom - L=pam8go.hex and don't mount a disk (f5) before hitting GO (4) then the entire emulator just vanishes! This is in a WinXP environment - I havn't tried it under Win2K or DOS. Here's a minor quibble - would you consider renaming the f5 function to "load" or "insert" a disk? Mount isn't really correct since after I mount a disk with f5, my next step is to return to tty mode and mount the disk again. Another "problem" is with the low level commands INIT and SYSGEN - if I try to run INIT, it exits gracefully with the error message "Wrong type of media ...". I can ctrl-D out of it and reboot, but I can't initialize a disk. Likewise with SYSGEN - if I attempt to gen a disk, I get an error saying the disk is not initialized by the correct version of INIT (I haven't tried to figure out which disk-images were made from disks created under which versions of HDOS, so this may be a legitimate response). I have no problem deleting/copying/writing to disk, so within the OS everything works well, but my impression is that these utilities essentially work outside of HDOS in their own environment. Still, it seems like they ought to work if everything about the emulation is on target. Finally, just a few more suggestions, related to disk handling. Would you add a couple of "indicators" to the f5/D display so that we could see if drives are loaded R or W/R? Or if you felt really ambitious, how about a persistent version of the f5 information bar that would show drive, label of disk loaded, w/r status and drive select? It's becoming obvious that we somehow have to find you an H17 setup so that it will be "your" system! There is a 6-page "HDOS Cookbook" that is part of the software reference manual which I think would be helpful to museum visitors. I'll try to find the correct 1.x version and OCR it down to a minimal text file if you would like to include it as part of the "display". Awesome! Best, Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Sun May 30 17:22:05 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Sun, 30 May 2004 15:22:05 -0700 (PDT) Subject: [sebhc] H8 Emulator update Message-ID: <200405302222.i4UMM5O2021289@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 30 May 2004 22:52:13 -0000 >Dave, this just keeps getting better - I'm having a lot more trouble >breaking it! ;>) Thats the idea! >- here's the only way I could do it this time around - my normal ini >file looks like this: > >L=pam8go.hex >W1=hdos20.h8d >XS=0 > >However, if I start with an .ini file that _only_ loads the rom - > >L=pam8go.hex > >and don't mount a disk (f5) before hitting GO (4) then the entire >emulator just vanishes! This is in a WinXP environment - I havn't tried >it under Win2K or DOS. This would be the old 80x86 CPU fart at running the stack misaligned off the top of the 64k segment - I really don't want to fix it because it will really slow the thing down (have to break all stack transfers (always a word) into two separete byte operations, and then reassemble them afterward. When you do this, you are doing EXACTLY the same thing that you did in the beginning when you ran at 040,000 - you are executing the PAM8 address space. The reason for this is that (as documented), the H17 system (IO ports and ROM) are **NOT INSTALLED** in the simulation until you mount a disk - this allows me to simulate my machine, and still let you have a disk. So - pressing '4' goes at 030.000 which executes NOP's up until 040.000 where it does exactly what it did before. I could give you an option to put in the INI file to install the H17 without mounting a disk (or you could just mount a disk - it can be re-mounted at any time). Another thing I could do would be to initialize the 8080 memory address space to $76 (HLT) instead of $00 (NOP) - this would cause the cpu to reset to PAM-8 if you execute unititialized memory - not really like a true H8 (but hey - theoritically, an H8 *could* power-up with HLT's throughout memory!) >Here's a minor quibble - would you consider renaming the f5 function to >"load" or "insert" a disk? Mount isn't really correct since after I >mount a disk with f5, my next step is to return to tty mode and mount >the disk again. F5 isn't load or insert ... at least not for the tape files. Mount seems most "correct" to me (It's also what I call the function in my other emulators and I do like to maintain consistancy) - unles this is a real problem for you, I would like to leave it as it is. >Another "problem" is with the low level commands INIT and SYSGEN - if I >try to run INIT, it exits gracefully with the error message "Wrong type >of media ...". I can ctrl-D out of it and reboot, but I can't initialize >a disk. Likewise with SYSGEN - if I attempt to gen a disk, I get an >error saying the disk is not initialized by the correct version of INIT >(I haven't tried to figure out which disk-images were made from disks >created under which versions of HDOS, so this may be a legitimate >response). I'll have to look into them - I wouldn't be supprised if there's a software timing issue. Another thing - My driver builds the sector header on the fly, and I may not gracefully handle someone trying to write to it - I'll look into it when I have a chance - in the meantime, DOS copy works great to replicate a disk - perhaps we could include a "blank" disk image for now. Perhaps Steven will be able to provide me with some info on exactly what these commands do and in what order - but no rush, I'm going to be tied up with "real work" this week. >Finally, just a few more suggestions, related to disk handling. Would >you add a couple of "indicators" to the f5/D display so that we could >see if drives are loaded R or W/R? Already there - If you look at the status line when you press F5/D, you will see something like: R1:name1 W2:name1 W3:name1 The R1 tells you that drive 1 is Read-only, the W2 and W3 tell you that these drives are read-Write. >It's becoming >obvious that we somehow have to find you an H17 setup so that it will be >"your" system! Yes please! >There is a 6-page "HDOS Cookbook" that is part of the software reference >manual which I think would be helpful to museum visitors. I'll try to >find the correct 1.x version and OCR it down to a minimal text file if >you would like to include it as part of the "display". That would be great! Most people will (like me) have only the HELP command which is a bit "light" - even a few pages of reference would be really helpful. 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 jack.rubin at ameritech.net Sun May 30 18:02:43 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 30 May 2004 18:02:43 -0500 Subject: [sebhc] H8 Emulator update In-Reply-To: <200405302222.i4UMM5O2021289@gatekeeper.evocative.com> Message-ID: <000001c4469a$379cd730$1f6fa8c0@eths.k12.il.us> > > So - pressing '4' goes at 030.000 which executes NOP's up > until 040.000 where it does exactly what it did before. At least I'm consistent - I know what not to do, so I'll just stop doing it! And with no throttling, it does it fast. > F5 isn't load or insert ... at least not for the tape files. > Mount seems most "correct" to me (It's also what I call the > function in my other emulators and I do like to maintain > consistancy) - unles this is a real problem for you, I would > like to leave it as it is. > no problem - we both know what's happening here > I'll have to look into them - I wouldn't be supprised if > there's a software timing issue. > > Another thing - My driver builds the sector header on the > fly, and I may not gracefully handle someone trying to write > to it - I'll look into it when I have a chance - in the > meantime, DOS copy works great to replicate a disk - perhaps > we could include a "blank" disk image for now. > I thought I saw a blank disk image at one point, but I couldn't find it today. I just deleted everything from one of the images and renamed it "EMPTY". I wanted to INIT it so I could change the volume label; I guess I can do that with the DUMP utility, but that seems a little heavy handed. Otherwise, copying on the host works fine for now but I'm still looking ahead to the ability to (transparently) swap real and virtual disks between real and virtual machines. > Already there - If you look at the status line when you press > F5/D, you > will see something like: R1:name1 W2:name1 W3:name1 > The R1 tells you that drive 1 is Read-only, the W2 and W3 > tell you that these drives are read-Write. whoops - sorry - never bothered to mount a disk RO to see if it changed. If you get bored, you could still do a drive select light. > >There is a 6-page "HDOS Cookbook" that is part of the software > >reference manual which I think would be helpful to museum visitors. > >I'll try to find the correct 1.x version and OCR it down to > a minimal > >text file if you would like to include it as part of the "display". > > That would be great! Most people will (like me) have only the > HELP command which is a bit "light" - even a few pages of > reference would be really helpful. > Will do! Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 30 18:37:50 2004 From: sp11 at hotmail.com (Steven Parker) Date: Sun, 30 May 2004 23:37:50 +0000 Subject: [sebhc] H8 Emulator update Message-ID: Dave says: > >Why not provide HDOS 2.0 instead? > >Two reasons: 1) ...the disks are big I don't want to have to include too >many of them. Since you zip your package, I think they shrink down pretty well. A user might appreciate a complete 2.0 disk set. OR .. just include a reference to SEBHC, so they can get support here! > >It would be nice to have a "real 8080" mode .... >Not currently - it's doable, but why are you so concerned about invalid >opcodes? - I won't think this should be an issue (except of course for the >HASL thing - which is a NOP in disguise). Did Heath use the other undoced >opcodes? I'm sure Heath never used any deliberately - the HASL thing is surely a case where an address was pointing to the wrong place and it was never discovered because in testing (on real hardware) it worked as intended. My interest would be to have a completely precise emulation of the cpu functionality. Not only to cover any other possible software accidents like HASL, but also to cover cases where programmers intentially did little "tricks" to determine if the processor is an 8080 or Z80, or perhaps to impede reverse-engineering of their code. Plus I just kinda like the idea of knowing the emulator is going to respond EXACTLY like the real thing. :-) Jack says: >Another "problem" is with the low level commands INIT and SYSGEN - if I >try to run INIT, it exits gracefully with the error message "Wrong type >of media ...". I can ctrl-D out of it and reboot, but I can't initialize >a disk. Likewise with SYSGEN - if I attempt to gen a disk, I get an >error saying the disk is not initialized by the correct version of INIT I was able to sysgen the "empty.h8d" that I added to disk-images/other. It's an HDOS 2.0-style initted disk image and I was using HDOS 2.0 sysgen. I did get a funny message about an illegal .DVD filename during the sysgen (will have to try this on a real H8 when I find my spare disks) but the disk image it made "boots" just fine. Cheers, - Steven _________________________________________________________________ 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 jack.rubin at ameritech.net Sun May 30 19:20:17 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 30 May 2004 19:20:17 -0500 Subject: [sebhc] H8 Emulator update In-Reply-To: Message-ID: <000001c446a5$0dc7c2c0$1f6fa8c0@eths.k12.il.us> Steven said: > I was able to sysgen the "empty.h8d" that I added to > disk-images/other. > It's an HDOS 2.0-style initted disk image and I was using > HDOS 2.0 sysgen. > I did get a funny message about an illegal .DVD filename > during the sysgen I knew I had seen an empty disk image somewhere! Yes, it gen'ed just fine, though I've gotten a bad DK.DVD error with the same system image on other occasions (using real disks) - these images are all from Dave Shaw/Wallace and may be corrupted. If you would, please tell me how you are dumping real disks to binaries, even if it is a quick and dirty hack. I've got more stuff I'd like to try in the emulator, including some original HDOS disks. Thanks. Jack -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Sun May 30 20:38:08 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 31 May 2004 01:38:08 +0000 Subject: [sebhc] H8 Emulator update Message-ID: >I've gotten a bad DK.DVD error with the same system image >on other occasions (using real disks) - these images are all from Dave >Shaw/Wallace and may be corrupted. No, the HDOS 2.0 images are ones I made, from a real, pristine, distribution set. Interesting you'd seen that before though. I still haven't found my spare disks but maybe someone else might want to look into it with a real system. >If you would, please tell me how you are dumping real disks to binaries, >even if it is a quick and dirty hack. I've got more stuff I'd like to >try in the emulator, including some original HDOS disks. I use the H8 "dump" (aka suprdump, diskdump, etc) program to display sector contents to the console, which is actually another computer capturing the output. I then run the dump through a stream edit script which converts it into program data, and excuting the program produces the binary. I figured I'd find disks with better tools on them soon and/or someone would post some. Speaking of tools, I'm really looking forward to seeing Eric's "fstool". Might you post it soon, Eric? _________________________________________________________________ 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 jack.rubin at ameritech.net Sun May 30 21:39:13 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Sun, 30 May 2004 21:39:13 -0500 Subject: [sebhc] H8 Emulator update In-Reply-To: Message-ID: <000101c446b8$761438a0$1f6fa8c0@eths.k12.il.us> > >I've gotten a bad DK.DVD error with the same system image > >on other occasions (using real disks) - these images are all > from Dave > >Shaw/Wallace and may be corrupted. > > No, the HDOS 2.0 images are ones I made, from a real, > pristine, distribution > set. Interesting you'd seen that before though. I still > haven't found my yeah - I'll to note the process more carefully next time > > >If you would, please tell me how you are dumping real disks to > >binaries, even if it is a quick and dirty hack. I've got > more stuff I'd > >like to try in the emulator, including some original HDOS disks. > > I use the H8 "dump" (aka suprdump, diskdump, etc) program to > display sector > contents to the console, which is actually another computer > capturing the > output. I then run the dump through a stream edit script > which converts it > into program data, and excuting the program produces the > binary. I figured > I'd find disks with better tools on them soon and/or someone > would post > some. I've been hacking at Dave Shaw's original diskdump, so I guess I'll just keep whacking away. Seems like about the same amount of effort. Thanks, Jack -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 31 04:37:27 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 31 May 2004 02:37:27 -0700 (PDT) Subject: [sebhc] H8 Emulator update Message-ID: <200405310937.i4V9bRMr031937@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 31 May 2004 09:49:49 -0000 At 18:02 30/05/2004 -0500, you wrote: Hi Jack, >whoops - sorry - never bothered to mount a disk RO to see if it changed. >If you get bored, you could still do a drive select light. Look carefully and you will see three small "dots" at the far right hand side of the status line that light up red when the drives are being accessed. These are the drive select lights for the three virtual disk drives,. I though about adding a "click" when the drive steps, but decided it would be a bit goofy. >> That would be great! Most people will (like me) have only the >> HELP command which is a bit "light" - even a few pages of >> reference would be really helpful. >> >Will do! > >Jack I'd really appreciate it - thanks! 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 Mon May 31 05:27:24 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 31 May 2004 03:27:24 -0700 (PDT) Subject: [sebhc] H8 Emulator update Message-ID: <200405311027.i4VAROAR032638@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 31 May 2004 10:36:44 -0000 >Since you zip your package, I think they shrink down pretty well. A user >might appreciate a complete 2.0 disk set. OR .. just include a reference to >SEBHC, so they can get support here! Ok - can you tell me exactly what disk images should be included (I'm still not very familier with HDOS and it's setup). I do like the idea of a reference to SEBHC ... I do mention it "in passing" in the section on "My H8", however it think it warrents it's own section on the help index. Could whoever is "most in charge" of the SEBHC site/list give me a one-or- two paragraph description that I can put in the simulator help. It should fit on a single help screen. >My interest would be to have a completely precise emulation of the cpu >functionality. Not only to cover any other possible software accidents like >HASL, but also to cover cases where programmers intentially did little >"tricks" to determine if the processor is an 8080 or Z80, or perhaps to >impede reverse-engineering of their code. Plus I just kinda like the idea >of knowing the emulator is going to respond EXACTLY like the real thing. >:-) Ok - it's done. The next release of the simulator will correctly emulate the invalid opcodes exactly the way a real 8080 would. 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 jack.rubin at ameritech.net Mon May 31 06:34:16 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 31 May 2004 06:34:16 -0500 Subject: [sebhc] H8 Emulator update In-Reply-To: <200405311027.i4VAROAR032638@gatekeeper.evocative.com> Message-ID: <001101c44703$352752a0$1f6fa8c0@eths.k12.il.us> > > Could whoever is "most in charge" of the SEBHC site/list give > me a one-or- two paragraph description that I can put in the > simulator help. It should fit on a single help screen. > Administration is shared, but I'm "most responsible" for the site, so I'll noodle out something for you. Jack -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 31 09:57:32 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 31 May 2004 10:57:32 -0400 Subject: [sebhc] H8 Emulator update In-Reply-To: (sp11@hotmail.com) References: Message-ID: <1086015263@rothfus.com> > Speaking of tools, I'm really looking forward to seeing Eric's "fstool". > Might you post it soon, Eric? Yup! I'm on vacation w/the family this weekend, so though I have access to e-mail, I don't have access to my program source. Eric -- Delivered by the SEBHC Mailing List From sp11 at hotmail.com Mon May 31 12:13:56 2004 From: sp11 at hotmail.com (Steven Parker) Date: Mon, 31 May 2004 17:13:56 +0000 Subject: [sebhc] H8 Emulator update Message-ID: >Ok - can you tell me exactly what disk images should be included (I'm still >not very familier with HDOS and it's setup). The HDOS 2.0 distribution is 3 disks: bootable system, software tools, and driver sources. These are the 3 HDOS_2* files in disk-images/HDOS. You might also want to give them a copy of empty.h8d from the "other" section. (Although with a bit of work someone can make one by deleteing everything from a copy of the sources disk). But "empty" will pack WAY down in zip. > >My interest would be to have a completely precise emulation of the cpu >Ok - it's done. Yay! Thanks! My only other top wishlist item would be double-sided and 40/80-track (or N-track) disk emulation. :-) But its really fabulous already! Cheers, - Steven _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/ -- Delivered by the SEBHC Mailing List From dave04a at dunfield.com Mon May 31 21:43:01 2004 From: dave04a at dunfield.com (Dave Dunfield) Date: Mon, 31 May 2004 19:43:01 -0700 (PDT) Subject: [sebhc] H8 Emulator update Message-ID: <200406010243.i512h1U0046728@gatekeeper.evocative.com> by mail.toadware.ca with SMTP; 1 Jun 2004 02:52:23 -0000 >My only other top wishlist item would be double-sided and 40/80-track (or >N-track) disk emulation. >:-) I need to understand how HDOS knows what size the drive is. If you could give me bootable images for 40-track DS, 80-Track SS and 80-track DS, what would help a lot. >But its really fabulous already! Thanks - It's probably the only way I'll ever be able to run HDOS... [If anyone EVER see's an available H17 - please let me know!] Although slow, it's amazingly cool to run the emulator under Pocket-DOS on my palmtop - with the sideways screen option you can fit the entire H8 front panel onto the screen at once! 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 CarrollWaddell at sc.rr.com Mon May 31 22:03:41 2004 From: CarrollWaddell at sc.rr.com (Carroll Waddell) Date: Mon, 31 May 2004 23:03:41 -0400 Subject: [sebhc] H8 Emulator update In-Reply-To: <200406010243.i512h1U0046728@gatekeeper.evocative.com> References: <200406010243.i512h1U0046728@gatekeeper.evocative.com> Message-ID: <40BBF20D.8010509@sc.rr.com> Dave, I was just looking at an article in the July 1981 edition of microcomputing titled, "Dissecting the HDOS Diskette." I don't have any idea if it will help you or not, but if you want it, and give me your address, I'll make a copy of it for you. Also, are you looking for the H17 controller card, or the diskette drive and enclosure? Carroll Dave Dunfield wrote: >>My only other top wishlist item would be double-sided and 40/80-track (or >>N-track) disk emulation. >>:-) >> >> > >I need to understand how HDOS knows what size the drive is. >If you could give me bootable images for 40-track DS, 80-Track SS >and 80-track DS, what would help a lot. > > > > >>But its really fabulous already! >> >> > >Thanks - It's probably the only way I'll ever be able to run HDOS... >[If anyone EVER see's an available H17 - please let me know!] > >Although slow, it's amazingly cool to run the emulator under Pocket-DOS >on my palmtop - with the sideways screen option you can fit the entire >H8 front panel onto the screen at once! > >Regards, >Dave > > > From jack.rubin at ameritech.net Mon May 31 22:16:19 2004 From: jack.rubin at ameritech.net (Jack Rubin) Date: Mon, 31 May 2004 22:16:19 -0500 Subject: [sebhc] H8 Emulator update In-Reply-To: <40BBF20D.8010509@sc.rr.com> Message-ID: <000601c44786$cf6e7950$1f6fa8c0@eths.k12.il.us> Carroll, That sounds like something a lot of people would be interested in. Would you please scan it or send me a copy and I'll post it to the archive. Thanks! Jack > -----Original Message----- > From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of > Carroll Waddell > Sent: Monday, May 31, 2004 10:04 PM > To: sebhc at sebhc.org > Subject: Re: [sebhc] H8 Emulator update > > > Dave, > I was just looking at an article in the July 1981 edition of > microcomputing titled, "Dissecting the HDOS Diskette." I > don't have any > idea if it will help you or not, but if you want it, and give me your > address, I'll make a copy of it for you. Also, are you > looking for the > H17 controller card, or the diskette drive and enclosure? Carroll > > Dave Dunfield wrote: > > >>My only other top wishlist item would be double-sided and > 40/80-track > >>(or > >>N-track) disk emulation. > >>:-) > >> > >> > > > >I need to understand how HDOS knows what size the drive is. > >If you could give me bootable images for 40-track DS, > 80-Track SS and > >80-track DS, what would help a lot. > > > > > > > > > >>But its really fabulous already! > >> > >> > > > >Thanks - It's probably the only way I'll ever be able to run HDOS... > >[If anyone EVER see's an available H17 - please let me know!] > > > >Although slow, it's amazingly cool to run the emulator under > Pocket-DOS > >on my palmtop - with the sideways screen option you can fit > the entire > >H8 front panel onto the screen at once! > > > >Regards, > >Dave > > > > > > > -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 31 23:27:42 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 31 May 2004 23:27:42 Subject: [sebhc] H8 Emulator update In-Reply-To: <200406010243.i512h1U0046728@gatekeeper.evocative.com> (message from Dave Dunfield on Mon, 31 May 2004 19:43:01 -0700 (PDT)) References: <200406010243.i512h1U0046728@gatekeeper.evocative.com> Message-ID: <1086055799@rothfus.com> > I need to understand how HDOS knows what size the drive is. > If you could give me bootable images for 40-track DS, 80-Track SS > and 80-track DS, what would help a lot. I have the source going up tomorrow for the "fstool" program which includes support for the HDOS file system. You can get a good idea of how HDOS does things from it, or feel free to use what you like. For example, the "label" structure looks like this. Note, however, that this structure does NOT indicate the number of bytes in each field value, or the endian-ness of multi-byte values. That is in the marshaling code that fstool uses to load or store this structure to the label sector of the HDOS image. ------------------------------------------------------------ #define LABELSIZE 60 #define LABELTRACK 0 #define LABELSECTOR 9 struct hdos_label { int serial; /* disk serial number */ struct hdos_date initdate; /* date disk initialized */ int dirsec; /* logical sec where dir starts */ int grtsec; /* logical sec where GRT starts */ int grpsize; /* group size (2,4, or 8 secs) */ int voltype; /* type of vol (0 = data, 1 = bootable, 2 = no dir) */ int version; /* version of init.abs for init */ int rgtsec; /* logical sec where RGT starts */ int size; /* number of sectors on disk */ int physize; /* phys sector size (fixed 256) */ int flags; /* volume flags 00 = 40 tk 1 sd 01 = 40 tk 2 sd 10 = 80 tk 1 sd 11 = 80 tk 2 sd */ int sides; /* number of sides = 1 or 2 */ int tracks; /* number of tracks = 40 or 80 */ char label[LABELSIZE];/* textual disk label */ int res; /* reserved */ int secs; /* sectors per track (fixed 10) */ }; ------------------------------------------------------------ The HDOS code is written as a library and should be quite portable to any OS/model. BTW, I told Steven that I'd put it up as a tar-ball for Linux-types. Do I need to do a ZIP also? In the mean-time, check out: http://home.comcast.net/~davidwallace2000/h8/project8080_archive/design_h17.html This is where I found everything I needed for HDOS...thanks Dave Shaw (and Dave Wallace for archiving it). Eric -- Delivered by the SEBHC Mailing List From eric at rothfus.com Mon May 31 23:35:16 2004 From: eric at rothfus.com (Eric J. Rothfus) Date: Mon, 31 May 2004 23:35:16 Subject: [sebhc] Quick note on my favorite topic - Floppy Formats References: <000601c44786$cf6e7950$1f6fa8c0@eths.k12.il.us> Message-ID: <1086060426@rothfus.com> Question for Dave or someone who has used his emulator more than I: - how important is the "volume number" for a diskette? As we get the floppy format issue settled, we'll probably need to store the volume number in the image header. However, I've never really cared much about the volume number...but someone might. The way an H17 HS disk is formated, the volume number is in the sector header. For track 0, this number is always 0. For the remaining tracks, it is the volume number of the floppy. Eric -- Delivered by the SEBHC Mailing List