FarmerPotato

Very! The 990/12 had 64 bit wide microcode for the 481s. Soldered in. I think I see the 1481 with ten sockets? So 80-bit wide. Plus that daughter card... The 1481 is a 9900 built from TTL. Not necessarily the TMS9900 but definitely a family member. With the 1481 microcode ROMs, you'd have a crucial tool to make a 9900 simulator at the silicon level. @mizapf Plenty of difficulties, but maybe Texas Instruments made it fairly close to a documented architecture. I've made notes on what I found so far.

OMG that is a bunch of SE9996 chips, and one marked TMX9996! Im interested in chips--a SBP 9900 and 9989 are exciting. Ceramic 9900 because it's beautiful. And some 9996. I was pondering whether to sacrifice one to get decapped. Check if an XDS has had its SE9996 pulled. If either XDS is the 9995 emulator, I'm very interested. (99105 would be priceless.) (You should bring one online!) Any system really besides the 34010 I've got. Yeah, they are heavy. About 40 lbs. I hesitate to ask for just a set of cards sent overseas, but I think you could repurpose the chassis to TM990. I'm interested in any XDS manuals, but I feel first that they should stay with the matching XDS box. The TM990/1481 is an incredible gem. At the same time I see this board in the 1982 price list, the 74S481 bit-slice chips that it uses (4 of) were not for sale. The Microprocessor Systems book shows it NRD. I would dearly like to study that 1481, and dump the microcode ROMs. It's going to be close kin to the 990/12. That said, I've got a 990/12 to study, and I bet someone else would enjoy it.

It's just too many ideas. I've been interested in the 340 since I came across its Font Library booklet. Maybe by 2030 I could add it to Geneve 2020... Incidentally, I was looking at the MVP a week ago. Pretty sure it is the upcoming chip Karl Guttag described in the 1992 Delphi transcript. I read the Hot Chips presentation. It is way, way overkill for retro. https://old.hotchips.org/wp-content/uploads/hc_archives/hc05/3_Tue/HC05.S5/HC05.5.2-Guttag-TI-MVP.pdf

The bits for the 9901 at 0000. keyboard, joystick, interrupts 1 and 2. Setting the 9901 to Timer mode. RS232 Bits, by usual name for 9902, at 1340/1380. Parallel at 1300. This is tricky but perhaps someone can ( @TheBF!) can highlight the important ones. Format for tables of CRU: By base and bit offset ( the address would go up by 2s where offset goes by 1s) Base 1340 ie LI R12,>1340 Bit offset N for SBO N SBZ N Base 1340 Addr Offset 1340. 0 1342. 1 1344. 2 etc

I've traced out most of the 9996 pin connections. A hypothesis --the die is rotated vs the 9995-- helped guess and prove MEMEN. I've used this to narrow down where to look for other pins, but several like RESET, NMI, HOLD, READY are probably all wired to VCC without even a resistor. Where the 9995 has pins INT1, INT4, I find the full set of 9900 signals. The code uses interrupt levels 1, 2, and 5. 7-15 immediately RTWP. The others go to RESET. SE9996 CPU at U60 1 MEMEN* 2 NMI or RESET? 3 same 4 5 ?VCC, or READY? 6 7 A15 (MSB. TI A0) 8 A14 9 A13 10 A12 11 A11 12 A10 13 A9 14 A8 15 A7 16 A6 17 A5 18 A4 19 GND 20 A3 21 A2 22 A1 (LSB. TI A14) 23 CRUOUT (maybe A15 if used) 24 XTAL 25 XTAL 26 unknown. CLKOUT? 27 28 D0 (LSB. TI D15) 29 D1 30 D2 31 D3 32 D4 -- 33 D5 34 D6 35 D7 36 D8 37 D9 38 D10 39 D11 40 D12 41 D13 42 D14 43 D15 (MSB. TI D0) 44 GND or ? 45 GND or ? 46 IC3 (from 9901) 47 IC2 48 IC1 49 IC0 50 INTREQ* (from 9901) 51 52 53 CRUCLK 54 55 56 to PAL 57 58 to PAL 59 VCC or ? 60 61 62 RD* 63 VCC or guess HOLD 64 WE* The PAL at U71 has: 1 ? 2 ? 3 MEMEN* 4 RD* 5 CPU 56 6 CPU 58 7 CRUCLK 8 CRUOUT/A0 9 CPU A15 10 GND -- 11 CPU A14 12 Enable U62,63 13 14 EPROM A13 15 16 Enable RAM U69 17 Enable RAM U65 18 19 20 VCC The story here is that the PAL is able to translate the top 2 address bits from the CPU. It also produces two signals to enable the RAM upper/lower bits. There are two 27C512 EPROMs for total 128K ROM. The lower 13 address bits A12:0 are driven by CPU A13:1, so the page size is 8Kx16. (4 pages fill a 64Kx8 address space.) The next EPROM bit A13 is driven by PAL U71-14. The A14 bit goes to a jumper. There's A15 yet to be traced. The jumper goes between either VCC or something else (not GND.) So the EPROM may hold two jumper-selected variations of the software. There are two 6264 RAM making 8Kx16. The RAM have separate enable signals out of the PAL. I speculate that CPU 56 and 58 may indicate upper or lower byte access. I know from disassembly: 0000-3FFE resident ROM 4000-7FFE mostly data 8000- ? probably memory-mapped devices like the two TMS9650s (256x16 memory) C000-Exxx must be RAM. There are several tables of address pointers that support this. I traced out two '138s decoding CRU access using A11:6. A15-13 (MSB) are 000 for CRU, else the external instruction code A12 - have not traced A11:6 are decoded in the 138s along with MEMEN A5:1 go to CRU devices such as 9901 A0 - not part of CRU address, it's CRUOUT data. I have not figured out CRUIN - doesn't seem to go directly from 9901 to the CPU.

Wow! So much to look at! #1 The last 8085 board has a NEC 765 floppy controller and two 34-pin connectors look like 5.25" floppy. Could be a 50-pin cable for 8" floppy. #2 The 9995 emulator has some features I recognize from my XDS/22 boards. The "pod" on a 2x2x40 cable that would go to a 9995 socket. (looks like extra GND in between all 40 wires) Row of fast AM9128 RAMs (70ns) for trace data Row of even faster cache RAM (45ns) next to it Weird though: if this is a single board emulator/trace module, how do you use/connect to it? With all the 1981 chips (but 1985 CPUs?) it's closer to the AMPL generation. In my XDS/22 the BTT (breakpoint-trace-timing) module has the 2x2x40 connector. I dunno what for, since it's a separate card from the emulator (emulator provides the external CPU pod.) Clearly some family heritage between these boards.

Did not see the card cage! I saw the prototyping card last week though. Nice! Unrelated, radiodad has this connector sample pack! It's all the common PC ports circa 1999. I would have appreciated this set, instead of shopping for a few of each from China. Then again, peconnectors.com (Phoenix) is also an awesome source. Getting the T bus connectors are another story (I bought four, 2x50 solder tail, on eBay). https://www.ebay.com/itm/256425520074

There's a thread about this somewhere here. It has the display device protocol in it--for the one that Texas Instruments had working. I found a cheap (<$20) VFD display. Futaba brand, I think. 40x4. Chars are 5x7 dots. Usual ASCII characters and 7 ? Slots for user-defined chars. Interface by I2C or SPI (just send it 8 bits for a char.) Thought that would be a nice upgrade. *VFD=Vacuum Fluorescent Display, what we had on VCRs before blue LEDs. (hate blue LEDs.) Speak n Spell type.

Oh, it's both horizontal and vertical travel. Horizon isn't fixed. Would it have to be a contiguous row? Address calculation gets messier-- MOV R3,R0 Row SLA R0,5 MPY by 32 A R3,R0 A R3,R0 But I guess you would be refreshing the whole table in one go, so VDPWA is set once. For scrolling, I made TL2 into four screens, so the refresh portion is always off-screen. TL1 scrolls half the speed so I allocated just 64x30 & refresh off screen.

(5 years ago, yikes) I tried a BML to mask out the bottom 3-4 rows of the screen. TL1 and TL2 were scrolling (different speeds) for a parallax effect. I wanted a fixed status display at the bottom. (The old "scrolling window" feature was gone.) BML would cover ties 21-24. Row 21 would be solid BML to hide partial tiles. Tiles to be erased after scrolling 8 pixels. I would draw status into BML for rows 22-24. With a 256x32 bitmap, 2 bits per pixel, I got a very confusing result. (Hardware F18A, recent firmware.) Probably my error, but to clarify-- Is there a way for the BML to mask both TL1 and TL2? Sprites aren't an issue.

It's the same package. The GUI runs the command line tools to compile. You can type the commands yourself. The WinCUPL GUI has the most bugs around reading/writing files and refreshing the screen. It gets stuck complaining about something you can't see. (Then it crashes.) The Winsim simulator GUJ is also bad at showing you changes to the screen. I just rely on the text files.

The readily available chip is the ATF22V10. GAL is not made in the last 10 years. ATF22V10 is erasable. It can functionally replace the old PAL/GAL chips (unless its faster speed is a problem.) I starting using them with the TL-866-II, to combine 3-4 separate logic chips. You should get the DIP-24. So far I use the PLCC-28 (for this you need an adapter on the T-48 or 56.) After adding a PLCC socket, you don't save any board space vs DIP-24. The thru-hole PLCC sockets make routing awful, so I now use the surface mount sockets. Plenty of trouble there. There is also an SOIC-24, which I will use when my design is final. So you should try the DIP-24. The WinCUPL software is a horrible experience. I've learned its bugs, and I can get my parts programmed. But the command line tools work fine on Windows, it's the GUI that should be avoided (Windows XP era). The examples with WinCUPL are a decent introduction. I learned from the barrel shifter example. Most others are not for the 22V10. There are old very good CUPL tutorials out there. I can share more info & examples.

The XDS/22 EPROMs are 128K of 9995 assembly and data. Parts of it may be 34010 assembly. It contains a full debugger, trace viewer, and assembler for the 34010. Initial disassembly using xda99. I started with the first 16K of code. The second 16K looks to be text and data. I went line-by-line through some XOPs. XOP 1 - print string (it's reentrant!), XOP 5 - print char XOP 12 - test bit XOP 13 - recurse in BLWP I'm learning things from this code. XOP 1 - Print String - PRT$ XOP 1 begins with: LST R15 This has the effect of restoring the bits that would be cleared/set when the XOP took effect. In particular, it clears the X in progress bit, so that XOP 1 can call XOP 5 (print char). Special chars 80-9f in the string represent a run of 1 to 31 spaces. (bug: 0 is 65536) Special chars a0-bf in the string will embed another string. The lower 5 bits and the following char 8 bits make an address offset. Special chars c0-df will return from the embedded string. STR1 TEXT 'HELLO. MY SERIAL NUMBER IS ' OFFSET EQU STR2-$ BYTE STR2/256+>A0,OFFSET-(OFFSET/256*256) BYTE '.',>0D,>0A,0 STR2 TEXT '719619' BYTE >c0 The offset can be positive 0 to 1fff. The current string position is pushed onto a stack. Processing continues at the new string. Special chars e0-ff work the same as a0-bf (top 3 bits masked off) XOP 5 - Print Character - PRTC does what it says XOP 12 - BTST followed by address Test a bit of the word pointed to by address and sets EQ. The bit number is given as the operand of XOP. XOP 4,12 DATA >c000 tests bit 4 of the word at >c000 (the operand address R11, minus R13, gives an offset into a table 8000,4000, 2000 etc) This is a neat trick--using the source field as a 4-bit constant. XOP 13 Using the workspace of XOP13 instead, re-enter some BLWP. Allows one-level recursion in a BLWP.

I know, my first ones were like that. I like that the scanner flatbed can be used on objects that aren't quite flat. Thanks for showing these! I see more similarity on the 9996 side, EPROM/SRAM, and the Cypress fast SRAM too. But the 320C25 support is specific to that. Yours has another board full of termination resistors, between the PCB and the probe pod. I would love to compare the EPROMS. See what is reused--probably the XOPs. So far, I've disassembled & commented some XOPs. Separate thread.

Ooh that last book is tasty. VDP Programmers Guide!

Cookie say "square root is a vegetable."

EPROMs dumped. They are two 27C512 64Kx8, supplying even byte and odd byte. I combined them into one 128Kx8 file. Disassembly begins. From here on, I'll use byte offsets into the image. There are four 32K banks in there. The first bank, 0000-7ffe (bytes), has some blank space at the end. The second bank, 8000-FFFE (bytes), starts with 1K of zeroes. Lots of string data in this bank. The string's full address (like ef7a) is given to XOP 1. I'm calling that PRINT. The string prompts indicate a full featured loader, debugger , and an assembler for 34010 code. Speculation: Logical Address map: 0000-03fe is not paged. 0400-7ffe might be paged. (EDIT: the PAL operates on the top 2 address bits, so a page is 8Kx16. In bytes, 16K of the 64K address space.) 8000-bffe is the 16K static RAM. workspaces are here, around 8200. c000-ffff Guess: RAM or memory mapped ports. At reset , c000 is checked for a magic word before jumping into an initialization routine. Three cases branch out: >dead zeroes a cru bit, then does init >babe skips part of the initialization otherwise, init: zero some other bit and initialize stuff. Speculate that c000 is not RAM, perhaps it's a latch, or the 9650 dual port chips. I also see a 74ALS870 near the 34010. This is a dual port register file, 16x4 bits. Interesting.

The above photos are JPG-- less contrast on the traces than the uncompressed TIFF. I'm labeling the traces on my TIFF. I've followed the 16-bit data bus from the two EPROMs to 9996. Identified /DBIN. Infer that A0 on CPU goes into a PAL, outputs to EPROM A0. So the 27C512 is banked. Starting to look like a 9995 die rotated 180 degrees. Metal traces use right angles. Traces fear and avoid being drilled at thru holes. I see tiny spurs branch off as traces route around a thru hole. Or, I infer a connection because otherwise pin is NC.

What is the name for this PCB process? Someone described it in a recent Pandemic club zoom. Was it resin-on-metal? It looks great.

Added more photos above

I've unpacked the XDS/22 system and photographed the cards inside. There are 4 slots on the "hybrid" backplane. These have two card edge sockets. The socket on the right has fewer than 100 pins. Those traces go into unpopulated, 2x50, T-bus headers of slots 5-7. BTT - breakpoint/trace/timing module. Emulator - card with TMS34010 graphics chip. (empty) Interface - supports up to 3 RS232 ports. The BTT card is cabled to a pod labeled "Logic Show" having 4x20 gold pins. The Emulator card has a heavy shielded cable, ending in a probe to connect to your card's (empty) 34010 socket. It also has a cable with female DB9. Maybe a serial port? The interface card goes into the "hybrid" bus edge connector of slot 4. It has only a few chips, including one TMS9902, but has footprints for two more 9902s. In fact the PCB is completely filled by unpopulated footprints. The card has 3 top connectors, with cables to 3 of the RS232 DB-25 ports back side of the XDS/22. I guess that my card operates port D, described as Host Computer. (Ports A, B, C were intended for another terminal, printer, PROM programmer, or another XDS/22.) Slots 5-7 were advertised as T-Bus (TM990 bus), but the 100-position edge connectors are not populated. I see that the "hybrid" bus traces mostly go straight into this T-bus. The XDS/33 would have used the T-Bus slots for the XMPL package: 5. TM990/103 User interface. (with a TMS99105 CPU.) 6. TM990/233 XMPL Program Memory 7. (empty) Photos (Epson Flatbed Scanner 1200 dpi) BTT (Breakpoint/Trace/Timing) Card Interface Card 34010 Emulator with SE9996 (TMS9995 in DIP64 with 16-bit data bus brought out) ... more photos coming ... References Bitsavers SPND0001A Texas Instruments TMS7000 Family Data Manual 1983 Bitsavers SCJ1271 Texas Instruments XDS22 TMS320C2x Emulator Users Guide 1988.pdf

I received two XDS/22 development stations. Inside, I see 3 cards. The BTT (Breakpoint/Trace/Timing) card has a 7742 microcontroller.

For $30, I would expect at least a rare AOL disk in fair condition.

Matthew is someone who would know 🙂 I figured something else while looking at the data sheet today. (wow what a nerd-snipe this has been.) The state transitions in a DRAM access cycle--RAS falling, rising, write asserted, CAS falling, rising--they happen on intervals much smaller than the 21.477 MHz clock can produce. So those synchronized events must come from an analog delay line. "Tap points" in a squiggly labyrinth where the signal emerges with different delays. That's my meager understanding. I'm not sure that is something you could switch in or out with a digital control bit. (The 4A used some extra gates to apply a nudge to memory timing.)

It's just speculation until someone tests the hypothesis. But even if tests show different DRAM timing, it's of no use unless the V9958 somehow frees more access slots for CPU access. Folks have documented, in excruciating detail, the exact way the 9938 allocates memory access slots among CPU ports, reading scan line data, and compositing sprites. There are many reasons why it would not matter if DRAM had faster access time: 1. Memory cycles are documented in the manual. I'm not aware of any 16K/64K distinction--anything? 2. Even shaving 50 ns off an access, the 9938 is on a rigid schedule for access slots. I expect the order of slots would be unchanged. 3. The manual states that the use of the 16K/64K bit is to optimize refresh cycles. Different DRAM require 4ms or 2ms between refresh. So the manual covers how to get a full refresh in 2ms for the 16K chips-- (I'm still puzzled by those schematics.)