This device seems to go by more than one name. The datasheet I'm looking at now says S6B0108

I get the impression that S6B0108 may refer to the bare chip version, and KS0108B the packaged QFP100 version?

The device is usually used in conjunction with another device KS0107B, one IC drives rows the other columns, but as the KS0107B is controlled by hard-wiring and has no accessible control registers it is usually not of interest to a programmer. One pin of the KS0107B, SHL, sets the direction of the internal shift register and could potentially be used to flip the display contents upside down but I have never seen this implemented. For any hardware hackers who want to try it is pin39 of a 100 pin package. Your mileage may vary.

There may be rotated display configurations but the most common one appears to be using the KS0107 to drive 64 rows, and using one or more KS0108 to drive 64 columns per device to produce sizes of 64*64, 128*64, 192*64. A 320*128 configuration is possible using two 107s and ten 108s (with the display split into two grids) but the chip select mapping for 10 devices would be complicated and a display of that size would be expected to use a single more powerful controller instead.

Like most small LCD controllers it has a busy time, during which it cannot accept further commands except "busy check". Unlike the HD44780 it is not immediately clear from documentation how long the busy time is, however as it lacks an inbuilt clear function all commands are executed quickly and probably in the same time.

A controller that did implement a "clear display" command would almost certainly have to implement a counter to step through all of the memory in order to clear it. This would be expected to take longer than a single byte write.

Calculating the busy period

The datasheet states that a 1/64 duty display (64 row) should have a clock of 250kHz (the RC clock on mine measures at 500kHz but I think it gets divided down) and the documented longest busy period is given as 3/fclk which is 3*(clock period) or 12us.

I would assume a 20% tolerance on the clock and pad that to 15us, however unless you are using memory mapping or a really fast CPU it is hard to exceed that except for special cases such as byte-read. It is also hard to execute a busy check fast enough to have the display return busy more than once so I believe that a fixed delay is a reasonable alternative to polling.

Another interesting note is that BUSY is not latched, it will change state mid-read. This means it is possible to raise E and wait for DB7 to change state instead of having to cycle E repeatedly. The datasheet graph contradicts this though, implying that the DB7 state will be stable after TD, so it may not be totally reliable and clones of the controller may require cycling of E in order to detect end of BUSY.

Busy period special cases

A write operation is typically preceeded by a function call and some calculation.

The write operations immediately after reset may be "inline" and lacking the inherent delay, so without busy check some padding delay may be needed there.

A read operation requires a dummy read followed by the actual read. These are usually coded inline, fast, and will need a delay in between.

Instruction set

For some reason in the instruction set documentation "Y" denotes horizontal position and "X" vertical. I don't know why, Memory organization is that bits in a byte are arranged vertically, then addresses count horizontally forming a 64*8 line. The address does not roll over to the next line.

Display Start Line allows you to smoothly scroll the display contents by a number of pixels. counting 0-63 makes the display roll up, 63-0 down. Positions 0,8,16,24,32,40,48,56 will correspond to display "pages" or 8 bit high lines.