OSI + Gotek (youtube video)

[Thomas]

As mentioned, receiving serial data with a /1 clock @ 4800 baud in asynchronous mode is almost impossible due to small frequency differences between sender and receiver.

Best described in the attached pdf

Atmel-Asyn_RDX.pdf

(81.44 KiB) Downloaded 23 times

[davisgw]

Mark,
I started to debug the cause of the freeze of Disktool, which happens most of the time before the transfer even starts. But I accidentally fixed it with my changes....it normally freezes right after the "Press any key" message. So I added some messages to see at what point the freeze occurs. See the source code below and the screen shots of the PC:

RAWREAD
JSR LOGRESET
JSR PRINT
.BYTE CR,LF
.BYTE 'WRITE PROTECT ALL DISKS!',CR,LF
.BYTE CR,LF
.BYTE 'Insert disk to be dumped',CR,LF,0
JSR ABORTMSG
JSR ANYKEY

JSR PRINT
.BYTE 'SETUP PIA',CR,LF <============ Debug message
JSR INITPIA
JSR PRINT
.BYTE 'SELECT DRIVE',CR,LF <============ Debug message
JSR SELDRV

JSR PRINT
.BYTE 'GOTO TRK 0',CR,LF <============ Debug message
LDA #0
STA lastdata

JSR TZERO ; STEP TO TRACK 0
BCS NOTRK
LDA #$58 ;0 10 110 00 ;$58- recv irq, RTS HIGH no xmit irq, 8E1, DIVIDE BY 1,
STA DRVACIA

With the added debug messages it no longer freezes AND the transfer starts and continues to completion!
So I suspect that the ACIA 4800 sync issue is not the cause of these machine failures (well, SOME of them).
My theory is that there is a timing issue with the PIA which causes the drive to fail stepping to track 0. Perhaps not
but the timing change these messages add to the code allows Disktool to complete a option 1 transfer. Any comments?
I will continue to confirm this if not.....

[Mark]

I think you're on a good track! I'm glad you can build this from source.

However, the PRINT routine needs to have the following message terminated with 0, otherwise it won't return execution until it encounters another 0 in the code. Perhaps part of LDA #$00?
Although working, it may not be calling initPIA & the other code as you can see other characters printed in the debug messages.

So change

.BYTE 'SETUP PIA',CR,LF <============ Debug message

to .BYTE 'SETUP PIA',CR,LF,0 <============ Debug message

Etc.

Good luck

[davisgw]

Mark,
When I changed the three print messages to have a null at the end, it shortened the messages so that the last message displayed was "Begin XMODEM/"
before freezing. So I padded the messages with about 25 blanks like the following:
.BYTE 'SETUP PIA ',CR,LF,0 <============ Debug message
That solved the problem and I can use option 1 to transfer on that 600D. It still fails to complete about 25% of the time because of the sync issue.
However, I wonder if these extra messages could improve the syncing? I doubt it but I do think that machine has a timing issue with the disk drive PIA interface to the Gotek. And none of the OS65D, Dos/65, Hexdos, and Disktool images fail to boot or execute programs.
But I did not do anything with option 3 and that still fails. And the resulting Gotek image must still be read only to boot repeatedly.
So unless you need more debug information from me I will patiently wait for your new version of Disktool. Thanks for your help....

[davisgw]

Hi Gotek users,
My previously posted Dos/65 Gotek images has proven to be defective due to an error in OSIHFE, which Mark has just fixed this week. The issue is that track 0 was short by 4 bytes and when the system does a warm start (from a 'ctrl-c' or after running most of the .COM files) it would get stuck trying to read track 0. Oddly enough they would cold boot OK I had no clue they were defective. So if you downloaded these Gotek images:
viewtopic.php?p=6444#p6444, erase them and download the attached replacement files.

[HOWARDHB]

I dowloaded these, they don't boot in WinOSI. Did you pehapse attach the old zip file?

[Mark]

DOS/65 requires a loader disk if not using a custom boot ROM. This one should work...

[HOWARDHB]

They all work!!!

[davisgw]

One of my 600D machines has developed serious problems. I'm booting from Gotek and the only images that are usually successful are Disktoo5, MemTest, and Dos/65, but OS65d3 fails to boot...it gets to track 16 on Gotek the display and the monitor screen remains blank. So I decided to utilize the 'F' and 'C' functions to find bad RAM and actually did identify and replace one pair of RAM. But the 'T' function continued to identify bad RAM on the 610 at $54xx even though I have replaced U39/U47 five times and U38/U46 once, and even swapped them with U35/U43 and u36/u44 to see if the failure moves. But it did not. The only success I THINK I've had is running a special MemTest Mark provided for page 0 and replaced the RAM there, which seems to be successful. Power to the boards measures 5.13V. ROM BASIC says there is 31999 bytes.
The RAM I have is 2114-550 (various manufacturers) which has worked fine until recently. Could this memory require 5.5V?
Additional steps I have taken:
1) I ran a low memory test provided by Mark to test the stack and page one. After getting a solid error at $03FE I replace the RAM there and the test now finishes clean after hours.
2) I re-soldered all socket pins on u39/u47 and all the socket pins surrounding that part of the board even though they all looked good. I got no errors from MemTest 12 hours overnight except a single hit, something like "0cxx 69 69", but since the expected and actual value are the same I don't know what that means. Anybody have an idea?
3) i got to wondering if the Gotek flash drive was corrupted from all the image updates. So I erased all the images from the "debug" flash drive and saved new ones from my PC...now Dos/65 and OS65D3 disk image 5 and image 2 boot correctly! BUT I can't do anything with OS65D3 because BEXEC* is corrupted (the menu is displayed but selecting a function causes BASIC to freeze). So at least the most puzzling issue (booting from Gotek) is explained.
4) I discovered that setting the read only setting in FF.CFG to "yes" prevents image corruption.
5) I removed the Gotek and booted OS65D3 from diskette and got the same result as 3). It seems like BASIC is corrupted after BEXEC* runs.
6) I suspect that the write enable line in the ribbon cable or connection to the (because of all the disassembly) Gotek is causing images to be corrupted but that is unconfirmed. But is there any way the ribbon cable could allow Dos/65 to boot but not OS65d3?
7) I'm not convinced that MemTest is perfect at finding memory issues? Does anyone know of a test that is more reliable?

So I'm asking if any of you have suggestions for what to do from this point? All suggestions are welcome...

[Mark]

When OSI Memtest encounters a read discrepancy it branches to another part of the program which reads the offending address again to display the value on the screen, so a response of 0Cxx C9 C9 means that there was a read failure, but when it was time to display the value it read correctly the second time. FLAKEY

OS65Dv3.3 BASIC runs from RAM at $0200 to ~$2200 with OS65D living above that. Programs load at $3A7E+ on V3.3.
We could modify OS65D so it boots to OS65D A* prompt or maybe just stop after starting BASIC? You could try loading programs or see if BASIC gets corrupted. (Assembler loads/runs at $1300 and Exmon at $1700 if you want to try those.)


Dos/65 Loads to high memory which varies depending on which version you have. Yours seems to use $3B00 to ~$5F00 for the OS, which is a totally different range than OS65D... which could explain why that works and OS65D doesn't.

Attached is modified C1P Tutorial Disk 5 where the default I/O flags have been changed from Memory Buffer & NULL to Keyboard & Screen making it boot to an interactive prompt instead of running BEXEC*. In addition NEW, LIST and ^C have been enabled by default.
A second image disables automatic BA command leaving you at A* prompt.

Boot to basic prompt

screen0000.gif (69.54 KiB) Viewed 2438 times