Obtaining the PAM-37 and H-17 ROM contents
Why I didn't include the actual ROM code files
How to get ROM contents if you have an H-8
What the ROM file format is
Virtual H8-5 tapes
Dave Shaw's Benchmark
Dave Wallace's Benchmark
Dave Shaw's Console Echo Test

First, let me be clear: I don't have the right to distribute the ROM contents. If and when I obtain the right, the correct files will be available from my site and will be included in any subsequent Virtual H8 releases. Until then, please don't even ask. But I have devised at least three ways you can make the correct PAM37.ROM and H17.ROM files on your own (if you have access to the right materials and equipment).

The first, but most tedious, way is to transcribe the object code from the PAM-37 ROM listing that was provided with the Z80 card manual. I have not inquired, but the Heathkit Company site can take email inquiries for copies of documentation, so you might ask for a copy of the HA8-6 manual (Heath part number 595-2908). (The H17 ROM code may be harder to come by: the H17 manual lists only a few selected routines, not the whole thing. Heath Co. used to sell the H17 ROM listings as part of the four-volume set of HDOS code listings, but I doubt that Heathkit Co. can provide that.)

The third method requires a running H-8 with the HA8-6 CPU and the H-17 controller. You will also need a copy of the Software Toolworks C/80 compiler for HDOS, the ability to use your PC as the H8's terminal and the two programs I supply. This is how I got PAM37 and the H17 code for my own use. It's the most convenient way to do the job, but requires that you own or can get access to the right hardware and software.

back to top

Why I didn't include the actual ROM code files

Plain and simple: I don't want to go to jail. It's against the law. Even if I'm not charging money.

back to top

How to get ROM contents if you have an H-8

The two C programs in the "etc" directory named "dumppam37.c" and "dumph17.c" are required, plus a working H-8 with the HA8-6 CPU card, 56K or more of RAM and an H-17 with at least two disk drives. The programs are intended to be compiled with the Toolworks C/80 compiler, version 3.1, which was published by The Software Toolworks. (I have only tried this with the Toolworks compiler version for HDOS -- they also sold C/80 for CP/M and other C compilers for the H-8 may or may not accept the code as written.) You will also need an HDOS work diskette, an HDOS 2.0 operating system (bootable) diskette and you'll probably want to have a text editor of some sort available.

On the PC side, you will want to have Hyperterminal running emulating a VT52 with comm settings of 9600/N/8/1 and have the serial port of your PC connected to the console port of your H-8. (This may or may not require special cables, null modem adapters, etc. "It's a hardware problem.") Once you can boot HDOS and operate it from your PC, you're ready to begin.

First, you will need to get the C code over to the HDOS work diskette. The simplest way is to do a "COPY SYx:DUMP37.C=TT:" command (where "x" is the unit the work disk is mounted on) and then have Hyperterminal transmit the dumppam37.c file. Hit Ctrl-D to end the HDOS copy operation. Now repeat the process for dumph17.c (to a different target file, please!).

Next, compile the two programs. This should be simple enough, except for making sure you put the right files on the right floppies at the right time (it's easier if you have three floppy drives, but it's possible with only two if you swap diskettes between the compile and the assemble steps).

Finally, set up Hyperterminal to capture text to a file and run DUMP37.ABS. Close the capture file when done and use a Windows text editor to remove superfluous text before and after the dump. Save this as "firmware\pam37.rom". Repeat the process using DUMP17.ABS and saving the edited result as "firmware\h17.rom". This should now give you working ROM contents.

back to top

What the ROM file format is

The PROM data is loaded by a routine in the simulator that understands how to read ascii text and create binary image. The loader routine is fairly flexible but the first line of the file must be the radix directive (either "RADIX DEC", "RADIX OCT" or "RADIX HEX" and the last line must be the "END" directive. In between there may be one or more code blocks, a sequence of "DATA" directives preceeded by an "ORG" directive.

If the radix is octal, the origin must be specified as seven characters in "split octal" notation (xxx.xxx) and the data must be specified as three octal digits per byte; if the radix is hex, the origin and data must be in hexidecimal. Lines beginning with semicolon are comments. Blank lines are also ignored. Data directives may specify one or more consecutive bytes of object code, with successive bytes separated by spaces or tabs. I tend to put up to 16 bytes in a single DATA directive, but the actual number of bytes that can be specified in a single directive is limited only by the length of the routine's file I/O buffer (256 bytes).

The following is an un-annotated version of the file that loads the code for the "display keycode" routine. The actual file is much larger because I include the text of the assembly language as commentary and also annotate the object code to show where the labels from the assembly code are.

RADIX	OCT
ORG	000.000
DATA	061 000	050 373 006 001 076 377 315 200 000 006 001 333 360 376
DATA	377 304 200 000 303 013 000
ORG	000.140
DATA	201 363 310 340 262 244 204 361 200 240
ORG	000.200
DATA	305 345 365 041 140 000 170 306 240 323 360 361 365 017 017 017
DATA	017 017 017 346 003 205 157 176 323 361 041 140 000 004 170 306
DATA	240 323 360 361 365 017 017 017 346 007 205 157 176 323 361 041
DATA	140 000 004 170 306 240 323 360 361 365 346 007 205 157 176 323
DATA	361 361 341 301 311
ORG	001.000
DATA	305 345 365 041 140 000 170 306 240 323 360 361 365 016 000 326
DATA	144 332 030 001 014 303 017 001 306 144 365 171 205 157 176 323
DATA	361 041 140 000 004 170 306 240 323 360 361 016 000 326 012 332
DATA	066 001 014 303 055 001 306 012 365 171 205 157 176 323 361 041
DATA	140 000 004 170 306 240 323 360 361 205 157 176 323 361 361 341
DATA	301 311
END

back to top

Virtual H8-5 tapes

The H8-5 tape files are pure binary memory images made when you use the PAM-37 "Save" command (see PAM-37 Keyboard instructions.) I've included three tape files in this release, two made by Dave Shaw and one by myself. These files are simply to show that the various pieces are working and so you can get a good feel for performance.

back to top

Dave Shaw's Benchmark

When Dave Shaw started his Project 8080 Heath H8 emulator, he developed a speed test to see how many instructions per second it would do. This is a copy of his benchmark program. (Thanks, Dave.) Dave's benchmark takes around 4:10 on an actual H-8.

back to top

Dave Wallace's Benchmark

Dave Shaw's benchmark program was weighted in favor of PUSH and POP instructions, which on a real 8080 take more than the average number of clock cycles. I built my own benchmark in an attempt to use an instruction mix which (a) included more varied operations and (b) averaged around six to seven clock cycles per instruction rather that the nine to ten his benchmark used. Though the two benchmarks use quite different combinations of instructions and take quite different times to run (mine takes about twice as long as Dave's), the results in terms of performance agree pretty well. My benchmark takes around 6:55 on an actual H-8.

back to top

Dave Shaw's Console Echo Test

This is a simple program that just echoes whatever is sent from the H-19 right back to it. This is a good demonstration that the 8250 simulator is working -- the H19 should do the same thing while this program is running as it would do in local mode. (Thanks again, Dave.)

back to top

Copyright (c) 2001 - 2003 by David A. Wallace