diff options
Diffstat (limited to 'src/emu/cpu/tms9900/tms9900.h')
-rw-r--r-- | src/emu/cpu/tms9900/tms9900.h | 157 |
1 files changed, 44 insertions, 113 deletions
diff --git a/src/emu/cpu/tms9900/tms9900.h b/src/emu/cpu/tms9900/tms9900.h index 0e21c0ccf71..07a5f72d4b2 100644 --- a/src/emu/cpu/tms9900/tms9900.h +++ b/src/emu/cpu/tms9900/tms9900.h @@ -6,41 +6,6 @@ behaviour. See tms9900.c for documentation - - Types of TMS99xx processors: - TI990/9 Early implementation, used in a few real-world applications, 1974 - very similar to mapper-less 990/10 and tms9900, but the Load - process is different - - TI990/10 Original multi-chip implementation for minicomputer systems, 1975 - - TI990/12 Multi-chip implementation, faster than 990/10. Huge instruction set - - TMS9900 Mono-chip implementation, 1976. Used in the TI-99/4(A) computer. - - TMS9940 Microcontroller with 2kb ROM, 128b RAM, decrementer, CRU bus, 1979 - - TMS9980 8-bit variant of tms9900. Two distinct chips actually : tms9980a - and tms9981 with an extra clock and simplified power supply - - TMS9985 9940 with 8kb ROM, 256b RAM, and a 8-bit external bus, c. 1978 (never released) - - TMS9989 Improved 9980, used in military hardware. - - SBP68689 Improved 9989, built as an ASIC as 9989 was running scarce - - TMS9995 TMS9985-like, with many improvements (but no ROM). Used in the - TI-99/8 prototype and the Geneve computer. - - TMS99000 Improved mono-chip implementation, meant to replace 990/10, 1981 - TMS99105 This chip is available in several variants which are similar - TMS99110 but emulate additional instructions, thanks to the so-called - macrostore feature. - - In this implementation we only consider TMS9900, 9980, and 9995. The - remaining types are implemented on an own code base as they introduce - significant changes (e.g. privileged mode, address mapper). For now we - leave the implementation of the rest up to 99xxcore.h. */ #ifndef __TMS9900_H__ @@ -48,21 +13,13 @@ #include "emu.h" #include "debugger.h" +#include "tms99com.h" -/* - Define symbols for interrupt lines. - - We use a separate RESET signal which is not captured by the core. - - Caution: Check irqline in set_input_line of each driver using this CPU. - Values have changed. Use these symbols instead. -*/ enum { - INPUT_LINE_99XX_RESET = 0, - INPUT_LINE_99XX_INTREQ = 1, - INPUT_LINE_99XX_INT1 = 2, - INPUT_LINE_99XX_INT4 = 3 + INT_9900_RESET = 0, + INT_9900_LOAD = 1, + INT_9900_INTREQ = 2 }; enum @@ -71,35 +28,6 @@ enum RESET_INT = -2 }; -enum -{ - TI990_10_ID = 1, - TMS9900_ID = 3, - TMS9940_ID = 4, - TMS9980_ID = 5, - TMS9985_ID = 6, - TMS9989_ID = 7, - TMS9995_ID = 9, - TMS99000_ID = 10, - TMS99105A_ID = 11, - TMS99110A_ID = 12 -}; - -#define MCFG_TMS99xx_ADD(_tag, _device, _clock, _prgmap, _iomap, _config) \ - MCFG_DEVICE_ADD(_tag, _device, _clock) \ - MCFG_DEVICE_PROGRAM_MAP(_prgmap) \ - MCFG_DEVICE_IO_MAP(_iomap) \ - MCFG_DEVICE_CONFIG(_config) - -enum -{ - IDLE_OP = 2, - RSET_OP = 3, - CKOF_OP = 5, - CKON_OP = 6, - LREX_OP = 7 -}; - static const char opname[][5] = { "ILL ", "A ", "AB ", "ABS ", "AI ", "ANDI", "B ", "BL ", "BLWP", "C ", "CI ", "CB ", "CKOF", "CKON", "CLR ", "COC ", "CZC ", "DEC ", "DECT", "DIV ", @@ -148,6 +76,8 @@ protected: virtual void device_stop(); virtual void device_reset(); + virtual void resolve_lines(); + // device_execute_interface overrides virtual UINT32 execute_min_cycles() const; virtual UINT32 execute_max_cycles() const; @@ -225,8 +155,8 @@ protected: bool m_irq_state; bool m_reset; - // Determine the interrupt level using the IC0-IC2/3 lines - virtual int get_intlevel(int state); + // Determine the interrupt level using the IC0-IC3 lines + int get_intlevel(int state); // Interrupt level as acquired from input lines (TMS9900: IC0-IC3, TMS9980: IC0-IC2) // We assume all values right-justified, i.e. TMS9980 also counts up by one @@ -235,6 +165,19 @@ protected: // Used to display the number of consumed cycles in the log. int m_first_cycle; + /************************************************************************/ + + // Clock output. This is not a pin of the TMS9900 because the TMS9900 + // needs an external clock, and usually one of those external lines is + // used for this purpose. + devcb_resolved_write_line m_clock_out_line; + + // Wait output. When asserted (high), the CPU is in a wait state. + devcb_resolved_write_line m_wait_line; + + // HOLD Acknowledge line. When asserted (high), the CPU is in HOLD state. + devcb_resolved_write_line m_holda_line; + // Signal to the outside world that we are now getting an instruction devcb_resolved_write_line m_iaq_line; @@ -244,6 +187,29 @@ protected: // DBIN line. When asserted (high), the CPU has disabled the data bus output buffers. devcb_resolved_write_line m_dbin_line; + // Trigger external operation. This is achieved by putting a special value in + // the most significant three bits of the address bus (TMS9995: data bus) and + // pulsing the CRUCLK line. + // Accordingly, we have + // + // A0 A1 A2 A3 A4 A5 ... A12 A13 A14 A15 + // 0 0 0 x x x x x x - normal CRU access + // 0 1 0 x x x x x x - IDLE + // 0 1 1 x x x x x x - RSET + // 1 0 1 x x x x x x - CKON + // 1 1 0 x x x x x x - CKOF + // 1 1 1 x x x x x x - LREX + // + // so the TMS9900 can only use CRU addresses 0 - 1ffe for CRU operations. + // By moving these three bits to the data bus, the TMS9995 can allow for the + // full range 0000-fffe for its CRU operations. + // + // We could realize this via the CRU access as well, but the data bus access + // is not that simple to emulate. For the sake of homogenity between the + // chip emulations we use a dedicated callback. + devcb_resolved_write8 m_external_operation; + + private: // Indicates if this is a byte-oriented command inline bool byte_operation(); @@ -425,41 +391,6 @@ private: inline void set_status_bit(int bit, bool state); inline void compare_and_set_lae(UINT16 value1, UINT16 value2); void set_status_parity(UINT8 value); - - /************************************************************************/ - - // Trigger external operation. This is achieved by putting a special value in - // the most significant three bits of the address bus (TMS9995: data bus) and - // pulsing the CRUCLK line. - // Accordingly, we have - // - // A0 A1 A2 A3 A4 A5 ... A12 A13 A14 A15 - // 0 0 0 x x x x x x - normal CRU access - // 0 1 0 x x x x x x - IDLE - // 0 1 1 x x x x x x - RSET - // 1 0 1 x x x x x x - CKON - // 1 1 0 x x x x x x - CKOF - // 1 1 1 x x x x x x - LREX - // - // so the TMS9900 can only use CRU addresses 0 - 1ffe for CRU operations. - // By moving these three bits to the data bus, the TMS9995 can allow for the - // full range 0000-fffe for its CRU operations. - // - // We could realize this via the CRU access as well, but the data bus access - // is not that simple to emulate. For the sake of homogenity between the - // chip emulations we use a dedicated callback. - devcb_resolved_write8 m_external_operation; - - // Clock output. This is not a pin of the TMS9900 because the TMS9900 - // needs an external clock, and usually one of those external lines is - // used for this purpose. - devcb_resolved_write_line m_clock_out_line; - - // Wait output. When asserted (high), the CPU is in a wait state. - devcb_resolved_write_line m_wait_line; - - // HOLD Acknowledge line. When asserted (high), the CPU is in HOLD state. - devcb_resolved_write_line m_holda_line; }; /*****************************************************************************/ |