Stuart

Ah, I see what you mean! You're probably right.

Isn't that what the SuperCart gives you? http://www.mainbyte.com/ti99/supercart/supercart.html (I think Ksarul has laid at a new PCB for it?) I've got a program that will load/save to that RAM (CART_RAM on http://www.stuartconner.me.uk/ti/ti.htm#miscellaneous_programs); some other versions exist as well. Should be able to peek/poke to the RAM from BASIC using the E/A functions.

In the last of your pictures above, there are three wires (white/blue/red) going from the green PCB to a small board next to the black plastic bit. Is there an optical sensor on that small board?

It's a sort of student learning system. Can go for £200+ on eBay ...

The spring allows that side of the motor mounting to move a bit - it is held to the chassis under spring pressure rather than being firmly screwed to it. Looking at the video - before taking the motor off, look at the bit that rotates a little in the video. With power off, can you rotate that by hand in the opposite direction to move the head towards the disk centre? If yes, repeat your test and the head moves back towards the stepper motor and starts buzzing? The head mechanism should actuate a switch when it gets to the outermost disk track - track 0 - then stop. If that switch (or the associated electronics) has failed then the motor will just keep on trying to move the head and make that buzzing noise. The bit of board with the three wires going to it - has that got an optical switch like this http://cpc.farnell.com/productimages/standard/en_GB/491342-40.jpg on it, and there's a bit of plastic on the head assembly that breaks the beam between the two halves?

Looking at the photo at the bottom of page 2 of the brochure linked to in post #2. At the extreme right of the photo are two screws, screwed in from the right to the left, one near the top of the photo and one near the bottom (the heads of the screws have been partially cropped from the photo). They appear to the holding a plate that secures the stepper motor to the chassis. If I'm right, and if you can get to them and remove them, then you can probably slide the stepper motor and head assembly to the right a bit, which gives you a bit more room to carefully wiggle bits and see where the obstruction is. I may be wrong about what those screws are holding though - difficult to tell from the photo at that angle. Have you tried rotating the lead screw from the stepper motor to the head by hand? Assuming it isn't seized (which may be what the problem is), it's probably possible to turn it and it will feel probably feel 'notchy'. (Don't turn it too far though in case the head is tight up against a limit switch)

You can get two independently-controllable signals direct from the joystick port, but I don't think it will do three. A couple of options spring to mind: (1) Use the joystick port as an I2C interface. See http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface. Connecting something like a PCF8574 (http://cache.nxp.com/documents/data_sheet/PCF8574_PCF8574A.pdf?pspll=1) will give you 8 controllable output bits. (2) Connect a TMS9901 to the side port. See http://www.stuartconner.me.uk/ti/images/eprom_programmer_circuit.pdf. This will give you lots of input/output bits. (3) The UberGROM cartridge has 6 digital GPIO pins that can be configured as input or output. Not sure if anyone has actually done anything with these yet, so you may be breaking new ground! You'll need to do your code in assembly to get anything near decent speed if you're strobing through sets of LEDs.

Can you push it easily that millimetre or two with your finger? Could be solidified grease/lubricant on the guide rail/rod that it moves on? EDIT - there's a brochure that appears to show the drive - https://archive.org/stream/bitsavers_teacbrochueJan84_4393819/TEAC_FD-30A_Brochure_Jan84#page/n1/mode/1up. Looks like two screws securing the stepper motor in place. If you can get to those and remove them, then you should be able to check if the head is jammed on the guide rail, or the motor or lead screw is jammed.

Clearing bit 18 after each received byte - yep, got to do that, as per post #13. The CALL IO line to load the transmit and receive rate registers - you modified the line to send 12 bits, not 11, to clear bit 11? (I tried configuring a serial port on my TM990 using assembly, using the configuration you were using, and it actually seemed to work OK. Whether it is the interval timer causing the problem or not, no idea. Glad it's up and running now though.)

So here's what I think is happening. There are a couple of points that I don't fully understand, but you seem to have a working solution. Also, you're better off looking at the TI data manual for this (ftp://ftp.whtech.com/datasheets%20and%20manuals/Datasheets%20-%20TI/TMS9902A.pdf) - it has tables covering all the input and output CRU bits, and Thierry's site doesn't cover everything. I'll refer to your code listing back in post #24. There are a number of registers available for programming: (1) Control Register - you select this for loading by writing a 1 to CRU bit 14. (2) Interval Register - selected for loading by writing a 1 to CRU bit 13. (3) Receive Data Rate Register - selected for loading by writing a 1 to CRU bit 12. (4) Transmit Data Rate Register - selected for loading by writing a 1 to CRU bit 11. You quite correctly selected and loaded registers 1, 3 and 4 in your code, lines 40 - 90. You load the register by writing one or more bits to CRU bits 10 - 0. We then added a soft reset of the 9902 in line 35. One effect of this is that it sets CRU bits 14 - 11 all to 1 - it selects *all* the registers for loading. So what happens in this condition? When you write to CRU bits 10 - 0, it writes to the first register that is selected using the priority order listed above. So with all the registers selected, the first write will be to the Control Register (which then deselects itself), the next write to the Interval Register, then the Receive Data Rate Register, then the Transmit Data Rate Register. So going through your code: -- Line 40 I don't think is necessary - CRU bit 14 is already set to 1 by the soft reset. Should be able to delete this line. -- Line 50 is good - it writes to the Control Register, which also clears CRU bit 14. -- Line 60 is not necessary - CRU bit 12 is already set to 1 by the soft reset. -- Line 70 is interesting - you intended to write to the Receive Data Rate Register, but the highest priority register currently selected (according to the list above) is the Interval Register, so this write goes to that register, which also clears CRU bit 13. (Writing to that register might start the interval timer which generates regular interrupts from the 9902, but I don't think that is a problem in this case.) -- Line 80 is not necessary - CRU bit 11 is already set to 1 by the soft reset. -- Line 90 - you intended to write to the Transmit Data Rate Register, but the highest priority register currently selected (according to the list above) is the Receive Data Rate Register. In the scenario we have at the moment, *both* the Receive and Transmit Data Rate Registers are selected, and in this case this write goes to *both* those registers (programming both with the same Baud rate). This also clears CRU bit 12. -- Line 100 - you're now clearing CRU bits 11 to 14. Bits 14, 13 and 12 are cleared already by writing to the registers, so it shouldn't be necessary to clear those. CRU bit 11 is still set, but the technique normally used to clear this is to write 12 bits in line 90 rather than 11 bits - the extra bit is written to bit 11 which clears it. The new line 55 I suggested to clear CRU bit 13 is deselecting the Interval Register so that the next write doesn't go to it. So your line 70 will write to *both* the Receive and Transmit Data Rate Registers, and your line 90 will write to the Transmit Data Rate Register alone (which is not necessary, but shouldn't cause a problem). Now, I'm not sure exactly why you were having a problem receiving when both the transmit *and* receive registers were being programmed. I may have to experiment a little. I think you should be able to revise your code as below to follow the 'normal' flow for programming the 9902: ... 35 CALL IO(3,1,CRU+31,1) !RESET TMS9902 40 (delete line) 50 CALL IO(3,8,CRU,203) !8N1 @ 3MHZ !PROGRAM CONTROL REGISTER 55 CALL IO(3,1,CRU+13,0) !DESELECT INTERVAL REGISTER 60 (delete line) 70 CALL IO(3,12,CRU,0,39) !9600 BPS !PROGRAM RECEIVE AND TRANSMIT DATA RATE REGISTERS ** Note the line above sends 12 bits, not 11 ** 80 (delete line) 90 (delete line) 100 (delete line) 110 PRINT "READY FOR INPUT" ... ...

You'll have to wait until tomorrow for that as it requires a little explanation. It's late, and a warm bed awaits me. It will also give me a chance to ponder why you had trouble receiving, as it now looks like you should have had trouble transmitting,

Have you only tried it with RXB so far? I'd try it in assembly - you could adapt the code I posted earlier (just send a 'fixed' character and see what comes back). May be a bug in RXB, or you haven't got the CALL IO parameters quite right. *** BUT FIRST! *** In your code, add a new line 55 to set CRU bit 13 to zero. See what happens ...

Logic analyser seems to be a good way to go. Just to point out another useful feature of the 9902 - CRU bit 15 enables you to test the state of the RIN (Receive In) pin directly. So using assembly (for the necessary speed), you could test bit 15 and wait until it goes low (indicating the start of a start bit), wait half a serial bit period, then sample each of the serial bits directly. You could then see exactly what is coming down the line, rather than what the 9902 is loading into the receive register. You'd need to do a bit of experimentation with timing loops to get the right values for the Baud rate you're using. The TIBUG monitor uses this technique to autodetect the Baud rate of your terminal: you power on then press a key for a character where the MSB is a '1'. The code measures the width of the start bit in a timing loop, then looks up the loop count in a small lookup table that gives the transmit/receive rate register values to load for that Baud rate.

I'm not sure you'll see an effect anyway in your application. I think the number of stop bits is only relevant if you are transmitted at the max rate, with a start bit immediately following the specified number of stop bits, which effectively provide 'padding' between the characters. A stop bit is a '1', which is also the 'idle state' of the line when no character is being transmitted.

I've taken my TMS 99105 (TMS 99110) breadboard project and made a PCB for it. Simple system - processor runs at 4 MHz, two pages of 32K RAM, two pages of 32K EPROM, and an RS-232 serial port to communicate with a terminal program on a PC. Runs a system monitor, Cortex BASIC and Forth. No means of saving programs, but you can maintain/edit them on the PC and download them over the serial link. On the PCB, there are take-off points for all the main signals including the demultiplexed address and data bus, if you want to expand it further. I've got a couple of bare PCBs spare - anyone interested? £16 each plus postage to you from the UK. There are full details plus approx. cost of the components here: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm PM me if interested.

If all 3 cards are the same brand, sounds like they have a compatibility problem. Try getting a card of the same brand as your working card off eBay - it doesn't have to be new if you just to want to prove the (in)compatibility problem. Cameras and PCs seem to be far more tolerant of different brand cards than CF devices for old processors.

Ooops! I've corrected that and uploaded a new version (the new binary image file has a v1_1 suffix). I'm not sure if the scrolling page buffer that the LBLA uses is going to be a pain when used with TIBUG and the disassembler. With the LBLA it is useful to be able to scroll back to see what you've done earlier, but not so sure you need to be able to do that with TIBUG and the disassembler, and it just ends up messing up the screen. Might look at changing that.

You don't need to change anything to receive. You just need to check if a character has been received into the receive buffer register, and if it has, read the character and reset the register. The CRU bits have different functions depending on whether you're reading or writing, so no problem using the same CRU bits to both transmit and receive a character. Some example code below. CLR R1 WAIT3 TB 21 Receive buffer register full? JNE WAIT3 No, loop until a character is received. STCR R1,8 Read character into MSB of R1. SBZ 18 Reset receive buffer register.

Been having some fun integrating a couple of programs into a single 8K cartridge: -- The MiniMem Line-by-Line Assembler (LBLA) - no more loading from tape. -- The TIBUG monitor from the TM990 CPU module. This is similar to (and a fore-runner of) the Mini Memory EASY BUG and the Editor/Assembler Debugger program, and enables you to run and tweak the program you've just entered using the LBLA. -- The TMS 9900 disassembler from the Powertran Cortex. Full details and a download link for the EPROM image here: http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_tibug_disassembler_cartridge. I've tested it using Classic99 and JS99'er, but not on the real hardware. Stuart.

You could probably clarify the flow slightly in your revised code. If you take line 135 and move to a new line 105, and change the comment to "Set /RTS active". With the 9902 in that condition, then your line 130 will send the character immediately. You only need to set /RTS active once - it will stay in that condition until you manually set it inactive. It doesn't reset automatically after each character you send. Good work, and nice to see something being done in RXB.

We have the Portal end credits for the TMS9900 as well. https://www.youtube.com/watch?v=AE2uSkZn4IM&t=93s

Are you switching on CRU bit 16 to enable the transmitter (and I think you need /RTS connected to /CTS in your cable)? Take a look at section 4.2 of the TMS9902 data manual, if you haven't already. Might also be worth doing a soft reset of the 9902 (CRU bit 31) to get it into a known state as well. Bit of code below for initialising the RS-232 port in the NanoPEB. Should work for the RS-232 PEB card as well. *Set port to 1200 Baud, 7 data bits, no parity, 1 stop bit. LI R12,BA9902 CRU base address of 9902 in NanoPEB. SBO 31 Reset 9902. LI R1,>8200 Control register: 1 stop bit, no parity, 7 data * bits (binary 10000010). LDCR R1,8 Load control register. SBZ 13 Disable loading of interval register. LI R1,>01A0 1200 Baud. LDCR R1,12 Load transmit and receive data rate registers. SBO 16 Set /RTS active low.

Another approach, which I think Omega alluded to in a round-about sort of way in a PM , would be to hook the sensors up to a Raspberry Pi (which also has an I2C interface), run a web server on that, set up a pretty page to display the sensor data, and access that using the Internet Browser on the TI. The Internet Browser includes a tag to refresh the page every couple of seconds to show up-to-date data. Lots of ways to skin this cat ...

If you didn't need it to be wireless, then practically any sensor you're likely to want is available with an I2C interface (such as an encased temperature and humidity sensor - https://www.adafruit.com/product/1293), and I've got an I2C interface for the joystick port here: http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface). The software listing will need expanding to be able to read a byte over the I2C interface (not difficult) and to interpret/display the data received.

Google "cardboard box dividers". Lots of suppliers, but you may have to order more than you actually need. If you don't mind the compartments being a bit bigger then wine is delivered in such boxes. If you want to buy a few boxes then I'd be happy to dispose of the contents for you.