I configured this one for 3 "user" banks. Each bank is 48K (in keeping with the MMU512K page size), and so a program has a maximum 48K TPA. Since the board has 512K, and I have not (yet) added a ramdisk, we could have more user segments. However, I'm not sure of what benefit that would be. It depends on how many users are supported plus any "background" programs you want to run. For 2 users, 3 banks is probably plenty.
Note that the MP/M equivalent of CCP (command prompt) does not
run in any user bank, so until a user presses RETURN on the
command they typed, no memory bank is allocated. A bank is only
used for the duration of running the program.
If people want to do more extensive programming or running of background jobs, it's fairly easy to expand the number of banks.
MP/M supports a maximum of 16 memory segments. It seems difficult to get user memory banks larger than 48K (due to the size of the system code), so that would be 720K of user banks (plus the 64K "bank 0" for the system).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/DM6PR01MB38504F84F898FAE8F2B1BF53F7709%40DM6PR01MB3850.prod.exchangelabs.com.
Thanks to Glenn, I now have MP/M-ready versions of the VDIP
utilities. I've updated the MP/M image to include those, and some
other useful utilities.
http://sebhc.durgadas.com/mms89/images/mpm.z67ide.xz
I've also put a README file there, to help provide more information for getting started.
http://sebhc.durgadas.com/mms89/images/README.MPM
This current system uses as much of the MMU-512K RAM as possible
(7 user segments of 48K each, plus the 64K system segment). Using
all of those segments would be a challenge.
I'm not sure what's available out there as far as MP/M user
tutorials goes, but I can help answer questions. A lot is similar
to CP/M 2.2, others reminiscent of CP/M 3. Still other
features/options are totally new. There is no HELP for commands
(yet), so you're back to reading whatever manuals you can find
online.
And no doubt there are at least a few out there who have no idea what the “VDIP” stuff is. This is the software that allows us to read/write files to flash drives using the FTDI VDIP-1 breakout board built into the new 3.0 and 4.0 Z80 CPU boards, the H17 “piggyback” I/O board, but also as a separate accessory board for the H8 or H89. I am ridiculously behind at documenting that and getting out the baselined code and a REMarks article. Right at the top of my 2022 New Years resolutions!
I see that a number of you out there are planning to build out serial/USB (VDIP) boards for the H89 so it’s time to get this documented!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/dee53669-a99c-d7f6-3857-403cca9cf817%40gmail.com.
Since my original motivation for doing MP/M was to implement a CP/NET server, I also have an H8 MP/M image that includes the CP/NET Server for the WizNET board. Of course, it requires all client nodes to also have a WizNET board, or else you must simulate clients on PC(s).
This server does not (yet) support CP/M3 clients. I've not tried
it to see what works and what doesn't.
Anyway, for those interested, the images are at http://sebhc.durgadas.com/mms89/images/
I also put tarballs of the CP/NET client packages there.
The CP/NET source code is at https://github.com/durgadas311/cpnet-z80
I did add protection for MP/M drive A: in this server, such that
CP/NET clients are not allowed to write to drive A: (the MP/M
system drive). This plugs one of the more-glaring security holes
in MP/M network servers.
I have updated the MP/M Z67-IDE image with latest changes. Most
notable is that I now have HELP there. It's not a replacement for
the MP/M User's Guide, but should "help".
http://sebhc.durgadas.com/mms89/images/ There's also a README file
there, giving a little background. This image uses the two serial
ports "con" (350Q) and "lp" (340Q) as consoles, and requires the
MMU-512K RAM add-on. It also benefits greatly from the VDIP1, if
you want to import more files (for just kicking tires, probably
fine as-is).
I did not update the CP/NET Server image (yet). Let me know if
you want to run that. I just completed CP/NET Server testing on an
RC2014 Z180 with a WizNET adapter, and can build a version for the
H8 fairly easily. That requires the H8xSPI+WizNET board. I can
help you run my simulator for CP/NET clients (requesters), or if
you have more WizNET boards you can use real H8s.
Douglas: So far unable to boot this on either of my two eligible configurations.
Big Blue has Rev 4 CPU and 512K RAM-MMU plus fully configured “piggyback” I/O board (H17@174Q; H37@170Q; H67@274Q). attempting to boot just returns immediately to the monitor prompt.
I was guessing that the image is looking for the H67 on 174Q so I went to my Rev 3.1 system (w/ 512K RAM-MMU). This one also has the new I/O board but without the H17 piggyback, and is configured for H37@170Q; H67@174Q. when I attempt to boot the system performs an I/O operation but then the front panel hangs with the horn on.
Both systems run CP/M 3 fine based on images Douglas has provided.
Feels like I’ve been here before. I remember having similar or same symptoms before back when I was first trying to get CP/M 3 running. Any thoughts on what’s wrong or how to debug? My preference is to run on Big Blue with the ’67 on 274Q. that’s my normal config and preserves flexibility in having one or both classes of floppy drives.
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Douglas Miller
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f4581259-4cce-1e59-bfea-5551aa0cae07%40gmail.com.
On Dec 31, 2021, at 12:42 AM, norberto.collado koyado.com <norberto...@koyado.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855E6423FB59E7B50C29FA4F7469%40SN6PR01MB3855.prod.exchangelabs.com.
I'm going to set this config up on my simulator and try. I'll
also verify that the image on the web site is not corrupted. The
boot loader is nearly identical to the CP/M 3, should only differ
in the high-level code that loads MPM.SYS vs. CPM3.SYS. But at
least one of your systems seems to never get to the point where it
is loading.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/56A3389E-7F52-4A5A-806B-3C5BF2D1AC77%40gmail.com.
I was able to recreate both issues. Tried various things, including a complete rebuild of the image, and still had problems. I then noticed that my setup (Z80 V4), based on an investigation for Norberto a year ago, had an earlier version of the new monitor ROM. I then updated the ROM and it worked.
The Z80 V3.1 system is still failing, and seems to be related to the PAM37 Monitor ROM setting up the boot stack differently than expected. I'll have to look into that deeper.
So, try updating your V4 ROM. This is the latest: http://sebhc.durgadas.com/mms89/h8mon2/h8mon2-v2.0b26.rom.
I also updated the MP/M image, just to be sure we're using the
same one: http://sebhc.durgadas.com/mms89/images/mpm.z67ide.xz
I think I've discovered an incompatibility between the new MP/M
(and CP/M 3) boot loaders and PAM37 (even MMS 444-84x). The MMS
ROM boot routines are inconsistent in how they enter the
bootloader code (read off disk). Original MMS hardware boots with
the error routine on the stack, Heath hardware boots with the
error routine popped off the stack (but still a "ghost" on the
stack). PAM37 does not do either. For the new ROM, I was brutally
consistent.
The new Monitor ROM always enters the bootloaders with the error
routine on the stack. This should not be a problem (apparently is
not, as I can boot Heath CP/M) for bootloaders that are not
expecting anything on the stack. But, CP/M3 (and MP/M) bootloaders
do expect the error routine, plus an optional boot string
(partition, slice identifiers). And if the error routine is
missing (as in PAM37) then the boot string is bogus (also) and the
loader throws an error by returning to the (invalid) error
routine, and crashes.
I'm working on a scheme so that CP/M3 and MP/M can detect how
they were entered and skip trying to use the error routine or boot
string in the case of ROMs like PAM37. For now, these images won't
boot from PAM37.
I updated the ROM to 2.0b26 and verified that I was still able to boot my good CP/M 3 and HDOS 3 images. All worked fine.
I then burned the new mpm.z67ide into a CF and tried to boot from that. I get the same behavior as before. It reads the boot code but then immediately bombs out and comes back to the monitor prompt.
This is on Big Blue; Rev 4 CPU; triple I/O “piggyback” board (H17, H37, H67). I did update the configuration information in the ROM to indicate the correct ports for the ’37 and ’67 and the fact that there’s a 512KB MMU board installed.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/70730bac-a391-5aac-e902-f7ca2eca3ffc%40gmail.com.
I'm probably going to need more details about your system and how you are booting. I'm able to boot this image from both the H19 and the front panel on my simulator, at least using the commands/sequences I'm familiar with.
Probably need to see what you have configured for settings in the ROM, plus what your dipswitch settings are.
Then need to know just what you are doing to boot, either console command or keypad sequence.
Last resort, may need you to copy off the first few Kbytes (2K should be plenty) of the CF card and send me that file.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/005501d7fe5d%24840cbd40%248c2637c0%24%40gmail.com.
Here’s the ROM configuration session:
H8: Config setup v0.2
Primary/Default boot device (E):
Primary/Default boot unit (0):
Primary/Default boot string ():
Secondary boot device (): C
Secondary boot unit (): 0
Secondary boot string ():
H8-512K RAM installed (Y):
H67 Port (FF=use SW1) (BC):
H47 Port (FF=use SW1) (FF):
H37 Port (FF=use SW1) (78):
Save changes (N): Y
Setup data saved
SW501 settings are as recommended on page 8 of:
http://koyado.com/Heathkit/H8-Z80-64K-RTC-ORG0-V4_files/Z80_V_4_0_Jumper_Definition_V02.pdf
i.e.
I usually issue boot from H19/monitor (“E0”) but problem also occurs via universal front panel keypad boot (“BOOT”, “67”, “274”, “0”)
A new problem seems to have arisen. On two occasions an attempt at booting seems to have corrupted something in the EEPROM. When this happens, if I turn the machine on I get RUN and PWR lights on full, MON light out and ION light on faintly (presumably cycling off and on). power cycling the machine does not resolve the problem. the only solution I have found is to pull the CPU card, remove the daughterboard (to access the EEPROM), pull the EEPROM and reprogram it. When I do that I can get the system back to normal.
This does not always happen. Has happened twice now. Usually when I attempt to boot from the image it just comes back to the prompt.
Not sure if I have an ability to dump from the CF drive directly but here’s the first 2K bytes of the file that I wrote to the device.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 C3 80 24 1F 01 08 00 08 00 00 00 00 00 00 00 00 À$.............
00000010 00 00 00 08 00 00 0C 01 00 0C 02 00 0C 03 00 0C ................
00000020 04 00 0C 05 00 0C 06 00 0C 07 00 0C 00 00 00 40 ...............@
00000030 00 05 1F 01 FB 07 FF 03 FF 00 00 00 02 00 01 80 ....û.ÿ.ÿ......€
00000040 00 FF FF FF 40 00 05 1F 01 FB 07 FF 03 FF 00 00 .ÿÿÿ@....û.ÿ.ÿ..
00000050 00 02 00 01 80 00 FF FF FF 40 00 05 1F 01 FB 07 ....€.ÿÿÿ@....û.
00000060 FF 03 FF 00 00 00 02 00 01 80 00 FF FF FF 40 00 ÿ.ÿ......€.ÿÿÿ@.
00000070 05 1F 01 FB 07 FF 03 FF 00 00 00 02 00 01 80 00 ...û.ÿ.ÿ......€.
00000080 FF FF FF 40 00 05 1F 01 FB 07 FF 03 FF 00 00 00 ÿÿÿ@....û.ÿ.ÿ...
00000090 02 00 01 80 00 FF FF FF 40 00 05 1F 01 FB 07 FF ...€.ÿÿÿ@....û.ÿ
000000A0 03 FF 00 00 00 02 00 01 80 00 FF FF FF 40 00 05 .ÿ......€.ÿÿÿ@..
000000B0 1F 01 FB 07 FF 03 FF 00 00 00 02 00 01 80 00 FF ..û.ÿ.ÿ......€.ÿ
000000C0 FF FF 40 00 05 1F 01 FB 07 FF 03 FF 00 00 00 02 ÿÿ@....û.ÿ.ÿ....
000000D0 00 01 80 00 FF FF FF 00 00 00 00 00 00 00 00 00 ..€.ÿÿÿ.........
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000200 C3 85 24 00 00 D1 21 EE 25 C1 79 FE C3 28 03 77 Ã…$..Ñ!î%ÁyþÃ(.w
00000210 78 B7 31 80 26 D5 C0 3A 34 20 FE 05 30 04 D6 03 x·1€&ÕÀ:4 þ.0.Ö.
00000220 18 02 D6 A8 E6 03 0F 0F 0F 32 E8 25 3A 8D 22 32 ..Ö¨æ....2è%:."2
00000230 E7 25 3A 91 22 32 EB 25 3A 50 21 4F 0C CD 6A 25 ç%:‘"2ë%:P!O.Íj%
00000240 CD 8B 25 CD C9 25 3A 83 22 E6 E0 C2 E7 24 0C 3E Í‹%ÍÉ%:ƒ"æàÂç$.>
00000250 0C 32 E7 25 CD 6A 25 CD 8B 25 21 85 22 06 08 1E .2ç%Íj%Í‹%!…"...
00000260 C8 CD 93 25 CD C9 25 21 EE 25 7E B7 28 07 D6 30 ÈÍ“%ÍÉ%!î%~·(.Ö0
00000270 21 93 22 BE D0 21 94 22 4F 06 00 09 09 09 E5 21 !“"¾Ð!”"O.....å!
00000280 9A 22 11 15 00 19 0D F2 05 25 11 0F 00 19 7E E1 š".....ò.%....~á
00000290 4E 23 5E 23 56 E6 03 47 32 83 24 28 13 79 E6 1F N#^#Væ.G2ƒ$(.yæ.
000002A0 4F 3E 01 CB 19 CB 1B CB 1A 07 B7 10 F6 32 84 24 O>.Ë.Ë.Ë..·.ö2„$
000002B0 3A E8 25 B1 32 E8 25 ED 53 E9 25 3E 01 32 EB 25 :è%±2è%íSé%>.2ë%
000002C0 3A 84 22 32 EC 25 3E 08 32 E7 25 3A 50 21 4F 0C :„"2ì%>.2ç%:P!O.
000002D0 CD 6A 25 CD 8B 25 CD AC 25 CD C9 25 21 E8 25 11 Íj%Í‹%ͬ%ÍÉ%!è%.
000002E0 77 23 01 05 00 ED B0 C3 80 22 06 00 ED 78 E6 08 w#...í°Ã€"..íxæ.
000002F0 28 04 10 F8 18 34 3E 40 ED 79 06 00 ED 78 E6 08 (..ø.4>@íy..íxæ.
00000300 20 04 10 F8 18 24 3E 00 ED 79 C9 0D 21 E7 25 06 ..ø.$>.íyÉ.!ç%.
00000310 06 1E D8 C5 0C 06 00 ED 78 E6 D8 BB 28 05 10 F7 ..ØÅ...íxæØ»(..÷
00000320 C1 18 07 C1 ED A3 C2 93 25 C9 D1 C9 21 80 22 0C Á..Áí£Â“%ÉÑÉ!€".
00000330 ED 78 0D E6 D8 FE 98 C8 E6 98 FE 88 20 F1 3A 84 íx.æØþ˜Èæ˜þˆ ñ:„
00000340 24 06 80 ED B2 3D 20 F9 C9 21 ED 25 18 03 ED 78 $.€í²= ùÉ!í%..íx
00000350 77 0C ED 78 0D E6 F0 FE 90 28 F3 FE B0 20 F2 ED w.íx.æðþ.(óþ° òí
00000360 78 7E E6 03 20 C4 C9 00 00 00 00 00 00 00 00 00 x~æ. ÄÉ.........
00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000004A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000004B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000004C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000004D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000004E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000004F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000550 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000570 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000590 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000005A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000005B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000005C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000005D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000005E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000005F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000600 C3 8B 22 81 16 00 02 00 00 32 4E E1 31 FF 23 E5 Ë"......2Ná1ÿ#å
00000610 21 81 16 11 00 02 B7 ED 52 22 7D 23 11 00 01 19 !.....·íR"}#....
00000620 06 07 3A 83 24 FE 03 C2 AB 22 04 80 CB 3C CB 1D ..:ƒ$þ.«".€Ë<Ë.
00000630 3D 20 F9 2C DD 21 7A 23 DD 75 00 3A 50 21 4F 0C = ù,Ý!z#Ýu.:P!O.
00000640 06 00 ED 78 E6 08 28 03 10 F8 C9 3E 40 ED 79 06 ..íxæ.(..øÉ>@íy.
00000650 00 ED 78 E6 08 20 03 10 F8 C9 3E 00 ED 79 0D 21 .íxæ. ..øÉ>.íy.!
00000660 76 23 06 06 C5 0C 06 00 ED 78 E6 D8 FE D8 28 03 v#..Å...íxæØþØ(.
00000670 10 F6 C9 C1 ED A3 C2 E4 22 21 00 30 0C ED 78 E6 .öÉÁí£Âä"!.0.íxæ
00000680 D8 FE 98 28 16 E6 98 FE 88 20 F2 0D 3A 84 24 06 Øþ˜(.æ˜þˆ ò.:„$.
00000690 80 ED B2 3D 20 F9 3D 20 FD 18 E1 21 7C 23 18 04 €í²= ù= ý.á!|#..
000006A0 ED 78 77 0C ED 78 0D E6 F0 FE 90 28 F3 FE B0 20 íxw.íx.æðþ.(óþ°
000006B0 F2 ED 78 7E E6 03 C0 F3 3E 9F D3 F0 3E 02 D3 F3 òíx~æ.Àó>ŸÓð>.Óó
000006C0 3A 36 20 E6 FD D3 F2 E6 20 20 09 21 63 23 06 07 :6 æýÓòæ .!c#..
000006D0 0E F2 ED B3 21 00 31 11 00 02 ED 4B 7D 23 ED B0 .òí³!.1...íK}#í°
000006E0 C3 DA 0E 04 0C 04 08 0C 08 20 00 00 00 00 00 00 ÃÚ....... ......
000006F0 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 1A ................
00000700 C3 2E 02 43 4F 50 59 52 49 47 48 54 20 28 43 29 Ã..COPYRIGHT (C)
00000710 20 31 39 38 31 2C 20 44 49 47 49 54 41 4C 20 52 1981, DIGITAL R
00000720 45 53 45 41 52 43 48 20 36 35 34 33 32 31 0E 0D ESEARCH 654321..
00000730 CD 87 08 11 B4 06 0E 09 CD 87 08 0E 0F 11 90 06 ͇..´...͇......
00000740 CD 87 08 FE FF 11 F5 06 CA 49 03 11 87 07 CD 36 ͇.þÿ.õ.ÊI..‡.Í6
00000750 03 CD 3C 03 11 07 08 CD 36 03 CD 3C 03 3A 87 07 .Í<....Í6.Í<.:‡.
00000760 67 2E 00 22 A4 05 22 A6 05 11 39 07 0E 09 CD 87 g.."¤."¦..9...͇
00000770 08 3A 88 07 CD 7A 03 11 53 07 0E 09 CD 87 08 3A .:ˆ.Íz..S...͇.:
00000780 89 07 CD 7A 03 11 6D 07 0E 09 CD 87 08 21 D0 05 ‰.Íz..m...͇.!Ð.
00000790 ED 5B A6 05 01 00 01 CD BB 03 3A 88 07 3D B7 1F í[¦....Í».:ˆ.=·.
000007A0 B7 1F 3C 67 2E 00 22 A8 05 EB 2A A6 05 B7 ED 52 ·.<g.."¨.ë*¦.·íR
000007B0 22 A6 05 EB 21 DB 05 ED 4B A8 05 CD BB 03 3A 8A "¦.ë!Û.íK¨.Í».:Š
000007C0 07 B7 28 25 3A 96 07 D6 02 E6 FC 0F 0F 3C 67 2E .·(%:–.Ö.æü..<g.
000007D0 00 22 A8 05 EB 2A A6 05 B7 ED 52 22 A6 05 EB 21 ."¨.ë*¦.·íR"¦.ë!
000007E0 E6 05 ED 4B A8 05 CD BB 03 2A A4 05 22 A6 05 21 æ.íK¨.Í».*¤."¦.!
000007F0 01 00 23 22 AA 05 ED 5B FF 07 B7 ED 52 CA 17 03 ..#"ª.í[ÿ.·íRÊ..
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/04a2fcac-5c2a-83ff-9c45-aba50520d1bd%40gmail.com.
Even matching your config, I'm still not seeing any problem. The reason I asked for the read of the CF was to ensure that the image got properly written to the CF card. In case something about the utility you use to write the card is somehow altering the image.
Does the ROM now say "beta26" when it signs on? Just to confirm you got the newest version updated.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00a901d7fe65%2437e51130%24a7af3390%24%40gmail.com.
On Dec 31, 2021, at 1:40 PM, Douglas Miller <durga...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/50d7675c-b35d-d322-5a5d-eb147142f7b7%40gmail.com.
I'm not coming up with any new ideas on what might be going on. It is disconcerting, that this seems to work fine on the simulator but not on the first real hardware we tried. It would be nice if it were something as simple as a faulty/corrupted CF card.
The fact that you occasionally see destruction of the ROM is worrying. There would not normally be any code mapped-in (copied to RAM) that knows how to write the EEPROM - except for after running the Config command (and before any other extended command). But, that code would have to be entered in a crash from some other cause.
I may need more details on your system, such as mods done to the
boards. I'm guessing your CP/M 3 image is an older one, so I can
experiment around with some older boot loader. But, I changed the
boot loader because it was crashing on the new ROM, so not sure
how that could show anything useful.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/AEFD211D-0F18-45C5-AC89-0456F99A5E7B%40gmail.com.
I’ve been using a set of 2G Transcend CF cards which have worked well but I’ve had them for many years. These are my “spares” that I use for random testing. I’ve got a much newer set of 8G cards (bought in September) so I’ll try one of those, but first need to back them up.
I blew it when I had the EEPROM problem. I should have done a comparison to the correct ROM image to see what was wrong. If it occurs again I’ll do that.
Let’s see what the CF swap does. It’s also possible that I’ve got some kind of hardware glitch, however this system has been rock steady since I brought it up in September… nothing special about any of the boards and no mods. Perhaps a jumper issue somewhere? Seems unlikely… jumpers configured per the guide:
http://koyado.com/Heathkit/H8-Z80-64K-RTC-ORG0-V4_files/Z80_V_4_0_Jumper_Definition_V02.pdf
I’ll try again tomorrow. I think Norberto said he is going to try as well so will be interesting to see his results…
Happy new year all!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/59fc662b-0703-705d-4c5f-b53c7643fe02%40gmail.com.
With B26.rom, Heath Quikdata fails to boot sometimes. It fails about 50% to boot.
I did try booting MP/M. It reads from CF card and gets stuck looping at the following PC register. See attached video.
I/O board settings: H17@174Q; H37@170Q; H67@274Q
Thanks,
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/016001d7fec1%24bfa6c580%243ef45080%24%40gmail.com.
With B26.rom, the SASIX page hang at random at different places. Here is an example:
B24.rom and B25.rom works fine all the time.
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/B5A64ADC-633C-4D75-B52C-677E6979A6A3%40koyado.com.
I hadn’t tried booting SASIX but just did. First time worked fine; second time it painted about half the screen and then I got a beep and the “H8” prompt. The next two times it worked fine. The fifth time it got about ¼ of the screen painted and again “beep” and the “H8” prompt…
For now I’ll hold off on any further testing while Douglas ponders on this behavior 😊
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/F5044F7F-624C-4221-852F-55543D6F9703%40koyado.com.
p.s. more info: after the last attempt (where SASIX menu was only ¼ painted) when the monitor was sitting at the H: prompt I hit “H” and got the boot help listing (as expected) but then I hit “?” and the system hung. No output. ION and MON LEDs out. This behavior is repeatable. After one of these failed boots some (many? maybe almost all?) commands work, e.g. Help, XC, XF all work, but as soon as I hit “?” it hangs. Dunno if it’s useful but using the monitor “P” command reports the program counter as 3BC4 which is consistent with what the front panel indicates (073.304).
I was able to dig up a SASIX image from previous efforts, and can verify similar issues. Tracing it, I see that it depends on the stack being in the condition it is on legacy ROMs. So, I am going to have to resign to H67 being a deviation from the other boots w.r.t. stack contents. I will revert the MMS CP/M-MP/M boot routine.
Since I can't reproduce any issues with MP/M boot, so I'm not
sure that is going to get fixed. But I will shortly upload new ROM
and MP/M images.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/006601d7ff12%24f0495170%24d0dbf450%24%40gmail.com.
I've updated the ROM and MPM images. New ROM version at
http://sebhc.durgadas.com/mms89/h8mon2/h8mon2-v2.0b27.rom. This
ROM now presents the same boot semantics for H67 as the legacy
ROMs, so should make SASIX work. Can't say what was the problem
with MP/M boot, but that has also been updated to match the ROM.
MP/M image at: http://sebhc.durgadas.com/mms89/images/mpm.z67ide.xz
I'm still working on some serial port init issues, but this mpm
image seems to be working OK, at least enough to run on the main
console. (latest test run, on Glenn's config, was working fine for
both terminals. I just want to make sure I fixed it right).
B27.rom is still broken to boot Heath QuikData SASIX console. No good.
I will try booting the mm image next.
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7c52abfb-eece-7d35-1905-f1233a0501ce%40gmail.com.
Especially if MP/M also does not work, this is not good. I'm able to boot MP/M and SASIX on my simulator, so there seems to be something subtly different about real hardware. I thought we had found all those. Does this CPU board have the "2mS enable" mods? Any other mods I might have missed? I might need you to send the SASIX image you're using, to see if I can reproduce it. I think the SASIX image I'm using is one you sent me a few years ago, to investigate other problems. Not sure why it would change.
Are you doing hard RESETs between attempts? Because we copy the ROM into RAM, it is theoretically possible for that to get corrupted and it won't get fixed until RESET. It's also possible that RAM contents varies slightly, for whatever reasons, and affects how it crashes (perhaps mine is also crashing, but just benignly falling through NOPs and recovering). But, I thought the static RAM chip we're using always powers-up to all "00".
I might need you to get a core dump after a boot failure, to see
if we can determine what's going on. That can be tricky, since the
coredump program runs in the same space as the boot loader, but if
you configure "H8-512K" to "Y" then most of that should be saved
to an alternate bank on RESET, and "vdump3" should get it all.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/000201d7ff5b%248fe0a510%24afa1ef30%24%40koyado.com.
With B27.rom, MP/M boots fine. I always do resets between boots to start with a good configuration. So, the only open is why SASIX is not working fine? Let me get you a vdump.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ccd4dda0-42a3-ae9f-e1a2-8d19b9a308ae%40gmail.com.
Attached is the vdump for b27.rom. With b25.rom, I can boot MP/M and SASIX without any problems so far.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/FC8D121A-F9A8-48D4-95BB-EEF807A5F685%40koyado.com.
I was able to replicate this too. MP/M works!, however the very first time I tried to boot the system hung (ION light on very dimly). But I have tried multiple times since with no trouble
I used TeraTerm on my PC for the console and connected an H19 @9600 baud to the second COM port. Pretty cool to see the CP/M prompt come up on two terminals! At 10Mhz things are pretty snappy. Not sure what practical need it serves today, but still pretty cool to get this kind of ability out of the lowly H8. Would make for a nice demo (future VCF?)
I have the MPM-86 manual set from my Z100. Never ran or used it before. Time to get smart on MP/M!
Thanks Douglas.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/FC8D121A-F9A8-48D4-95BB-EEF807A5F685%40koyado.com.
I see that MP/M gets stuck sometimes during boot. Here is a picture and vdump for this scenario.
For now, B25.rom looks like a better image for both OS’s. Also, with B25.rom, MP/M hangs at random at same place with speaker constantly on.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00cd01d7ff6a%2482e7bb00%2488b73100%24%40gmail.com.
Glenn,
Have you seen this checksum error at random? A reset seems to fix it. I’m not sure if my USB flash drive is getting tire…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/64F1705A-6880-48AE-BDF9-FD3F17DD1C58%40koyado.com.
I'm assuming a typo here: "with B25.rom, MP/M hangs" should say "with B27.rom, MP/M hangs"...
The major difference between B25 and B27 was addition of support for the RTM keypad sequence, HLT detection, and single-step. I'm wondering what those could have broken, but it is certainly likely they my simulator may not accurately emulate the single-step hardware (although I was able to test it). I'm wondering if single-step is getting enabled somehow, or somehow causing crashes (if the single-step interrupt occurred when no JMP vector was setup, it certainly would crash).
I'm looking at the coredumps now to see what I can see.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/64F1705A-6880-48AE-BDF9-FD3F17DD1C58%40koyado.com.
Mine also hung after the bank 007 message the very first time. I’ve rebooted maybe 5 or 6 times since then and not been able to reproduce… I’m on B27 ROM.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855375EF477416878E39E7DF7489%40SN6PR01MB3855.prod.exchangelabs.com.
I confess due to concerns about reliability/flakiness I’ve not been using vflash. Have pulled the chip out and programmed directly.
I do know not all USB flash drives work well. I’ve been sticking with the SanDisk Cruzers.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/2D42A432-B4DD-4F1E-AE5D-0B22B91DEEA8%40koyado.com.
With B24 same behavior as B25, no changes when booting MP/M. It works sometimes and others do not.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855375EF477416878E39E7DF7489%40SN6PR01MB3855.prod.exchangelabs.com.
Looking at those two dumps, they both appear to be for SASIX boots. Is that what you intended? I thought the second one was for an MP/M hang. The dumps are identical in the area saved off in bank 3, which seems unlikely for two separate boots. If they truly are for separate SASIX boot attempts, then they show that the menu was attempting to display when perhaps an interrupt was taken. It might help to have a screenshot to match up to a dump.
I do see evidence that something is overwriting the first by of "ROM" code (now in RAM). Location 0000 is "FF" in the dumps, but it should be "F3" (DI instruction). This could be evidence of a stack underrun at some point. Can't be sure if it is related.
If I can correlate the stack clues to the screen output, it might help confirm if the stack is showing me an interrupt frame, or if the code just took off someplace else and got a new stack. It's highly liklely that the code which is displaying the menu would take at least one 2mS clock interrupt, so I would expect to see some remnants of that.
I guess the other question is whether the H19 is beeping continuously or it is the H8 FP speaker (I assume when you said speaker you meant H8 and not the H19). This would tell us whether the program is dumping garbage (with ASCII BEL characters) to the H19 or if it has turned on the FP speaker and failed to turn it off.
It's looking like the code I did for Norberto's request for RTM/HLT/single-step is not clean/correct. I forget whether Norberto did extensive testing or not. I tested what I could on the simulator, but wouldn't be surprised if real hardware had some subtle differences there. We may have to revert that feature and work on it later, when thorough testing can be done.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855375EF477416878E39E7DF7489%40SN6PR01MB3855.prod.exchangelabs.com.
I went back to B27. After booting MP/M, and after several “DIR” commands, at random it fails to display the “DIR” content completely as shown in attached picture. Hopefully this info can help to debug this issue.
Additional debug info:
The “ION” LED on a successful boot, it will blink after the “Bank 007” message. When it gets stuck after the “Bank 007” message, it stays dim (as mentioned by Glenn), and does not come back to full intensity. It seems like interrupts issue????
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/266570BB-3AA9-4FF9-BA6D-D9AE4893D270%40koyado.com.
Could the "partial DIR" issue you're seeing be a "bounce" (noisy
key) on the H19 keyboard? I get the same thing if I double-press
CR after typing the "DIR" command. It appears the the MP/M DIR.PRL
program aborts on any key pressed.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/6BAE2B29-41A7-46C0-B82F-E5C94B964D42%40koyado.com.
I just tested MP/M on a second terminal and I agree that is very cool to see this working. Was MP/M offered for the H89??
How I can find where all the utilities are?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00cd01d7ff6a%2482e7bb00%2488b73100%24%40gmail.com.
Yes! The Return key is not working that good anymore. My kids abused this terminal back in the 80’s playing games. So I will need to take it out for repair tomorrow morning. Good catch.
I have a second H19 with same issue with several keys getting stuck. Terry G. send me some parts to fix them. I guess tomorrow will be a good day to fix both H19 terminals.
Anything else we can do to get more info to you to fix the hangs after the “Bank 007” message?
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5e77a684-0617-a460-365e-339c9e483325%40gmail.com.
MMS did make an MP/M that ran on the H89, but it was designed to run on their 77422 "co-processor" card (a.k.a. Network card), so that it had more memory and 4MHz CPU. It really wasn't sold as a product, though. Basically, it was still encumbered by the H89 which had to do the I/O.
So, the commands are not shown by the default DIR command, so that they are accessible from other user numbers/consoles ("SYS" attribute set). "DIR [SYS]" will show all files. There is a HELP command, which gives some info. Otherwise, it's the MP/M User's Guide. I can post a copy if Google doesn't give you immediate access.
One interesting command is "MPMSTAT". The output scrolls off the screen, but if you're quick with ^S^Q you can pause it, or if you are attached to a modern terminal program on your PC you can scroll back. It shows basically what is going on in MP/M. For an example, I would start the command "ed junk" on one console, then run MPMSTAT on the other - you'll see one of the memory segments being used for "ED". (FYI, to exit ED type the "Q" command and confirm you want to quit with "Y"). It's also possible to detach from a program (like ED) and then run other commands, later returning to ED on the same console.
I am wondering if the occasional MP/M hang is related to the SASIX issue. Tomorrow, I can work-up a version of the ROM that removes the RTM/HLT/single-step features, for you to try out. Otherwise, getting a dump from an MP/M hang would be a good start. So far, the only dumps I've seen are from SASIX boot attempt(s) (possibly both from the same attempt).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9603CC3A-9ADD-4EBD-A75E-1CA569F75762%40koyado.com.
Hmmm… Let me remove the battery on the 512KB board, so on power-on is set to default. I know I took the MP/M trace. Will do it again after this change.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/d7bf73e2-6ba0-03f6-9102-dc12e99805aa%40gmail.com.
Here is a picture when I took the MP/M trace. Will do it again with battery removed.
From: norberto...@koyado.com <norberto...@koyado.com>
Sent: Saturday, January 1, 2022 9:02 PM
To: 'se...@googlegroups.com' <se...@googlegroups.com>
Subject: RE: [sebhc] MP/M for the H8/H89 - MP/M hang
Hmmm… Let me remove the battery on the 512KB board, so on power-on is set to default. I know I took the MP/M trace. Will do it again after this change.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/d7bf73e2-6ba0-03f6-9102-dc12e99805aa%40gmail.com.
Cleared RAM and took trace again, attached!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/003b01d7ff96%242d665f20%2488331d60%24%40koyado.com.
When I exit “Vtalk31”, I cannot type any characters. It just waits at the “0A>” prompt. I had to reset the system to recover and it is easy to reproduce.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004501d7ff9a%247f235f30%247d6a1d90%24%40koyado.com.
Vget31 and Vput31 are working fine. The issue I have is that when I download a file from the USB flash drive with Vget31, I do not know where the file gets written to. How I can find such file. For example: vget31 b27.rom…
Norberto
From: norberto...@koyado.com <norberto...@koyado.com>
Sent: Saturday, January 1, 2022 9:48 PM
To: 'se...@googlegroups.com' <se...@googlegroups.com>
Subject: RE: [sebhc] MP/M for the H8/H89 - MP/M hang
When I exit “Vtalk31”, I cannot type any characters. It just waits at the “0A>” prompt. I had to reset the system to recover and it is easy to reproduce.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004501d7ff9a%247f235f30%247d6a1d90%24%40koyado.com.
Vdir31 does not work. System hangs. ☹
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/005901d7ff9f%2466cd1c00%2434675400%24%40koyado.com.
My bad on this one as my Z67-IDE+ was write protected. Once disabled, I was able to find the file. Vget31 is working fine.
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/005901d7ff9f%2466cd1c00%2434675400%24%40koyado.com.
I did a lot of reboots/resets and finally I got this error message on MPM.SYS. I wonder if related.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004501d7ff9a%247f235f30%247d6a1d90%24%40koyado.com.
That error, "Read failure: MPM.SYS", is being printed *after* MPM.SYS has been read and loaded. So, it's further indication of a crash of some sort (somehow it fell backward into code it already finished running). I'll look into the dump and see if I can reproduce any of the VDIP1 issues as well.
After it has printed the "load map" (incl. memory banks), that is
the point where it jumps from the MPMLDR program into actual MP/M
system (XIOS). At that point, the XIOS must do the final
initialization of the hardware, so it is a natural point for
problems to occur.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/621BED91-6623-482D-A13D-C678D6B67200%40koyado.com.
Douglas: interesting quirk with VTALK. When I run it on console 1 the output appears on console 0. Is that supposed to be possible? It initially seems to run OK on console 0 but then it leaves things in a bad state? I’m using BDOS call 6 for I/o so perhaps not the right approach for MP/M? I need a non-blocking read call for the console (return -1 if nothing to read). let me know if you have thoughts on how to fix… (or if this is a bug of some sort?)
Norberto: VDIR31 works for me. Note that it is a pretty inefficient program due to some quirks of the VDIP software interface. It actually has to do two passes to build a directory. The first pass just gets the list of file names, then it must make a call *for each file* to get the file details. If you have a lot of files on the USB drive it may appear to be dead but it is probably working. Also if you haven’t upped your CPU speed to MAX (mpmspd max) it will be much slower. It is limited to a max of 256 files/directories on a flash drive.
In my revised soon-to-be-baselined version I will include feedback messages to indicate what the program is doing. I’ll also look at ways to possibly make it more responsive…
Set your speed to MAX and try again and wait a while for the output. Let me know if this doesn’t work…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/006101d7ffa0%241c0f1640%24542d42c0%24%40koyado.com.
It is certainly possible for a program on one console to print to
a different console, but all BDOS calls should direct "console"
I/O to the specific console assigned to process. Standard
"console" BDOS calls in MP/M do not allow one to select a
different console, that is done by a special XDOS function. BIOS
calls are another matter: now the caller must pass the console
number in register D (so "garbage" in D would cause unpredictable
results - including the appearance of a hang (no output) if the
value in D is invalid).
When I run VDIR31 on console 1, the output stays on console 1.
So, it appears we have some odd hardware behavior that my
simulator does not simulate. I hate it when that happens. Or else,
it is related to memory content (did you try clearing RAM before
starting?). If clearing RAM stabilizes things, it could be I'm
looking for an "uninitialized variable" situation - although
MPM.SYS is not a sparse image of system RAM, and any gaps were
filled with zeroes. I'd have to search for any places that
uninitialized RAM is being accessed.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00c701d7ffe3%24521cb0b0%24f6561210%24%40gmail.com.
Douglas: please try to run VTALK31. This utility uses a simple task-time loop that polls for console input, transmits it if any to the VDIP monitor, then polls for VDIP response, prints it if any, and loops until console input is ^C.
On Console 0 I can run it and it works (e.g. do a DIR on the USB drive) and I can Control-C out of it, but I never get a command prompt back – the console is hung.
If I run it on Console 1 it runs but all of the input/output is on Console 0 !! If I control-c on console 0 then I get the command prompt back on console 1 (but console 0 is then hung!)
I believe from the email that Norberto saw similar results.
Vtalk just uses BDOS 6 calls for console I/O (attached).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/0e5eb4bb-a45d-b12a-29db-6d67c0476b72%40gmail.com.
Yeah, I'm seeing similar results. Looks like the system has crashed after the ^C. I'll need to investigate further. Not sure if it's related to the boot issue or not.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/017101d8002c%24a6ed24f0%24f4c76ed0%24%40gmail.com.
I think I see the problem. VTALK31 forces "HDOS" to "1", so it is directly using the console port 350Q. That program needs to take the HDOS value from the CC commandline. Not sure that that explains the crash, but I'll try a new version of it.
In this dump I'm seeing evidence of stack overflow on the Init process (which is what is running at that time). I'm analyzing the stack contents for clues, but at this point I don't think the stack overflow is the cause of the problem, just a symptom (something crashes and then "bad code" ends up pushing things on the stack). I'm seeing evidence that the 2mS clock is running, which it should not do until after it prints the signon message. Need to see what clues I can find.
Cleared RAM and took trace again, attached!
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of norberto...@koyado.com
Sent: Saturday, January 1, 2022 9:04 PM
To: se...@googlegroups.com
Subject: RE: [sebhc] MP/M for the H8/H89 - MP/M hang
Here is a picture when I took the MP/M trace. Will do it again with battery removed.
Sent: Saturday, January 1, 2022 9:02 PM
To: 'se...@googlegroups.com' <se...@googlegroups.com>
Subject: RE: [sebhc] MP/M for the H8/H89 - MP/M hang
On Jan 2, 2022, at 6:14 PM, Douglas Miller <durga...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/31008bfa-2b55-8d73-72a7-40f99070d3cf%40gmail.com.
Note, vtalk31.c does not use a "CPM" symbol, it only checks
"#ifndef HDOS". So, defining CPM does nothing for vtalk31.c. At
least, that's in the version I have.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/787D03CD-D4D1-4EF7-927A-9CFD579C2E80%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/234b255b-a626-9dce-10eb-c496e1d972c4%40gmail.com.
You are completely correct. I changed “HDOS” to “CPM” in the #define statement and rebuilt and all works fine. I’m sure that was what I had done wrong. I’m not happy that in HDOS I have to go in and directly manipulate the console port. I have tried multiple times to use OS calls (putting console in “RAW” mode) but so far have been unable to make it work the way I want).
Anyway huge apologies and thanks for spotting that. Recompiled VTALK31.COM attached (renamed to allow me to email it…)
I performed
STAT VTALK31.COM [SYS]
And then was able to run from Console 1. All seems normal to me. Please report any problems!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/31008bfa-2b55-8d73-72a7-40f99070d3cf%40gmail.com.
Thanks and Vtalk31 is working fine now.
I cannot get VDIR31 to work. I left the system alone for 3hrs and nothing happened.
Let me try a new USB flash with just a couple of files.
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/01a501d80038%2487659660%249630c320%24%40gmail.com.
I'm still not finding exactly what's wrong, but am thinking it
has to do with interrupts. Digging into some MP/M source code, it
appears that MP/M does not explicitly disable interrupts when it
starts initialization, in spite of the System Guide saying
interrupts are disabled when the sysinit routine is called. Based
on a hunch, I've built a new image that ensures interrupts are
disable before calling into MP/M for the first time. It's at least
a good guess.
I've also update VTALK31 with a fixed version.
Douglas,
That fixed the issue. I did about 20 boots/resets and it worked without any issues. Great job! Before it was failing about 6 times out of 10.
When booting the SASIX console, it beeps and returns to the console but it doesn’t display anything on the H19 terminal. If I type “?” on the H19, the system hangs (ION and MON LEDS) go off. This works fine with B24 and B25.rom. I wonder what is different between B25 and B27 for the SASIX interface. I’m booting from drive 1 as drive 0 is for MP/M. Can MP/M boot from drive 1 as well?
Almost there…😊
Are you adding the utility to setup the RTC in MP/M as in CP/M3?
Thanks,
--
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/521d4c89-8898-9b40-2eab-a1ca34879042%40gmail.com.
Glenn,
VDIR31 worked fine with a small list of files. I had too many files (581 files) on the other USB drive for VDIR31 to handle.
Can we get VPIP31 so that we can upload multiple files at once?
Thanks,
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00ad01d80042%246759a780%24360cf680%24%40koyado.com.
On Jan 3, 2022, at 1:19 AM, Norberto Collado <norberto...@koyado.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/846C38DB-C70B-4F53-B3F2-558D95CBD1F7%40koyado.com.
Great news that MP/M is working now.
The major difference between B25 and B27 is that I added, as you requested, support for the RTM button on the keypad, and associated support for detecting HLT in programs and use of the single-step feature. Among other things, this required changing things around in the ROM to make space, related to the fixed-entry-points required for legacy support.
I'm wondering if SASIX is using some previously-unknown entry point in the ROM, or if I messed up one of those. Or else something related to RTM/HLT/SS is reacting badly with SASIX. I have not had the chance to investigate that, but will look into it. I don't want to just pull-out support for RTM/HLT/SS, but that may have to be the immediate solution.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/317AA205-3912-44D9-B6C9-D97651E4F9F9%40koyado.com.
Douglas,
Try this image on your simulator for the SASIX issue… Z67-IDE+ running at 274Q, H37 at 170Q and H17 at 174Q
http://koyado.com/Heathkit/Z67-IDE-plus_files/QSCPM4M.imgc.zip
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/2e6c4116-8eb0-4af7-0ce6-447f63cd9523%40gmail.com.
I'm still not able to reproduce a problem with that image, on the simulator.
Looking at the core dump, I'm dissecting the stack and validating what I see there. It appears that SASIX takes a 2mS interrupt "at the wrong spot" and the monitor thinks it sees a HLT instruction. At that point, the HLT detect fails to properly enter the monitor, so it looks like a hang - although it appears that the code is just waiting for input.
So, one issue is why HLT detection is enabled. I thought that was disabled by default, but will need to review.
Second issue is why did the HLT detection fail to gracefully enter the monitor?
Or... is the SASIX "crash" actually going back to the monitor prompt?
This was something suspicious I noticed when I was copying the HLT detection code from PAM37, probably a day-1 bug: the code naively decrements the "PC" and checks for 0x76 (HLT), but that byte could be the last byte of a multi-byte instruction, even something as ordinary as JMP 76xx, and cause it to false-trigger. In this case the instruction is "BIT 6,M" a.k.a. 0xCB, 0x76.
Perhaps the thing to do is to rip-out the HLT detection code.
Does anyone object to that? Or else I need to track down why it is
enabled by default.
This feature seems to be intended to allow user programs to use
HLT as a "return to monitor" instruction. The program halts until
the next 2mS interrupt, at which point the monitor sees 0x76 and
breaks out. But, as stated, it is virtually impossible to
correctly detect a true HLT vs. some random 0x76 in the
instruction stream. It takes extremely unlucky timing... but
apparently not THAT unlucky. Or else Norberto needs to start
buying lottery tickets.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/F63D5E9C-A5CE-41D7-A051-32B195E79387%40koyado.com.
Don't forget your friends! ;-)
I think I found the issue, after fresh eyes on the HLT detection
code, I found a couple issues and think it is fixed now. Version
beta28 is available:
http://sebhc.durgadas.com/mms89/h8mon2/h8mon2-v2.0b28.rom
The HLT detection code is still there, but I got the proper default setting to "off" now. It's unclear to me if this feature ever worked right (PAM37, etc), but it is possible to enable HLT detection now and "caveat emptor". Given the way that flag byte is handled (even in PAM37), it would be a wonder if you could enable HLT detection and have it stay enabled (if the monitor is running). Or have it stay disabled (in PAM37).
I see that one of the first things that SASIX does it disable HLT
detection, which is probably because the feature is so broken that
you can't risk leaving it enabled. If I had only properly checked
that bit... oh, well.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855D4A1DE7E94A0E01B65F7F74B9%40SN6PR01MB3855.prod.exchangelabs.com.
FYI, the HALT LED probably won't light - it's not actually a HLT instruction, just the monitor HLT-detector is false-triggering on an incidental 0x76 byte.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855FFA1B40243F97F18BB51F74B9%40SN6PR01MB3855.prod.exchangelabs.com.
I was able to boot HDOS 3 via SASIX fine with rev 28 ROM. CP/M 3 and MP/M also booting fine.
If the purpose of some of the recent ROM rework is to enable the front keypad “RTM/0” interrupt, that is still not working. I miss that feature. Very handy for breaking into a hung program to see what’s going on…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/aaf1e7d2-4918-83ee-87a3-8db030d65a1f%40gmail.com.
I'll need some more information on how that's failing. I would
like to be able to reproduce it. It was working on my simulator
when I tested it, but your conditions are probably different. I
think I just poked a simple loop into memory and executed it, then
pressed RTM/0 and it returned to the prompt. Did a similar thing
for single-step, where the loop increment or decremented HL and I
watched that value change on the front panel (or maybe I was
watching the PC).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/002901d801e0%24302f7bf0%24908e73d0%24%40gmail.com.
Pressing the “0” and “E” keys simultaneously is the RTM/0 request. On the H8 this is one of the two keypad combinations that is explicitly wired in the hardware (the other is RST/0). RTM/0 generates a level 10 hardware interrupt.
When I press the RTM/0 sequence on any of my other H8s I get a beep, the MON light comes on and I have full keypad control of the monitor. I can probe registers and RAM, etc. if I don’t change anything then I can hit key 4 (“GO”) and return to the program or OS with everything as it was
When I try this with the beta 28 ROM system nothing happens. the sequence is ignored.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ca6cdcf1-cfef-23f4-e43b-62d8d5d14412%40gmail.com.
What I was asking for was a specific scenario that I could try
out. I have code that *should* do the RTM/0 function, and seems to
on my simulator - I just tried it now in the SASIX menu, and it
beeped and gave me the H8: prompt (because SASIX menu is operating
off a different stack, things were not able to run perfectly -
I'll look into whether that is a situation that's expected to
work). But, the RTM/0 key did trigger an INT1 and the interrupt
handler did detect the RTM/0 key and break-out to the monitor.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004d01d801e2%2477381370%2465a83a50%24%40gmail.com.
Glenn, thanks for the update!
I also updated to B28.rom and now CP/M SASIX console and MP/M are working fine.
Thanks,
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/002901d801e0%24302f7bf0%24908e73d0%24%40gmail.com.
On B28, I selected to run the FP display test and then I pressed “0” and “E” keys simultaneously and it stopped the FP test. This is working. When I pressed “GO” again it just restarts the H8 monitor again and not the FP display test.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004d01d801e2%2477381370%2465a83a50%24%40gmail.com.
On Jan 5, 2022, at 2:34 AM, Norberto Collado <norberto...@koyado.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9137A1F8-E420-471E-B67B-65DA3507FA13%40koyado.com.
I'm surprised if PAM37 allowed you to return to monitor from HDOS3, let alone resume. I'll have to see if I can setup that environment and try it.
The built-in front panel test command may not be a good candidate
for this feature, either - it is not a separate program but rather
a command within the monitor. Thus the system is operating "in
monitor" at the time you press RTM, and that is handled
differently.
Looking at PAM37 (which I used as a model), I suspect there are issues with the stack, especially when performing monitor commands that require mapping in the expanded ROM. This may need to be (significantly) redesigned so that entry to the monitor switches back to the monitor stack (top of memory). Even that has potential problems, as a program (or OS) may be using that part of memory and overwriting it with monitor stack is not going to end well. I'll have to think about how to handle this.
It seems to me that the original feature was intended for "small"
user programs (not OSes) running in a limited scope/environment.
The extended ROM presents some new challenges since the stack
needs to be outside the area used to map-in the ROM in order to
run many of the new commands.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/A24490A7-D7B0-4CEF-AF20-DF17CC9A0ED9%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855AD4CF2FD37997FAAB55CF74B9%40SN6PR01MB3855.prod.exchangelabs.com.
Douglas,
Completed the following steps without any issues:
Thanks for getting RTM/O function working.
Norberto 😊
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855FD4FB10CEA849ABE5BBFF74B9%40SN6PR01MB3855.prod.exchangelabs.com.
On Jan 5, 2022, at 11:43 PM, Norberto Collado <norberto...@koyado.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/8A0B4B14-6254-427F-9508-102CE49E89DD%40koyado.com.
I think there may still be "improvements" to be made, as some
monitor commands (those that require mapping in the whole ROM)
will have issues depending on where the stack is located.
Hopefully the core "debug" commands function. I may have to
redesign the code that searches the extended ROM area such that it
doesn't use the stack at all, so that it can function if the
extended ROM overlays the current stack. That's probably not a
trivial change, though.
Great! Thanks guys.
Sent from my iPad
On Jan 5, 2022, at 11:43 PM, Norberto Collado <norberto...@koyado.com> wrote:
Douglas,
Completed the following steps without any issues:
- REG, PC, ALTER, 030003, ALTER, REG, BC, GO -> Register B increments.
- Pressed the “0” and “E” keys simultaneously to enter the RTM/0 request.
- Selected the PC registerI think there may still be :"
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/51588F89-8615-4523-9496-1D5BA8D17717%40gmail.com.