Issues with 5 1/4" drives and the Versafloppy II

[JNZ]

I don't know who's following this thread (and in what detail), but by doing the above modifications and by making my VCO for the PLL loop on my VFII match the other board (rather than following the adjustment procedure in the manual) I was able to make my board talk to my drives! It now produces identical input and output when I read/write from a disk! Hoorah! I intend to use the code in the VFII diagnostic as a guideline for making GETSYS and PUTSYS programs, and to then write my own BIOS for CP/M.

 

[JNZ]

Here's an interesting tidbit that tripped me up for hours and hours. I couldn't for the life of me figure out why my console output code wasn't working. It was behaving as if it wasn't waiting for the transmit buffer to be empty, even though I literally copied and pasted the same code from another program, where it worked fine. The code is:

; siost is the status register, and sioda is data

co:
    ;console output (arrive with character in c)
    in	a,(siost)		
    and	a,01h		
    jr	z,co
    ld	a,c
    out	(sioda),a

    ret

I wrote this code in the VFII diagnostic program and copied it over for a GETSYS program I'm writing. It worked just fine when I compiled it in the diagnostic program.

Well, it turns out that the line

and a,01h

assembled into the correct opcode E6byte in the previous program only because I used ZASMB on CP/M (which is a fairly buggy assembler). For this new program I was using z80asm, which interpreted that line as

and a

which is opcode A7. The register A anded with A can't be relied on to set the Z flag in this case, and thus the code would never wait for the transmit buffer to be empty.

The correct code is, of course:

and 01h

which ands A with 0x01, the mask for checking the transmit status bit.

This isn't the first bug that's tripped me up in ZASMB, and hopefully I won't need to use that compiler anymore.

 

[JNZ]

During all this debugging I also got tired of constantly standing up and resetting my computer when my code made it lock up. I wrote a dead-simple program for the ATMega328p that waits for "r" on the serial interface and drives two pins in a timed sequence, which stops the CPU, toggles reset, then starts the CPU.

r
Stopping CPU (pin 2 low)
Resetting (pin 3 low)
Starting CPU (pin 2 and 3 high)
Done

Clearly it's just hacked together, but any engineering solution that helps me be lazier is a win.

 

[tingo]

Assembler, not compiler.
Otherwise - you are doing well, nice progress! I'm reading with interest.