I have some stupid virus, so here are some notes on architecture for the next version. Good job I wrote tests.
- serial_ula_tick() to be polled at 1/13 MHz from 6502.c, implementing TXC and RXC into ACIA. Two tick events required per cycle of TXC, as 0.5 bit-periods of TDRE delay will need to be generated. Clock rates > 1/26 MHz (38.4 KHz) will need to be fudged somehow. Clearing the blipped DCD line after the appropriate time (~1uS IIRC) needs to happen in here also;
- replace existing acia_poll() with orthogonal acia_poll_rx() and acia_poll_tx(); _tx() must be called at double TXC rate. Music 2000 will be impacted;
- ACIA bitwise I/O to be brought under this _rx() / _tx() umbrella; right now this code is ad-hoc and probably in tape.c rather than acia.c. Re-interface, so bits are shifted in and out by _rx() and _tx(). Any pipelining for correct CFS duplicated-CRC behaviours in MOS 1.2 and 0.1 needs to go in here too. Figure out what should happen if clients of acia.c prefer to do bytewise I/O rather than bitwise (Music 2000, probably). Bits to/from _rx() and _tx() will also need to be converted to/from 1200ths of tone as presented by the three tape format back-ends. This should probably be in serial.c. For transmit, bits -> 1200ths must work down to 75 baud. Fudging will be required for TXC and RXC > 1200 Hz for both rx and tx. 19200 baud decoding of a carefully-crafted 2400/1200 stream possible on hardware?
- TDRE processing also needs to occur under acia_poll_tx();
- tape overclocking perhaps should work by simulating a faster divider in either ULA or ACIA, and then fudging the bits <-> 1200ths routine.
Statistics: Posted by Diminished — Fri Dec 06, 2024 10:58 am