ATF750

Entry posted by supercat August 17, 2006

1,674 views

Well, I've got the logic worked out for a "universal" PLD for the AtariAge/CPUWIZ boards using an Atmel ATF750B. The chip is pin-compatible with the 20V8/22V10 which is handy. In a lot of ways I'm not too keen about the design of the chip or the software, though.

The chip is basically positioned as a 22V10 superset. Each output pin (there are ten) has the same set of product terms as on a 22V10, but they're split into two groups. One group feeds a flipflop; the other group feeds, either by itself or "ored" with the first group, into a second flipflop. Either the input or output of the second flipflop may drive the pin; the signal from the pin and the outputs of the two flipflops are fed into the logic array.

Although any of the flipflops may be clocked directly from pin 1 (as on a 22V10), each has a product term that may be used instead (with a slight extra propagation delay). Each also has an independent asynchronous reset chip. There is a global synchronous preset product term, but there's no way to exclude any latches from its effects (which makes it rather useless). Product terms that are not used for these functions are not available for other uses.

Although there are occasions when it's useful to have a pin generate a combinatorial output but have its flipflop fed back into the logic array, it is, to put it mildly, irksome that there's no easy way to have buried asynchronous logic. The separate asynchronous clock and reset functions allow for latched signals to trigger at interesting times, but avoiding race conditions can be a challenge.

Incidentally, while the lack of any buried combinatorial feedback terms is generally a nuisance, having the flipflop on the output of a combinatorial pin can sometimes be useful. Atmel warns that slow-changing clock signals may cause clocks to register multiple times, possibly causing nastiness. My solution in this case it to use the register associated with my "clock output" signal to generate a cleaned-up "clock input" signal.

  cko = (list of "interesting memory accesses");
 cko.ckmux = clk;
 cko.ar = !cko & !clk;

When ana interesting memory access occurs, the CKO pin (pin 22) will go high. This is fed through an RC circuit into CLK on pin 1. When CKO is high, a rising edge of CLK will cause the flipflop behind CKO to go high as well. Even if CLK bounces low and high a few more times, however, the latched signal on CKO will remain high. It will only go low after CKO has gone low and CLK has followed suit.

Unfortunately, the simulator seems to be quite useless at dealing with product-term clocks. Even when I run with maximum verbosity and the simulator shows the clock on a flipflop changing while the data pin is high and asynchronous reset is inactive, nothing happens. So I'll have to do things by hand. Grr...

For my mega-PLD, I've decided to support six banking modes, plus a "boot mode" which on powerup locks the cart into bank 1 until addresses $1FFC and $1FFD are accessed consecutively, whereupon the cart will proceed into F4 mode (starting in bank 1). To switch into another mode, the code must access address $0ACE followed immediately by an address which determines the following mode:

$0CCC -- Mode 0 (boot mode--not sure why one would do this)
$0CCD -- Mode 1 (F4)
$0CCE -- Mode 2 (F8)
$0CCF -- Mode 3 (F6)
$0CDC -- Mode 4 (Parker Brothers)
$0CDD -- Mode 5 (no banking allowed--use to put multiple 4K games on a multicart)
$0CDE -- Mode 6 (new EE banking)

Note that all of those locations map into RIOT RAM, so a cart can switch modes by copying code to RAM and then executing it. I would consider it extremely unlikely that the mode-switch sequence could occur by mistake even though it's always active.

The new EE mode is a cross between F4 and E0 modes. The top 2K of address space banks into one of eight 2K pages, and the bottom 2K banks into a different set of eight 2K pages. There are six sets of hotspots:

0068-006F -- Select lower bank
0510-05FF (bit 4 set) -- Select lower bank using A5-A7
0070-0077 -- Select upper bank
0610-06FF (bit 4 set) -- Select upper bank using A5-A7
0078-007F -- Select both banks
0710-07FF (bit 4 set) -- Select both banks using A5-A7

The $0500-$07FF hotspots are designed so that if code is compiled using "rorg" values of $1000 for the first bank, $3000 for the next, etc. up to $FFFF, the MSB of a code address can be used to select the appropriate bank. For example, if a routine will always be invoked with the stack pointer at $FF, the return code may do something like:

  ldx $FF; MSB of return address
 nop $700,x; Set both banks for return address
 rts

The programmer would have to keep track of whether to set one or both banks, but there's no need for funny bitshifting or conditional logic.

The other set of bankswitch locations is there to save a cycle on bankswitching. I don't really know whether that's apt to be particularly useful, but since it fit I figured I may as well.

Anyone have any comments on the proposal?