reifsnyderb

Make sure you check the output of the voltage regulators prior to installing any cards. I've had bad, brand new, voltage regulators.

Atari's Z-8 0 schematic showed that it should be possible for the Atari to send an interrupt to the Z-80. So, I kept that capability but forgot to take the Z-80 /M1 signal into account. If the Atari can send the Z-80 an interrupt, it would help with debugging Z-80 software as it would be possible for the interrupt to exit the Z-80 out of an endless loop or run a machine code monitor. I decided to run the /M1 signal to the output PLD. Picture of the back side of the Z-80 CP/M card. The short blue wire is added to support the Atari sending an interrupt to the Z-80. This line is the M1 line and should be high during normal I/O. M1 will be low when an interrupt is called. U22 is now programmed to take M1 into account when handling output from the Z-80 to the Atari. This connection has been added for the next version of the card.

They make smaller diameter capacitors that will fit. Because of differences in diameter, I ended up buying 2 sizes of the same capacitor.

First 1090XL Expansion Card Manual is now available... 1090 Expansion Card Instructions v01.pdf

Did you ever get a chance to test this?

Given what I've seen, when things do intermittently work, I think I've got the main parts working. Sometimes the write test almost completely works. Sometimes. I also started adding a system so you can interrupt the Z-80. The idea is that if you are working on a Z-80 program that hangs, that you could trigger an interrupt for debugging. I figure that control/shift/i would work. I set the CP/M BIOS to put the Z-80 in interrupt mode 2 so it will run the code at $0030. For now, $0030 would do nothing but do a warm start. However, it would be easy enough to jump to a monitor program, for example. That way somebody could check the memory to try to determine what happened. This came about because the Atari schematic showed that the Atari could lower the Z-80 interrupt line. So, I kept that functionality but didn't know what I'd do with it when I designed the card. But it would be useful for debugging purposes.

Ok. I've got one of these coming: https://www.ebay.com/itm/175793498479 It may be here by April 30th. Another week long delay to see if I really got this thing working. <sigh>

More troubleshooting. It could be a bad cable. I pulled off the shrink tubing and found a resistor wasn't connected. Re-flowing the solder connections isn't helping yet, either. <sigh>

I believe it's supposed to be the newest version. It also crashes if the log gets too full. (I have to delete the log file.) I just tried RI and DTR. There's no extra check box. I guess I'll have to contact JoSch. I guess the most frustrating part is that I've wasted a lot of time trying to troubleshoot this with the assumption respeqt was a known good.

These are the options I have.... Experimentation shows... 1. DSR is the handshake method that is used. 2. I haven't noticed a different with the DTR Control Enable 3. The High speed mode baud rate seems to work fine. 4. A non-standard speed, with a low POKEY divisor, results in the program crashing 5. Keeping the delay at 250us seems to be the trick. There's no check box for the edge timing. I just discovered that if the system pauses, and I wait for 10 or more seconds, it may eventually continue. I never tried waiting so long when it quit working. Even so, when testing for writes, it clearly completely failed.

Where do I set this timing at?

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.

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.

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.

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