The LC79401 chips are 80-bit-wide segment driver chips (4 of the '401 chips equals 320 pixels wide); the LC79430 are 80-bit-wide common driver chips (3 of the '430 chips equals 240 pixels high).
The row data is clocked on a 4-bit-wide serial bus. Look at the five traces entering IC4 that pass under the silk text "C12". These are the serial pixel data input for the row (CP, DI1, DI2, DI3, DI4) coming from the external interface connector. You can probably figure out how to drive this thing by using the LC79430 and LC79401 data sheets and tracing connections from the controller interface connector to the driver ICs on the board. It would be fun.
You could probably drive this thing with decently powerful microcontroller. It seems like you clock the pixel data for a row into the four LC79401 segment driver chips, which accept 4-bit wide serial input. You basically clock in the display data one row at a time to refresh the display. Because it's not a single serial input stream, but a 4-bit-wide serial input, you won't be able to use a regular single SPI peripheral on a microcontroller. I would first just prototype it using GPIO directly, and you could do this on basically any decent microcontroller. (It will take 9600 bytes to store the pixel data for the frame, so you'll have the simplest time if you choose a microcontroller with 16KB+ of RAM (in the long run you could do on-the-fly pixel data generation so you don't have to buffer the entire display if you want to optimize cost). Once you have prototyped the LCD controller using GPIO directly, you should be able to use an external bus interface with DMA to automate sending pixel data to the LCD and allow your microcontroller to be mostly freed up to do other work while the DMA controller drives data to refresh the LCD. The high-density STM32 microcontrollers have a flexible static memory controller (FSMC) that can do this type of thing (other microcontrollers have similar features).
Are you up for the challenge?