OSI SBII Basic in ROM problem

[Reggraham]

I am experiencing a weird problem with the MSBASIC in ROM, I'm using the OSI Basic Roms downloaded from the link in Dave's repository.
Doing a simple test routine shown below I get an odd result
10 DIM M$(255)
20 FOR I = 32 TO 255
30 M$ = M$ + CHR$(I)
40 NEXT I
50 PRINT M$
characters A to G and a to g are displayed as I to O and i to o respectively.
CHR$(65) returns I as does CHR$(73), ASC(A) and ASC(I) both return 73
I haven't tried the UK101 ROMS yet but before I do is this a known problem as I don't remember it on my original SBII but that was 46 years ago.

[Mark]

That is unexpected behavior. Not sure what the problem is but perhaps it is a ROM problem?

You can checksum each ROM in situ with the following program:

Code: Select all

10 L=65535:FOR X=0 TO 3:J=X*2048:C=0
20 GOSUB 50
30 NEXT
40 END
50 FOR I=40960 TO 43007
60 C=C+PEEK(I+J):IF C > L THEN C=C-65536
70 NEXT
80 PRINT C
90 RETURN

You should see
1651 -basic1
63557 -basic2
6509 -basic3 or 7080 - basic 3 with string garbage collection fix
48513 -basic4

[bxdanny]

It sounds like bit 3 is stuck high in the RAM chip where your string is being stored, at least when certain patterns are in other bits. If you have any spare 2114s, try changing U31, also carefully check the traces around it.

P.S. No need for the DIM statement (line 10). That creates a string array (MS(0) through M$(255)) which you are not even using, and is entirely separate from the simple string M$.

[Reggraham]

Hi
I tried that and the checksum results are as you said they were supposed to be.
I tried with 3 different versions of the Monitor ROM CEGMON, SJGMON BETA-011 and SYN600 all give the same result. It's weird as every thing else appears to work fine and it's only this characters I think, I need to see a print of what the whole set should be from CHR$(32) to CHR$(255) then I can compare with what I am getting to see what could be causing it.
The Basic in ROM I'm using is 1.0 rev 3.2. I need to buy some more 2716s so I can have multiple versions to test.
It's annoying as a couple of years ago I threw out 20 or 30 2716s and only kept 2764s and above thinking I would never use them again.

[dave]

Congratulations on the build!

I agree with Danny, it seems like you've got some bad RAM. If the program displays correctly on the screen, then it's the string variables.

Try changing line 30 to "PRINT CHR$(I) and see if that changes anything.

If the low memory (first 1k) were bad, your program wouldn't list or run properly. The variables are stored at the highest detected RAM, so your highest 1K is suspect. You should probably check all the RAM just in case. If you don't have spare RAM chips, you can

1) Use Mark's memory test, or another memory test, to check your RAM (You can load it via the cassette/serial port, or type it in)
2) Use the monitor to store and view memory locations, walking through the map in 1k inc1rements
3) try swapping out banks of RAM with the video memory and see how the display is affected.

Good luck!

Dave

[Mark]

As Dave said, string variables are stored at the top of memory in BASIC, integer variable are stored at the bottom, just after the end of the BASIC program. Since BASIC runs and the program is not corrupted, we know some amount of lower RAM is good. And your ROMS are fine if your checksums match.
I assume after resetting your OSI you press 'C' for cold start, then <RETURN> when prompted for "Memory Size?" BASIC will try to determine the top of memory at that point, by writing $92 (%10010010) and shifting it left to get $24 (%001001001) until it fails. If you are seeing "7423 Bytes Free" then BASIC thinks you have 8K of working RAM and it's passed a simple memory test. If that's not what you see, what do you see?

So when booting your OSI enter 2048 when ask for Memory Size? and you'll only use the lower 2K.
Your sample program should run correctly (As bxdanny said, line 10 is not needed).
You can try increasing memory size by 1K to see when it fails. (3072,4096,5120,6144,7168) BASIC does not validate the memory size you input, so you can make it fail when running if you put in a number larger than available.
Or as Dave says, load the OSI memory test program, which needs only 1K of memory. It can be found on this page

If BASIC thinks you have 8K of RAM, but programs are failing, then it's likely a partially bad 2114 or a solder bridge.

[dave]

If BASIC thinks you have 8K of RAM, but programs are failing, then it's likely a partially bad 2114 or a solder bridge.

Yes, that's a great point! If this machine used to work, or was produced on an assembly line, then a bad 2114 would be the most likely culprit. But for a newly built machine, it is far more likely to be a missed solder connection or a solder bridge. If so, swapping chips won't help, but a memory test will pinpoint the error, as will inspecting the PCB.

[Reggraham]

Thanks for the advice turns out the new RAM I bought either isn't fast enough or is bad I started replacing with the old chips I found in my box of very chips and it has started working. I'm going to have to build a chip tester to see if it's bad chips or a timing problem. But at least it is now working

[Reggraham]

Did some more research on the new RAM I bought (from EBAY) turns out to be low power CMOS which probably accounts for it being unreliable, I'll build a test board with good data buffers, if they then work ok i'll build a proper expansion board with the 8K

[dave]

Glad to hear you got it working.