Upgrade 610 from 2114 RAM to 6264 8K x 8

[Mark]

Glad to hear you're making progress!
Any idea how large your boot ROM is? I might guess it is 2K, but that boot menu has a lot of options that could make it much larger. Dumping 2K will help determine if any other memory ranges need to be included.

This earlier post offered two programs to dump your ROM to a serial port.
BASIC is just fine, and a program is included below. The program below will dump the contents from $F800 to $FFFF as hex data, 8 bytes per row to the serial port. You can record the cassette audio from your OSI on your laptop with something like Audacity and decode it there or use RS-232 & capture the hex data with a terminal program.

The following code sends hexadecimal contents of memory from $F800 (63488) to $FFFF (65535) to the OSI serial port. It should work on any BASIC-In-ROM OSI machine. Change the values in line 20 to dump other address ranges.

Code: Select all

 10 A$="0123456789ABCDEF":J=0:POKE517,1
 20 FOR I=63488 TO 65535:D=PEEK(I)
 30 PRINT MID$(A$,D/16+1,1);MID$(A$,(DAND15)+1,1);" ";
 40 J=J+1:IF J < 8 GOTO 60
 50 PRINTCHR$(13);CHR$(10);:J=0
 60 NEXT:POKE517,0

If capturing audio, it will need to be converted back to text with something like OSIKCS or similar KANSAS CITY STANDARD decoder, then converted to binary with a hex->binary converter like DeHex to make a binary image. In Windows Explorer, drag the captured audio file on top of OSIKCS.EXE to convert wav file to data, (rename it with a .txt extension to view) then drag that resulting file on top of Dehex.exe to convert to binary. You can use a command prompt to do the same if it's easier. The tools will build on Mac/Linux too. Hope this helps!
-Mark

[davisgw]

The monitor ROM is a 2716 ePROM and some of the selections on the boot menu I think go to code that is burned into ROMs residing on a S-100 buss ROM memory card, for example the OSI Extended Monitor. And some may just be duplicate pointer references to the boot loader for OS65D. As you say the dump will reveal the answers (I apparently left no notes for myself because I never thought it would be 50 years later!).

I plan to use software on the PC called RealTerm: https://sourceforge.net/projects/realterm/. It features settings to provide HEX capture of data in either BIG endian or little endian so I'm hoping it does what I need.

What is the file extension needed for portability of the image? Should it be .TXT, .BIN, or something else.

Thanks for the BASIC program, but what happens when it sends the line feed, carriage return? Does that get stripped out be the terminal program.
Is there a reason to send 8 bytes per row?

[bxdanny]

Davis,

I was wondering why you have WP6502 as a separate menu item. A disk version of WP6502 would normally boot in the same way as a regular 65D or similar disk, so the "Boot DOS" option would suffice for it. Or do you have WP6502 itself in ROM? I'd be interested in the details if you do. (And don't worry, I'd be fine with it. I'm not trying to enforce any DQFLS copyrights or license terms, despite my having done work for them. )

-Danny

P.S. I'm guessing that Mark put eight bytes per line simply because that is what fits on the C1P/Superboard screen, and that the DeHex program will remove all non-hex characters. But be aware that there will be ten NUL ($00) characters inserted right after each carriage return (before the linefeed), and that this will prevent the file of hex characters from displaying properly in Notepad. (Wordpad will display it correctly, though it will appear double-spaced.)

If you really want to avoid the extra nulls, and the double spacing on both the OSI and PC displays, you can change line 50 to read

50 WAIT 61440,2:POKE 61441,13:WAIT 61440,2:POKE 61441,10:POKE 14,0:J=0

But the original program will certainly work fine as well for creating the ROM image file on the PC.

[davisgw]

Danny,
Did you formerly help develop WP6502? I truely cannot remember if I burned the assembler code to ROM, however I read an article once on how to relocate the code so it's possible I did, perhaps to take advantage of the (40 x 80?) display card in my S-100 system. I am slowly working up to resurrecting that system but have my hands full with the 2 newer Superboards right now. Thanks for the tips.

I hope RealTerm works as I expect it to....

[bxdanny]

davisgw,

I didn't work on the core word-processing functionality of WP6502, no, but I created the file interface program (load/save/rename/delete/see directory/exit), known as WPEXEC, for the final version, which was the OS-65U release of version 1.3a. I also cleaned up and improved the mail-merge program (I think it was called DQ Mail), which allowed generating form letters with fields filled in from DMS database files. The actual word processing code was written (either entirely, or pretty close to it) by a man named Fred Beyer.

-Danny

[davisgw]

It seems apparent that I'm being bitten by the famous BASIC string bug. I change the following 3 lines of the program:
10 A$="0123456789ABCDEF":J=0:POKE517,1
20 FOR I=63488 TO 65535:D=PEEK(I)
30 PRINT MID$(A$,D/16+1,1);MID$(A$,(DAND15)+1,1);" ";
to be:
10 A$="0123456789ABCDEF"
11J=0:POKE517,1
20 FOR I=63488 TO 65535:D=PEEK(I)
30 PRINT MID$(A$,(D/16)+1,1);MID$(A$,(D AND 15)+1,1);" ";
This is because A$ was being to the value ""0123456789ABCDEF":J=0:POKE517,1" and also PRINT MID$ was producing
the wrong result. Now for the location FFFE the value is 192 or X'C0' but it prints on the screen as X'D0'. So even though most of the
dump looks OK, I can assume that many locations are being printed wrong. And I don't see any reason why this is happening.
In fact beginning at FFF8 it should be 20 02 30 01 00 C0 01 but what's printed is 20 02 30 01 00 D0 01.

Any ideas how to fix this? By the way the label on my BASIC4 ROM says it has the string fix....

[bxdanny]

It sounds like something is wrong with your BASIC ROMs, or maybe your RAM or your CPU. The original version of the program as posted by Mark works fine for me. (Admittedly that is on WinOSI, not real OSI hardware, but it shouldn't make a difference.)

You could try just dumping raw 8-bit bytes to the cassette/serial port, i.e.

FOR I=63488 TO 65535:D=PEEK(I):WAIT 61440,2:POKE 61441,D:NEXT

At 300 bps 8N2, that should take 75 seconds (1 minute 15 seconds) to execute.


Capture the output as audio if necessary, or if you can, as simply a stream of 2048 bytes, and post the results. Someone here will figure it out.

[bxdanny]

BTW, if the contents of $FFF8-$FFFE really are supposed to be what you said (what happened to $FFFF?), then we already know that you have another ROM at $C000, since that is where your reset vector (word at $FFFC) points. But $C000 is normally the address of the disk interface PIA. So that can't possibly be the reset address of a system with a floppy disk (unless there is some fancy switching of the memory map going on).

[Mark]

As I recall the BASIC string bug is a problem with the Microsoft BASIC string garbage collection routine triggered by low RAM situations that reorders strings in memory after many concatenations /manipulations, and would not be an issue with this type of use. The bug was an endless loop when there was too little free space to move strings.

My best guess as to why C0 would print as D0 is A$ is missing a character. (Perhaps a touchy key on the OSI keyboard?)
However Danny's 1 line program is great & concise - just make sure whatever you capture the data with does not strip nulls. (Save as RAW or use RAW transfer in terminal program if possible.)

Capturing audio will also preserve all contents, however be sure to use at least 22000 samples/second 8bit mono or higher and save as WAV not MP3. Capturing at a higher sample rate or bit depth is just fine but not required.

If you have the Extended Monitor available you could save the ROM contents in MOS checksum format with the command SF800,0000

Good Luck!

[davisgw]

I know why this problem happened....apparently 50 years ago when I burned the monitor ROM in that system I also burned concurrent changes in BASIC3 and BASIC4 ROMs, one of which has an error. They are a matched set of 3 because changing out any one causes either no menu or BASIC won't come up. So I will need to remove all 3 from one of the newer Superboards to solve the problem and make another attempt (I hope). Fortunately, one of the other monitor ROMs I burned does not require changes in the BASIC ROMs and it also has an enhanced boot menu.