Stuart

I'm not familiar with DU2K - does it just report whether there is a valid FDC header? Testing using the MiniMem will (a) test whether the card can be enabled (LED lights) and (b) shows you what (if any) data is being read from the DSR space - irrespective of whether that data represents a valid DSR header or not. If you can read data from the DSR space but it is not the correct data, that might help track down the problem, like a shorted data line.

If you've got a Minimem cartridge you can use EasyBug to enable the FDC card and check the DSR. Select EasyBug from the title menu screen then at the '?' prompt type C1100<Return>1<Return>(LED on card should now be on)<full stop>M4000<Return><Space><Space><Space><Space><Space><Space>... should read out the start of the DSR as >AA, >02, >00, >00, >40, >44 ,,, Do you get that?

The black cylinders are ferrite rings; they help stop interference on the power supply between different parts of the circuit. The wire goes straight through the middle of them. I've just measured the current drawn by a NanoPEB when modified to be powered through the side port: ~75mA 'at rest', rising to ~85mA when accessing the CF card. I've had mine connected through the speech synth for an hour or so and no smell of burning in the console or molten copper traces dripping out the bottom.

Looking at Thierry's pages, the normal load-and-run process calls the loader to load your code then calls the linker to run the program. If you do autorun, it is the loader that runs the program - the linker is not used. The linker sets up some stuff in the VDP (to give the green screen) and *maybe* also sets some stuff that GPLLNK relies on. If you don't go through the linker, GPLLNK won't work.

Yes, it looks as if the BLWP @GPLLNK is returning to the E/A. Comment out that line and the DATA line and it autostarts (meaning it doesn't return to E/A, just sits there in the continual loop in the code).

Enabling interrupts seems to be the key as people have suggested. Page 312 of the E/A manual says that interrupts need to be enabled "to start processing sound operation". No mention about this in the GPLLNK section covering the bad and accept tone responses. I had a little play with the code below. Without the LIMI 2 and LIMI 0 in the loop, the tone starts but never ends. With the LIMI's, the tone plays for 1/2 a second or so as expected. BUT I couldn't get the code to autorun from the E/A option 3 to test - what am I doing wrong? DEF START REF GPLLNK START LWPI WS CLR R1 MOVB R1,@>837C BLWP @GPLLNK DATA >0034 ACCEPT TONE. LI R2,>FFFF LOOP1 LIMI 2 LIMI 0 DEC R2 JNE LOOP1 JMP START WS BSS 32 WORKSPACE. END START

Does your code auto-run after loading? If so, GPLLNK apparently doesn't work (so maybe nothing to do with the CRU address?). But anyway, easy enough to play a tone using code from Thierry at [http://www.unige.ch/medecine/nouspikel/ti99/tms9919.htm#Programming]. The bad response tone is middle A - not sure what the accept tone is. The code I use is: 45 * Play middle "A" note on generator 1. 46 47 LI R0,>8E0F Frequency on generator 1. 48 MOVB R0,@>8400 Sound port address. 49 SWPB R0 50 MOVB R0,@>8400 51 LI R0,>9000 Volume: maximum. 52 MOVB R0,@>8400 53 54 * Delay for approx. 1/2 second. 55 56 LI R0,>4000 57 BDR1 DEC R0 58 JNE BDR1 59 60 * Turn sound off. 61 62 LI R0,>9F00 63 MOVB R0,@>8400

An idea ... if you load the "Text to Speech" software into Classic99 and run it, you should be able to find where it writes to the Speech Synth (at address >9400?). Then patch the code so it writes to a block of RAM instead, then dump that data.

Some of the older consoles used the shielding for a heatsink on the TIM9904 clock chip as well.

When putting together my sideport EPROM programmer which co-exists with a CF7+ on a Y cable, I found that the CF7+ was pulling the CRUIN line high when the CF7+ was not being accessed, so nothing else could pull it low so you couldn't read over the CRU bus from another device. Cutting the track to pin 33 on the CF7+ and inserting a 1K resistor sorted it. I told Jaime about it and not sure if he fixed it for the nanoPEB. Might explain the problems with other PEB cards with the CF7 on a Y cable?

Are we on the way to "-ioport:sideportsplitter(union(peb:slot8:hfdc:h1),(peb:slot2:rs232))"?

If you can't find the equations ... as you presumably have a circuit schematic you know what signals are connected to the PAL/GAL inputs and outputs. Should be fairly straightforward to knock up an adaptor to exercise the inputs and see how the outputs respond, and reverse engineer the equations from that.

That's exactly it as far as I recall. One of the VDP tables overlaps the character definition table, so all the character definitions have been shifted up in the table, so to display the pattern for character "A" you need to print the character ASC("A")+>60 (or whatever the offset is).

Matt, have you got a copy of the "Interface Standard & Design Guide for TI-99/4A Peripherals" book by Tony Lewis? That covers DSRs and has some circuit bits as well - you'd probably find it interesting. Not sure where you got a copy from though - I believe it's still available so probably no scanned copies around. Someone else may chip in if they know where you can get a copy from. Stuart.

If you look at Thierry's page for the Horizon Ramdisk [http://www.nouspikel.com/ti99/titechpages.htm] that shows the schematic for the DSR RAM as well as the ramdisk RAM. Should give you a place to start, although you should be able to simplify things considerably. Looks like you'll need something like: -- 74LS138 to decode the CRU address for your 'card'. -- 74LS259 to latch a 'card enabled/disabled' CRU bit. -- Your EPROM. -- 74LS245 data buffer. -- Miscellaneous logic gates and other components.

Contact him via http://www.cozx.com/dpitts/ti990.html - e-mail address at the bottom of the page. Have you tried asking your wife, see how much she thinks it's worth?

Try a 74HCT245 (HC*T*). The logic levels for the HC range aren't directly compatible with the 74LS/TTL chips used everywhere else, but the HCT range is.

I always assumed that the 9995 uses a 4-phase 3MHz clock generated from the 12MHz crystal - they've in effect incorporated the TIM9904 clock generator onto the processor die. Phase 3 of the clock is brought externally as CLKOUT, in a similar way to Phi 3 being the only clock phase used by external components in a 9900 system.

>> Stuart, is there a way to maybe software disable/enable the joystick i2c interface, so that a program can keep the keyboard working, and maybe even the joystick working? << I'm sure with a bit more tinkering this could be done. Might need a bit more on the hardware side as well. >> I had thought you could not control both joystick drives at the same time, though...? Or did you build the hardware such that it wouldn't be necessary to? << I use one of the joystick drives for the clock, and for the data I use the joystick UP input which conveniently goes to one of the pins on the TMS9901 that you can use as either an input or an output. It's normally an input for scanning the keyboard and joysticks, but I use it as an output. Need to (software) reset the 9901 before it can be used as an input for scanning the keyboard again though. >> Any chance of implementing reads? << They work already (but didn't need them for the LCD display). Just need to set SDA high so the slave can pull it low, then a CRU Test Bit command on the relevant pin on the 9901. >> Also multi byte transfers would be great. << Yep, no problem with those. Just need the device-specific code to make multiple calls to the I2C write/read byte routine. >> Does the lcd module (PCF8574?) not send an ack bit after sending the slave address? << It does. With the I2C protocol, the slave sends an Ack(nowledge) bit after the slave address and each 8-bit transfer. So the master needs to send 9 clock pulses for each byte, with the last clock pulse for the Ack bit from the slave. I can see the LCD slave doing that on the 'scope but I just don't bother testing for it.

Some of you might have heard of an "I2C" interface - "I Squared C" or "Inter-Integrated Circuit". The ICs in your old VCR would have used it to communicate with each other, and your digital STB likely uses it internally as well. Devices with an I2C interface are getting popular in the hobbyist market also because that is also one of the interfaces that comes as standard on the Raspberry Pi and Arduino. There are loads of types of I2C device available - LED drivers, LCD drivers, serial memory (RAM and EEPROM), clocks, analogue-to-digital converters, digital-to-analogue converters, and so on. Electrically, the interface is very simple - just two wires plus ground. One wire is for a clock (SCL) and the other is for serial data (SDA). When writing to a 'slave' device, the 'master' drives both the clock and the data lines. When reading from a slave device, the master controls the clock line and the slave drives the data line. Multiple devices can be connected to the clock and data lines. Each device has a unique address, and the master sends the address of the device to access before reading or writing data to it. The clock frequency is very flexible - most devices have an upper limit of about 100 kHz, and anything below that is OK. So how can we use this on the TI? Well the joystick port has two lines we can control individually, and we can feed the data line back in through a third pin to sense its state. All we need is a 74LS06 inverter and two pullup resistors hooked onto the joystick port and we're all set to go. (I connected a pair of LEDs to help with debugging as well). You'll need a +5V power supply as well. You won't be able to use the console keyboard scanning routine while using the I2C interface as that will send out some spurious signals over the interface (you actually need the interface powered down or disconnected for the keyboard to be read properly), but you could probably write a bespoke keyboard scanning routine that scans just certain keys on the keyboard matrix rows/columns that aren't connected to the joystick port. Oh - Alpha Lock needs to be up as well! Software wise, the code needs to be able to control pins on the joystick port directly over the CRU interface, so that means assembly code. It should be possible for an XB program (for example) to pass data to/from the assembly routines. Cortex BASIC should also work as that includes instructions to control the CRU interface. The routines fall into two groups: (1) Routines that provide raw control of the I2C interface - send the start sequence, send the I2C device address, send (or read) a byte, and send the stop sequence. These routines will be common to any type of I2C device being controlled. (2) Routines that determine the actual bytes to send or receive according to the I2C device type. So for a serial memory device you would need to send one or more bytes specifying the memory address to access, then read or write the contents of that address. For a clock device you would need to send bytes to set or read dd-mm-yy and hh:mm. For a simple proof of concept, I've connected up a 20 character by 4 four line LCD display with an I2C interface - £7.00 on eBay. The LCD display itself has a parallel interface but comes with an I2C interface 'backboard' already soldered on that performs the serial I2C interface to parallel conversion. The code I've used to display a message on this is below. To prove it all works, photo below. Stuart. ===================== DEF START SCL EQU 19 CRU BIT FOR SCL SIGNAL. SDA EQU 31 CRU BIT FOR SDA SIGNAL. START LWPI WS LOAD WORKSPACE. LIMI 0 DISABLE ALL INTERRUPTS. *CONFIGURE TMS9901. CLR R12 9901 CRU BASE ADDRESS. SBO 20 SET 9901 P4 HIGH TO SELECT DEMUX 1 IN U302. SBZ 18 SET 9901 P2 (A) LOW ... *TO CONTROL SCL: *- SBO SCL TO SET SCL HIGH *- SBZ SCL TO SET SCL LOW *TO CONTROL SDA: *- SBO SDA TO SET SDA HIGH *- SBZ SDA TO SET SDA LOW *SET INITIAL CONDITION, WITH SCL AND SDA BOTH HIGH. SBO SCL SBO SDA BL @DELAY1 *INITIALISE POINTER TO ADDRESS/DATA TO SEND. LI R4,I2CDAT *SEND START SEQUENCE - SDA LOW, SCL REMAINS HIGH. SBZ SDA BL @DELAY1 *SEND I2C DEVICE ADDRESS. MOVB *R4+,R9 GET ADDRESS INTO MSB OF R9. BL @SNDBYT SEND ADDRESS. *SEND COMMANDS AND DATA. *HAVE TO SEND TO LCD DISPLAY AS TWO GROUPS OF 4 BITS, *WITH CONTROL SIGNALS ALSO SET APPROPRIATELY. *THIS SECTION OF CODE IS SPECIFIC TO THE TYPE OF I2C DEVICE *BEING CONTROLLED. LI R7,>0800 RIGHT NIBBLE CONTAINS DATA FOR LCD CONTROL PINS. CLR R6 COUNTER FOR THE 6 LCD INIT COMMANDS. GETBYT MOVB *R4+,R2 GET DATA INTO MSB OF R2. CB R2,@BFF >FF TERMINATOR CHARACTER? JEQ STOP YES, JUMP. * DO LEFT NIBBLE. MOVB R2,R5 MAKE COPY OF ORIGINAL DATA BYTE. ANDI R5,>F000 SET ALL BITS OF RIGHT NIBBLE TO 0. SOC R7,R5 SET BACKLIGHT ON, RS, R/W, E ALL LOW. MOV R5,R8 COPY BYTE. MOV R5,R9 BL @SNDBYT ORI R5,>0400 SET E HIGH. MOV R5,R9 BL @SNDBYT MOV R8,R9 SET E LOW AGAIN. BL @SNDBYT * DO RIGHT NIBBLE. MOVB R2,R5 COPY ORIGINAL DATA BYTE AGAIN. SLA R5,4 SHIFT RIGHT NIBBLE TO LEFT NIBBLE. ANDI R5,>F000 SET ALL BITS OF RIGHT NIBBLE TO 0. SOC R7,R5 SET BACKLIGHT ON, RS, R/W, E ALL LOW. MOV R5,R8 COPY BYTE. MOV R5,R9 BL @SNDBYT ORI R5,>0400 SET E HIGH. MOV R5,R9 BL @SNDBYT MOV R8,R9 SET E LOW AGAIN. BL @SNDBYT INC R6 INCREMENT COUNT OF LCD INIT COMMANDS TO SEND. CI R6,6 DONE ALL 6? JNE GETBYT NO, DO NEXT BYTE. AI R7,>0100 CHANGE TO SET RS HIGH. JMP GETBYT DO NEXT BYTE. *SEND STOP SEQUENCE - SDA TAKEN HIGH WHEN SCL ALREADY HIGH. STOP SBZ SCL SET SCL LOW. BL @DELAY2 WAIT 1/2 CLOCK PERIOD. SBZ SDA SET SDA LOW AGAIN AFTER ACK BIT. BL @DELAY2 WAIT 1/2 CLOCK PERIOD. SBO SCL SET CLOCK HIGH. BL @DELAY1 WAIT 1 CLOCK PERIOD. SBO SDA SET SDA HIGH. FINISH JMP FINISH * *SEND BYTE IN MSB OF R9. *R9 IS DESTROYED. * SNDBYT MOV R11,@SAVR11 SAVE RETURN ADDRESS. LI R3,8 LOAD BIT COUNTER. SBITS SLA R9,1 SHIFT MSb OF BYTE INTO CARRY STATUS BIT. JOC CARRY1 MOV @SBZ31,@SETSDA NO CARRY - WRITE OP-CODE TO ROUTINE BELOW. JMP CARRY2 CARRY1 MOV @SBO31,@SETSDA CARRY - WRITE OP-CODE TO ROUTINE BELOW. CARRY2 SBZ SCL SET SCL LOW. BL @DELAY2 WAIT 1/2 CLOCK PERIOD. SETSDA DATA >0000 SET SDA - OP-CODE WRITTEN ABOVE. BL @DELAY2 WAIT 1/2 CLOCK PERIOD. SBO SCL SET SCL HIGH. BL @DELAY1 WAIT 1 CLOCK PERIOD. DEC R3 INCREMENT BIT COUNTER. JNE SBITS LOOP UNTIL ALL BITS DONE. SBZ SCL SET CLOCK LOW. BL @DELAY2 WAIT 1/2 CLOCK PERIOD. SBO SDA SET SDA HIGH SO SLAVE CAN SEND ACK BIT. BL @DELAY2 WAIT 1/2 CLOCK PERIOD. SBO SCL SEND ANOTHER CLOCK PULSE FOR ACK BIT - IGNORE IT. BL @DELAY1 WAIT 1 CLOCK PERIOD. MOV @SAVR11,R11 RESTORE RETURN ADDRESS B *R11 RETURN. * *DELAY LOOP - ONE PERIOD. * DLYPRD EQU >0002 DELAY1 LI R1,DLYPRD DEL1 DEC R1 JNE DEL1 B *R11 * *DELAY LOOP - HALF PERIOD. * DELAY2 LI R1,DLYPRD/2 JMP DEL1 *STORAGE. WS BSS 32 PROGRAM WORKSPACE. SAVR11 DATA >0000 SAVED RETURN ADDRESS FOR SUB-ROUTINES. SBO31 DATA >1D1F OP-CODE FOR 'SBO 31'. SBZ31 DATA >1E1F OP-CODE FOR 'SBZ 31'. *NOTE ABOUT I2C ADDRESS: *RASP PI REPORTS LCD DISPLAY AS ADDRESS >27. *NEED TO SHIFT THAT LEFT ONE BIT, SO NEED TO USE ADDRESS *>4E TO WRITE, >4F TO READ. I2CDAT BYTE >4E ADDRESS. MUST IMMEDIATELY PRECEDE DATA. BYTE >33,>32,>06,>0C,>28,>01 TEXT '* Texas *' TEXT '* TI-99/4A *' TEXT '* Instruments *' TEXT '* I2C Interface *' BFF BYTE >FF TERMINATOR CHARACTER. END ======================

I have a nice little project nearly finished - one chip and two resistors lets you control up to 127 addressable devices through the joystick port - LCD displays (16x2 char, 20x4, etc), ADCs, DACs, serial memory, motor drivers ...

The nanoPEB uses a few extra bytes of video RAM compared to the standard disk controller, and ISTR that F'Web also tries to use those bytes. I'll try to search back through the topics if no one can remember.

Anyone got a copy of the original version of Funnelweb (did it start at V3?) that has been modded to work with the NanoPEB? Thanks, Stuart.

Bear in mind though that the TI Home Computer Division would have to buy the chips from the TI Semiconductor Division, who would want a good profit out of the deal ...

I got a dead Mitsumi keyboard working this afternoon. If you have a Mitsumi keyboard where none of the keys work, or groups of keys don't work, then the problem is likely to be the connection between the keyboard PCB and the flexible membrane, and you might want to try repairing it as follows: (1) Remove the keyboard from the console. (2) On the back of the keyboard PCB, unsolder the two wires from the pins of the Alpha Lock key switch. Make sure that there are no blobs of solder left on the pins - they need to go through the PCB later. (3) Make a note of the orientation of the two metal strips on the back of the PCB, so they can be refitted correctly. (4) Remove all the screws from the back of the PCB. Note that there's one hidden under the ribbon cable, near the sticky foam pad - carefully bend the ribbon cable up to access it. (5) Remove the PCB from the rest of the keyboard. If you've removed all the screws, it should come off easily. (6) Turn the PCB over and look at the white membrane. Towards one edge you'll see a group of pads that make contact with corresponding pads on the PCB. (7) Starting in one corner, carefully peel the membrane off the PCB. The membrane should be tacky, not firmly stuck. Flex it as little as possible to avoid cracking any of the carbon tracks. Once removed, avoid getting any hair or dust on the tacky side as this might affect operation of the keys. ( Get some electrically conductive silver paint (such as www.maplin.co.uk/p/electrically-conductive-silver-paint-n36ba) and carefully paint over each of the pads that make contact with the PCB, making sure you get right to the end of the track that whizzes off round to the keys. Give them a couple of coats, with 1/2 hour drying time in between. Make sure you don't get any paint between the pads as it will short them together. (9) On the PCB, there is a white plastic strip over the pads that make contact with the membrane. Carefully peel this off to reveal the gold-plated pads on the PCB below. Make sure that this area is clean and smooth - the membrane needs to lie completely flat against it to ensure a good connection. (10) Refit the membrane to the PCB. Check that it is accurately aligned, with the screw holes aligned and the black carbon circles directly over the gold 'maze' tracks on the PCB. Check that it is lying completely flat - no ripples. (11) Get a small piece of thin, soft foam and cut to size to cover the group of pads connecting the PCB and the membrane. Attach in place to the membrane with double-sided tape. (The foam needs to compress to about half a millimetre or so or so when the PCB is fitted back to the rest of the keyboard and screwed down. A small piece of cardboard from a cereal packet would probably work instead of foam - just need something that will ensure that the pads on the PCB and membrane are firmly pushed together.) (12) Refit the PCB to the rest of the keyboard, refit the screws and resolder the wires to the Alpha Lock key switch. (13) Refit the keyboard to the console and see if it now works. Stuart.