HDOS Device Driver Resources
smb...@gmail.com
glenn.f...@gmail.com
The “go to” tutorial is in Issue 20 of REMark. Recommend you start there. It has a simple CK: device driver for a 2-ms interrupt-driven clock.
remark-issue20-1981.pdf (pestingers.net)
HDOS included source for the print and serial drivers with the HDOS 2 distribution disks. There are multiple copies of these in the SEBHC.ORG disk archive, for example see the disk (confusingly) labelled “HDOS3.H8D” in Vol 1.
HDOS3.H8D
HDOS 2.0 Driver Source (Copyright(C) Heath Co 1980)890-104
======== === ==== =========
FILE EXT SIZE DATE
======== === ==== =========
ATH44 ASM 68 07-Oct-80
ATH84 ASM 34 29-Oct-80
DDDVD ASM 31 29-Oct-80
DDINIT ASM 64 03-Dec-80
LPH24 ASM 46 07-Oct-80
MAKMSD ASM 11 07-Oct-80
ND ASM 10 07-Oct-80
SYDVD ASM 34 07-Oct-80
SYINIT ASM 37 08-Oct-80
GLASSTTY ASM 16 07-Oct-80
TBRA ACM 2 07-Oct-80
TYPTX ACM 2 07-Oct-80
U8250 ACM 9 07-Oct-80
U8251 ACM 5 07-Oct-80
ZEROS ACM 1 07-Oct-80
RGT SYS 1 07-Oct-80
GRT SYS 1 07-Oct-80
DIRECT SYS 8 07-Oct-80
======== === ==== =========
Files 18, Total 380, Free 2
HUG also released an enhanced “SY:” (H17) driver on 885-1095 (also in Vol. 1 on SEBHC site):
885-1095_SY_DEVICE_DRIVER.H8D
HUG SY: DEVICE DRIVER P/N 885-1095
======== === ==== =========
FILE EXT SIZE DATE
======== === ==== =========
README DOC 14 15-Jun-81
SY DVD 12 15-Jun-81
DKH17 ASM 23 15-Jun-81
DKH17I ASM 16 15-Jun-81
DKH17 REL 6 15-Jun-81
DKH17I REL 6 15-Jun-81
DVDDKGEN ABS 3 15-Jun-81
DVDDKGEN ASM 6 15-Jun-81
MFREADY ACM 7 15-Jun-81
MFDVD ACM 49 15-Jun-81
MFINIT ACM 33 15-Jun-81
INITAUTO ABS 28 15-Jun-81
SYDVD DOC 84 16-Jun-81
RGT SYS 1 21-Oct-80
GRT SYS 1 21-Oct-80
DIRECT SYS 6 21-Oct-80
======== === ==== =========
Files 16, Total 295, Free 88
And there’s 885-1105 there as well which has a few more print drivers plus enhancements to CK.DVD:
885-1105_HDOS_2-0_DEVICE_DRIVERS.H8D
DEVICE DRIVERS FOR HDOS 2.0 HUG P/N 885-1105
======== === ==== =========
FILE EXT SIZE DATE
======== === ==== =========
README DOC 26 22-Oct-81
LPMX80 ABS 7 22-Oct-81
LPMX80 ASM 55 22-Oct-81
DEMOMX BAS 6 22-Oct-81
PT560 ABS 6 22-Oct-81
PT560 ASM 77 22-Oct-81
PT560 DOC 13 22-Oct-81
DEMO560 BAS 24 22-Oct-81
GRAPH560 BAS 17 22-Oct-81
LADVD ABS 6 22-Oct-81
LADVD ASM 51 22-Oct-81
CKDVD ABS 5 22-Oct-81
CKDVD ASM 48 22-Oct-81
OCKDVD ABS 4 22-Oct-81
SETTIME ABS 1 22-Oct-81
SETTIME ASM 10 22-Oct-81
RGT SYS 1 22-Oct-81
GRT SYS 1 22-Oct-81
DIRECT SYS 18 22-Oct-81
======== === ==== =========
Files 19, Total 376, Free 4
There are generally two pieces to any disk device driver: the core driver and the “INIT” portion. You don’t *have* to write an INIT piece but if you don’t you will not be able to initialize any media. You can weld the core and init portions together with MAKEMSD.ASM (from HDOS 2.0 tools disk) or I think there’s a “COMBINE.ASM” on the second SY: disk?
If it’s useful I’ve included my VD.ASM which is my jukebox driver. I didn’t do an INIT because I simply populate jukebox slots with already-formatted images…
There are multiple SEBHCers with DD experience so feel free to ask or post your code for analysis…
- Glenn
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b0597887-ee8b-44be-983d-5c738b006e9an%40googlegroups.com.
smb...@gmail.com
glenn.f...@gmail.com
I do all my development on my H8 (at 10Mhz cpu speed). Old fashioned that way I guess… I do code editing, backup and archiving on my PC, then use VPIP to transfer the files to the H8 for assembly and test.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/d9d25f31-a807-4096-8d73-f26b3911e241n%40googlegroups.com.
smb...@gmail.com
glenn.f...@gmail.com
Scott: The article "A Small C Compiler for the 8080's" by Ron Cain in the May 1980 issue of Dr. Dobb’s Journal was a watershed event for C lovers. Small C compiles C source into 8080 assembly language, so building an application is a two-step process: compile code to .ASM and assemble that to produce an executable. With the addition of "A Runtime Library for the Small C Compiler" in the September issue Small C became a decent way for people to get their feet wet with C.
Small C was available on HUG 885-1134 as a 4-disk set
https://sebhc.github.io/sebhc/software/Applications/SEBHCArchive_Vol1_20090625.zip
It’s valuable from a historical perspective, but there are better implementations for daily use (keep reading…)
Importantly, Small C was a starting point for other implementations. The one I’m most familiar with is Walt Bilofsky’s C/80 from Software Toolworks. This is a very usable and reliable C compiler, built on the Small C foundation but with enough professional features to qualify as a full-fledged development environment. The final version was rev 3.1. It is available for HDOS and CP/M.
Home · sebhc/sebhc Wiki (github.com)
If you plan to do any work with floating point or long values also grab the Mathpak. We only have rev 3.0 for that but it works fine with the 3.1 compiler:
Home · sebhc/sebhc Wiki (github.com)
Another version we have for HDOS is Aztec C, from Manx Software Systems. I have less personal experience with this compiler.
Home · sebhc/sebhc Wiki (github.com)
Rick Davis was instrumental in obtaining this software and may have more knowledge/experience.
There are two ways to configure C/80. In the default (and original a-la Ron Cain) version you compile a single C file into a single .ASM file and use the provided assembler to produce the .ABS file. This is fine for learning mode and for small projects, but most people will want to configure the product to be used with either M80 (Microsoft) or RMAC (Digital Research) assemblers. This lets you produce modular code and allows for much more sophisticated uses.
If you end up using C/80 I can be of further assistance. I’ve written a great deal of code for the H8 using this compiler and (shamefully) haven’t yet posted too much of it (but plan to!) My Vinculum utilities are published if you’d like to look at some reference code
sebhc/vdip-utilities: Utility programs for use with the FTDI VDIP1 (github.com)
Joe Travis has done some work pulling together utility libraries for C/80 and may be able to help in that regard…
I’ve developed quite a bit of C/80 code for the HA-8-3 graphics board and plan to publish that on our github repository once I get a chance to finish cleanup and documentation…
Good luck!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/14a677bd-3de2-442f-b782-c52c046847ebn%40googlegroups.com.
Douglas Miller
I've also been using C/80 for the HDOS Network utilities, which leverages the modularity afforded by M80/L80. https://github.com/durgadas311/hdos-net
Be aware that C code produces much larger executables than assembly. It is probably not suitable for writing device drivers, for that and other reasons.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00e701d9782a%2486ddc260%2494994720%24%40gmail.com.
Glenn Roberts
But agree in general with Doug that your programs are going to be larger. Fortunately the days of having only 8 or 16K of RAM are gone for most of us.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7524f4a3-6f03-9b05-21c5-7c924f1d7251%40gmail.com.
smb...@gmail.com
smb...@gmail.com
Glenn Roberts
On Apr 27, 2023, at 9:25 PM, smb...@gmail.com <smb...@gmail.com> wrote:
Am I correct in assuming that an HDOS2 driver will generally work on HDOS3?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1146bf92-6089-49ff-8b55-4267549624aen%40googlegroups.com.
Douglas Miller
I never did figure out how to make HDOS device drivers using HDOS tools (didn't try very hard). I used zmac and a customized version of ld80 to create the DVD file I used for exploring the network HDOS driver (which never did pan-out, but the device drivers worked).
The ld80 I'm using is here: https://github.com/durgadas311/ld80.git. Let me know if you want to go that route.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1146bf92-6089-49ff-8b55-4267549624aen%40googlegroups.com.
Scott Baker
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a5ca207c-68fe-2d2f-e953-08a8a290ff3f%40gmail.com.
Douglas Miller
M80 will produce REL files, but I never found the HDOS L80 manual
to see how to turn that into what's needed for a DVD (a special
file that contains code followed by a list of all the relocatable
addresses in the code).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CA%2B8qVMNdjTHnf1kF1Q9Swr3VCQ5-PT2uUzaJ%2BaiPrL4LrqrTqg%40mail.gmail.com.
smb...@gmail.com
smb...@gmail.com
Douglas Miller
Note that the standard .REL file is not a DVD file, it is an intermediate format invented by MicroSoft. Zmac also produces .REL files, as does CP/M's RMAC (and the CP/M version of M80).
Looking at those instructions, that method (which is similar to what one used to have to do on CP/M before RMAC came along) has you assembling two copies of the same program but ORGed at different addresses, then running a special program that compares those two copies in order to determine where there are relocatable addresses and build the relocation list from that. These instructions are for using the native HDOS assembler ASM and ABS files (and that special program DVDDKGEN), not MicroSoft's M80 and REL files. It is unfortunate that the instructions tell you to name the ASM output file with the .REL suffix, since that suffix already has a very different meaning. In this case ".REL" is an arbitrary string used in place of ".ABS", and has no association to the .REL files produced by zmac, M80, and RMAC.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9312c2bf-ee49-4f91-9313-9d6277b6b4f4n%40googlegroups.com.
Glenn Roberts
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/25b42be9-3e47-87ca-2a95-c45acba8a1a5%40gmail.com.
Les Bird
Douglas Miller
Glenn, this has raised my curiosity. What is it that makes ASM produce the relocation table for MYSY.ABS (to be carried over to the DVD by MAKMSD)?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/E22F0D87-126F-40C2-8A70-3790C765E76E%40gmail.com.
Darrell Pelan
glenn.f...@gmail.com
So the pseudo-op “CODE PIC” causes the assembler to start generating a relocation table. Every time the assembler encounters an address (e.g. instructions like JMP, CALL, LXI, SHLD, STA, etc.) it adds the appropriate offset of the code that needs to be patched to the table. The header information is defined in PICDEF.ACM:
PICDEF SPACE 3,10
** PIC FORMAT EQUIVALENCES.
ORG 0
PIC.ID DS 1 377Q = BINARY FILE FLAG
DS 1 FILE TYPE (FT.PIC)
PIC.LEN DS 2 LENGTH OF ENTIRE RECORD
PIC.PTR DS 2 INDEX OF START OF PIC TABLE
PIC.COD DS 0 CODE STARTS HERE
The relocation table is simply appended to the file (with the pointer to it defined in the code header as shown above).
When HDOS LOADs the file (.LOADD or .LOADO syscalls) and sees the ‘1’ in the second byte it reads the PIC table and then adds the appropriate offset to each affected instruction, based on where the program is being loaded at run time. This is how HDOSOVL1, HDOOVL2 and device drivers are loaded.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/528bb1b7-7296-42e7-4336-50906f68dded%40gmail.com.
smb...@gmail.com
Douglas Miller
Thanks, that clears up a mystery for me. If I ever go back to
building HDOS device drivers, I can try and use the "normal" HDOS
tools (with vhdos), instead of zmac/ld80 on Linux.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/037b01d979d7%2446237a40%24d26a6ec0%24%40gmail.com.
Dan Emrick
smb...@gmail.com
Darrell Pelan
glenn.f...@gmail.com
Scott: I’ve extracted the files from 885-1095 (HUG SY: driver) and sent you a link to a folder in my google drive…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1a43b329-4390-4442-81b2-2d9660b86209n%40googlegroups.com.
smb...@gmail.com
It's easy enough to correct it by lopping off the last 512 bytes, but it also seems like a bug. h8dutility knows what size the file is supposed to be.
Darrell Pelan
smb...@gmail.com
glenn.f...@gmail.com
Can’t immediately explain the issue. These were extracted via H8DUtility3. It might be interesting to re-create the H8D and see what the file looks like.. if I get time later I’ll examine the H8D file directly in dump mode.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f65556be-cf72-475d-b227-f7ee4c1a895en%40googlegroups.com.
smb...@gmail.com
Joseph Travis
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/08f8e0b3-5d19-49cd-89c8-664457dd77c4n%40googlegroups.com.
glenn.f...@gmail.com
Good question. Not silly. You probably want BOOT.ABS (attached)
Just say BOOT SY0: and your system will reboot (or specify any device you want – if no device given, you’ll be prompted). If you’ve used AUTOINIT to initialize the volume, you’ll skip the “Action: boot?” prompt (in all my years I don’t think I’ve ever had to do anything but boot at this prompt!) You can alternatively patch the disk boot track to remove that, but I’d have to search a bit for the patch. I think there’s a HUG app that does that for you too…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/08f8e0b3-5d19-49cd-89c8-664457dd77c4n%40googlegroups.com.
glenn.f...@gmail.com
So I mounted the disk image in the Jukebox and it shows the file using 6 sectors (which is consistent with what I saw when I examined the H8D image DIRECT.SYS). When I DUMP it I get what’s expected and none of the mysterious extra 2 sectors in the version I extracted via H8DUtility3.
Les: you might want to check to see why when we extract via H8DUtility3 we get the extra garbage. Suggests a possible bug in the extraction code.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f65556be-cf72-475d-b227-f7ee4c1a895en%40googlegroups.com.
Scott Baker
There is a label sector at block 9, and it does contain a volume number and a label, and my debug message shows that sector was read by mount. Is anyone familiar with the MOUNT driver entry point? I'm implementing a no-op here and merely clearing the carry to indicate the mount is successful. Am I supposed to return some information, or place the label into memory somewhere?VOLUME 00000, MOUNTED ON RD0:
LABEL:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/05ff01d97a84%245f716900%241e543b00%24%40gmail.com.
smb...@gmail.com
LABEL: SCOTTWASHERE
Glenn Roberts
On Apr 29, 2023, at 11:00 PM, smb...@gmail.com <smb...@gmail.com> wrote:
Never mind the previous message -- not some obscure undocumented task I needed to do inside of the device driver's MOUNT code, but an ordinary run-of-the-mill bug in my code. I'm working now:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/e4e47928-da16-4121-b1dd-4dd9ae6fae77n%40googlegroups.com.
Joseph Travis
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/C2C70BA8-F0DD-43EE-AED6-0E2D2977604F%40gmail.com.
Glenn Roberts
On Apr 30, 2023, at 8:46 AM, Joseph Travis <jtravi...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCb0t-ZrRvX%3Dcoh-V7K42CdGU08ySn2SFznuDDL_HYhgQ%40mail.gmail.com.
norberto.collado koyado.com
What kind of device is RD0:?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/C2C70BA8-F0DD-43EE-AED6-0E2D2977604F%40gmail.com.
smb...@gmail.com
norberto.collado koyado.com
One ask that I will like to see under HDOS and eventually under CP/M, is for VDIP1 on second USB port to be able to connect a USB 3.5” floppy drive to read and write to it. That will be cool to have.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/09e60d81-c50d-496a-bdf1-36a7be3a9a08n%40googlegroups.com.
glenn.f...@gmail.com
FTDi does make a firmware package that supports a “BOMS” (“bulk only mass storage”) device on the second USB port (actually it’s port 1, the one built onto the board is port 2). We normally use their VDAP firmware (default) but the VF2F provides for some disk-to-disk copying ability. I haven’t read up on it. Terry looked at some of these firmware options so he may know a bit more…
- Glenn
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB38447A7EFF14466203D4BC28F76E9%40BN7PR01MB3844.prod.exchangelabs.com.
Joseph Travis
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/003901d97bc3%24deb1e560%249c15b020%24%40gmail.com.
glenn.f...@gmail.com
Not the 32. I believe we need V2DIP1-48 *** Terry: please verify? ***
I have to make a small modification to my vinculum utilities to accommodate a slight difference in the firmware output format for this chip.
Unfortunately I was so busy with VCF that I let the opportunity slip to get one and now I haven’t been able to find a source (everyone seems to have zero stock). Once I have one I can modify and test my vinculum utilities. If you manage to get one you could contact terry who has made a small mod to the vinculum firmware to go back to the output format for the VDIP-1…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCCtw7U9TLiv73JeU5HzjDCr0HL0JNwPpJQNxcKGfx-aQ%40mail.gmail.com.
norberto.collado koyado.com
Per Terry:
The V2DIP1-48 is a drop-in replacement for the VDIP1, with one exception. VDIP1 firmware inserts a blank line before the DIRT command results, V2 firmware does not. I modified the V2 firmware to include the extra line and Glenn's utilities work without issue with the V2DIP1-48 module. FTDI provides the Vinculum-II firmware source and a full IDE which makes firmware customization straightforward.
Norby
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/000201d97bce%246a961380%243fc23a80%24%40gmail.com.
smb...@gmail.com
norberto.collado koyado.com
They are all for backordering.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/384a4ad7-43cf-414d-9dbe-ae3a25b9f32an%40googlegroups.com.
Glenn Roberts
On Apr 30, 2023, at 10:33 PM, norberto.collado koyado.com <norberto...@koyado.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38550602EE8CAD31BDC8024DF76E9%40SN6PR01MB3855.prod.exchangelabs.com.
Glenn Roberts
On Apr 30, 2023, at 10:33 PM, norberto.collado koyado.com <norberto...@koyado.com> wrote:
They are all for backordering.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38550602EE8CAD31BDC8024DF76E9%40SN6PR01MB3855.prod.exchangelabs.com.
smb...@gmail.com
norberto.collado koyado.com
smb...@gmail.com
smb...@gmail.com
norberto.collado koyado.com
I booted from my H8 CF controller and system will get stuck during the “INIT RD0:” command. Then, I had to reset to get system back.
Norberto
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of norberto.collado koyado.com
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/847b5c60-d38f-4579-b0a1-4e2ee483f745n%40googlegroups.com.
Joseph Travis
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38553D98F428296736AEAF2EF76F9%40SN6PR01MB3855.prod.exchangelabs.com.
Norby
norberto.collado koyado.com
Take it back! Same issue with different error message. System hangs after printing the last message.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/94a1e278-fa7a-4bda-af48-0ee58e326ac2n%40googlegroups.com.
norberto.collado koyado.com
At least mount tries to run…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385538FEB9370926D0328F0BF76F9%40SN6PR01MB3855.prod.exchangelabs.com.
smb...@gmail.com
H8:
ACTION? <BOOT> BOOT
CF1 STATUS=50
CF2 STATUS=50
HDOS, VERSION 3.0
ISSUE # 50.07.00
SYSTEM HAS 64K OF RAM
DRIVERS FOUND - TT: SY: HB: CK: ND: RD: FD:
VOLUME 33000, MOUNTED ON SY0:
LABEL: MTC00
S: INIT RD0:
CF1 STATUS=50
CF2 STATUS=50
RD: LOAD
DISMOUNTING ALL DISKS:
VOLUME 33000, DISMOUNTED FROM SY0:
LABEL: MTC00
REMOVE THE DISK(S). HIT RETURN WHEN READY:
INSERT THE VOLUME YOU WISH TO INITIALIZE INTO RD0:;
REMEMBER, ANY DATA ON THIS VOLUME WILL BE DESTROYED.
HIT RETURN WHEN READY.
READY?
RD: READY
RD: MOUNT
THE VOLUME NOW IN THE DRIVE ...
RD: READ REGARDLESS UNI=00 BLK=0009 DEST=3E00 COUNT=0100
PAGE=01 ADDR=0900
IS VOLUME # 00500
LABEL = "RD0 "
TYPE NO TO CANCEL, TYPE YES TO ERASE AND INITIALIZE THE DISK. (YES/NO) ?YES
ENTER A UNIQUE VOLUME SERIAL NUMBER FROM 0 TO 65535: 500
ENTER A VOLUME LABEL OF 60 CHARACTERS OR LESS:
RD0 <
RD: READY
RD: MOUNT
RD: WRITE UNI=00 BLK=0000 SRC=2280 COUNT=0900
PAGE=01 ADDR=0000
ENTER THE NUMBERS OF THE BAD SECTORS ONE AT A TIME. HIT RETURN
AFTER EACH ENTRY, AND WHEN FINISHED.
SECTOR?
RD: MOUNT
RD: WRITE UNI=00 BLK=0010 SRC=3E00 COUNT=0100
PAGE=01 ADDR=1000
RD: MOUNT
RD: WRITE UNI=00 BLK=0009 SRC=3911 COUNT=0100
PAGE=01 ADDR=0900
RD: MOUNT
RD: WRITE UNI=00 BLK=0260 SRC=3D00 COUNT=0100
PAGE=01 ADDR=2000
RD: WRITE UNI=00 BLK=0248 SRC=3A11 COUNT=0200
PAGE=01 ADDR=0800
RD: WRITE UNI=00 BLK=024A SRC=3A11 COUNT=0200
PAGE=01 ADDR=0A00
RD: WRITE UNI=00 BLK=024C SRC=3A11 COUNT=0200
PAGE=01 ADDR=0C00
RD: WRITE UNI=00 BLK=024E SRC=3A11 COUNT=0200
PAGE=01 ADDR=0E00
RD: WRITE UNI=00 BLK=0250 SRC=3A11 COUNT=0200
PAGE=01 ADDR=1000
RD: WRITE UNI=00 BLK=0252 SRC=3A11 COUNT=0200
PAGE=01 ADDR=1200
RD: WRITE UNI=00 BLK=0254 SRC=3A11 COUNT=0200
PAGE=01 ADDR=1400
RD: WRITE UNI=00 BLK=0256 SRC=3A11 COUNT=0200
PAGE=01 ADDR=1600
RD: WRITE UNI=00 BLK=0258 SRC=3A11 COUNT=0200
PAGE=01 ADDR=1800
RD: WRITE UNI=00 BLK=025A SRC=3A11 COUNT=0200
PAGE=01 ADDR=1A00
RD: WRITE UNI=00 BLK=025C SRC=3A11 COUNT=0200
PAGE=01 ADDR=1C00
RD: WRITE UNI=00 BLK=025E SRC=3A11 COUNT=0200
PAGE=01 ADDR=1E00
DISK INITIALIZATION COMPLETE.
INSERT THE VOLUME YOU WISH TO INITIALIZE INTO RD0:;
REMEMBER, ANY DATA ON THIS VOLUME WILL BE DESTROYED.
HIT RETURN WHEN READY.
READY?
DEVICE <SY0:> ?
DO YOU HAVE ANY MORE DISKS TO INITIALIZE (YES/NO) <NO> ?NO
VOLUME 33000, MOUNTED ON SY0:
LABEL: MTC00
S: MOU RD0:
RD: READY
RD: MOUNT
RD: READ REGARDLESS UNI=00 BLK=0009 DEST=1C00 COUNT=0100
PAGE=01 ADDR=0900
RD: MOUNT
RD: WRITE UNI=00 BLK=0000 SRC=0260 COUNT=0000
RD: READ UNI=00 BLK=0010 DEST=D600 COUNT=0100
PAGE=01 ADDR=1000
RD: READ UNI=00 BLK=0260 DEST=1C00 COUNT=0100
PAGE=01 ADDR=2000
RD: READ UNI=00 BLK=0248 DEST=F600 COUNT=0200
PAGE=01 ADDR=0800
RD: READ UNI=00 BLK=024A DEST=F600 COUNT=0200
PAGE=01 ADDR=0A00
RD: WRITE UNI=00 BLK=0260 SRC=D600 COUNT=0100
PAGE=01 ADDR=2000
RD: READ UNI=00 BLK=024A DEST=F600 COUNT=0200
PAGE=01 ADDR=0A00
RD: WRITE UNI=00 BLK=024A SRC=F600 COUNT=0200
PAGE=01 ADDR=0A00
RD: READ REGARDLESS UNI=00 BLK=0009 DEST=1C00 COUNT=0100
PAGE=01 ADDR=0900
VOLUME 00500, MOUNTED ON RD0:
LABEL: RD0
S: DIR RD0:
RD: READ UNI=00 BLK=0248 DEST=F600 COUNT=0200
PAGE=01 ADDR=0800
RD: READ UNI=00 BLK=024A DEST=F600 COUNT=0200
PAGE=01 ADDR=0A00
RD: READ UNI=00 BLK=0248 DEST=F600 COUNT=0200
PAGE=01 ADDR=0800
RD: READ UNI=00 BLK=024A DEST=F600 COUNT=0200
PAGE=01 ADDR=0A00
NAME .EXT SIZE CREATED TIME FLAGS--- DATE: 02-MAR-82
0 FILES, USING 0 SECTORS (1728 FREE)
S:
norberto.collado koyado.com
Yes, I was using HDOS2. With HDOS3, it will not hang, but still get the table overflow message, so I cannot init under HDOS3.
Image I’m using here: http://koyado.com/heathkit/New-H8-Website/download/hcf_32kmonitor_20230330_1930.zip
Image boot format:
H8: Boot FF-0: ; boot HDOS 2.0
H8: Boot FF-0:1 ;boot HDOS 3.0
H8: Boot FF-0:2 ;boot Heath CP/M.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/662bbb69-577a-42c5-bd21-1cd1650a2e79n%40googlegroups.com.
smb...@gmail.com
smb...@gmail.com
norberto.collado koyado.com
Did try booting from my Z67-IDE+ controller HDOS2 and it fails in a different manner and system went back to the H8: monitor.
Also booted from another HDOS2 image and still fails and it goes back to the OS…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/76a9cdf0-f073-40d6-90eb-8d6ac44ffe7cn%40googlegroups.com.
norberto.collado koyado.com
The previous email capture looks like the HDOS got corrupted, just ignore it. I did try on Glenn’s Rusty image and I get the following under HDOS2.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855877917AC6D7DA76673C7F76F9%40SN6PR01MB3855.prod.exchangelabs.com.
Douglas Miller
For what it's worth...
I saw a similar-looking problem when I was experimenting with
HDOS device drivers for networking, where HDOS was getting
corrupted and crashing. What I believe was happening was that the
device driver was getting relocated twice, the second time causing
corruption of all the addresses. Everything starting working
correctly when I changed the initialization callback (DC.LOD, etc)
so that it set the DEV.RES flags DR.PR+DR.IM. Without this, it
appears that HDOS kept thinking the driver needed to be relocated.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855788778D41311257EF63AF76F9%40SN6PR01MB3855.prod.exchangelabs.com.
Richard Davis Jr.
Glenn Roberts
On May 2, 2023, at 9:08 AM, Richard Davis Jr. <rickdav...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CABvWWgavpW6t6EV1tD4c6WLj-wFweg_9Y2%2B7QrOwco%2BckskG7Q%40mail.gmail.com.
norberto.collado koyado.com
Sent: Tuesday, May 2, 2023 6:15:10 AM
To: se...@googlegroups.com <se...@googlegroups.com>
Glenn Roberts
On May 2, 2023, at 4:26 PM, norberto.collado koyado.com <norberto...@koyado.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385553995161116F50E7AEA0F76F9%40SN6PR01MB3855.prod.exchangelabs.com.
Scott Baker
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/305F5307-C5A2-4FDE-8D49-BF750C8853C0%40gmail.com.
norberto.collado koyado.com
Sent: Tuesday, May 2, 2023 4:12:43 PM
Scott Baker
073.333 104 05268 MOV B,H
073.334 115 05269 MOV C,L BC = byte count
073.335 041 341 074 05270 LXI H,FDPB
073.340 315 076 077 05271 CALL $FREAB.
073.343 332 062 074 05272 JC FDP7 Error
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385543C72E94E02305E06402F76C9%40SN6PR01MB3855.prod.exchangelabs.com.
norberto.collado koyado.com
Thanks for fixing HDOS2.0 RD0 driver issue. I just added the driver and It worked fine. No need to rename existing drivers. I have 4 dvd drivers running. Attached is the trace…
Runs fine at 8MHz.
This is a great addition to the 512KB board and the new 8GB Memory board. Better than Trionyx mass memory for the H8: http://koyado.com/Heathkit/Z-H8_CPU_Board_files/TRIONYX-MASS-MEMORY-FOR-THE-H8-05092017.pdf.
Let me know once schematics are up for the 8GB board and thanks for making it backwards compatible with the 512KB board; ingenuous. 😊
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CA%2B8qVMOF7ibm4iK2KeV%3DYHhi%3DQ3tpONfPKeZOjxDB5rVoef%2Bgw%40mail.gmail.com.
norberto.collado koyado.com
Sysgen worked fine as well. Now, how I boot from it?
Douglas, what it will take to enable the “H8: BOOT MM-0:” command to boot from the 512KB memory board instead of the MMS77318 ramdisk?
Sysgen:
Norby
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38555F36DC796AD6D9080482F76C9%40SN6PR01MB3855.prod.exchangelabs.com.
smb...@gmail.com
norberto.collado koyado.com
It is straight forward and Douglas can guide you thru the process.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c95aa5b6-a035-44bc-bb98-c5930f961cebn%40googlegroups.com.
Douglas Miller
One thing we should consider is some sort of checksum to validate that the ramdisk has actually been "sysgened". I'll need to review what the MMS 77318 did for that, and see if it is worth following. It also creates the need to standardize the boot area of the ramdisk somehow. Right now, the start of the ramdisk is decided by the OS (CP/M 3 or HDOS) and is probably different, so we'll need some standard way of determining where to boot from. Although, I guess making the CP/M 3 ramdisk bootable is probably not desired?
Also, if a machine is being used for both CP/M 3 and HDOS then
booting CP/M 3 will trash the ramdisk for HDOS. Just some things
to consider. The MMS 77318 was only bootable for CP/M 2.2, but one
still needs to know where the ramdisk starts (and where OS RAM
ends). Probably that is 64K for everything except CP/M 3, although
some of the "Z" variants of CP/M might also be different.
The "need" for booting from ramdisk may be diminished by
solid-state storage options, too (Z67-IDE, CF, SDCard). Booting
from MMS 77318 compared to H17 was mind-blowing, but it may not be
very noticeable compared to CF.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385533E0B7363824B37A3E79F76C9%40SN6PR01MB3855.prod.exchangelabs.com.
norberto.collado koyado.com
Thanks Douglas for such great feedback. It might not be worth for the 512KB board as CP/M3 will trash it, but it might be good for the 8MB board above the 512KB range.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3122a284-7b63-f442-acdd-b6f2fe90b4f1%40gmail.com.
smb...@gmail.com
Glenn Roberts
On May 3, 2023, at 10:44 AM, smb...@gmail.com <smb...@gmail.com> wrote:
Another thing I want to look into this weekend is autodetecting the type of board (512K or 8MB) and the presence of the board and installing some guardrails. I think this would be simple enough, just writing some strategic values and see any making sure they change in the correct page (and don't change main memory and/or the incorrect page). Right now if you load RD0: without an MMU-capable board, it will probably just crash the computer, and if you use RD1: - RD7: on the 512K board it will just overwrite RD0:.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/d1bdd742-60da-4ebf-b246-d8e80c3e46fan%40googlegroups.com.
smb...@gmail.com
DEVICE<SY0:>? RD0:
VOLUME 33000, DISMOUNTED FROM SY0:
LABEL: MTC00
HDOS, VERSION 3.0
ISSUE # 50.07.00
SYSTEM HAS 64K OF RAM
VOLUME 00500, MOUNTED ON SY0:
LABEL: RD0
S:
Glenn Roberts
On May 7, 2023, at 3:48 AM, smb...@gmail.com <smb...@gmail.com> wrote:
Glenn, I've implemented the SET command for a few options already SET DEBUG and SET TINY (for the the 512K board). Adding to it to offset the start of the Ramdisk would be easy enough.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5f66e760-853d-4f59-a9f5-a630d98330a5n%40googlegroups.com.
smb...@gmail.com
smb...@gmail.com
H8: Boot RR-3
ACTION? <BOOT> BOOT
HDOS, VERSION 3.0
ISSUE # 50.07.00
SYSTEM HAS 64K OF RAM
VOLUME 00503, MOUNTED ON SY0:
LABEL: RD3
S:
Douglas Miller
I'm wondering if we can go ahead use the 'M' device for this, since any
version of the new ROM on an H89 would be using the H8x512K (or variant)
anyway (and not the MMS 77318). I can't think of any other use for 'R'
yet, either, but just seems like 'M' could be reused for this. I don't
have strong feelings either way, though.
>>> <se...@googlegroups.com> *On Behalf Of *Douglas Miller
>>> *Sent:* Wednesday, May 3, 2023 5:08 AM
>>> *To:* se...@googlegroups.com
>>> *Subject:* Re: [sebhc] HDOS Device Driver Resources
>>>
>>> It is straight forward and Douglas can guide you
>>> thru the process.
>>>
>>> Norberto
>>>
>>> <se...@googlegroups.com> *On Behalf Of
>>> *smb...@gmail.com
>>> *Sent:* Tuesday, May 2, 2023 11:07 PM
>>> *To:* SEBHC <se...@googlegroups.com>
>>> *Subject:* Re: [sebhc] HDOS Device Driver Resources
>>> Excellent, great to hear it's working Norberto.
>>>
>>> The new boards arrived from jlcpcb today and
>>> I've started building one up. I'll have it
>>> tested and (assuming all is well) have
>>> schematics and gerbers ready by the weekend.
>>>
>>> If the boot is straightforward enough, I can
>>> take a look at that. By "straightforward", I
>>> mean just load a handful of sectors from memory.
>>> If it needs to parse directories or anything
>>> fancy like that, then might need some help.
>>>
>>> Scott
>>>
>>> On Tuesday, 2 May 2023 at 21:22:01 UTC-7 Norby
>>> wrote:
>>>
>>> Sysgen worked fine as well. Now, how I boot
>>> from it?
>>>
>>> Douglas, what it will take to enable the
>>> “H8: BOOT MM-0:” command to boot from the
>>> 512KB memory board instead of the MMS77318
>>> ramdisk?
>>>
>>>
>>> Norby
>>>
>>> *From:* se...@googlegroups.com
>>> <se...@googlegroups.com> *On Behalf Of
>>> *norberto.collado koyado.com <http://koyado.com>
>>> *Sent:* Tuesday, May 2, 2023 9:11 PM
>>> *To:* se...@googlegroups.com
>>> *Subject:* RE: [sebhc] HDOS Device Driver
>>>
>>> Thanks for fixing HDOS2.0 RD0 driver issue.
>>> I just added the driver and It worked fine.
>>> No need to rename existing drivers. I have 4
>>> dvd drivers running. Attached is the trace…
>>>
>>> This is a great addition to the 512KB board
>>> and the new 8GB Memory board. Better than
>>> Trionyx mass memory for the H8:
>>> http://koyado.com/Heathkit/Z-H8_CPU_Board_files/TRIONYX-MASS-MEMORY-FOR-THE-H8-05092017.pdf.
>>>
>>>
>>> Let me know once schematics are up for the
>>> 8GB board and thanks for making it backwards
>>> compatible with the 512KB board; ingenuous. 😊
>>>
>>> Norberto
>>>
>>> <se...@googlegroups.com> *On Behalf Of
>>> *Scott Baker
>>> *Sent:* Tuesday, May 2, 2023 7:53 PM
>>> *To:* se...@googlegroups.com
>>> *Subject:* Re: [sebhc] HDOS Device Driver
>>> wrote:
>>>
>>> Thanks Scott!
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:*se...@googlegroups.com<se...@googlegroups.com>
>>> *To:*
>>> se...@googlegroups.com<se...@googlegroups.com>
>>> *Subject:* Re: [sebhc] HDOS Device
>>>
>>> I got it working with both Norberto’s
>>> hdos3 and hdos2 images last night. For
>>> hdos3 I removed every disk driver except SY.
>>>
>>> For hdos2 it will require a code change.
>>>
>>> Will provide more details tonight.
>>>
>>> Scott
>>>
>>> On Tue, May 2, 2023 at 3:09 PM Glenn
>>> Roberts <glenn.f...@gmail.com> wrote:
>>>
>>> I can try later this evening
>>>
>>> Sent from my iPad
>>>
>>> On May 2, 2023, at 4:26 PM,
>>> norberto.collado koyado.com
>>>
>>>
>>>
>>> I went down to 2 dvd devices and
>>> still same issue.
>>>
>>> Get Outlook for iOS
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:*se...@googlegroups.com<se...@googlegroups.com>
>>> *Sent:* Tuesday, May 2, 2023
>>> 6:15:10 AM
>>> *To:*
>>> se...@googlegroups.com<se...@googlegroups.com>
>>> *Subject:* Re: [sebhc] HDOS
>>>
>>> The previous email
>>> capture looks like the
>>> HDOS got corrupted, just
>>> ignore it. I did try on
>>> Glenn’s Rusty image and
>>> I get the following
>>> under HDOS2.
>>>
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On Behalf Of
>>> *norberto.collado
>>> koyado.com
>>> <http://koyado.com>
>>> *Sent:* Monday, May 1,
>>> 2023 10:47 PM
>>> *To:* se...@googlegroups.com
>>> *Subject:* RE: [sebhc]
>>>
>>> Did try booting from my
>>> Z67-IDE+ controller
>>> HDOS2 and it fails in a
>>> different manner and
>>> system went back to the
>>> H8: monitor.
>>>
>>> HDOS2 image and still
>>> fails and it goes back
>>> to the OS…
>>>
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On Behalf Of
>>> *smb...@gmail.com
>>> *Sent:* Monday, May 1,
>>> 2023 10:27 PM
>>> *To:* SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:* Re: [sebhc]
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On Behalf Of
>>> *smb...@gmail.com
>>> *Sent:* Monday,
>>> <se...@googlegroups.com>
>>> *Subject:* Re:
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On Behalf
>>> Of
>>> *norberto.collado
>>> koyado.com
>>> <http://koyado.com>
>>> *Sent:*
>>> 1, 2023 8:51 PM
>>> se...@googlegroups.com
>>> *Subject:*
>>> HDOS Device
>>> Driver Resources
>>>
>>> Take it
>>> back! Same
>>> issue with
>>> different
>>> error
>>> message.
>>> System hangs
>>> after
>>> printing the
>>> last message.
>>>
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On Behalf
>>> Of *Norby
>>> *Sent:*
>>> 1, 2023 8:46 PM
>>> <se...@googlegroups.com>
>>> *Subject:*
>>>
>>> *From:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *smb...@gmail.com
>>> *Sent:*
>>> May
>>> 1,
>>> 2023
>>> 7:36 PM
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:*se...@googlegroups.com<se...@googlegroups.com>
>>> *Sent:*Monday,
>>> 1,
>>> 2023
>>> 6:50:28
>>> AM
>>>
>>>
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>> wrote:
>>>
>>>
>>>
>>>
>>> They
>>> are
>>> all
>>> for
>>> backordering.
>>>
>>>
>>> *se...@googlegroups.com<se...@googlegroups.com>
>>> *Date:
>>> *Sunday,
>>> 30,
>>> 2023
>>> at
>>> 7:27
>>> PM
>>> *SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:
>>> *Re:
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *glenn.f...@gmail.com
>>> *Sent:*
>>> April
>>> 30,
>>> 2023
>>> 6:44
>>> PM
>>> se...@googlegroups.com
>>> *Subject:*
>>>
>>> *From:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *Joseph
>>> Travis
>>> *Sent:*
>>> April
>>> 30,
>>> 2023
>>> 9:12
>>> PM
>>> se...@googlegroups.com
>>> *Subject:*
>>>
>>> *From:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *norberto.collado
>>> koyado.com
>>> <http://koyado.com>
>>> *Sent:*
>>> April
>>> 30,
>>> 2023
>>> 8:19
>>> PM
>>> se...@googlegroups.com
>>> *Subject:*
>>> *se...@googlegroups.com<se...@googlegroups.com>
>>> *Date:
>>> *Sunday,
>>> 30,
>>> 2023
>>> at
>>> 4:49
>>> PM
>>> *SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:
>>> *Re:
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *Glenn
>>> Roberts
>>> *Sent:*
>>> April
>>> 30,
>>> 2023
>>> 3:09
>>> AM
>>> se...@googlegroups.com
>>> *Subject:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *smb...@gmail.com
>>> *Sent:*
>>> April
>>> 28,
>>> 2023
>>> 4:40
>>> PM
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *smb...@gmail.com
>>> *Sent:*
>>> April
>>> 28,
>>> 2023
>>> 3:45
>>> PM
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>>
>>> *From:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *Douglas
>>> Miller
>>> *Sent:*
>>> April
>>> 28,
>>> 2023
>>> 7:37
>>> AM
>>> se...@googlegroups.com
>>> *Subject:*
>>>
>>> *From:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *smb...@gmail.com
>>> *Sent:*
>>> April
>>> 26,
>>> 2023
>>> 2:09
>>> AM
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *smb...@gmail.com
>>> *Sent:*
>>> April
>>> 18,
>>> 2023
>>> 11:02
>>> AM
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>> HDOS
>>> included
>>> source
>>> for
>>> the
>>> and
>>> serial
>>> drivers
>>> with
>>> the
>>> HDOS
>>> 2
>>> distribution
>>> disks.
>>> There
>>> are
>>> multiple
>>> copies
>>> of
>>> these
>>> in
>>> the
>>> SEBHC.ORG
>>> archive,
>>> for
>>> example
>>> see
>>> the
>>> disk
>>> (confusingly)
>>> labelled
>>> “HDOS3.H8D”
>>> in
>>> Vol
>>> 1.
>>>
>>> ======== === ==== =========
>>> FILE EXT SIZE DATE
>>>
>>> ======== === ==== =========
>>> *ATH84 ASM 34 29-Oct-80*
>>> *DDDVD ASM 31 29-Oct-80*
>>> *DDINIT ASM 64 03-Dec-80*
>>> *LPH24 ASM 46 07-Oct-80*
>>> *MAKMSD ASM 11 07-Oct-80*
>>> *ND ASM 10 07-Oct-80*
>>> *SYDVD ASM 34 07-Oct-80*
>>> *SYINIT ASM 37 08-Oct-80*
>>> *GLASSTTY ASM 16 07-Oct-80*
>>> *TBRA ACM 2 07-Oct-80*
>>> *TYPTX ACM 2 07-Oct-80*
>>> *U8250 ACM 9 07-Oct-80*
>>> *U8251 ACM 5 07-Oct-80*
>>> *ZEROS ACM 1 07-Oct-80*
>>> *RGT SYS 1 07-Oct-80*
>>> *GRT SYS 1 07-Oct-80*
>>> *DIRECT SYS 8 07-Oct-80*
>>> ======== === ==== =========
>>> *Files 18, Total 380, Free 2*
>>> HUG
>>> also
>>> released
>>> an
>>> enhanced
>>> “SY:”
>>> (H17)
>>> driver
>>> on
>>> 885-1095
>>> (also
>>> in
>>> Vol.
>>> 1
>>> on
>>> SEBHC
>>> site):
>>>
>>> ======== === ==== =========
>>> FILE EXT SIZE DATE
>>>
>>> ======== === ==== =========
>>> *SY DVD 12 15-Jun-81*
>>> *DKH17 ASM 23 15-Jun-81*
>>> *DKH17I ASM 16 15-Jun-81*
>>> *DKH17 REL 6 15-Jun-81*
>>> *DKH17I REL 6 15-Jun-81*
>>> *DVDDKGEN ABS 3 15-Jun-81*
>>> *DVDDKGEN ASM 6 15-Jun-81*
>>> *MFREADY ACM 7 15-Jun-81*
>>> *MFDVD ACM 49 15-Jun-81*
>>> *MFINIT ACM 33 15-Jun-81*
>>> *INITAUTO ABS 28 15-Jun-81*
>>> *SYDVD DOC 84 16-Jun-81*
>>> *RGT SYS 1 21-Oct-80*
>>> *GRT SYS 1 21-Oct-80*
>>> *DIRECT SYS 6 21-Oct-80*
>>> ======== === ==== =========
>>> *Files 16, Total 295, Free 88*
>>> And
>>> there’s
>>> 885-1105
>>> there
>>> as
>>> well
>>> which
>>> has
>>> a
>>> few
>>> more
>>> drivers
>>> plus
>>> enhancements
>>> to
>>> CK.DVD:
>>>
>>> ======== === ==== =========
>>> FILE EXT SIZE DATE
>>>
>>> ======== === ==== =========
>>> *LPMX80 ABS 7 22-Oct-81*
>>> *LPMX80 ASM 55 22-Oct-81*
>>> *DEMOMX BAS 6 22-Oct-81*
>>> *PT560 ABS 6 22-Oct-81*
>>> *PT560 ASM 77 22-Oct-81*
>>> *PT560 DOC 13 22-Oct-81*
>>> *DEMO560 BAS 24 22-Oct-81*
>>> *GRAPH560 BAS 17 22-Oct-81*
>>> *LADVD ABS 6 22-Oct-81*
>>> *LADVD ASM 51 22-Oct-81*
>>> *CKDVD ABS 5 22-Oct-81*
>>> *CKDVD ASM 48 22-Oct-81*
>>> *OCKDVD ABS 4 22-Oct-81*
>>> *SETTIME ABS 1 22-Oct-81*
>>> *SETTIME ASM 10 22-Oct-81*
>>> *RGT SYS 1 22-Oct-81*
>>> *GRT SYS 1 22-Oct-81*
>>> *DIRECT SYS 18 22-Oct-81*
>>> ======== === ==== =========
>>> *Files 19, Total 376, Free 4*
>>> There
>>> are
>>> generally
>>> two
>>> pieces
>>> to
>>> any
>>> disk
>>> device
>>> driver:
>>> the
>>> core
>>> driver
>>> and
>>> the
>>> “INIT”
>>> portion.
>>> You
>>> don’t
>>>
>>> *From:*
>>> se...@googlegroups.com
>>> <se...@googlegroups.com>
>>> *On
>>> Behalf
>>> Of
>>> *smb...@gmail.com
>>> *Sent:*
>>> April
>>> 17,
>>> 2023
>>> 9:58
>>> PM
>>> SEBHC
>>> <se...@googlegroups.com>
>>> *Subject:*
>>> <https://groups.google.com/d/msgid/sebhc/d9d25f31-a807-4096-8d73-f26b3911e241n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/14a677bd-3de2-442f-b782-c52c046847ebn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/00e701d9782a%2486ddc260%2494994720%24%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/7524f4a3-6f03-9b05-21c5-7c924f1d7251%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/1146bf92-6089-49ff-8b55-4267549624aen%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/a5ca207c-68fe-2d2f-e953-08a8a290ff3f%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/CA%2B8qVMNdjTHnf1kF1Q9Swr3VCQ5-PT2uUzaJ%2BaiPrL4LrqrTqg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/9312c2bf-ee49-4f91-9313-9d6277b6b4f4n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/25b42be9-3e47-87ca-2a95-c45acba8a1a5%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/E22F0D87-126F-40C2-8A70-3790C765E76E%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/528bb1b7-7296-42e7-4336-50906f68dded%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/037b01d979d7%2446237a40%24d26a6ec0%24%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/1a43b329-4390-4442-81b2-2d9660b86209n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/f65556be-cf72-475d-b227-f7ee4c1a895en%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/05ff01d97a84%245f716900%241e543b00%24%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/e4e47928-da16-4121-b1dd-4dd9ae6fae77n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/C2C70BA8-F0DD-43EE-AED6-0E2D2977604F%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/09e60d81-c50d-496a-bdf1-36a7be3a9a08n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/BN7PR01MB38447A7EFF14466203D4BC28F76E9%40BN7PR01MB3844.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/003901d97bc3%24deb1e560%249c15b020%24%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/CAGQDgBCCtw7U9TLiv73JeU5HzjDCr0HL0JNwPpJQNxcKGfx-aQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/000201d97bce%246a961380%243fc23a80%24%40gmail.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/384a4ad7-43cf-414d-9dbe-ae3a25b9f32an%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB38550602EE8CAD31BDC8024DF76E9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/02d5cc52-ff17-4164-9b2d-22bac11f9852n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/847b5c60-d38f-4579-b0a1-4e2ee483f745n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB38553D98F428296736AEAF2EF76F9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received
>>> this message
>>> because you
>>> are
>>> subscribed
>>> to the
>>> Groups
>>> "SEBHC" group.
>>> To
>>> unsubscribe
>>> from this
>>> group and
>>> stop
>>> receiving
>>> emails from
>>> it, send an
>>> email to
>>> sebhc+un...@googlegroups.com.
>>> To view this
>>> discussion
>>> on the web
>>> visit
>>> <https://groups.google.com/d/msgid/sebhc/94a1e278-fa7a-4bda-af48-0ee58e326ac2n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received
>>> this message
>>> because you
>>> are
>>> subscribed
>>> to the
>>> Groups
>>> "SEBHC" group.
>>> To
>>> unsubscribe
>>> from this
>>> group and
>>> stop
>>> receiving
>>> emails from
>>> it, send an
>>> email to
>>> sebhc+un...@googlegroups.com.
>>>
>>> To view this
>>> discussion
>>> on the web
>>> visit
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB385538FEB9370926D0328F0BF76F9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message
>>> because you are subscribed to
>>> the Google Groups "SEBHC" group.
>>> To unsubscribe from this group
>>> and stop receiving emails from
>>> it, send an email to
>>> sebhc+un...@googlegroups.com.
>>> To view this discussion on the
>>> web visit
>>> <https://groups.google.com/d/msgid/sebhc/CC461742-8D7C-4884-B408-8974D74C3704%40gmail.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message
>>> because you are subscribed to
>>> the Google Groups "SEBHC" group.
>>> To unsubscribe from this group
>>> and stop receiving emails from
>>> it, send an email to
>>> sebhc+un...@googlegroups.com.
>>> To view this discussion on the
>>> web visit
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB385553995161116F50E7AEA0F76F9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because
>>> you are subscribed to the Google
>>> Groups "SEBHC" group.
>>> To unsubscribe from this group and
>>> stop receiving emails from it, send
>>> an email to
>>> sebhc+un...@googlegroups.com.
>>> To view this discussion on the web
>>> visit
>>> <https://groups.google.com/d/msgid/sebhc/305F5307-C5A2-4FDE-8D49-BF750C8853C0%40gmail.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you
>>> are subscribed to the Google Groups
>>> "SEBHC" group.
>>> To unsubscribe from this group and stop
>>> receiving emails from it, send an email
>>> to sebhc+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/CA%2B8qVMO_pKN5XqWYmr6%3DozGtWshHOY2YduZx3Nwz5FEB2Xb2Pg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you
>>> are subscribed to the Google Groups
>>> "SEBHC" group.
>>> To unsubscribe from this group and stop
>>> receiving emails from it, send an email
>>> to sebhc+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB385543C72E94E02305E06402F76C9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are
>>> subscribed to the Google Groups "SEBHC" group.
>>> To unsubscribe from this group and stop
>>> receiving emails from it, send an email to
>>> sebhc+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/CA%2B8qVMOF7ibm4iK2KeV%3DYHhi%3DQ3tpONfPKeZOjxDB5rVoef%2Bgw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are
>>> subscribed to the Google Groups "SEBHC" group.
>>> To unsubscribe from this group and stop
>>> receiving emails from it, send an email to
>>> sebhc+un...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB38555F36DC796AD6D9080482F76C9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are
>>> subscribed to the Google Groups "SEBHC" group.
>>> To unsubscribe from this group and stop
>>> receiving emails from it, send an email to
>>> sebhc+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/c95aa5b6-a035-44bc-bb98-c5930f961cebn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are
>>> subscribed to the Google Groups "SEBHC" group.
>>> To unsubscribe from this group and stop
>>> receiving emails from it, send an email to
>>> sebhc+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/SN6PR01MB385533E0B7363824B37A3E79F76C9%40SN6PR01MB3855.prod.exchangelabs.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are subscribed
>>> to the Google Groups "SEBHC" group.
>>> To unsubscribe from this group and stop receiving
>>> emails from it, send an email to
>>> sebhc+un...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/3122a284-7b63-f442-acdd-b6f2fe90b4f1%40gmail.com?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are subscribed to
>>> the Google Groups "SEBHC" group.
>>> To unsubscribe from this group and stop receiving emails
>>> from it, send an email to sebhc+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> <https://groups.google.com/d/msgid/sebhc/d1bdd742-60da-4ebf-b246-d8e80c3e46fan%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> --
>> You received this message because you are subscribed to the
>> Google Groups "SEBHC" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to sebhc+un...@googlegroups.com.
>> To view this discussion on the web visit
>> <https://groups.google.com/d/msgid/sebhc/5f66e760-853d-4f59-a9f5-a630d98330a5n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sebhc+un...@googlegroups.com.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/sebhc/34221128-1517-480e-ba5d-861fdb288c93n%40googlegroups.com?utm_medium=email&utm_source=footer>.
smb...@gmail.com
Douglas Miller
Sure, and submit it so I can add to the github repo. At some
point, we'd want this to work for Heath CP/M, too. I don't think
we need to try and make a CP/M 3 boot option, for several reasons.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/bf29dbb3-9271-42c1-9a01-3536a7f2b1bfn%40googlegroups.com.
norberto.collado koyado.com
Sure, just send me the files with high level instructions to test it out on the Z80/512KB with V2.1 FW. What changes are needed to run on the Z180 that has 1MB of RAM?
Norby
From: se...@googlegroups.com <se...@googlegroups.com>
On Behalf Of smb...@gmail.com
Sent: Sunday, May 7, 2023 1:35 PM
To: SEBHC <se...@googlegroups.com>
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/bf29dbb3-9271-42c1-9a01-3536a7f2b1bfn%40googlegroups.com.
Douglas Miller
The Z180 will require a different boot method, which we can work
on once this version is stable.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385559162F2EB31D563FF4F7F7709%40SN6PR01MB3855.prod.exchangelabs.com.
smb...@gmail.com
smb...@gmail.com
norberto.collado koyado.com
Here is the output of the rddiag file. Tested the new rd.dvd and so far so good. Next step is to download the new monitor.
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/da79b597-6f02-40c1-83c4-3dce712484dan%40googlegroups.com.
norberto.collado koyado.com
This is so cool! I was able to boot from it. Then, Powered down the H8 system, removed the 512KB board, put it back after 10 minutes, and it booted from RAM without any issues.
From the serial monitor selected 8MHz and it booted into HDOS within a second. Now my Z67-IDE+ feels slow when compared with the RAM board and the CF controller.
I’m impressed Scott and thank you for doing this. You just recreated Trionyx Mass Storage Controller and much better. Back then in the mid 80’s I had my 256KB memory board doing the same with Trionyx drivers (http://koyado.com/Heathkit/256K_Memory_Board_Bank_SW.html) which I still have.
On the 8MB board, can we get the capability to boot from drive 1 as well? Eventually we need to boot from Heath CP/M using the same procedure that Rick/Joe’ developed on the CF controller.
I did test booting from the front panel and no issues.
Thanks,
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38558BCD8BEE040A3B142D90F7769%40SN6PR01MB3855.prod.exchangelabs.com.
smb...@gmail.com
Douglas Miller
Can we establish some sort of "signature" so we can tell whether
the ramdisk has been sysgened? Either some "magic cookie" in the
first 256 bytes, or else a convention for checksumming that area.
This will require changes to the way the ramdisk is made bootable
(whatever program "sysgen"s it). I think this is important because
it is far too easy to wipe out the boot pages, for example by
booting CP/M 3 or running a memory test.
One issue with booting other ramdisk drives ("partitions") is the same as with harddisks - there's no way to tell where the subsequent ramdisks start. This could also be part of signing the bootstrap sector, too, by placing some sort of partition information in that sector (i.e. a Master Boot Record). since the H8-512K will never have more than one ramdisk, it may make sense to keep whatever we do here simple so that it doesn't take up any more space than absolutely necessary.
For CP/M we have the same problem as with harddisks: If the partitioning can be customized then the DPB (filesystem configuration) also needs to customized and probably stored on the ramdisk somewhere. MMS put that information in the "MBR", I'm not sure what Heath or QuikStor did.
An alternative here is to be less "flexible" about how the
ramdisk is used. I don't know what is being done right now to
create multiple ramdisk drives, so can't comment on how flexible
it is and whether it needs to be that way. If one wanted to create
RD1:, how does that happen and who chooses what size RD0: and RD1:
are? (etc for RD2: and so forth).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ea2e862a-b1de-401e-a6f6-660b2b94d33cn%40googlegroups.com.
Douglas Miller
As I ponder this, I'm thinking we should handle this the same as
harddisks. The ROM only reads the bootstrap off the first physical
sectors of the media, and whatever it reads is responsible for any
partitioning the user may have setup. If the ramdisk is
partitioned into multiple drives, then a different bootstrap is
used than for the simple case of the entire ramdisk being one
drive. This means that the boot command "unit" will always be "0",
but an optional partition may be specified to select which ramdisk
drive (partition) to boot - and the "primary" bootstrap is
responsible for interpreting that and continuing the boot using
the selected partition. This is how harddisks are booted (although
not all partitioning bootstraps honor the partition number
specified in the boot command, instead requiring the user to
select the partition from a menu).