I'm using an essentially unmodified version of the PIC firmware that I developed for the Atom interface. It's written in C and is structured in such a way that the business end of things can be lifted out and driven by an emulator instead of actual interface hardware. This is invaluable for debugging client code - especially when a stupid error might mean a 2 minute delay while a tape loads...
Anyway, they say a picture speaks a thousand words so here's my 1K ...
This directory listing is the output of the following code running under the MESS emulator with my interface firmware jammed in at the appropriate point:
Code: Select all
; init directory reader
;
ld b,2 ; directory control
ld l,0 ; 0 = reset directory reader
ld c,7
out (c),l
call response
call expect_3f ; error if != $3f
getdirent:
ld b,2 ; directory control
ld l,1 ; 1 = get next directory entry
ld c,7
out (c),l
call response
cp $3f
jr z,gotentry ; $3f = continue
cp $40
jr z,alldone ; $40 = finished
call expect_3f ; error if != $3f
alldone:
ret
gotentry:
ld b,6 ; acquire data control
ld l,$3f ; 3f = reset data reader
ld c,7
out (c),l
jr readentry
printchar:
rst 10h
readentry:
in a,(c) ; collect a character from the filename
jr nz,printchar
ld a,$76 ; print a newline
rst 10h
jr getdirent
response:
; mustn't change BC contents
ld l,0 ; delay loop setting
rsp_delay:
dec l
jr nz,rsp_delay
in a,(c) ; get response code
jp m,rsp_delay ; and loop whilst negative
ret
expect_3f
cp $3f
jr nz,exp_itsbad
ret
exp_itsbad:
sub $41-10
rst 08h
It's important to have code working in the emulator. It means that when I run this program on the actual hardware tomorrow I can concentrate on working out where the hardware needs tweaking instead of battling against 2 unknowns...