Superboard Expanded on S-100 motherboard

[bxdanny]

Glenn,

Each source line seems to be terminated with the sequence <carriage return><null><linefeed>, or 0D 00 0A hex, as you can see from the hex dump below.

Code: Select all

H:\Users\Danny\Downloads>debug srccode.txt
-d
0AE5:0100  0D 0A 0A 2E 50 52 49 4E-54 0D 0A 0D 0A 20 20 20   ....PRINT....
0AE5:0110  31 30 20 3B 2A 2A 2A 2A-2A 2A 2A 2A 2A 2A 2A 2A   10 ;************
0AE5:0120  2A 2A 2A 2A 2A 20 56 49-44 4D 45 4D 20 2A 2A 2A   ***** VIDMEM ***
0AE5:0130  2A 2A 2A 2A 2A 2A 2A 2A-2A 2A 2A 2A 2A 2A 2A 2A   ****************
0AE5:0140  0D 00 0A 20 20 20 32 30-20 3B 56 42 31 43 20 56   ...   20 ;VB1C V
0AE5:0150  49 44 45 4F 20 44 49 53-50 4C 41 59 20 44 52 49   IDEO DISPLAY DRI
0AE5:0160  56 45 52 0D 00 0A 20 20-20 33 30 20 3B 47 4C 45   VER...   30 ;GLE
0AE5:0170  4E 4E 20 57 2E 20 44 41-56 49 53 0D 00 0A 20 20   NN W. DAVIS...

But the lines immediately preceding and following your PRINT command (which could be shortened to just P) end with 0D 0A 0A and 0D 0A 0D 0A, respectively. Why that should be, I don't know. The file looks like a mess if loaded into Notepad, but it is quite legible if loaded into Wordpad, although it appears to be double-spaced vertically.

Frankly, I find it difficult to follow unassembled source code. Seeing the output produced by an A1 assembly would be a lot more useful.

[bxdanny]

Well, I did some more testing, and it seems that the OSI Assembler ALWAYS terminates lines of output with the 0D 00 0A sequence. Why it does that, i don't know. Possibly the original author was using a printer that needed the extra delay that provided. (Remember, it was written back in 1976.) So Glenn, it''s not anything your driver or your configuration is doing that is causing that. The best solution is probably to filter the resulting files on the PC to remove all NUL ($00) characters.

I also found that, on the C1P version of 65D 3.3, PRINT!(20) puts the screen into 24x24 mode, and PRINT!(21) puts it into 48x12 mode. These commands (which output ESC Ctl-T and ESC Ctl-U respectively) clear the screen, set the physical screen mode, and also set the screen margins used for text output.
Mark: in WinOSI, when using the "C1E" configuration with either RGB or composite color enabled in the video options, these commands blank the screen, but if monochrome video is selected, they work properly.

[davisgw]

I've mostly spent the last few days spinning my wheels, except I've created source code for the VB2 video card and added it to the S-100 utilities ePROM. I also inspected the listing for the VB1C memory mapped video card and discovered 2 typo's in the source that caused the 65D boot to hang. They did not fail assembly because the typo changed the instruction from the intended indirect addressing to absolute...the statements should have been
LDA (POINTER),Y and STA (POINTER),Y but were instead LDA POINTER,Y and STA POINTER,Y. Anyway I made the changes to the source code and burned it to the S-100 utilities ePROM and instead of hanging 65D boot the text appeared to be printed to the same location on the screen. And since the card memory overlays the C1P video, it likely never work well for BASIC-IN-ROM without more changes than I'm willing to make. So for now at least I'm giving up on the VB1C memory mapped card, though I will leave the object code in the ePROM.
The good news is that all special keystrokes I used editing the source files functioned as expected on the monitor with the VB2 card.

Mark, Now that I have the serial link to the laptop I can dump the DOS/65 disk like you requested...do you want me to boot DOS/65 and then dump memory? My next assignment is to build DOS/65 to use my new video driver...

[davisgw]

I require assistance using the DOS/65 file text editor. I'm trying to make a small change to SIM so that I can SYSGEN a new system but none of the editor commands seem to work as described in the documentation. I can open the .ASM file but when I try to skip forward to the place where I want to add a line of text nothing happens except re-display of the <*> prompt. I've tried all of the commands that are supposed to display text with the same results.
PLEASE HELP!

Sign me: Spoiled by PC editors

[Mark]

Hi,
I missed your last message.
Yes, please dump the DOS65 floppy(s?) you have, as I have not seen a version for the C1P yet. No need to dump DOS65 memory though.

Also I've finally posted an update to WinOSI that should fix the screen width error when color was enabled with "C1E" emulation as well as a number of issues found over the last two years!

Sorry I don't have any real experience with DOS/65, and the docs I've seen for Edit seem to explain everything but how to actually use it! All attempts at buffer transfer end with garbage on the screen. Perhaps my DOS65 is corrupted? Is there some way to transfer the edited file back via serial? Real CP/M could use PIP but what would DOS/65 use? I don't have any real docs on "Modem" or other obvious serial I/O programs...

[davisgw]

Mark, I finally figured out the DOS/65 editor, and you are right that the manual does not state clearly how to use it. But though it looks very good at creating new text files but quite cumbersome making changes to an existing one....it's nearly impossible without a printed listing. And the SIM is so big that 2 drives are a requirement to edit and assemble it. I have not yet succeeded because my edited SIM spits one error during assembly.

As to dumping the DOS/65 floppies it will require some planning because I think they will need to be dumped while running DOS/65 and the MODEM program I have may require changes to run on the SB II....I have a printout but not sure if the .COM file is modified for SB II. And I have not looked closely at https://osi.marks-lab.com/software/tools.html#OSITools for the OSIDump utility, but it will probably read DOS/65 floppies, will it? And there are 9 diskettes in the set which will take a lot of time to dump them all...it's on my list of things to do.

BTW, DOS/65 includes a MOVE utility that performs the CP/M PIP function, but the syntax is non-intuitive to me.

[Mark]

The dumping tools for OSI are stand-alone programs, not based on a particular OS.
There are two choices.
DiskTool is a newer program that can read/dump and write floppy images on OSI. Its a bit bigger than it's predecessor OSIDump, but both will work to dump floppies. (If you have a spare floppy disk, it's better to use DiskTool and write the included bootable disk image to your floppy for future use & quick loading.) OSIDump can only read disks, but it is a bit smaller & uses less RAM & thus somewhat faster to load via serial port.

The procedure to get going is the same for either version.
First you will need a terminal program that can send & receive ASCII and well as Xmodem/CRC or Xmodem/1K.

I've used Tera Term with good success. You can search for it to download on the official Japanese site, but I've had problems with the site timing out lately. However I have a copy on my web page at
https://osi.marks-lab.com/software/file ... -4.106.exe for TeraTerm with installer or
https://osi.marks-lab.com/software/file ... -4.106.zip for Tera Term archive only.

Download Disktool.zip or OSIDump.zip and extract the included ".LOD" file somewhere handy.
Connect to your OSI via serial port with the terminal program.
<RESET> the OSI, enter the monitor by typing 'M' and press 'L' to load from the serial port.
Next use File/Send File.... to upload the ".LOD" file, DiskTool.LOD or OSIDump.lod eventually you should see a message on your OSI stating the program is on serial now. At this point all interaction with the program is done with the terminal.

The dump process can occur at the standard speed or 16x speed. This is recommended for 300bps connections as you can go to 4800. If you are already at 9600 or higher it may make the speed too high. If you change the transfer speed in the program, make sure to change the terminal program as well. 5.25" disk images are ~90K and would take hours at 300baud!

Dumps can be done as ASCII Hexadecimal transfers, but for fastest speed, choose Xmodem/crc as the file is transferred in binary, and is 1/2 the size.

After setting speed and hex/xmodem transfer, select '1' from the menu to start the dump, insert the floppy in the OSI and get ready to receive a file on the term program. Press a key to start transfer. For Xmodem you will be prompted to begin receiving via xmodem. With teraterm select File/Transfer/Xmodem/Receive... and ensure binary & crc options are checked. Choose a filename like "Disk1.65d" for Xmodem transfers as that extension is known by WinOSI. Hex dumps will have to be dehexed before use.
After the transfer you should end up back at the program's menu for another go.

Anyway it's all pretty easy once you get going, just ask if you have any questions.

Oh, if you choose to use Disktool, you can write a disk using the file "DiskTool5.65d" and you will be able to boot that instead of having to reupload the program via serial in the future. It doesn't use an OS on the disk, just a custom loader to boot disktool, but it looks like an OS65Dv3 floppy. (The program to make the bootable disk image is named "BootThis" also on the tools page.

Good Luck!
-Mark

[davisgw]

Mark,
I already used Terraterm for the ROM dumps I posted. But you confused me about making a bootable disk for DiskTool with BootThis.exe. I assume i need to run the EXE on the PC to create the image but it has a bunch of parameters which I don't know the answer to:

Usage: BootThis -[leo58] infile [outfile]
Create OSI booting disk image from infile
Infile is expected to be 6502 OSI executable
-5 create 5.25" disk image
-8 create 8" disk image
-lxxxx specify load (target) address in hex for included file
-exxxx specify execution address in hex for included file
-n"DiskName" 6 chars per line disk label for OS65D Dir
-o overwrite existing output file
Please enlighten me.

Also, after several failed attempts to create a new DOS/65 image I've concluded that simply adding a single 6502 instruction is enough to fail assembly because the file is too big for the allocated space. I think that redefining the memory size and the space allocation for SIM will fix that. Do you know?

[Mark]

Sorry for the confusion. The bootable disk image made by BootThis.exe is already included in the DiskTool.zip archive as "DiskTool5.65D"

You need to serially upload "DiskTool.LOD" to the OSI the first time.
Once running on the OSI, this program will allow you to download disk contents from your OSI or write disk contents uploaded from your terminal.

If your floppy drive is working OK and you have a spare diskette, you can select option 2 "Receive Disk Xmodem" in the program, then select "DiskTool5.65D" to transfer from your terminal to the OSI using xmodem. (You do not need to format the floppy before use.)
This should create a bootable DiskTool floppy for future use if everything goes OK, and it will be much easier & faster to boot the floppy than upload the program via serial port.

Anyway, once DiskTool is running on the OSI you will be able to make images of your OSI disks.


Good Luck!

-Mark

[davisgw]

Finally I have succeeded modifying and building DOS/65 floppies that support my S-100 video card. See my new topic to get a discussion going from other DOS/65 users.

After many trials and errors to make a system work with added function for my video card I realized that if I was successful the floppies would likely be incompatible with certain functions provided with the original floppies. So I replaced some code in SIM with code to drive my video card without increasing the system tracks on the floppies. Here is what I ended up with.

The original video driver exit routine is:

vidext lda lstpge,x get char under cursor
sta lstchr and save
lda #$5f cursor char
sta lstpge,x send to screen
stx index save index
;The following five lines output a visual indication
;on the screen of the state of the mstwrt flag. If
;the flag is set a special character (the $e5) is
;placed on the last visible line of the display.
;This indication serves as a warning to the user
;not to change diskettes.
lda #' ' ready for blank
bit mstwrt test must write flag
bpl *+4 ok if clear
lda #$e5 else send special char
sta vidprm to prompt location
pla restore char
rts

And I replace it with:

vidext lda lstpge,x get char under cursor
sta lstchr and save
stx index save index
pla
jsr $e320
;The following five lines output a visual indication
;on the screen of the state of the mstwrt flag. If
;the flag is set a special character (the $e5) is
;placed on the last visible line of the display.
;This indication serves as a warning to the user
;not to change diskettes.
bit mstwrt test must write flag
bpl extvid
cmp #$0a test for eol
bne extvid
ldx #'$' send special char
stx $d401
extvid rts

So after I get some other loose ends finished I can work on dumping floppies. Will Disktool change the serial port to 4800 baud?