Ok so I’m using SX/B, which is BASIC for the SX. Even if you’ve never touched SX/B, it reads very easily, anyone who knows the PIC or other mcu should understand…..
Here’s the logic behind the code:
The main() of the program starts at “start_point” and runs to the end of the file.
Its job is to count the number of stored bits, and if more than 7 are stored, to notify the PC, put the byte on the port, and reset the “shifter” so a new byte of data can start. Very simple. It also waits for the PC to ACK the byte. Notice sh*t hits the fan if the PC hasn’t ack’d the old byte before the new byte is ready. This is OK because I’ve got the PC timing down to less than half of how long it takes the amiga to spit out a byte. See earlier posts on timing!!
The ISR is the other important port of the program. More happens here than in main.
My ISR can be triggered by two methods:
1. Falling-edge triggered by a negative-going 0-volt pulse. Ie a “1” from the drive
2. From a timeout that runs 1.5us from the last time the ISR was triggered, for any reason.
The ISR’s job is to first check to see what triggered it. Whenever the ISR was triggered by an edge, “processedge” is called.
Otherwise, it must have been due to an RTCC rollover timeout condition, and so the default handling is to process a “0.” First we see if we are idle, and if we are just seeing more idle-bits —- which would just be 5v high’s all the time, if so we just ignore and exit the ISR. If we aren’t idle(ie last bit was an edge), then we start storing “0”s into the shifter. exit the ISR.
Processedge simply turns off the idle condition and stores a “1” into the shifter. exit the ISR.
Very simple and elegant. I think.
Guaranteed that my problems are timing related, where the ISR has been triggered due to a timeout, and we miss an edge event. I spend a relatively long time in the ISR — but I think that my current approach is really the best — shortening the time spent in the ISR, where it would make a difference, is just not possible – given the current setup.
Missing an edge event is somewhat tragic because it does one of two things. It either adds extra zeros to the current ‘grouping’ of bits which corrupts the current data and shifts the next data,or it considers valid high-zero’s to be simply an idle condition — in which case we lose the next up to three bits.
See earlier timing discussions where I’ve ruled out other possibilities of problems….