H89 Emulator integrated into H8D Utility

[Les Bird]

Greetings,

 

A couple weeks ago I was playing around with the H8D Utility and thought to myself, "Wow, it would be cool to be able to run these images without sending them to an SVD or a floppy" and so I began the quest of learning how to write an emulator. I figured it'd be neat to integrate it into the H8D Utility. For less than 2 weeks worth of work I'd say it's looking pretty good so far. If you download my latest H8D Utility (V1.46) you can sample the very early version of the emulator.

 

What works:

 

1. The H89 ROMs work. You get the H: prompt and can do ROM stuff. The package includes ROMs for MTR89 (444-62) and MTR90 (444-142).

2. Booting into CP/M works. If you have the archive of images use the boot image called "CBOOT.H8D". The BIOS-80 versions don't work but I'll figure those out eventually.

3. Booting into HDOS partially works. You get to the Enter Date prompt, you can type in a date, but then it says "Unable to mount system volume" and resets.

 

What doesn't work:

 

1. H19 emulator is not in yet. My plans are to include H9, H19 and H29 emulation but H19 will be my first priority.

2. Can't boot all the way to HDOS yet (see above).

3. Can't boot a CP/M distribution image. It tries to run the CONFIGUR utility but I don't have all the ports emulated yet for this to work.

4. Some CP/M applications may not work if it tries to access special ports.

5. Timing is not implemented yet. Right now it runs the emulator as fast as your system can handle it. I'll add a check box for "Simulate Time" eventually which will run the emulator at (or close to) 2MHz but for now enjoy the 200+MHz H89.

6. Writing to disk images does not work yet.

 

There are probably other things that aren't working yet that I forgot to mention but just keep in mind that this is an early version.

 

Direct download here:

http://www.lesbird.com/sebhc/software/Utilities/H8DUtilityV1_46.zip

 

Send me feedback and suggestions.

 

- Les

http://www.lesbird.com/sebhc

 

[Joseph E McGlone]

Les-

 

That's a cool project!

 

Joe

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To post to this group, send email to se...@googlegroups.com.
To unsubscribe from this group, send email to sebhc+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sebhc?hl=en.

[Chris Elmquist]

On Tuesday (12/08/2009 at 03:59PM -0500), Les Bird wrote:
>
> Direct download here:
> http://www.lesbird.com/sebhc/software/Utilities/H8DUtilityV1_46.zip
>
> Send me feedback and suggestions.

Suggest: A Linux version... ;-)

Otherwise, sounds cool. Big effort.

cje

--
Chris Elmquist

[GC]

That's basically what I created last summer, except mine additionally
had the ability to create blank virtual disk images of arbitrary sizes
formatting them as HDOS file system images, supported virtualization
of the HDOS file system to an underlying OS (thus no need for a
conversion utility to/from images, just used HDOS), virtualized 8080 I/
O UARTS through telnet (implemented a telnet server), implemented an
emulated hardware debugger as found in modern x86 chips with the
ability to watch ports, memory, registers, etc., was arbitrarily
extendible with a plug-in system so that new virtual emulated hardware
could be added dynamically to the system, supported arbitrary ROM
images as external files, emulated the H-8 front panel (I skipped the
cassette stuff), had an installer, ... and booted!

[Les Bird]

Sounds pretty cool. Where can we download this emulator? I'd like to check
it out. Is the source code available? What disk formats did it support? For
example, would you be able to run all of the H8D images we have? That's my
main goal with this emulator is to be able to conveniently load these images
up on your PC and use them.

I'm sure I'll figure out the "booting" problem with HDOS, just a matter of
time.

Did you also write an H19 emulator? Like could you play some of the HDOS or
CP/M graphical games?

- Les

[Les Bird]

>>
>> Send me feedback and suggestions.
>
> Suggest: A Linux version... ;-)
>
> Otherwise, sounds cool. Big effort.
>

Chris, I'm afraid you'll have to wait for Mark's emulator to run it on
Linux. Mine is written in C# using the .NET framework so it's pretty much
locked to Windows. Maybe you can install Windows on a virtual machine under
Linux?

- Les

[GC]

Was uploaded to this group and posted approximately 8/26/2009. Pulled
due to lack of interest.

The source is not available, there is quite a bit of code, and much of
it depends upon libraries (such as the TCP/IP code used in the telnet
server) that I don't want to open source. The plug-in architecture
was also intimately tied to my 8080 emulator implementation, so it
also would be of little use to anyone. All coded in C++.

I didn't try to run all of your images. My documentation pointed
users to your ROM images, and disk images. I primarily was interested
in running my own disk images, created by my own upload utilities. I
didn't bother with CP/M, as I am not interested in it, however, it
could have been made to work. I don't know about "your" disk formats,
however, it worked with any image format that was a correctly
formatted HDOS binary image. By that I mean, the boot sectors, GRT,
RGT, and Directory need to be formatted and laid out correctly. It
was also capable of producing such images of arbitrary size and
cluster (blocking) factor, up to the limits of HDOS. (Which most
definitely can be larger than the 8" disk images you referred to in
one of your earlier posts.) I suspect it was capable of reading/
writing most of your images. SYSGEN worked. Didn't bother with INIT
as my utility built such images. It would boot your HDOS 2.0 image,
support running most of the programs--I suspect all except the
formatting programs which I didn't bother with. Basic worked. ASM
worked. Edit worked. DBUG worked. ...

The most interesting feature was the ability to mount a virtual
device, "NT0: - NT7:" which could be mapped to an arbitrary folder of
your windows machine. Once such a virtual device had been mounted,
one could copy files to/from this device from HDOS and they would
appear in the Windows folder (or the HDOS disk image). The HDOS
directory commands saw them, etc. One could use the virtual device as
a scratch drive for assemblies, etc. With the large sized images (I
think about 5 meg), I could put lots of source files onto a single
image (almost unlimited file size up (useful for listings) to about
250 files) and rebuild programs from days of yore. I implemented most
of the flag settings, but not all. I could assemble utilities using
Windows as a scratch drive, or my large image devices. I could also
produce PDF's of listing files for HDOS (as opposed to the scanned in
ones you have made from my listings of thirty years ago). My listings
were searchable as they began as text files, not image files. All of
this worked without additional drivers or changes to the images, from
the bootable HDOS 2.0 images posted on your web-site.

I was headed toward adding symbol support to the emulated hardware
debugger--hence the need from recompiled listings--but never did. I
got things to work without them, and was able to preserve my own
images in a runnable fashion, whether or not my H-8 and H-89's still
worked--as long as Windows was available. I think that I spent less
than a month writing it all. Perhaps now you understand why I had
requested an ethernet port on your H8-2000 boards. I wanted to
network real H8's to virtual H8's.

[Les Bird]

Greetings,

 

Just uploaded an update to my emulator. Everything is working except for the H19 part. Working on that now.

 

What it does:

 

You can boot HDOS and do HDOS stuff.

You can boot CP/M and do CP/M stuff.

You can read/write to the loaded disk images.

You can PIP, SYSGEN, TEST17, run BH BASIC, just about anything (except INIT and FORMAT).

 

I'm working on:

 

H19 emulation. Right now it's not much of a terminal at all. The RichTextBox window doesn't know how to translate backspaces so if you press the backspace key it inserts a space. Working on it...

Formatting virtual drives in CP/M (currently you have to load an empty image or load an image and ERA *.* to empty it).

INITing virtual drives in HDOS (same as above, can't INIT yet but that will be in soon).

 

Right now it's a great tool for trying out a lot of the disk images in the archive. You can even use it to rearrange some of the disk images and save them out as new files. As a test I booted into CP/M, loaded a copy of a CP/M disk in SY1:, erased everything, did a MOVCPM17 62 and SYSGEN'd the empty disk in SY1. I then saved out that image, loaded it into SY0:, reset the emulator and booted the new 62K CP/M image. Flawless.

 

Probably still some stray bugs lurking around so be patient if you try to use it.

 

Direct download is here:

http://www.lesbird.com/sebhc/software/Utilities/H8DUtilityV1_46a.zip

 

Bootable disk images for CP/M and HDOS are here:

http://www.lesbird.com/sebhc/software/Utilities/H8DBootables.zip

 

The emulator has issues with BIOS80 and HUG's enhanced HSY device driver so don't boot images that use those. The H8DBootables.zip file contains a distribution verson of the HDOS system so when you press B<cr> at the H: prompt, don't forget to press the spacebar so it can autobaud.

 

Will keep everyone posted as I make progress.

 

- Les

http://www.lesbird.com/sebhc

 

 

[GC]

If you emulate the 8251 instead of the 8250, users won't need to
remember to hit the baud-rate determining space when booting
distribution HDOS diskettes.

[Les Bird]

Thanks Gregg,

I'll keep that in mind. Maybe add a checkbox for 8250 or 8251 emulation in
the future.

- Les

----- Original Message -----
From: "GC" <gre...@esx.com>
To: "SEBHC" <se...@googlegroups.com>
Sent: Thursday, December 10, 2009 9:30 PM
Subject: [sebhc] Re: H89 Emulator integrated into H8D Utility

[Mark Garlanger]

But then you would have an H8, not a H89. The H89 didn't have an 8251 for the console.

Mark

[GC]

Is the goal to execute and preserve images in user friendly useful
ways, or emulate every transistor in an H89 exactly? If you are
trying to emulate every transistor accurately, how do you deal with
the National versus Intel 8250's. Which will you emulate? One had an
internal race condition bug that impacted the design, prevented many
H89's from shipping until worked around, my recollection due to a
different chip process? Which will you emulate? Were you aware of
the bug? Is your emulator? If you emulate the transistors exactly,
can you emulate different processes? Does one emulate the more
general 8250 baud-rate change bug necessitating loop-back mode, where
the chip glitches characters using the old divisor when you change the
divisor? Where will it all end? Every magnetic charge on the
physical media? What about the paper diskette label? Does HDOS know
the difference between H89's and H8's? Where? How? Why? The
important differentiation between an H8 and H89 was Z-80. Yes some
code wouldn't work if it drove the UART directly, yes ...

So what's my point? Every emulator, every emulator, every emulator
(Mark even yours) will make some simplifying assumptions about the
emulated hardware. I doubt if any emulate every transistor with 100%
fidelity. Have you emulated the exact model of Z-80 that we used
(with regard to the undocumented op-codes)? The option to emulate an
H-8 with H-19 attached is not illegitimate. For the record, I was not
allowed to ship any code that assumed the user had an H-19 attached.
Not one line. None. Nada. Zilch. Prevented a full screen debugger,
as well as other code, from ever officially shipping. HUG didn't have
that restriction.

> > sebhc+un...@googlegroups.com <sebhc%2Bunsu...@googlegroups.com>.

[Dave McGuire]

ALL electronic circuits are inherently analog. All chips, all
systems, everything that works with electrons is analog. Even the
venerable 7400-series TTL chip family are all analog devices...but we
use them and document them as if they were digital; their
specifications are all in the context of "digital" circuitry.

I say all computer simulators should be written as SPICE netlists
and simulated at the analog level.

So there.

I think I need a margarita.

-Dave

--
Dave McGuire
Port Charlotte, FL

[Chris Elmquist]

On Friday (12/11/2009 at 05:24PM -0500), Dave McGuire wrote:
>
> ALL electronic circuits are inherently analog. All chips, all
> systems, everything that works with electrons is analog. Even the
> venerable 7400-series TTL chip family are all analog devices...but we
> use them and document them as if they were digital; their
> specifications are all in the context of "digital" circuitry.
>
> I say all computer simulators should be written as SPICE netlists
> and simulated at the analog level.
>
> So there.

I'm totally in favor of this because then you'll all need one of the
supercomputers I've recently worked on to run the simulator. A 10000
core Xeon cluster should run that H-89 at about 1X real speed.

;-)

> I think I need a margarita.

I'm totally in favor of this too.

--
Chris Elmquist

[Les Bird]

> On Friday (12/11/2009 at 05:24PM -0500), Dave McGuire wrote:
>>
>> ALL electronic circuits are inherently analog. All chips, all
>> systems, everything that works with electrons is analog. Even the
>> venerable 7400-series TTL chip family are all analog devices...but we
>> use them and document them as if they were digital; their
>> specifications are all in the context of "digital" circuitry.
>>
>> I say all computer simulators should be written as SPICE netlists
>> and simulated at the analog level.
>>
>> So there.
>
> I'm totally in favor of this because then you'll all need one of the
> supercomputers I've recently worked on to run the simulator. A 10000
> core Xeon cluster should run that H-89 at about 1X real speed.
>
> ;-)
>

So are you going to supply us with free systems Chris?

>> I think I need a margarita.
>
> I'm totally in favor of this too.
>

Count me in too.

- Les

[Jack Rubin]

Chris, you surprise me - we really need hot toddies up here!
Jack

[Mark Garlanger]

Hi Gregg,

  I have no delusions, that my emulator is identical to a real system. ;-)  I know that it is making MANY simplifications. In fact, it isn't even properly handling the baud rate detection, that brought up this discussion. My emulator has a fixed throttle, that makes it performs close to 9600 baud for the H19 portion. But it doesn't try to simulate the distortion that is seen if the computer and terminal are at different speeds. So even though HDOS starts off at a different speed (2400?), it instantly accepts it, so that HDOS thinks it's running at the slower speed, but it is still performing at 9600. I intend to fix it, but it hasn't been a high enough priority issue. As for the bugs, I don't plan to add support for them, but the work-arounds (like putting the 8250 in loopback mode when programming the divisor) should behave like a read 8250 would. I would eventually like to see the terminal programs work properly in the emulator, with options of having the emulator take control of a real serial port on the host computer. This would allow the emulated machine to transfer software to/from a real H89 (or even another emulated computer).

As for the magnetic charges on the disks, thanks to Dan, we have been making good progress on that. Full tracks are being read (all bits) AND it is even able to store the 'hole' status detected for each byte read from the disk. Once the full track is read, the host computer processes it and corrects for the bit-shifting since we are not relying on the sync character to find the start of the sector.
For the diskette label, I was considering to have an optional field in the disk image file, that would be the scanned label, in JPG or PNG format.

As for HDOS knowing the differences, I'm not sure, but I do know that the H89 ROM has code to emulate the ports that are only present on the H8.

For the Z80, I'm not going to analyze and emulate the exact model (which I'm guessing, probably changed more than once during the 5-6 year run of the H89). But I have worked on some of the undocumented opcodes that are described on-line. As I have time, I will continue adding them.

As for having the images in a user friendly format, the simple fix for the 'spaces' issue is for the emulator documentation/help-file to recommend 'working' HDOS disks instead of the 'original distribution disks'. These disks would have the baud rate already set, so no spaces need to be pressed. This also allows it to have all the other TT: options set for the H89 (BKS, NOMLO, NOMLI), so that it is even easier for the first-time user. People, who want to use the original distribution disks, would still have that option, and it would still behave (as close as possible) to a real H89).

Now, I just need to find time to work on all this.  ;-) 

Mark

To unsubscribe from this group, send email to sebhc+un...@googlegroups.com.

[Chris Elmquist]

On Friday (12/11/2009 at 06:29PM -0600), Jack Rubin wrote:
> >
> > > I think I need a margarita.
> >
> > I'm totally in favor of this too.
>

> Chris, you surprise me - we really need hot toddies up here!

oh c'mon... it's a balmy 11F right now. It's still fall...

;-)

Chris

--
Chris Elmquist

[Les Bird]

Greetings,

 

A new update to my H89 Emulator is up for download. This time *most* H19 emulation is in but I think it's more of an H19 simulator then an emulator. I translate most of the H19 ESC sequences to cursor and draw functions so it's not really emulated in the sense that it's running H19 ROM code. All graphic characters and reverse video is in and working. The H19 font is in and working. Most games can be played now but you must put your numeric keypad in NUMLOCK mode for it to work correctly.

 

Also added a not so accurate 2MHz checkbox. Runs more like a 4MHz H89 though. Will tweak this as I go.

 

I'll probably move the H19 simulated screen to a DirectX surface and allow fullscreen mode in the near future.

 

There's an ONLINE button at the bottom. If it turns red that means focus to the drawing surface has been lost so all keyboard input won't be captured. Just click it to resume focus and go "online" again.

 

You can also change the H19 screen color so if you'd rather have the amber screen just click the COLOR button at the bottom and pick a new color.

 

Seems pretty solid now in HDOS and CP/M.

 

So far my utility has the following functions:

 

1. Allows you to catalog and view the contents of H8D disk images.

2. Allows you to extract files from HDOS disk images to your hard drive.

3. Send/Receive disk images from an SVD.

4. Send/Receive disk images to a real H8/H89 using Dwight's H89LDR client.

5. Run and try most H8D disk images in the integrated H89 Emulator.

 

Just about anything that has to do with H8D disk images can be done with my utility. It's come a long way so far.

 

Direct download:

http://www.lesbird.com/sebhc/software/Utilities/H8DUtilityV1_46c.zip

 

Boot images:

http://www.lesbird.com/sebhc/software/Utilities/H8DBootables.zip

 

- Les

http://www.lesbird.com/sebhc

 

[GC]

Mark:

I think you totally missed my point. In any case, with regard to
emulating the 8250 bugs, the issue is not what you do when the
emulated code correctly sets loop-back mode, as HDOS does, but what
happens when software doesn't. I don't recall that the app-notes of
1978 covered this issue. I am sure that there is code from that day
that doesn't. I found it out the hard way, and I suspect that your
8250 code won't glitch out the same characters that those original
8250's did. No one probably emulates the exact behavior of an 8250.
And more to the point, it's not really necessary! Simplification is
okay. Like most (all?) emulator writers, you have made some
simplifying assumptions--just different ones. Optionally emulating an
8251 does not invalidate the integrity of an emulator--at least for
software which does not directly drive the UART. I think the goal is
to not get all OCD over these issues to the point where you don't ever
end up with anything useful. I believe the old expression is, "Shoot
the engineer and ship the product".

I stand by my original comment, that by emulating an 8251, one can
eliminate the newbie issue of requiring spaces. By additionally
emulating the 8250's, you can probably enable people to run the
applications that do drive the hardware directly. But you're never
going to emulate the hardware "exactly". I also agree that H-89's
didn't have 8251's for their consoles.

As for the issue with configured distribution disks. If memory
serves, I wrote much of the code. I understand it. In fact, it
brings to mind a rather funny H-8 story.

One day, Neil Beneditz was working on some hardware, and wanted some
latest software. As we were between releases, I just duplicated a
disk that I was using for development. He returned to my office a few
hours later very perplexed. He accused me of breaking his H-17, or at
least of causing it to squeak. He couldn't believe that software
could make drives squeak, but he was adamant that I had done so.

Being ever the curious type, I followed Neil back to his office where
he demonstrated that I had, in fact, made is drives squeak. I
chuckled a bit to myself, and assured that he was right, and that I
would rectify the situation, headed back to my office, and coded up a
new HDOS command called "oil". One could oil the disk drives, memory,
led's, bus?, ... I took it back to Neil and instructed him on it's
use. The more he oiled the drives, the less they squeaked. When you
oiled the H-8 front panel, it would display "Drip" or some such
nonsense, and make a dripping sound. I believe when you oiled the
bus, or perhaps memory, the system would crash as all H-8's would in
those days if you had a bad stack, or other serious programming
error. They typically would whine away with the horn blaring, the
front-panel blank, etc.

Neil happily accepted my new software, with the new command, only to
return to my office again--a few hours later. He sat on his haunches
on the end of one of my engineering benches looking at me out of the
corner of his eyes. It was now undeniable, I truly could control the
squeaking of his H-17. (I think Neil had designed the H-17. Plumber
may have designed the controller, maybe it was Neil and Larry
together.) This was even more troubling to him. How could I do this,
he demanded! I laughed, after all, the hardest part of the "oil"
application was making it reliably crash when he oiled the memory.
After toying with him for a while, I confessed.

As you may know, HDOS supported an application called TEST17. One of
the primary original purposes of TEST17 was to determine the maximum
reliable step rate that your actual drives supported. Though they
were specified at 30ms per track, some (mostly early) would do 6ms
reliably. (I think 30 is the correct number, it's been a long time.)
Decreasing the step time would dramatically improve the performance of
your system for anything close to disk intensive. (Gordon was a smart
guy.) I had given Neil a disk configured for fast step times. His
drives squeaked when they stepped that fast. Mine didn't. Every time
he oiled the drives with the command, I reduced the step rate, and
updated the data block on the diskette. (I believe it was on track
0. I'd have to check a listing. Perhaps at the end of the label.)
We all had a good laugh before it was over. Neil was a fun guy to
work with, and I occasionally still see his son at the local Radio
Shack.

I suspect much of this energy capturing every magnetic flux change
would be better spent in creating an image format that included at
least some rudimentary type of error checking. Once on a hard drive,
the binary images are fine, but downloading them in the form they are
is probably a larger engineering "error" than ignoring the sync
characters in a disk image.

Interestingly, from a historical perspective, the inability to make
engineering compromises cost Heath/Zenith severely in the market
place. Zenith purchased Heath because we had an engineer building an
MBASIC interpreter for the H11. At the time, nearly all business
software (think Peach Tree) was written in MBASIC. The theory was
that by creating an MBASIC interpreter for the H-11, our customers
would have a scalable hardware/software platform--much as DEC provided
to it's customers. H-8, floppy and cassette based. H-11, had bigger
floppies, tape backup available, even hard drives. Zenith thought it
was a neat plan--and it was. Unfortunately, HBASIC (as it was called)
never saw the light of day, because the responsible engineer would not
make any design compromises. An example was that even lines were
managed by B-Trees. In this engineer's mind, you must always be able
to insert another line between two lines without renumbering by
adopting a text book numbering scheme (123.2), etc. It was a neat
idea. And on big iron, probably would not have been a problem.
However, due to this, and other design decisions, HBASIC wouldn't not
even run on a PDP-11 with 128KB of RAM, much less one with an address
space closer to 56KB. (For the record, Gordon who was responsible for
Benton Harbor Basic was gone by this time, I carefully haven't
revealed the HBASIC engineer's name. My intention is not to criticize
him, but rather, to illustrate the point.) Eventually, the engineer
agreed to an overlaying scheme, albeit reluctantly, but the resulting
system ended up being too slow. I am sure it would have been the
world's best BASIC ever written, but it never saw the light of day.

Examining the issue from a different perspective, we had an
engineering manager once who decided that he was going to "help"
Microsoft fix MBASIC. He procured the NBS (? National Bureau of
Standards) test suites available for basic at the time. I believe
that I let him then use a batch processor that I had written for HDOS,
and we ran them. (Yet another product they wouold not let me
release.) Needless to say, (for any one familiar with MBASIC in those
days,) MBASIC failed miserably. He proudly told Microsoft we would
not take delivery until the issues were fixed. Microsoft responded
that if he didn't want to take delivery of MBASIC, that was his
problem. They weren't going to fix all of the issues that he had
found. As an aside, doing so would have probably broken many an
MBASIC program that already existed. Perhaps the manager was trying
to impress the Microsoft folks. If he was, it didn't work. Gordon's
BH Basic was probably way more conforming to the basic standard.
(Just consider the simple operation of opening a file.) It didn't
matter. MBASIC had become the standard--along with all of its flaws
and warts.

If all of these thoughts don't flow together, just step back and take
the satellite view.

> > sebhc%2Bunsu...@googlegroups.com<sebhc%252Buns...@googlegroups.com >

[Les Bird]

Gregg,

Making the drives squeak? That's one of the funniest H-8 stories I've ever
heard. Ah the good 'ole days.. if only we could go back. Now everything is
so darn complicated!

- Les

----- Original Message -----
From: "GC" <gre...@esx.com>
To: "SEBHC" <se...@googlegroups.com>

sebhc+un...@googlegroups.com.

[West, Ronald S.]

Gregg,

Good story.

So, did HBASIC get converted to BHBASIC or were they separate products? Do you still have a copy of HBASIC lying around?

Ron

> -----Original Message-----
> From: se...@googlegroups.com [mailto:se...@googlegroups.com]

> On Behalf Of GC
> Sent: Monday, December 14, 2009 5:38 PM
> To: SEBHC
> Subject: [sebhc] Re: H89 Emulator integrated into H8D Utility
>

> sebhc+un...@googlegroups.com<sebhc%2Bunsubscribe@googleg
roups.com><
> > >
> sebhc%2Bunsu...@googlegroups.com<sebhc%252Bunsubscribe@goo

glegroups.com >
> > > >.
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/sebhc?hl=en.
> >
> > > --
> >
> > > You received this message because you are subscribed to
> the Google Groups
> > > "SEBHC" group.
> > > To post to this group, send email to se...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > sebhc+un...@googlegroups.com
> <sebhc%2Bunsu...@googlegroups.com>.
> > > For more options, visit this group at
> > >http://groups.google.com/group/sebhc?hl=en.
>

> --
>
> You received this message because you are subscribed to the
> Google Groups "SEBHC" group.
> To post to this group, send email to se...@googlegroups.com.
> To unsubscribe from this group, send email to

> sebhc+un...@googlegroups.com.

[GC]

HBASIC was "written" after BHBasic. Gordon wrote BHBASIC, and he was
long gone by then. BHBASIC was written in assembler. As you may
know, Gordon wrote BASCOM at Microsoft (among other things).

I never kept a copy of HBASIC because it truly never was functional.
I remember watching the engineer responsible for HBASIC running one
piece, perhaps the editor, and then running another piece, perhaps the
interpreter. I was not a usable MBASIC clone. It was not a usable
Basic interpreter. I am not sure that I was ever even given a copy,
although the source was probably on one of our Unix machines.

The HBASIC story is a tragic. The scalable software architecture
would have been great. I think it was Larry Plummer's idea. He had
some good ideas. This was one of them.

At some point after HBASIC's demise, the engineer left the company. I
am purposefully ambiguous, as there is no point in hammering him some
25+ years later. He may have completed it working for another
company, although I don't believe it ever ran on anything close to
micro-computer hardware of that day. It was written in C, so it could
have been easily ported to any of the Unix variants of the day.
Perhaps it ultimately ran years later on PC hardware, with much larger
address spaces. I just don't know.

> ...
>
> read more »

[Les Bird]

Greetings,

 

Yet another update to my H8D Utility is up on my web site. V1.47 which includes a much improved H19 simulation for the integrated H89 emulator. Timing is improved as well so it should run quite close (not exact) to an actual 2MHz H89 when the 2MHz box is checked. I now render the output to a DirectX surface (XNA run-time download required) which looks much better, runs much faster, and now can be toggled to a full screen window. The games (both CP/M and HDOS versions) run pretty good - Munchkin, YWing2 and Grav were all tested and working.

 

Bill Loguidice, you can now play the Grav game in my emulator! Give it a try if you get a chance.

 

Just remember when playing the games that you should use the numeric keypad and you should have the NumLock key down.

 

Direct download can be found here:

http://sebhc.lesbird.com/software/Utilities/H8DUtilityV1_47.zip

 

XNA run-time download here (via my web site) - download and install this before running the emulator:

http://sebhc.lesbird.com/software/Utilities/xnafx31_redist.msi

 

Bootable disk images for CP/M and HDOS 2 here:

http://sebhc.lesbird.com/software/Utilities/H8DBootables.zip

 

I've received some positive feedback about the emulator as well as some suggestions. Thanks!

 

- Les

http://sebhc.lesbird.com

 

[Bill Loguidice]

Thanks, I’ll also repost this on Armchair Arcade. I hope I get some time to try this, but sadly no promises at this point (and it’s killing me, believe me).

 

====================================================
Bill Loguidice, Managing Director
Armchair Arcade, Inc.
http://www.armchairarcade.com
A PC Magazine Top 100 Website
====================================================
Authored Books: http://www.armchairarcade.com/books
====================================================
LinkedIn: http://www.linkedin.com/in/billloguidice
====================================================

 

From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf Of Les Bird

Sent: Thursday, December 17, 2009 4:40 PM
To: se...@googlegroups.com

--

[Les Bird]

Bill, here are a couple screenshots for the Grav game running in my emulator in-case you want to post them too.

 

- Les

[Bill Loguidice]

Perfect, thanks.

 

====================================================
Bill Loguidice, Managing Director
Armchair Arcade, Inc.
http://www.armchairarcade.com
A PC Magazine Top 100 Website
====================================================
Authored Books: http://www.armchairarcade.com/books
====================================================
LinkedIn: http://www.linkedin.com/in/billloguidice
====================================================

 

From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf Of Les Bird

Sent: Thursday, December 17, 2009 4:54 PM
To: se...@googlegroups.com

--

[Les Bird]

Greetings,

 

A new V1.47b update to my H89 emulator is up on my web site. This time I have the following additions:

 

1. You can now INIT images in HDOS. If an image is not loaded a new empty image is created automatically that can be formatted.

2. You can now boot HDOS with the HSY device driver, although only 40 track, 1 sided is supported at this time.

3. You can now boot HDOS 3 (a version is included in the new H8DBOOTABLES.ZIP file).

4. You can now INIT images in HDOS 3 to create blank HDOS 3.x H8D disk images.

5. The CP/M CONFIGUR program works now with one minor issue (see below).

6. Added some game images to the H8DBOOTABLES.ZIP file. (Grav, YWing II, Space Pirates)

7. Added full distributions for CP/M 2.2.03, CP/M 2.2.04, HDOS 1.6 and HDOS 2.0.

8. Added a DOOR button to each drive. This simulates opening the drive door for those HDOS utilities that need you to insert a disk. Click it again to close it. This is not a very "friendly" feature yet as you need to save the image each time you swap it. Will try to make this more friendly.

 

Stuff not working yet:

 

1. Can't format from CP/M yet.

2. Can't format double sided or 80 track images yet.

3. BIOS-80 CP/M disks don't fully work yet.

4. Maybe some other stuff doesn't work that I haven't tried yet.

 

For the most part it is a pretty solid emulator. Will post another update when I get CP/M format working and when multiple sided 80 track images are functional.

 

CP/M CONFIGUR work-around:

 

The baud rate is not automatically detected when using the CP/M CONFIGUR utility. The work-around is to select N for Standard System, then select A for Terminal Characteristics, then select A for CRT and press '9' for 9600 baud then type in 0E8 for the I/O port. Now you can save the settings normally with the Y key. You only need to be concerned with the CONFIGUR program if you are booting from a distribution disk that runs it automatically. Once you save the settings you'll be able to save the modified image to the hard drive and boot from that version in the future.

 

Take you H-89 with you! Install my emulator on your laptop along with a full compliment of disk images and enjoy playing with the H-89 wherever you may be.

 

Direct download link:

http://sebhc.lesbird.com/software/Utilities/H8DUtilityV1_47.zip

 

H8 bootable disk images:

http://sebhc.lesbird.com/software/Utilities/H8DBootables.zip

 

XNA run-time download:

http://sebhc.lesbird.com/software/Utilities/xnafx31_redist.msi

 

- Les

http://sebhc.lesbird.com

 

[Les Bird]

Greetings,

 

Another update (V1.47d) to my H89 emulator.

 

1. In HDOS 3 you can now INIT images with up to 2 sides and 80 tracks (up to 400K).

2. Fixed a lock-up if you let the emulator sit idle too long. An integer timer would overlap to a negative number causing it to delay until it went positive again.

3. Corrected TAB alignment in H19 emulation.

4. Added more Heath ESC functions in H19 emulation.

5. Added function keys F1-F5 and BLUE, RED and GREY. On the PC keyboard they are F1-F5, F7 is BLUE, F8 is RED and F9 is GREY.

6. Fixed caps-lock not working correctly.

7. Shouldn't have to press the NUMLOCK key anymore when playing games using the numeric keypad.

 

Still not working:

 

1. Can't format in CP/M yet.

2. Only 40 track, 1 sided images supported in CP/M.

 

When I created the H17 HDOS 3 distribution image the other day it was all done using my emulator. INIT'ing the virtual disk, SYSGEN'ing it from the original distribution image, saving it as an H8D file, setting/resetting flags and copying the H17.DVD over to the newly created distribution image. It all went smooth and is a much faster altenative then working with the real hardware. Without the 2MHz box checked it's like running a 200+ MHz H89. Formatting images is super fast, loading the OS is near instantaneous (especially CP/M), writing/reading data to/from images is quick.

 

Direct download here:

http://sebhc.lesbird.com/software/Utilities/H8DUtilityV1_47.zip

 

New H8D bootables images here (cleaned it up a bit, added new HDOS 3 bootables based on the original distribution):

http://sebhc.lesbird.com/software/Utilities/H8DBootables.zip

 

Added some early documentaton for it here (scroll down to the emulator section):

http://sebhc.lesbird.com/software/Utilities/H8DUtility.html

 

Don't forget the XNA run-time for the H19 emulation (install this before running the emulator):