[sebhc] Tape recovery

[Dave Dunfield]

Hi Steven,

Thanks for the suggestions.

>>PAM-8 can load the tapes fine - but I read the Tape status port ($F9) and
>>test the RX-READY bit (02 mask) and I never see a data indication. I have
>>initialized the ports EXACTLY the way PAM-8 does (I patched the emulator to
>>record all I/O events and looked to see exactly what PAM-8 does) ... but I
>>still cannot see any data

>Two guesses .. PAM-8 inits the port immediately after a hard reset .. 
>sending the init sequence again may have unexpected results.   Try just 
>doing I/O in your program assuming the port is already set up.

I thought of this, and tried two approachs:

1) I did the whole long initialization:
   - Write dummy command word with out RESET to insure you are not in command state
   - Write command word with RESET bit set to insure software reset
   - Write mode word
   - Write operating command word

   I also added an I/O trace to the emulator, and looked at EXACTLY what PAM-8
   does - It writes the mode word out of reset, but not a command word. The
   command word gets written when you invoke the Load or Dump function.

   I tried this same approach - let PAM-8 write the mode word, and then write
   the command word in my code. I verified under the emulator that the values
   written to the UART are exactly the same (and no extra ones)

   Still no joy - I don't see what is going wrong. As noted in my orignal email,
   it works on the emulator. Ie: If I mount a file as input, the program does
   read it and dump to the console - since the emulator uses only the addresses
   and bit of the load/dump 8251, it suggests the program "logically" works
   (and yes, the emulators implementation works with PAM-8).

   It appears that something is blocking the Cassette data before it hits the
   Uart - I'm going to drag out the scope sometime this weekend and look directly
   and the RxD and RxC pins to see what it happening.

>Another idea I had was that perhaps in the process of getting your program 
>in, an interrupt vector got installed and was still live, and the interrupt 
>service routine is stealing the caracters before you can see them.

Nope - verified this one too - There is no interrupt enabled on the load/dump
uart, and there are no vectors set up (yes, I checked). I even tried running
the program with interrupts disabled (which kills the front panel, so I know
they are indeed disabled) - Still no joy.

Will dig into it more when I get some time. Gotta pressing hardware/manufacturing
problem with one of my main products, so I'm going to be tied up for the next few
days. (Also gotta PDP rescue happening this weekend, so it's going to be busy :-)

Regards,
Dave
-- 
dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Vintage computing equipment collector.
                http://www.parse.com/~ddunfield/museum/index.html

--
Delivered by the SEBHC Mailing List