Superboard Expanded on S-100 motherboard

[davisgw]

badanny,
Thanks for your suggestions. But the BASIC VidSwap program for BASIC-IN-ROM needs to be saved somewhere other than cassette to be of much use...my old cassette player/recorder has bitten the big one, but I could load it into Hexdos and save it on disk. So I tried the changes you provided for the monitor ROM and it looks pretty good on the 600D, except when I boot from Hesdos for a source of material to display the BASIC programs look like they have tabs in the middle of the longer statements.
But I also discovered that my ROM changes to the S-100 Superboard have broken Hexdos....I did not notice because it appears to boot but when I try to enter a command nothing happens
Also, I have a copy of a C1P-VIDSWAP program from https://osi.marks-lab.com/software/osios5.html but the description seems wrong for a unmodified C1P. Do you know anything about it?
Anyway, as requested, here is the image for WP6502 from the original disk.

[bxdanny]

I don't think your ROM "broke" Hexdos. I think your Hexdos disks may have been corrupted on Track 0 (which contains the actual OS). I also had trouble (error messages like "?DT ERROR") when I tried running the Hexdos images you sent (even after cleaning with OSIHFE). But when i combined the Track 0 of the Hexdos disk image I uploaded in 2015 (which I had assembled from Steve Hendrix's source code) with the remaining tracks from the Hexdos images you posted yesterday, everything worked, even using the copy of your ROM. So I am attaching to this message a ZIP file which contains the files portions of your Hexdos disks combined with the kernel portion (Track 0) of mine (plus the copyright statement Steve H. asks for).

Dave, if you see this, you may want to put the attached Hexdos4.zip file into the OSIweb archives.

[davisgw]

OK, I tried both my original and my copies of Hexdos and Hexasm with the same result on my S100 machine, but they work fine in my unmodified 600D superboards. So I had a look at the Monitor ROM and the changes for BASIC-IN-ROM video date back to 1985 and did not preserve the registers on entry and exit. So that's where I plan to start changing the code....it will be trial and error to fix.

My other problem is that I don't seem to have the right incantations to successfully write your Hexdos image. I tried XMODEM, XMODEM/CRC, and HEX transfers on both .LOD and .65D file types and nothing transferred....the .LOD attempts resulted in immediate aborts, but sounded like some data was transferred. Does the diskette need to be formatted in Hexdos format? Please explain how it's done....

[bxdanny]

I thought the Disktool program could handle any format, but Hexdos's track zero may be giving it a problem, since it specifies 9 pages, which don't all actually fit on a 5.25" floppy disk track. Somewhere in that 9th page, the index hole is encountered and reading stops. But it's OK, I was able to reconstruct what must have been on the disks, by combining the image of the Hexdos track 0 I had previously built with the remainders of the disk images you sent, as I indicated (and attached) in my previous message in this thread.

The WP6502 disk image you sent confused me at first, as it clearly contains a C4P operating system. I guess the instructions probably said that C1P users should copy tracks 0 and 1 from their standard 65D disk (meaning version 3.0, 3.1, or 3.2) to a copy of the WP6502 disk, and that is what you did. I was surprised to see the R/Tape and W/Tape options on the WP6502 menu, since a C4PMF doesn't have a tape interface. But a C1P does, and since they knew this would be used on C1s too, they just left that in there. Interestingly, this WP6502 moves itself down to $0222 (where the tape version loads) for execution.

[Mark]

Ya Disktool will write a 9 page Track0 on 5.25" and 15 on 8". If it doesn't recognize it, it just writes the bytes it receives. It then reads what was written to see if it matches and retries 3 times.

I recall davisgw had to use 300baud to successfully transfer the DiskTool disk image.

Could it be a bad driver for the PL2303? I understand Prolific intentionally prevented their drivers from working correctly when it detected one of the knockoff clone USB-Serial adapters, although that may have been for earlier chip versions. I believe the GS version should be OK. (There are lots of articles about the PL2303 & Windows/driver issues besides the clone issue... Davisgw, What version of Windows are you using?)

There is no hexadecimal upload capability, Disktool Receive Disk is always xmodem since it has to pause sends when it writes a disk track. TeraTerm should auto select CRC or Checksum when sending data.

Once DiskTool is loaded
OSI Serial Disk Tool
----------------------
1. Dump Raw Image
3. Receive Disk Xmodem
4. Select Drive
5. Set Drive Type
6. Set Serial Divisor
7. Xmodem/Hex xfer opts
8. Exit
L. View log

Drv=A/5.25 Baud@1x Xmdm

Set #6 serial divisor. Change TeraTerm speed, then press SPACE to get the menu again to confirm comm speed.

Then select #3 to begin 90K disk image upload.

--->3

Send Disk via XMODEM
Insert WRITABLE disk in drive A
ALL DATA WILL BE LOST!

ESC KEY OR ^X ABORTS

Press any key when ready
Begin XMODEM/Checksum transfer. Press <ESC> to abort...

In TeraTerm Start File/Transfer/XMODEM/Send & select disk image, then click OK
Data will transfer and disk should be written. Errors will be printed on C1P screen and stored in Log for viewing.

OSI Serial Disk Tool
----------------------
1. Dump Raw Image
3. Receive Disk Xmodem
4. Select Drive
5. Set Drive Type
6. Set Serial Divisor
7. Xmodem/Hex xfer opts
8. Exit
L. View log

Drv=A/5.25 Baud@16x Xmdm
--->L
Write Track 0 boot 2300...OK
Write Track 1 HexDos 2050...OK
Write Track 2 HexDos 2050...OK
Write Track 3 HexDos 2050...OK
Write Track 4 HexDos 2050...OK
Write Track 5 HexDos 2050...OK
Write Track 6 HexDos 2050...OK
Write Track 7 HexDos 2050...OK
Write Track 8 HexDos 2050...OK
Write Track 9 HexDos 2050...OK
Write Track 10 HexDos 2050...OK
Write Track 11 HexDos 2050...OK
Write Track 12 HexDos 2050...OK
Write Track 13 HexDos 2050...OK
Write Track 14 HexDos 2050...OK
Write Track 15 HexDos 2050...OK
Write Track 16 HexDos 2050...OK
Write Track 17 HexDos 2050...OK
Write Track 18 HexDos 2050...OK
Write Track 19 HexDos 2050...OK
Write Track 20 HexDos 2050...OK
Write Track 21 HexDos 2050...OK
Write Track 22 HexDos 2050...OK
Write Track 23 HexDos 2050...OK
Write Track 24 HexDos 2050...OK
Write Track 25 HexDos 2050...OK
Write Track 26 HexDos 2050...OK
Write Track 27 HexDos 2050...OK
Write Track 28 HexDos 2050...OK
Write Track 29 HexDos 2050...OK
Write Track 30 HexDos 2050...OK
Write Track 31 HexDos 2050...OK
Write Track 32 HexDos 2050...OK
Write Track 33 HexDos 2050...OK
Write Track 34 HexDos 2050...OK
Write Track 35 HexDos 2050...OK
Write Track 36 HexDos 2050...OK
Write Track 37 HexDos 2050...OK
Write Track 38 HexDos 2050...OK
Write Track 39 HexDos 2050...OK
Press any key when ready

-Mark

[bxdanny]

Mark, the question now is whether it can READ a disk that (claims to) have 9 pages on Track 0, and produce an image file that will run under WinOSI. I initially thought his disks might actually be corrupted on track 0, but it looks like I was wrong about that. It is something in his revised boot/Monitor ROM that is incompatible with Hexdos. I will take a closer look at the image files he sent me. Possibly they have something in the last four bytes of the track image that get interpreted as the "high-water mark"?

No, I just checked, that doesn't seem to be the case. The high-water mark looks OK.

[Mark]

Okay sorry for my confusion,
Yes, in later versions of disk dump tools the last 4 bytes of 65D file track are used as a high water mark & XOR high water mark used to record the highest byte address read from disk, information that is otherwise lost when dumped.

I did recently find a bug in WinOSI dealing with a high water mark in 65D file not correctly wrapping back to index hole during read. I fixed the bug, and just finished posting it. Here:

Changing one byte of high water mark will invalidate it in case you need to.

[bxdanny]

Mark,

Thanks for that update. And it looks like that WAS the problem. With the updated WinOSI, the Hexdos images Glenn Davis uploaded work fine!


[And yeah, I have difficulty sleeping, which is why I am (again) up at 3:30 in the morning.]

[davisgw]

Mark, bxdanny,
I did all the steps you detailed to perform the transfer but forgot I needed to transfer at 300 baud to write the Disktool disk. So I re-did the permutations I previously tried and found that the transfer starts at 300 baud, XMODEM/CRC transfer, and file type of .LOD (NOT .65D). So I looked at the driver for the adapter and it is V5.1.4.0 which Windows 7 claims is the latest. Then I looked at the connection and found that I only have the correct genders to make it using a 10 ft long cable I have plugged into the 3 ft cable on the adapter. I think this is the problem and will look for a gender bender that will make the connection with the 3 ft adapter cable.

I have been re-examining the monitor ROM code for the video and remember that back in 1983 I was pulling out hair for a solution to the many reasons that the video code is called and ended up tiptoeing through the stack to figure that out. But at that time I likely was not aware of any variations presented by Hexdos. In my latest update to this code look at lines 1850-2190 is where these decisions are made and the last (wrong?) decision at 2140 I do a JMP to return after changing the stack pointer....that's risky!

Also I have the Hexdos source code that I have yet to analyze for calls into the ROM. Let me know your thoughts. Thanks a bunch. You guys are the best.

[bxdanny]

davisgw,

As I indicated to Mark, there in fact was nothing wrong with the Hexdos images you posted. The existing version of WinOSI was not reading them correctly, and Mark has now fixed that.

Why Hexdos isn't working right with your revised ROM, if standard BASIC-in_ROM IS working, I can't imagine. Or haven't you tested that? Is the entry point for your output driver still $FF69? Hexdos (and any system that expands the output capability of ROM BASIC, such as Pico-Dos and my enhanced version thereof) needs that address. Hexdos uses a clever trick (see the code at $09DB, and also at $08B9 for handling input) involving use of the shift-right instruction on a ROM location to determine if it is running on the standard ROM or CEGMON. I used a different method, but one having the same purpose. The version of your ROM that I have used counts as "standard". I was wrong about 65D drivers having to preserve the registers, but drivers for ROM BASIC certainly do.