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…
--
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7524f4a3-6f03-9b05-21c5-7c924f1d7251%40gmail.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a5ca207c-68fe-2d2f-e953-08a8a290ff3f%40gmail.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/25b42be9-3e47-87ca-2a95-c45acba8a1a5%40gmail.com.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/08f8e0b3-5d19-49cd-89c8-664457dd77c4n%40googlegroups.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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/C2C70BA8-F0DD-43EE-AED6-0E2D2977604F%40gmail.com.
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.
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.
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.
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…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB38447A7EFF14466203D4BC28F76E9%40BN7PR01MB3844.prod.exchangelabs.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/003901d97bc3%24deb1e560%249c15b020%24%40gmail.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.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38553D98F428296736AEAF2EF76F9%40SN6PR01MB3855.prod.exchangelabs.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.
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.
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.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/305F5307-C5A2-4FDE-8D49-BF750C8853C0%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385543C72E94E02305E06402F76C9%40SN6PR01MB3855.prod.exchangelabs.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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).