Superboard Expanded on S-100 motherboard

[bxdanny]

Actually, on the standard version (Tutorial Disk 5) of OS-65D 3.3 for the C1P, a version of the Diskette Utilities containing the Track Zero Read/Write Utility can be found on track 39, sector 1 (in the "file" COMPAR, which isn't really loadable as a file). It still loads to and should be run at $0200.

[davisgw]

Hi bxdanny,
All of my attempts to run the 65D Track 0 Read/Write utility were failures...no dialog offering 2 choices. So I searched everywhere and never found any OSI document explaining how to load and run it, but I found 2 journal/magazine articles describing it and both referenced the wrong track and sector to load it for V3.3...I can confirm that it is NOT on Track 11, sector 2. Thanks for clearing that part up!!! The most informative source is a article by Richard Trethewey in MICRO describing how to modify Track 0 to stop automatically running BEXEC*. So after I finally was able to modify Track 0 it took 4 attempts to create a floppy that would boot and use my video....but it is extremely S-L-O-O-W. it takes about 30 seconds to display the BEXEC* menu instead of 3 seconds. I don't know if it's the delay I put in the driver to keep from overrunning the video card or if it's my use of $0201 - 0202 that is stepping on 65D.

I have 2 questions now:
1) Does anyone know the repetition rate that the C1p scans the keyboard?
2) Do you know where OSI documented some of the "secret" utilities like this one?

Thanks again.

[bxdanny]

Writing to $0201 and $0202 while 65D BASIC is running will definitely mess up BASIC. Specifically, it will alter the dispatch addresses for the END and FOR commands. And writing to $0230/$0231 will change the dispatch address for the CONT command. You can expect that these commands will become non-functional. You will either need to swap out the storage locations on page 2 used by your driver on entry to it, and swap them back on exit (like 65D does with $0213-$0216 used by the keyboard driver - see the code at $252B), or simply use other locations, like the ones I suggested.

The most detailed technical info about 65D can be found in the Disassembly Manual at https://osiweb.org/manuals/OS65D_Dissasembly_Manual.pdf (it's for the 8" version of 65D 3.2) and the original 65D 3.0 user manual at https://osiweb.org/manuals/OS-65D_V3.0_usermanual.pdf (again, primarily describing the 8" version, but I think there are some brief mentions of differences in the 5.25" version).

It looks like you did finally find the Track Zero R/W utility, but as I said about 24 hours ago, on the 3.3 C1P disk it is at track 39, sector 1 (as always, as a 5-page sector).

[In my "Enhanced Pico-DOS" system, in the Files section of this board, I incorporated track zero read/write functionality into that system's 65D kernel as a "ZE" command, but since it doesn't display the expected syntax like OSI's full utility does, I figured it was better to use the full original utility.]

[bxdanny]

It also occurs to me that the escape sequence used by the 65D 3.3 BEXEC* to clear the screen (and in the C1 version to set 48 x 12 text mode) might be causing your driver to react oddly, gwd. You could try REMming out line 50000, then resaving BEXEC* that way (!50000, insert REM before the IF statement, then DISK!"PU BEXEC*) and rebooting, to see if that helps the delay problem. You could also try just RUNning the altered version without rebooting.

[Message edited 11:55 PM 7/8/2023]

[davisgw]

I tried modifying BEXEC* like you describe but got a error from BASIC on the next line.
But that's not going to solve my problem anyway....here's what I tried.

1) I decided that modifying the source code to eliminate any Page 2 memory use (at least for disk based driver) should be my objective. With that in mind, since HEXDOS would allow me to edit and assemble using the enhanced video, I tried to use COPY65D to copy the source for editing by HEXASM. I quickly discovered that COPY65D reads the source file and creates an empty file for HEXASM....I have no idea why. Then I discovered that EDIT produces an error when calculating the workspace size because of an arithmetic error because I have 36K of free memory.....if I override the memory size on boot it works, but then the source file is empty.
2) I tried to NOP the delay in my video driver for 65D but there was little difference writing text by BEXEC*. But with the modified diskette using my video driver on boot I transferred to the assembler and it is NOT using my video driver....when I load the source code and print it goes to the C1p video.
3) I have not tried to build DOS/65 because my driver would likely have a conflict.
So I'm resigned to reworking the driver source from a printout the way I did 50 years ago, except now I have to capture the printout on a laptop from the C1p serial port because I don't have any compatible printer anymore.
Any ideas on the HEXDOS issues or an easier way to edit the source code with 65D would be appreciated.

[bxdanny]

I've never used HEXASM (despite having posted a disk image containing it), nor the COPY65D program you are referring to, so I really don't know why they are behaving as you described.

Can you possibly post actual hex dumps of your monitor ROM and the video driver ROM? It looks like, in ROM BASIC/HEXDOS, you were outputting everything to both the OSI memory-mapped video and the S-100 video board, and that the driver for the S-100 board was depending somehow on values (on page 2) written by the driver for the OSI video. Is that right?

[bxdanny]

Also, if you have any documentation for the video board, can you post that? Specifically, what each of the two bytes of the port does on input and on output, and what control codes/escape sequences it is supposed to respond to. You said at one point the board processes control codes internally, if so you shouldn't really need a driver to keep track of anything, it should just check if the board is ready for a character, and send it when it is.

[davisgw]

You are correct. My video driver attempts to preserve the C1p video while also outputting the text to the VB2 board, and anything that is not a text character or a control character is omitted. I will try to dump the video driver ROM when I capture the source code from the serial port, but getting the source code printout is my priority.
Here is part of the SSM VB2 "Theory of Operation" that describes the board interface. Reading it now with hindsight, when I put this together in 1980 there was no internet and I had no IBM PC so I could not easily look up the TBMT (Transmit Buffer Empty) response from the card for my video driver to use....when I modify the source I can add polling for this response to the delay after writing a character to the card.

SSM_VB2_UM.pdf

(287.12 KiB) Downloaded 417 times

I also have a SSM VB1C video card (which until this week had bad memory chips) that also works in my system. The example driver in the documentation takes advantage of the memory mapping capability and does not make use of the ports at all. But their example driver has a built-in delay for line scrolling and end-of-line.
Do you have any idea how to hook 65D ASM code into my video driver?
Also I have an idea why HEXDOS COPY65D copies the source code file to an empty file....I will test that too.

[bxdanny]

64 x 16 is not too big an improvement over 48 x 12, especially if it only does CAPITALS. Or is your Superboard the 600B that only does 24 x 24?

Anyway, the most important piece of data needed right now is: what bit of what port address carries that Buffer Empty signal, and what polarity signals empty? Second piece of information needed: what is the control character to signal "clear screen"?

A simple driver to just send characters when the board is ready can be entered as hex codes, and doesn't really need an assembler to create. For something more complex, it might be best to use the a65 cross-assembler (available from Mark's site) on your PC, and then transfer the assembled code via serial cable.

[davisgw]

The surprises and forgotten details just keep coming...and Gremlins are running rampant. Firstly to answer Danny’s question, my oldest Superboard which became the base for my S-100 system is a Revision B which does not have 48 x 12 support. My other 2 Superboards that I recently expanded with 610 boards, RAM and floppy support are Revision D. So I will likely activate the 48 x 12 video on boot up. Does anyone know how to turn it off in case I need to?

Next, I got frustrated with not having improved text running OS65D, so I authored a 10 line driver in ROM and changed the vector on track 0 of a OS65D disk and after a few iterations got it to work…not only in BASIC but also DOS, ASM, and EM! Then I began the real progress. The driver is located at $E320 in the Utilities ROM dump that follows.

By printing the source code to the screen I soon discovered that the driver at $E000 is NOT the code we previously discussed and it does NOT use RAM in page 2…there is RAM I implemented for this purpose at $F400-F7FF. And also the standalone BASIC-IN-ROM driver we previously discussed is in the Monitor ROM at $F800. See the Monitor ROM dump that follows.

When I tried to dump the ROM’s and the source code to my laptop I got no data received and tried EVERYTHING to get it to transfer like it did when I dumped the other ROM’s for my other Superboards. Finally I resorted to checking wiring and discover that the RS-232 cable, which I’m
>>>SURE<<< is the one I used before, could not possibly transfer any data. So I found a RS-232 cable I fabricated 50 years ago that is correct and everything worked….except the ROM dumps had no carriage returns or line feeds and the source code dumps had too many. I ended up editing the files on my PC.

So I think that my video drivers are responsible for the missing/extra carriage returns, even though everything looked correct on the display. I dumped the ROM’s from ROM BASIC and the source code from OS65D ASM.

Here are the dumps for your inspection. I think the driver at $E000 my be unnecessary since the new one at $E320 works so well without tossing any data.

C1p_MapS100.pdf

(17.49 KiB) Downloaded 409 times

MonitorRomS100.txt

(4.5 KiB) Downloaded 430 times

UtilRomS100.txt

(4.5 KiB) Downloaded 453 times

VidctlS100Src.pdf

(13.83 KiB) Downloaded 422 times

VidmemS100Src.pdf

(12.06 KiB) Downloaded 424 times