Stuart

Correct!

OK, lets step it up a bit - where would you find this? You're more likely to see it this way round: Hint: it's an item manufactured by TI.

Well that would be the console keyboard connector.

Try a couple of different RAM chips. Two that I find work OK are an Hitachi HM62256BLP-7 and a Cypress CY62256LL-70PXC. Have seen problems with Alliance RAM, which is what I think you're using.

Subprogram >0034 plays the accept tone sound? I have a pencilled note in my E/A manual that interrupts need to be enabled for the sound list to be processed. If interrupts are not enabled, not sure if the routine hangs (like you're finding) or you just don't hear the sound. GPLLNK also won't work with a program that autoruns after loading with the E/A module option 3. I know you're not doing this, but there was some investigation into this in a thread some time ago and a solution found. If you're able to find that thread, it may help in determining what GPLLNK needs in addition to the info that Lee and others have provided above. If all else, fails, I use the code below in one of my programs to play the bad response tone. If you change the frequency in the first line to that of the accept tone, it gets round your problem (assuming you don't need GPLLNK for anything else). * Play middle "A" note on generator 1. LI R0,>8E0F Frequency on generator 1. MOVB R0,@>8400 Sound port address. SWPB R0 MOVB R0,@>8400 LI R0,>9000 Volume: maximum. MOVB R0,@>8400 * Delay for approx. 1/2 second. LI R0,>4000 BDR1 DEC R0 JNE BDR1 * Turn sound off. LI R0,>9F00 MOVB R0,@>8400

With your transmit routine, the code in TI docs usually has things in a slightly different order and tests a different bit. See if the following is any better; it tests for character transmission complete while the transmitter is enabled. MOV @CX,R12 SBO 16 (>10) Bit 16 - turn on transmitter EO TB 22 (>16) Bit 22 - test transmit buffer register empty *** Testing different bit to your code *** JNE EO Loop until it is LDCR @>0002(R13),8 SBZ 16 (>10) Bit 16 - turn off transmitter RT

In Insane's post #6 he said he was using a standard modem cable, where the NanoPEB CTS and RTS would be connected through to the relevant pins on the modem. So CTS on the NanoPEB wouldn't be left disconnected like with your Tx/Rx/Gnd-only cable.

If you've got only transmit, receive and ground connected to the modem, have you got pins 7 (RTS) and 8 (CTS) connected together in the connector at the NanoPEB end? I believe the 9902 waits until CTS is active when transmitting, so any software that loops until the character is transmitted will appear to hang unless CTS is connected. (The NanoPEB is different to the TI Serial PEB card in that CTS is brought straight out to the serial connector rather than being connected to DSR(?) on the card.) NanoPEB Lantronix 9-way D-type Male 25-way D-type Female Pin Pin 2 (RX) ------<<------ (RX out) 3 3 (TX) ------>>------ (TX in) 2 5 (GND) -------------- (GND) 7 7 (RTS) -->>--+ 8 (CTS) --<<--+ (pins 7 and 8 connected together)

Adding: https://www.mpeforth.com/wp/wp-content/uploads/2015/12/MPE_PR_From_Telescope_to_Comet_2014_11_13.pdf

Actually, looking at the SuperCart construction notes, there's already a resistor between pins 27 and 28. If you've built the SuperCart using a TI game cartridge as per http://www.mainbyte.com/ti99/supercart/supercart_4bank.html, then you should be able to write protect the RAM simply by inserting a switch in the wire between the 3rd edge connector pin and pin 27 of the RAM.

You'll either need to bend pin 27 so it doesn't go into the socket, or cut the trace to the IC pin 27 on the PCB. Bending the pin out of the socket might be easier then it leaves your PCB pristine. You might find it best to only change the switch with the console powered off, then you don't get a problem with the RAM possibly being corrupted when the switch output is connected to neither input for a couple of milliseconds as the switch changes position. Should be a simple schematic attached.

Pin 27 is /WE. So have a switch in-line with the connection to that pin, plus a ~1K resistor connected between that pin and pin 28 (+5V) to ensure that /WE is pulled high when the switch is in the 'off' position.

In bitmap mode you can display text on a 32 character by 24 row grid - so easy to add labels if the tick marks happen to align with the character grid (or possibly tweak your axis scales so that they do align). If they don't align, then you could define the label text character bitmaps as stationary sprites which can be positioned with pixel accuracy.

I wouldn't say that 14K of RAM free for program and variables restricts it to "very very small programs"!

It's in the manual - section 4.2.12.4. (Appendix A of the manual contains an alphabetical list of BASIC keywords which is handy for finding where things are described.) Yes, I ported Cortex BASIC over from the original Cortex version.

Cortex BASIC does, not sure about RXB. Scroll down to the bottom of the following page for an example: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm

http://www.unige.ch/medecine/nouspikel/ti99/download.htm#disass A couple of headings down from the top of the page, "The disk controller card ROM" Also appears to be the code for DSRLNK a bit further down the page (ea3.txt)?

In addition to Tursi's reply above, take a look at https://archive.org/details/COMPUTES_Beginners_Guide_to_C64_Sound_1984_COMPUTE_Publications_a. All the addresses and program listings are for the C64 so you'll have to convert them to TI-99 addresses, but it contains valuable info about how the SID chip works. Here's the SID chip playing on my TM990 system:

If SB uses the MSB of both R1 and R4, your LI R4,>30 needs to be LI R4,>3000 to put the >30 into the MSB?

What you might want to consider is displaying both hex data and ASCII on the same screen, something like below. Very useful for spotting text strings within the data. (Noticed a little typo in your video - HEXIDECIMAL should be HEXADECIMAL)

Get yourself a copy of the TI-99 circuit diagram if you haven't already (Google will find it for you). Find the TMS9901 on the circuit diagram and look at the inputs from the keyboard - pins P5 and /INT3 - /INT10. With the keyboard disconnected, check that each of these is being pulled to +5V. There's a pull-up resistor and a capacitor on each line that might be causing the problem. The TIM9904 clock chip has no bearing on the keyboard problem.

Pretty much all the 9901 pins are already used, but it's fairly easy to add a second 9901 to the console by piggybacking it on the existing one and mapping it to unused CRU address (>0400 or >0800?). If you've got a RAMDisk in your system and have the source code for the DSR, then it is fairly easy to add a new device entry (so you don't need to mess around with the hardware to support a separate DSR just for the clock), and then add the software to support opening and reading/writing to the clock. That's how I added support for a parallel keyboard interface many many years ago.

Did you change the 9904 (the clock chip) or the 40-pin 9901, which interfaces with the keyboard?

http://www.unige.ch/medecine/nouspikel/ti99/eeproms.htm#console

c506, r514 - the circuit diagram is a bad copy - they connect to the line to the left, that goes up towards the top of the page.