Superboard Expanded on S-100 motherboard

[Mark]

davisgw,

I should explain this better to avoid confusion.

The ".lod" files are used with the OSI 65V ROM monitor or compatible. There are the HEX codes and commands used to upload a runnable program to the OSI via serial port. They are not files that are useful to write to disk drives. The "Disktool.lod" file is a runnable program which is loaded through the OSI monitor.

The disk dump image files for 5.25" drives should be 90K in size, and contain the binary track data for a disk. The file extensions are usually .img or .65D, but can be anything really. The earliest dump program transferred data as hexadecimal dumps which need to be converted to binary to be useful (with a program like DeHex ), but are a nice to quickly view disk data as text & verify dumps are working. 65D disk images can also be used for 8" floppies, but they are 289K in size.

The "Disktool5.65D" file is a bootable disk image that can be written to a 5.25" floppy for future disk boots. Although it is the same program, there is an addition loader program on the floppy to transfer DiskTool to the correct spot in memory before starting the code, as well as disk formatting to be compatible with the OSI disk boot loader.

I try to use .lod for 65V files (should be .65V), .65A for OSI 65A monitor C3 files, .65D for disk images (OS65D & compatible formats), .65U for C3 OS65U disks. And .WAV for cassette dumps. However nothing is set in stone, people use what is convenient or makes sense to them.

I hope this helps!

[davisgw]

Mark, bxdanny,
For most of the past 2 months I was convinced that my monitor display code broke booting HEXDOS because in order to fully replace the BASIC ROM display function I had resorted to searching the stack to bypass it (I must have discovered the power of the stack 50 years ago....). But after trying everything I could think of to correct the bugs (I had programmed about 3 dozen variations of code in ePROM by this time) I decided to go back to the beginning....and I discovered that ROM BASIC would STILL not come up, which is why HEXDOS was broken. So I swapped all 4 of the BASIC ROMS from one of my working 600D systems and it worked again. Then I swapped back the original BASIC ROMS and it still worked so I knew I have been dealing with dirty/corroded ROM sockets or pins! AAARRRGGGHHH!
On the plus side I removed the code that played with the stack and preserve registers, $0200-$0202, so now my new video driver does not REPLACE the original BASIC driver, and any software that uses the ROM BASIC video also will drive my S-100 video card....and HEXDOS now works again.
I also discovered that I had relocated some monitor code for reasons I can't remember, adding to the confusion in correcting the ePROM.
bxdanny,
I have changed $FFE0 and $FFE1 as you suggested for the 600D systems, but the text is almost off the left side of the monitor. Did you tell me how to shift the text to the right? I can't find it if you did.....
Thanks to both of you....

[bxdanny]

I think I did ask in a previous message if you had tried the system using just ROM BASIC without Hexdos.

As for $FFE0-$FFE2, here is how they work:

- $FFE0 contains the offset into page $D3 (or page $D7 on systems with 2k of video RAM) where the cursor will be placed when a carriage return ($0D) code is received. So it controls the left margin of text, and also which line is the bottom one for text output.
- $FFE1 controls the line length. Specifically, it contains one less than the number of characters that should be displayed on a screen line (or equivalently, it is the offset of the rightmost character output on a screen line from the leftmost one).
- $FFE2 is simply a flag that should always contain either 0 (for 1k of video RAM, with output going to page $D3) or 1 (for 2k of video RAM, with output going to page $D7).

[In some message I posted a few years ago, I got the functions of $FFE1 and $FFE2 reversed, but the above is correct.]

-Danny

[davisgw]

I blew off your question because I had used the same 600B, without the S-100 expansion, to dump the contents of the ePROMS back in February....but at that point I still would have suspected my video driver because I was mucking with the stack. I guess I shot myself in the foot.... ;-(

[davisgw]

bxdanny,
Now that my modified monitor issues are resolved I began looking at other things we discussed, the first being the modified video for WP6502.
I have not yet made a 48 x 13 floppy with the video mods you described but I tried booting with 65D 3.3 that is modified to use the S-100 video
driver and then switching to the WP6502 disk to run BEXEC*...everything works well until I come to the WELCOME screen and I answer the query whether I want to change codes by typing RETURN. The result is "SN error on 500". But if I boot from a WP6502 floppy it does not fail and responds with a selection menu. So can I assume that 65D 3.3 is somehow incompatible? Can I modify the output vector on a WP6502 floppy to use my S-100
video driver?

[bxdanny]

65D 3.3 is definitely incompatible with WP6502. But if you have the full set of five Tutorial Disks, try booting with Tutorial Disk 2 (which drops you directly into BASIC immediate mode), then switch to your WP6502 disk and type RUN"BEXEC*" or just RUN"WP6502".

-Danny

[davisgw]

bxdanny,
Once again my thanks. I started to modify track 0 on a copy of my WP6502 floppy only to realize at some point I had based it on 65D 3.3. So after verifying that running BEXEC* after booting from disk 2 successfully loaded WP6502 I tried a new approach to creating a working disk....I copied 65D from disk 2 to a blank disk, modified track 0 to point to my video driver, then created and copied the BEXEC* and program files for WP6502. I worked like a charm. Then I created a 600D disk from disk 2, track 0 modified with your 48 x 13 driver, and created and copied the program files. It also works as
expected.
I only copied BEXEC*, WP6502, WP6503, AND TODWO to each disk. Did I miss anything?
I'm attaching a couple pics of my systems for your viewing pleasure....

[davisgw]

Mark,
I have a new mystery with the Disktool. I was trying to transfer a disk image to the OSI at 300 baud but was completely unsuccessful...the bytes transferred pop-up showed no bytes transferred. After several attempts I tried using Teraterm File->Sendfile and it appears to transfer data but the image is never written to disk and Disktool does not appear to receive the image. After much frustration I tried receiving a disk image and it worked just fine even at 4800 baud. Then I tried transferring that same image back to Disktool and again nothing gets transferred. I also tried several variations of file types with no success. As I recall when I wrote the Disktool image I had difficulty even at 300 baud, but because of that I apparently never tried 4800 baud to receive an image on Teraterm.
My questions are:
1) What could cause Teraterm to successfully receive an image from Disktool but fail to send that same image back to Disktool?
2) What is the difference between Teraterm SendFile and Transfer->XMODEM->Send?
3) How can I obtain more information to debug this?

[davisgw]

It occurred to me later that I had not tried changing flow control settings, since it was set to none. I tried the other possible settings and still got the same result. But it's possible that the USB to serial adapter does not provide sufficient levels to be compatible with the OSI serial port. I will also look for an alternative to Teraterm.

[Mark]

I forget which USB-Serial adapter you are using. I think I recall your adapter is not a Prolific PL2303 based which could be an issue if its a clone chip. https://www.eevblog.com/forum/reviews/n ... -adapters/


The Teraterm menu item File/Send file... sends raw ASCII or binary where File/Transfer/XMODEM/send or receive uses the selected file transfer protocol (Xmodem) to communicate.

File/Send file... is only required to upload the Disktool program to the OSI through the OSI monitor.

By default the OSI initializes the ACIA to 8N2 on reset, so if you are uploading the DiskTool program to the OSI monitor, setting TeraTerm to 8N2 will be best.
Once Disktool is running, it resets the OSI ACIA to the more standard 8N1, as this is ~10% faster. So using 8N1 with Disktool is best.

Flow control is not used on the OSI nor with DiskTool as there should never be data rates or data dumps that cause overflow, plus it would increase the code size & complexity. Communication is pretty much only half-duplex so flow control should not be needed. It's best to disable flow control.

Xmodem is required to upload disk images to the OSI so that the serial stream can be paused to write a complete track when received. This should be Disktool menu item #3 "Receive Disk Xmodem"

To write a disk on the OSI:
At the DiskTool menu, press '3', insert a target diskette in the OSI, then press Enter on Teraterm... you should see the "Begin XMODEM/Checksum transfer. Press <ESC> to abort..." message.
Now use File/Transfer/Xmodem/send in Teraterm to select the OSI disk image you want to upload.
The Teraterm Xmodem dialog should show the transfer status.

Teraterm

teraterm.jpg (48.05 KiB) Viewed 58664 times

The OSI will show the status of each track written.

C1P

osi.jpg (16.57 KiB) Viewed 58664 times

Good Luck!
-Mark