CPM/Z-80 card for the 1090XL -- Calling anyone with Z-80 experience!

[ivop]

1 hour ago, reifsnyderb said:

 

I just started to take a look at this.  I removed the serial number code from CCP.  Did you mean to keep the serial number code in CCP as it's not in BDOS? 

 

The beginning of BDOS is at $EC00.  Should BDOS really start at $EC06?  The BIOS would have to change the zero page vector to $EC06, of course.

 

I thought the purpose of having the zero page vector was so that applications could find BDOS.....

You are not using the original DRI source code. BDOS starts with a six byte serial, and jmp BDOSE (the entry point) is after that. In a lot of versions it's just six zeroes, sometimes the second byte is 16H to indicate it's version 2.2 of CP/M. It's indeed used to find the BDOS entry for applications to call, but it's also used to determine MEMTOP (MSB used only), and sometimes to calculate the beginning of CCP. I have seen code doing a hardcoded BDOS vector - 00806H = start of CCP. For example The Amsterdam Compiler Kit (ACK) does that.

 

Original code from January 1980:

 

Spoiler

; serial number (not documented in original DRI source file)
    db  0   ; OEM number, low byte
    db  0   ; CP/M version, 16h = 2.2
    db  0   ; OEM number, high byte
    db  0,0,0   ; serial number, big-endian

;   enter here from the user's program with function number in c,
;   and information address in d,e
    jmp bdose   ;past parameter block

;   ************************************************
;   *** relative locations 0009 - 000e           ***
;   ************************************************
pererr: dw  persub  ;permanent error subroutine
selerr: dw  selsub  ;select error subroutine
roderr: dw  rodsub  ;ro disk error subroutine
roferr: dw  rofsub  ;ro file error subroutine

bdose:              ;arrive here from user programs
    xchg            ;info=DE, DE=info
    shld    info
    xchg
    mov a,e     ;linfo = low(info) - don't equ

 

 

The original CCP source code has support for conditional assembly of it serial number:

Spoiler

    ifndef  noserial
serialize:
    ;check serialization
    lxi d,serial    ;check six bytes
    lxi h,bdosl
    mvi b,6
ser0:   ldax    d
    cmp m
    jnz badserial
    inx d
    inx h
    dcr b
    jnz ser0
    ret         ;serial number is ok
    endif
 

 

I used the vanilla sources to build CP/M for my 8080 emulator, and they are the same .SYS files I included in the cpm1090.zip file I posted here for you earlier. My builds are in the cpm22 directory in the atari8080 github repo. The original is here: https://github.com/brouhaha/cpm22/ . The only thing they did is convert it from the ancient 8080 ASM.COM format to something more modern. The assembler you need is linked to in the description.

 

Edit: fixed to -00806H

 

Also found the code in boot.s in ACK:

Spoiler

    ! Now the 'heap'.

    lhld 0x0006              ! BDOS entry point
    lxi d, -0x806            ! offset to start of CCP
    dad d
    shld _cpm_ramtop
 

 

Edited April 21 by ivop

[ivop]

1 hour ago, reifsnyderb said:

Track 3, Sector 1 should be Sector 79 on an Atari disk.  So, that being said, and if my math is correct, sector 79 would start at offset 10112.  The directory should have the user byte and filename first.  So, I am thinking that the directory entries, and possibly files (?) all need shifted by 16 bytes.

The 16 bytes are the ATR header.

Also, the 79th sector starts after 3*26=78 sectors, which is 78*128=9984 bytes ($2700). With the ATR header, that's file offset 10000 (0x2710).

 

From the bootdisk.atr that was made with mkfs.cpm and the diskdefs following your spec (boottrk 3):

Spoiler

....

000026D0   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................
000026E0   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................
000026F0   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................
00002700   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................
00002710   00 44 55 4D  50 20 20 20  20 43 4F 4D  00 00 00 04  .DUMP    COM....
00002720   02 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00002730   00 53 54 41  54 20 20 20  20 43 4F 4D  00 01 00 29  .STAT    COM...)
00002740   03 04 05 06  07 08 00 00  00 00 00 00  00 00 00 00  ................
00002750   00 50 49 50  20 20 20 20  20 43 4F 4D  00 00 00 3A  .PIP     COM...:
00002760   09 0A 0B 0C  0D 0E 0F 10  00 00 00 00  00 00 00 00  ................
00002770   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................
00002780   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................
00002790   E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  E5 E5 E5 E5  ................

....
 

 

Edited April 21 by ivop

[reifsnyderb]

8 minutes ago, ivop said:

You are not using the original DRI source code. BDOS starts with a six byte serial, and BDOSE (the entry point) is after that. In a lot of versions it's just six zeroes, sometimes the second byte is 16H to indicate it's version 2.2 of CP/M. It's indeed used to find the BDOS entry for applications to call, but it's also used to determine MEMTOP (MSB used only), and sometimes to calculate the beginning of CCP. I have seen code doing a hardcoded BDOSE-00606H = start of CCP. For example The Amsterdam Compiler Kit (ACK) does that.

 

Original code from January 1980:

 

  Reveal hidden contents

; serial number (not documented in original DRI source file)
    db  0   ; OEM number, low byte
    db  0   ; CP/M version, 16h = 2.2
    db  0   ; OEM number, high byte
    db  0,0,0   ; serial number, big-endian

;   enter here from the user's program with function number in c,
;   and information address in d,e
    jmp bdose   ;past parameter block

;   ************************************************
;   *** relative locations 0009 - 000e           ***
;   ************************************************
pererr: dw  persub  ;permanent error subroutine
selerr: dw  selsub  ;select error subroutine
roderr: dw  rodsub  ;ro disk error subroutine
roferr: dw  rofsub  ;ro file error subroutine

bdose:              ;arrive here from user programs
    xchg            ;info=DE, DE=info
    shld    info
    xchg
    mov a,e     ;linfo = low(info) - don't equ

 

 

The original CCP source code has support for conditional assembly of it serial number:

  Reveal hidden contents

    ifndef  noserial
serialize:
    ;check serialization
    lxi d,serial    ;check six bytes
    lxi h,bdosl
    mvi b,6
ser0:   ldax    d
    cmp m
    jnz badserial
    inx d
    inx h
    dcr b
    jnz ser0
    ret         ;serial number is ok
    endif
 

 

I used the vanilla sources to build CP/M for my 8080 emulator, and they are the same .SYS files I included in the cpm1090.zip file I posted here for you earlier. My builds are in the cpm22 directory in the atari8080 github repo. The original is here: https://github.com/brouhaha/cpm22/ . The only thing they did is convert it from the ancient 8080 ASM.COM format to something more modern. The assembler you need is linked to in the description.

 

Got it.  I just tried the ccp.sys and bdos.sys on my boot disk image and it works.  I can tell it's changed because if I try to get an empty directory the response is no all in caps.   🙂

 

[ivop]

14 minutes ago, reifsnyderb said:

Got it.  I just tried the ccp.sys and bdos.sys on my boot disk image and it works.  I can tell it's changed because if I try to get an empty directory the response is no all in caps.   🙂

 

Great! Just for fun, you could mount my sample bootdisk.atr as drive B: and do DIR there. Then try DUMP DUMP.COM And STAT DSK:

 

Edit: and test writing to disk with PIP FOO.COM=DUMP.COM   and then FOO FOO.COM

 

Edited April 21 by ivop

[reifsnyderb]

7 minutes ago, ivop said:

Great! Just for fun, you could mount my sample bootdisk.atr as drive B: and do DIR there. Then try DUMP DUMP.COM And STAT DSK:

 

Ok.  I just tried it.  It isn't printing out the directory.  respeqt shows it reading sector 79+, but it's not displaying anything.  I am not sure where the issue is yet.

 

From looking at directory entries, it appears the data section, of the disk, always starts on block 2.  I am guessing block 1 is the directory.  (I was just trying to manually create a directory entry, too.)

 

So this confirms that something still isn't working right.

[reifsnyderb]

58 minutes ago, ivop said:

Great! Just for fun, you could mount my sample bootdisk.atr as drive B: and do DIR there. Then try DUMP DUMP.COM And STAT DSK:

 

Ok.  I just traced it down to a screw-up of the LDIR instruction I used in the BIOS.  It's fixed.  The directory is now displayed and stat works.   🙂

 

[reifsnyderb]

Now I can't get it to write to the disk.  I am not sure where the problem lies....     😞

 

Edit to add:

When trying to copy a file, with PIP, I get "Invalid Format" statements.  But STAT runs.  So, I can't believe the format is too messed up.  The disk format is so stupidly simple that nothing jumps out.  Using PIP, I just verified that it doesn't even attempt to write to the disk.

 

I am suspecting that "Invalid format" could be a syntax error as this is when I omit the "=" from the PIP command.

 

When I do use the "=" sign, in the PIP command I get a "no file" error.

 

Either way, it never tries to write to the disk.  All BIOS code looks good so far.  I put a break, in the Atari IO code, and on copy attempts (with PIP) the break point is never reached.

 

It's as though something else is wrong in CP/M.  I really don't know at this point.

Edited April 21 by reifsnyderb

[ivop]

Here's a disk image that might help you debugging this problem

 

Source:

Spoiler

#include <stdio.h>
#include <string.h>
#include <cpm.h>

unsigned char buffer[128];

int main(int argc, char **argv) {
    int i;

    cpm_fcb.ex = cpm_fcb.s1 = cpm_fcb.s2 = cpm_fcb.rc = 0;
    memcpy(&cpm_fcb.f, "FOO     BAR", 11);

    printf("Opening file\n");
    if (cpm_make_file(&cpm_fcb)) {
        printf("Error opening file, file exists?\n");
        return 1;
    }

    printf("Setting DMA\n");
    cpm_set_dma(&buffer);

    printf("Filling buffer\n");
    for (i=0; i<128; i++)
        buffer[i] = i;

    printf("Writing buffer\n");
    if (cpm_write_sequential(&cpm_fcb)) {
        printf("Error writing to disk\n");
        return 1;
    }

    printf("Closing file\n");
    if (cpm_close_file(&cpm_fcb)) {
        printf("Error closing file\n");
        return 1;
    }

    printf("Done.\n");
    return 0;
 

 

Expected output:

Spoiler

64k CP/M vers 2.2

A>dir foo.bar
NO FILE
A>write
Opening file
Setting DMA
Filling buffer
Writing buffer
Closing file
Done.

A>dir foo.bar
A: FOO      BAR
A>dump foo.bar

0000 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0010 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
0020 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
0030 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
0040 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
0050 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
0060 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
0070 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F

 

Edit: BTW are you sure the disk is writable? I don't know what RespeQt's defaults are. Might be R/O.

 

writetest.atr

Edited April 21 by ivop

[reifsnyderb]

45 minutes ago, ivop said:

Here's a disk image that might help you debugging this problem

 

Source:

  Reveal hidden contents

#include <stdio.h>
#include <string.h>
#include <cpm.h>

unsigned char buffer[128];

int main(int argc, char **argv) {
    int i;

    cpm_fcb.ex = cpm_fcb.s1 = cpm_fcb.s2 = cpm_fcb.rc = 0;
    memcpy(&cpm_fcb.f, "FOO     BAR", 11);

    printf("Opening file\n");
    if (cpm_make_file(&cpm_fcb)) {
        printf("Error opening file, file exists?\n");
        return 1;
    }

    printf("Setting DMA\n");
    cpm_set_dma(&buffer);

    printf("Filling buffer\n");
    for (i=0; i<128; i++)
        buffer[i] = i;

    printf("Writing buffer\n");
    if (cpm_write_sequential(&cpm_fcb)) {
        printf("Error writing to disk\n");
        return 1;
    }

    printf("Closing file\n");
    if (cpm_close_file(&cpm_fcb)) {
        printf("Error closing file\n");
        return 1;
    }

    printf("Done.\n");
    return 0;
 

 

Expected output:

  Reveal hidden contents

64k CP/M vers 2.2

A>dir foo.bar
NO FILE
A>write
Opening file
Setting DMA
Filling buffer
Writing buffer
Closing file
Done.

A>dir foo.bar
A: FOO      BAR
A>dump foo.bar

0000 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0010 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
0020 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
0030 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
0040 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
0050 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
0060 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
0070 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F

 

Edit: BTW are you sure the disk is writable? I don't know what RespeQt's defaults are. Might be R/O.

 

writetest.atr 130.02 kB · 2 downloads

Thanks! 

 

I am sure that the disk is writable and have been making sure to confirm this.  It appears that RespeQt caches changes and asks if I want to commit them when I close the program.

 

I've done some testing with your writetest.atr file.  What I've found is intermittent.  What is really interesting is that if I set my Atari to use Atari OS R 2 and do I/O at 19200, the failure rate is very high.  If, on the other hand, I use my OS 6.2 (pre-release), which has HIAS high speed SIO, and set the I/O to 56k that my failure rate drops.  My working theory is that I have some interference from NMI's being called.  However, I was thinking that the OS SIO routines would prevent any sort of interference like this.  Otherwise, I don't have a good idea why high speed SIO would get me farther along than normal 19,200 SIO.

 

 

[_The Doctor__]

More data can be handled in a given period with the higher speed, sounds like the traffic cop isn't fully on the job and he might need a paddy wagon instead of a car to carry so many travelers to their destination.

Try saving to a hard disk/ramdisk or equivalent and see what happens

Edited April 21 by _The Doctor__

[reifsnyderb]

8 minutes ago, _The Doctor__ said:

More data can be handled in a given period with the higher speed, sounds like the traffic cop isn't fully on the job and he might need a paddy wagon instead of a car to carry so many travelers to their destination.

Try saving to a hard disk/ramdisk or equivalent and see what happens

I'd rather get this working first before implementing a RAM disk.

[_The Doctor__]

No, using a ramdisk on a MIO or in the Atari side since the data is going to the device residing on the Atari Side, Remember the 1090 was to have a hard disk card as well. So I'd figure a quick test would be to see that it's flow control and buffer perhaps within the I/O window.

The faster save at he higher rate might have meant less buffer overflow or less I'm not ready/I am ready toggles.

Saving to a fast SD storage etc.

Edited April 21 by _The Doctor__

[reifsnyderb]

12 minutes ago, _The Doctor__ said:

No, using a ramdisk on a MIO or in the Atari side since the data is going to the device residing on the Atari Side, Remember the 1090 was to have a hard disk card as well. So I'd figure a quick test would be to see that it's flow control and buffer perhaps within the I/O window.

The faster save at he higher rate might have meant less buffer overflow or less I'm not ready/I am ready toggles.

The system has a lot of delays in it that should be handling any flow control.  So, there shouldn't be any overflow type situations.

 

Basically, it works as follows:

 

1.  CPM is loaded.

2.  The Atari goes into a loop waiting for the Z-80 to signal that it needs something.

3.  When the Z-80 signals it needs something, the Atari tells the Z-80 it needs the data bus.

4.  After the Z-80 signals it needs something, it goes into a loop waiting for a value, in memory, to change to signal the Atari is done.

5.  After the Atari signals it needs the data bus, the Z-80 finishes it's current instruction, lowers the bus ack signal, and goes into high impedance mode.  (The Z-80 is, basically, paused.)

6.  The Atari banks in the 3rd bank ($C000-$FFFF)

7.  The Atari grabs it's instructions from a structure.

8.  The Atari executes it's instructions.  (i.e.  read a sector)

9.  Any data received, such as a 128 byte sector, is put in a buffer for the Z-80

10.  The Atari changes a signal byte to signal the Z-80 that everything is done.

11.  The Atari turns the banks off.

12.  The Atari raises the bus request signal (this starts the Z-80 again).

13.  The Atari has a short loop to make sure that it give the Z-80 time to raise the bus ack signal.

14.  The Z-80 sees that the Atari is done, by checking the signal byte, and raises the bus ack signal.

15.  The Atari goes back to waiting for the Z-80 to signal it needs something.  (Step 2.)

 

So, with the Z-80 being paused, the Z-80 won't be doing anything while the Atari is handling I/O.  When the Z-80 is busy, the Atari is waiting on the Z-80.  Of course. the Atari does have NMI's and IRQ's to handle as well.

Edited April 21 by reifsnyderb

[_The Doctor__]

So I should have said traffic cops, someone is taking too long getting the message in or out on the radio/walkie talkie and the stop signs on either end of the single lane are not being turned in sync. So you will have a head on or no cars at all for a bit. Unless there is a glitch in the instruction being executed that is. Anyway faster saves might have been helpful keeping waiting data from occurring or timing out.

[reifsnyderb]

1 minute ago, _The Doctor__ said:

So I should have said traffic cops, someone is taking too long getting the message in or out on the radio/walkie talkie and the stop signs on either end of the single lane are not being turned in sync. So you will have a head on or no cars at all for a bit. Unless there is a glitch in the instruction being executed that is. Anyway faster saves might have been helpful keeping waiting data from occurring or timing out.

All of the disk I/O is going through Atari's Resident Disk Handler.  What is odd is that I've been able to confirm that some of the writes are working.....but not all are working.

 

Here's the read/write code:

 

;	--------------------------------------------------------------------
;	READ SECTOR
;	--------------------------------------------------------------------
SR15:

	LDX		IODISK			; Store the disk drive number in DCB
	INX									; Increment as CP/M disk drive is zero based
	STX		DUNIT			
	
	JSR		GTSCTR		; Get and calculate the sector number.  It will be in DCB DAUX1 & DAUX2

	LDA		#low SBUFF	; Set the sector buffer address
	STA		DBUFLO
	LDA		#high SBUFF
	STA		DBUFHI

	LDA		#READ			; Set command to read a sector.
	STA		DCOMND

	JSR	DSKINV
	
	LDA	DSTATS			; Save status
	CMP	#$01					; If status is $01, successsful, set it to $00
	BNE	SR15A
	LDA	#$00
SR15A
	STA	IOSTAT
	
	JMP	Z80RET


;	--------------------------------------------------------------------
;	WRITE SECTOR
;	--------------------------------------------------------------------
SR16:

	LDX		IODISK			; Store the disk drive number in DCB
	INX									; Increment as CP/M disk drive is zer based
	STX		DUNIT			
	
	;	Get the Sector number
	JSR		GTSCTR		; Get and calculate the sector number.  It will be in DCB DAUX1 & DAUX2

	LDA		#low SBUFF	; Set the sector buffer address
	STA		DBUFLO
	LDA		#high SBUFF
	STA		DBUFHI

	LDA		#WRITE			; Set command to write a sector.
	STA		DCOMND
	
	JSR	DSKINV
	
	LDA	DSTATS			; Save status

	CMP	#$01					; If status is $01, successsful, set it to $00 for CP/M
	BNE	SR16A
	LDA	#$00
SR16A
	STA	IOSTAT

	JMP	Z80RET

 

[ivop]

1 hour ago, reifsnyderb said:

All of the disk I/O is going through Atari's Resident Disk Handler.  What is odd is that I've been able to confirm that some of the writes are working.....but not all are working.

 

Here's the read/write code:

 

	JSR	DSKINV

 

Shouldn't that be JSR SIOV ? ($E459). You also need to set DBYTLO/HI to 128, and DSTATS data direction.

 

You could basically copy most of my code from CP/M-65:

Spoiler

zproc bios_READ
    lda #$40        ; data direction receive
    sta DSTATS
    lda #SIO_READ_SECTOR
    bne do_SIO
zendproc

zproc bios_WRITE
    lda #$80        ; data direction send
    sta DSTATS
    lda #SIO_WRITE_SECTOR

do_SIO:
    sta DCOMND
    lda #$31
    clc
    adc drive_number
    sta DDEVIC
    and #$0f
    sta DUNIT

    lda dma
    sta DBUFLO
    lda dma+1
    sta DBUFHI

    lda #128
    sta DBYTLO
    lda #0
    sta DBYTHI

    lda sector_num      ; Atari starts counting at sector 1
    clc
    adc #1
    sta DAUX1
    lda sector_num+1
    adc #0
    sta DAUX2

#ifdef ATARI_XL
    jsr SIOV_wrapper
#else
    jsr SIOV
#endif

    lda DSTATS
    cmp #1
    beq status_ok

    sec
    rts

status_ok:
    clc
    rts
zendproc
 

 

Edited April 21 by ivop

[reifsnyderb]

I could have done JSR SIOV.  But, I figured I'd use the resident disk handler as it's basically the same thing and requires fewer inputs.

Edited April 22 by reifsnyderb

[ivop]

23 minutes ago, reifsnyderb said:

I could have done JSR SIOV.  But, I figured I'd use the resident disk handler as it's basically the same thing and requires fewer inputs.

I see. I'd forgotten about that as I always use SIO directly. I just noticed a bug in my CP/M-65 code. DDEVIC always needs to be set to $31, and SIO adds DUNIT to it. Well, they don't support multiple drives yet, so it never failed

 

Back to your code. I assume write.com fails? After which command does it fail? (make_file, write_sequential, or close?)

 

[reifsnyderb]

14 minutes ago, ivop said:

I see. I'd forgotten about that as I always use SIO directly. I just noticed a bug in my CP/M-65 code. DDEVIC always needs to be set to $31, and SIO adds DUNIT to it. Well, they don't support multiple drives yet, so it never failed

 

Back to your code. I assume write.com fails? After which command does it fail? (make_file, write_sequential, or close?)

 

There is no consistent place it's been failing as it varies.  The only thing consistent is that the system gets farther along when the SIO speed is fast.

 

Edit to add:  It seems more reliable when I have the OS with the high speed SIO running.

 

Edit to add:

New code, so as to save some space....

 

;	--------------------------------------------------------------------
;	READ SECTOR
;	--------------------------------------------------------------------
SR15:

	LDA		#READ			; Set command to read a sector.
	STA		DCOMND

	BNE		SR16A

;	--------------------------------------------------------------------
;	WRITE SECTOR
;	--------------------------------------------------------------------
SR16:

	LDA		#WRITE			; Set command to write a sector.
	STA		DCOMND

SR16A:
	LDX		IODISK			; Store the disk drive number in DCB
	INX									; Increment as CP/M disk drive is zero based
	STX		DUNIT			
	
	;	Get the Sector number
	JSR		GTSCTR		; Get and calculate the sector number.  It will be in DCB DAUX1 & DAUX2

	LDA		#low SBUFF	; Set the sector buffer address
	STA		DBUFLO
	LDA		#high SBUFF
	STA		DBUFHI
	
	JSR	DSKINV
	
	LDX	DSTATS			; Get status

	CPX	#$01					; If status is $01, successsful, set it to $00 for CP/M
	BNE	SR16B
	DEX
SR16B
	STX	IOSTAT				; Save status

	JMP	Z80RET

 

Edited April 22 by reifsnyderb

[ivop]

13 minutes ago, reifsnyderb said:

There is no consistent place it's been failing as it varies.  The only thing consistent is that it the system gets farther along when the SIO speed is fast.

Could you make a sector copy to a real floppy and try that?

 

Edit: if you have only one real drive, you could boot from that, swap disks, and then press CTRL-C, assuming your CONIN routines passes along <32 characters.

 

Edited April 22 by ivop

[reifsnyderb]

1 minute ago, ivop said:

Could you make a sector copy to a real floppy and try that?

 

I think my sector copy programs only support SSSD. 

 

Are you thinking that respeqt could be the problem?  (The thought had occurred to me...)  I have other atr's I could try so as to see if respeqt is the problem.

[reifsnyderb]

Ok.  I just tried 3 other atr files.  I know these work fine with Altirra.  I am having similar problems with respeqt and the USB cable.  I don't know if it's respeqt, the cable, or something else.

 

[ivop]

5 minutes ago, reifsnyderb said:

Ok.  I just tried 3 other atr files.  I know these work fine with Altirra.  I am having similar problems with respeqt and the USB cable.  I don't know if it's respeqt, the cable, or something else.

That's disappointing. I just found this:

 

 

Perhaps reading works well enough (with retries?) to make a copy to a real floppy? It needs extended memory, but I assume that's not a problem with your 1090 memory expansion

 

[reifsnyderb]

16 minutes ago, ivop said:

That's disappointing. I just found this:

 

 

Perhaps reading works well enough (with retries?) to make a copy to a real floppy? It needs extended memory, but I assume that's not a problem with your 1090 memory expansion

 

Looking at the logs of respeqt, it doesn't usually give an indication of why it failed.  I don't know what sort of response it's given the Atari, either.  I also thought that the Atari automatically would do retries.  (I was thinking about adding retries, to the Atari IO code, but didn't as my thought is the retries are more for a failing disk and/or drive.)

 

I am thinking about trying the cable with the Windows 10 computer just to see if the cable is the problem.

 

 

 

 

[_The Doctor__]

For your sector copy use mydos, it should work fine.

As to RespeQT, you may have to pick a different edge timing in it's config depending on your port. (while this matters on a real RS232 port, it seems to affect USB timing ever so slightly as well.)

The sector copier is MTL at fault. What are you using?