Block Transfer Engine

•  
  2011-05-01 Published this page.
•  
  2010-09-17 Started this page (not published)

• Programming Information
• • Register File
  • Normal Usage
  • Special Features
  • Caveats
• Board description
• • Data Bus Separation
  • Logic Implementation
  • Layout description
• Driver
• • Simple test suite
• Board Revisions
• • 2.1C (ok)
  • 2.1B (working, but API with bugs)
  • 2.1A (prototype)
  • 1.0B (not working)

This section describes how the block transfer engine is programmed.

Register File

The blitter uses a 16-byte address space in the I/O area. The two address options are $EF60 and $E860. Here is the register file:

Note that registers are not initialized on reset. The reserved registers must be set (for future compatibility), but cannot be read.

Normal Usage

To transfer a block of continous data from one memory area to the next, do:

1. Set the LDADDR to the first address of the source memory block
2. Set the STADDR to the first address of the target memory block
3. Set the LDINC and STINC to 1
4. Set the CNT to the number of bytes to transfer minus 1
5. Set the control bits in register 15 - writing to this register starts the process. For normal transfer set the register to $0c to use /MEMSEL, and don't set the CARRY and Complement bits

The address values are incremented directly after the transfer. I.e. after the transfer the address points to the address after the memory block.

The increment value is decremented after the transfer. The transfer stops when an underflow occurs in this process. I.e. after the transfer the CNT register holds $FF.

As the maximum number of bytes to transfer is 256 (by writing 255 into CNT), to transfer more data, multiple transfers have to be used. The registers are updated such that just writing to register 15 multiple times transfer multiple contiguous blocks.

Special Features

Here are some special features:

• Reverse Transfer: If you want to transfer data in reverse order, i.e. from a high address to a low address, you can use the Complement bits in the control register 15. For example to use an offset of minus one (-1), you need to set the INC register with $FF, and also set the corresponding Complement bit COMPL in the control register. This leads to an added offset of $FFFFF, which actually is like substracting one. By using a positive offset in one address and a negative offset in the other address, you can reverse the order of the data bytes in a memory block
• 256 byte INC offset: The INC register can only hold values up to 255. To implement a transfer that takes a byte off of each page - i.e. with an offset of 256 byte - the CARRY control register bits can be used. The carry is used in the appropriate addition of the INC value to the address. Thus when the INC register is set to 255, and the carry is set, an offset of 256 is used for the transfer.
• I/O DMA: The blitter can also be used to implement data transfer from an I/O address to memory and vice versa. Using a /IOSEL with an INC value of zero (and carry not set) in the load setup reads each byte from the same I/O address.

Caveats

There are some caveats when using the blitter:

• The block transfer is not interruptible. I.e. you possibly introduce a latency of about 512 cycles (256 bytes max transfer, one load and one store each).
• The blitter stops the bus with the RDY signal. This means that this signal is not available for a device to signal lower speed to the blitter. I.e. memory or I/O devices that use RDY cannot be used with the blitter.
• The blitter uses physical addresses on the CS/A bus. The CPU normally sees address locations translated by the CPU's memory management unit. This translation from virtual to physical addresses must be done explicitely when programming the blitter.

In the How it works page the principles of operation are described. Here I'll describe some of the implementation details (of the V2 board).

Data Bus Separation

In the principle description the CPU data bus is connected to the INBUS drivers, the increment registers, the increment data buffer, and - not shown there - to the input as well as output of the data transfer register (where the transferred data is kept). This would put a lot of load on the actual CPU data bus. Therefore I added IC15, a data bus driver that separates the actual CPU data bus from the board data bus.

Logic Implementation

The system actually only uses a few bits of "state" if you don't count the address and increment registers. It must know if it is active, and when active it needs to know which operation it is doing - fetch or store. This state is defined in the signals /ACTIVE and FETCH/-STORE. In the 2.0 version these bits were determined by some RS-Flipflops, and all other logic was derived from that and implemented in two PAL chips. But my PAL burner is not that reliable and I had a Xilinx 9536 CPLD around, so I decided to move everything into the CPLD - which is shown in the 2.1 version. Unfortunately the CPLD is about a few lines short of being able to include all the logic. So some small parts are still implemented as inverters and AND gates.

Note that the 2.1 board contains some "PIN" pads, to be able to easily use the remaining logic gates even though these chips are SMD...

Layout description

If you look at the layout, it is dominated by a five-by-four array of SOW20 chips with some smaller chips to the right. These implement the INBUS, OUTBUS and Increment busses as follows:

The first row of chips implements the Increment bus, with two '574 as increment value registers for fetch and store. Then there is IC24 ('245) to read out the increment bus, and IC23 ('245) to feed a zero increment into the adder.

To the right of that comes IC32 ('245) and IC25/IC28 (both '193) that implement the transfer counter.

The next three rows of ICs implement the address bits 0-7, 8-15 and 16-19 respectively, including their part of the INBUS and OUTBUS busses. From left to right First comes the address drivers that are used to drive the OUTBUS to the CPU address bus. Then there are the two '574 that hold the fetch and store address values; then there is the data bus driver, connecting the INBUS with the CPU data bus. The right-most 20-pin chip is the ALU output driver, that drives the adder output onto the INBUS. The smaller chips to the right are '293 4-bit adders, implementing the actually "ALU" adder.