ATN circuit and FTDI chips

[Don_Kirby]

I'm using an FTDI chip (FT232R) for a USB interface with a ZX-44. I haven't had any problems using the suggested ATN circuit. I haven't had any problems without the cicuit either. I'm wondering if it would be a bad idea to lose the NPN and associated passives, and just pull the reset high. In my limited testing, this hasen't had any ill effects, but I'm sure I'm not doing a very thorough job of testing.

-Don

[dkinzer]

I'm wondering if it would be a bad idea to lose the NPN and associated passives, and just pull the reset high.

The transistor is suggested primarily because it allows other signals to also effect a reset. It also "squares up" the capacitively-coupled reset signal from the DTR line.

If there are no other reset sources you can probably drive the reset input from the DTR output of the FT232, either directly or through a capacitor.

[mwf]

Could you explain what is going on with reset when preparing for a download? If you are cap coupled, does polarity really matter? Does the timing matter (yes, but what are the limits?) Howmany resets are needed? Do extra resets matter?

I want to download to more than one processor from one FT232R. The gpio pins on the FT232R would be used to select the processor I want to talk to and the others would be held in reset. Since I have to drive reset directly anyway can I just do whatever the transistor does with my reset signal?

[dkinzer]

Could you explain what is going on with reset when preparing for a download?

The ZX looks for a series of resets relatively close together. When the proper sequence is detected, the ZX enters a special command mode in which it responds to commands sent over the serial line, e.g. download.

The details: Each time a reset is received, if it has been less than 30 RTC ticks (about 50mS) since the last reset then the current reset is counted as an "ATN reset" and a counter is incremented. If the elapsed time between resets was greater than or equal to 30 RTC ticks, the current reset is deemed not an "ATN reset" and the ATN reset counter is cleared. Next, the device waits for a bit to allow more reset pulses to arrive. If the tick count gets to 50, it checks the accumulated count of ATN resets. If the count 3 or greater, the device enters the special command mode.

From the foregoing description, you can see that a minimum of 4 reset pulses are required with at least 30 ticks but no more than 50 ticks of inactive time between them. Additional reset pulses (within reason) have no negative effect as long as they are closely enough spaced. Clearly, the duty cycle of the reset pulses (at the chip) will affect the process since the device will not begin to execute until the reset input is brought high.

If you are cap coupled, does polarity really matter?

The capacitive coupling of the reset signal serves to minimize the effect of the duty cycle. The polarity matters only in that the ZX chip responds to an active low signal on its reset input.

[mwf]

"From the foregoing description, you can see that a minimum of 4 reset pulses are required with at least 30mS but no more than 50mS of inactive time between them."

I understand the 50ms limit, but not the 30ms minimum. Is that needed to do the counting? I take it that the times are how long the reset is not asserted and that the width of reset is unimportant.

Is there any limitation on timing between the resets and the first command from the PC? If not, I can do the resets in my PC code and then invoke the downloader, ignoring its pulses on DTR.

[dkinzer]

I understand the 50ms limit, but not the 30ms minimum. Is that needed to do the counting?

The 30-50 tick (not milliseconds) window and the count was chosen to reduce the likelihood that ordinary resets would not be mistaken for an ATN request.

I take it that the times are how long the reset is not asserted and that the width of reset is unimportant.

For practical purposes, this statement is true. To be more precise, when the processor starts running it executes an initialization sequence. Fairly early in this sequence it checks the RTC tick count to see how long the processor ran (after RTC initialization) prior to the most recent reset. If the tick count prior to the last reset exceeded 30, the current reset is counted as an ATN reset. Slightly later, the RTC is initialized and then the processor sits in a loop until the RTC has ticked 50 times (about 97 mS) to allow for additional ATN resets. If the tick count gets to 50 (i.e., no additional reset has occurred), the ATN reset count is cleared

Is there any limitation on timing between the resets and the first command from the PC? If not, I can do the resets in my PC code and then invoke the downloader, ignoring its pulses on DTR.

The following information can be gleaned from the downloader code but is summarized here for further clarification.

When the ZX enters the "command mode" it emits a prompt character (a greater than sign, 0x3e) indicating that it is ready to receive commands. The downloader looks for that response after performing the ATN sequence and before it begins sending commands. If the timing is such that the response is missed, it can be evoked again by sending an escape character (0x1b). This causes the ZX to clear its command buffer and emit the prompt character again.

Commands sent to the ZX consist of 1 or more characters terminated by a carriage return (0x0d) or line feed (0x0a). Each character sent is echoed back; the carriage return or line feed is echoed as a CR and a LF.

The 'L' command initiates a download. When the ZX enters download mode it sends an ACK character ('A', 0x41) to indicate that it is ready to receive Intel hex records. When a record is received, the ZX sends an ACK if the checksum was correct and it recognized the record type. Otherwise, it sends a NAK ('N', 0x4e).

A verification is performed in the same manner as a download except that the command 'V' is used (in place of 'L'). If any byte in the data portion of the record fails to verify, a NAK will be sent.

When downloading/verification is complete, execution is begun by resetting the processor.

Some special processing is required for the record type that contains the minimum ZX firmware version. Rather than sending this record to the ZX, the downloader can simply ignore the record (risking downloading code that won't run on the installed VM version) or it can compare the minimum version with previously retrieved VM version information.

You can get the ZX to send information including the VM version number by sending it the 'I' command. The response to this command (in addition to the echo of the command and CRLF) will be in the form:

Code: Select all

ZX24 v1.2.3\r\n0100,abcd

The portion preceding the \r\n (CRLF) indicates the ZX device and the VM version. The portion following the \r\n gives the hexadecimal values for the size of the program last downloaded and its CRC. Note that there is currently no trailing CRLF.

It should also be noted that the ZX device name may be more than four characters long (e.g. ZX24ae) but it will not contain a space and will always be followed by a space. This fact can be used to locate the beginning of the VM version string.

[mwf]

It sounds like the prudent thing to do is to force a reset to all but one ZX24, the one I want to download, and latch that state so the resets will be held even if the FT232 is reset itself. Then use DTR to do the resets on the ZX24 to be downloaded. Finally clear the reset latchs so all the ZX24s can run. I'd like to avoid rewriting the downloader.

[stevech]

The details: Each time a reset is received, if it has been less than 30 RTC ticks (about 50mS) since the last reset then the current reset is counted as an "ATN reset" and a counter is incremented. If the elapsed time between resets was greater than or equal to 30 RTC ticks, the current reset is deemed not an "ATN reset" and the ATN reset counter is cleared. Next, the device waits for a bit to allow more reset pulses to arrive. If the tick count gets to 50, it checks the accumulated count of ATN resets. If the count 3 or greater, the device enters the special command mode.

From the foregoing description, you can see that a minimum of 4 reset pulses are required with at least 30mS but no more than 50mS of inactive.

Suggestion: Add this explanation to the user manual. The new option on a Zload command line for period and duty cycle needs an explanation that the period cannot exceed the value discussed above (30 RTC ticks).