Stuart

Shush! I was going to do that self-publishing stuff and sell him a hard copy for £50 ...

Looks like ... https://archive.org/search.php?query=tms9900 ... is a useful page to bookmark.

TMS 9900 Family System Development Manual (Application Report) (https://archive.org/details/bitsavers_tiTMS9900MstemDevelopmentManual1977_4482262/mode/2up). Contains many of the diagrams used in the "how-to-build-your-own-working-16-bit-microcomputer.pdf" book. 9900 Family Systems Design and Data Book. A hefty tome, but most of it covered in the other 9900 data books. TM 990/100M User's Guide (www.bitsavers.org\components\ti\TMS9900\tm990-100\1602000-9701_TM990_100M_Users_Guide_Dec78.pdf). This is a manual for a single board computer which contains full schematics and circuit descriptions. May be of interest. Hard copies for this or the /101 module come up on eBay occasionally.

Presumably the chips used for the 8<>16 bit data bus multiplexer. Wouldn't be needed for the 8-bit external data bus 9985.

Personally I'd start by replacing the two MCM6810 RAMs, but you need at least some level of soldering skills to do it.

The 9918 outputs colour composite on a single pin. The 9928/29 outputs video on three pins - luminance (the 'black and white') on one, and colour difference on the other two - and these are combined into a single colour video signal in the (external) PAL UHF modulator. There are some links on the board that you set according to the VDP in use. So with a 9929 plugged into a board set up for a 9918, you're only getting the luminance signal, with no colour information.

How about ... JNE JMP1 C @>0000, @>0002 'Set EQ to not equal. JMP JMP2 JMP1 C R0,R0 'Set EQ to equal. JMP2 ... Or ... XXX EQU >2000 STST R1 CZC @XXX,R1

So you've set the switches such that you can write to the 8K RAM and read the same data back? Worth checking the supply voltage on pin 28 of the 48T08 when its plugged in and the computer's on. If it's less than ~4.75V then the device goes into write protect mode where you also can't read from it (but the normal 8K RAM would still work). The supply voltage is going to be less than the computer +5V supply anyway due to the diode in the battery backup circuit. If the voltage is low, might be worth just bending pin 28 out of the socket and connecting direct to +5V on the PCB and see if it then works.

I've heard it referred to as "Never Twice Same Color". Didn't you US guys have a knob on the side of the TV to adjust the colour as colour shifts are really noticeable on skin tones? Never a problem for us Brits with PAL, as the phase reversal of the signal every other line cancels out any errors. It was (is) rather clever how the engineers overlaid the colour information on the black and white signal so that black and white receivers continued to work with the colour signal.

Looks similar to what I done, but just for the low and high memory areas. With your solution, might want to add a DIP switch and pullup resistors on your new U2A/B inputs so you can simply switch blocks in and out as you experiment?

There are a couple of mentions of the SR70 in the "Interviews with old TI employees" thread.

Did you ever get anywhere with this @FarmerPotato? I've just added a TMS9901-40 to my TMS99110 board (running at 4 MHz) and it works fine, in terms of programming the 9901 clock for 250ms level-3 interrupts. Just wired it in the same way as the 9902, and fed /INTREQ and IC0 - IC3 to the CPU.

This is the sort of thing that any disassembler will have problems with, as alluded to above: 06A0 BL @LOADER Load VDP registers. 2426 0280 BYTE >02,>80+R0 Graphics 2 mode, external video off. 8081 BYTE >80,>80+R1 16K, no display, no interrupt, graphics 2, size & mag=0. 0682 BYTE >06,>80+R2 PNTBA=>1800. Screen image table. FF83 BYTE >FF,>80+R3 CTBA=>2000. Colour table. 0384 BYTE >03,>80+R4 PGTBA=>0000. Pattern descriptor table. 3685 BYTE >36,>80+R5 SNTBA=>1B00. Sprite name table. 0786 BYTE >07,>80+R6 SPGBA=>3800. Sprite pattern generator (descriptor) table. 0087 BDCOL BYTE >00,>80+R7 Backdrop=background colour. 0000 DATA 0 04C6 CLR R6 Write nulls to VRAM. 0207 LI R7,VRAMW The LOADER routine advances the BL return address over those bytes of data, but a disassembler won't know that, and will deliciously disassemble the two words after BL @LOADER as CI R0,>8081, then (I think) a BL R2, and so on.

I like on page 3 "Game about a presidential election". I wonder if such a game would have considered the current reality a bit far fetched? Page 9 - "Something to get the wife involved." Page 9 again - "Medical emergency remedies First Aid etc" on cassette. "Will you just bleed quietly for a moment dear while I load this program ..." Quite surprised how many of the users are wanting to use the computer for business or technical stuff rather than just games - assembly language stuff, cypher & data compression, home energy control, statistics, financial stuff, ...

Anyone else get an error trying to open the PDF?

Before *each and every* call to DSRLNK, you need to put a pointer to the PAB name length field in >8356 (MOV @PABADR9,@>8356 or similar). I can't see that you do this, and *may* be the cause of the error.

JED2EQN is part of National Semiconductor's OPALjr package which you can download from [http://www.brouhaha.com/~eric/retrocomputing/mmi/palasm/opaljr21.zip]. I got the link from this page: [https://www.uchobby.com/index.php/2008/03/30/gals-for-electronics-hobby/]. I use the OPALjr package (EQN2JED) to compile the GAL for the Mini Cortex. You need to either run it on an old DOS computer, or I use DOSBox under Windows. You only need to extract the DEVICE.LIB, EQN2JED.EXE (or JED2EQN.EXE) and MANUAL.TXT files from the zip file - you don't need to use the installer. Just tried JED2EQN with a .jed file I had set up to clone a 74LS138 - wasn't entirely successful as it said the /Y0 output was connected to GND ...

Just be careful that you're not calling routine "1" which saves R11 to SAVRTN, which then calls routine "2" which saves *its* R11 to SAVRTN. Routine "2" will return as intended, but routine "1" will then return to the same place that routine "2" returned to ...

Mike, I'm not sure why you've got every routine wrapped in a "MOV R11,@SAVRTN" and "MOV @SAVRTN,R11". You only need those if the routine actually modifies R11 - including making another BL call from within the routine.

Or increase it in size to 32-bit?

The 9918 has been rotated 180 degrees on the QI board, so anything might have happened ...

There's no sign of them having burnt? Good catch! The +5V rail provides about 1A, so R9 and R10 between them need to dissipate around 5W. 3W 0.56 Ohm resistors are readily available - do a bit of Googling and see what will physically fit. Looking at the photo of the 99/4 PSU on the Mainbyte site, that has those resistors with colour codes and they are 5%. If you measure the voltage at U3 pin 2, does that come up to 5V immediately? The delay is just due to C15 charging through the high resistance R9 and R10?

For the transistors, I'd just get replacements and see if it fixes the problem. Personally (but I'm no expert), I'd try replacing in order: -- Q1 and Q2 -- C15 -- D9 and D10 -- U3 -- C11 and C13 I would think the resistors are OK unless they are visibly damaged.

Check the output of U4 pin 2 (which may be an oscillating signal - not sure). Does this signal change over the period it takes the 5V rail to come up? If yes the problem likely to be in the components around U4. If no, problem likely to be in components around U3.

We don't know how such a routine would be used and how big the data blocks might be of course, but might there be scope to leave the data where it is and maintain a pointer to the data? Or maybe a linked list of pointers (and data lengths) for a block of data split into sub-blocks?