OSI + Gotek (youtube video)

[davisgw]

Thanks Mark. The computer is partially disassembled now so that I can verify whether the ribbon cable has open circuits. I may need to make a new cable. I will try your specially prepared OS65D3 when I get the chance within 2 weeks time. Thanks again.

[davisgw]

Mark,
I finally got time to verify that the floppy ribbon cable seems OK. So I loaded both of you modified OS65D3 images as you described but the results do not enlighten me at all. The image with BASIC loaded states that 17793 bytes are free and when I load BEXEC* and LIST it seems to list the entire program to the console without any noticeable errors. But when I execute RUN it appears that BASIC hangs...the cursor goes to the next line but there is no other indication the system is still alive. If I don't load BEXEC* but instead type EXIT and then EM I can dump memory or disassemble memory without any noticeable errors. The same goes for the DOS image.
I was also prepared to swap power supplies with the working 600D but the voltage to the board is 4.91V instead of 5.13V for the failing one.
So do these results indicate to you where the problem might be? I feel even more frustrated....
I just purchased some spare memory: https://www.ebay.com/itm/135257226970 that I could use if I knew where to plug it but do not even know for sure if it's compatible as a 2114 replacement. Any ideas from anyone are appreciated.

[bxdanny]

If BASIC comes up OK with the input and output devices set to 2, but output disappears when BEXEC* is run, it certainly suggests that something BEXEC* does is what makes the output disappear. But the only relevant thing that BEXEC* does is to set the current input and output devices equal to the default console device stored at location 10950 (or $2AC6). So before running BEXEC*, PRINT out what the value of PEEK(10950) is. If it isn't 2, that's the problem. But the value there is determined by the contents of ROM location $FE01. If that is 0, then $2AC6 gets set to 1 (indicating a serial system). Any non-zero value at $FE01 and the system is set up as video-based ($2AC6 gets set to 2).

Actually, the 3.3 BEXEC* does one other thing with regard to setting up the screen: it sets the screen to 48 x 12 mode with colors enabled. You could instead make it disable colors by adding the line

905 POKE 56000,1

before running the program, just in case that somehow has an effect (which it really shouldn't).

[davisgw]

You may be onto something but it looks like something else entirely....perhaps something related to BASIC program execution.
I displayed $FE01 and it has object code in that location so it is nonzero and the $2AC6 value is 2. So I set BEXEC* line 20 to blanks to remove the POKEs that change the console device and then type RUN...I get the same result without console output. Then I tried loading and running the RENAME utility from the OS65D3.3 disk 5 image and get the same result. So it does not appear to be anything specific that is done by BEXEC*.
I also noticed when I selected the OS65D3.3 disk 5 image that it will boot and display the menu but selecting any of the options (the selection does print to the console) but nothing appears to happen when it's entered. All the memory has been tested but access timings are different for program execution versus storage and retrieval....could the memory just be too slow? To verify that I can swap memory from pages that run (Dos/65) to OS65D3...but what address ranges should I try first?
Any other ideas? Thanks for any help.

[davisgw]

I fixed it! I played a hunch (nevermind that I broke it to begin with...) based on the evidence that OS65D3 BASIC loads from $0200 to $2200, most of my replacement unproven RAM came from China, and I trusted that TestMem had pretty well verified $0400 to $7FFF. That left page 0 memory that Mark provided tests for and had identified bad RAM at $03DE, which I replaced with a pair of Chinese RAM. But ever since then the console had displayed a full screen of random graphics characters instead of the boot menu on power up. So I just replaced the page 0 RAM with the AM9114 RAM that is supposed to be USA old stock of AMD 2114 RAM, also untested on the 600D....it booted OS65D3 first time with no problem, Dos/65, and also other images I tried. Wahoo! Thanks to everyone who helped.

Mark, I hate to say it but your lowmem tests could use improvement but I can't provide proof why they failed to find the problem....only a hunch that it was too slow. Thanks anyway, good effort.

[davisgw]

I did not mean to imply, in my previous post, that I'm ungrateful to Mark for providing the low memory tests. On the contrary, Mark is a rock star and we had no way to know the RAM I had in page 0 had a problem that could not be detected with a static test. After all my frustration I wanted to point out that we should never trust that the best memory tests may still fail to identify a problem. Since the 2114 RAM chips are likely old and failure is not far in the future, more comprehensive tests may be needed. Sorry Mark....

[davisgw]

Once again I shot myself in the foot. Without comparing the serial port clock circuit for the 600D vs the 600B I wired the input to U57 to C0 on one of my 600D boards, intending to get 4800 baud....it did not work as anticipated. Now that I know I screwed up I will try to analyze the 600D clocking to figure out the correct change, but before my head begins to explode can anyone describe the correct change to the clock input of U57 for 4800 baud on the 600D board?
Any help is appreciated.

[davisgw]

Well, as I suspected, there IS a difference in the clocking between the 600B and 600D boards. After much head scratching and reviewing my changes to the 600D board I discovered that connecting U57-2 to U30-14 (C0) yields a serial port speed of 9600 baud, not 4800 baud as it does on the 600B board. The correct change for the 600D board is to connect I57-2 to U30-13 (C1). So my change to add a switch to J3-8, J3-10, J3-12 and connecting U30-13 to J3-12 for the switch selection for 4800 baud works perfectly! Thanks to all who helped even if the help was misleading
On the plus side I've become an expert disassembling and reassembling this 600D system....