Stuart

What command are you typing at the console, and what error code is it returning?

CALL MOUNT won't work inside a program, as others have said. But have a look at this page [http://gtello.pagesperso-orange.fr/ti99_e.htm] and there's a program you can use to switch volumes within a program. Scroll down that page to the picture of the NanoPEB and that's where the details are.

Do you still get the audio beep when you switch on? Or any sound at all?

Should work OK. "Loading/saving from/to disk is now supported using standard device/file names in quotes (for example, SAVE "DSK3.MYPROG" and LOAD "DSK3.MYPROG"). The auto-run feature as described in the Cortex user guide is also supported. Note though that I think the system crashes at the moment if you try to save a file with the same name as an existing file."

Use this: http://led.linear1.org/1led.wiz (which is linked to from that link you provided). There are three numbers involved: (1) The voltage you're driving the LED from. So this is 5V if you're connecting the LED + series resistor across a 5V power supply. (2) The forward voltage of the LED - this is your 2.2V or 3.3V. (3) The current through the LED - you can get this from the LED datasheet but 20mA is usually an approx. value. The higher the current the brighter the LED. For a 5V supply, you'll probably need a resistor in the range 100 - 300 Ohms approx. An alternative way to do it is to get a 'resistor selection pack' that covers that range, and starting with a 300 Ohm resistor try consecutively lower values until the LED achieves the brightness you want. You may find that the resistor value recommended by a 'series resistor calculator' is either too bright or not bright enough anyway, and you want to nudge up or down to the next resistor value.

A similar trick is used with the error message strings in Cortex BASIC, but it negates the final byte in each string (which sets the MS bit so JLT/JGT jumps can be used). The required character is recovered by negating the value again.

Hmmm ... that's very strange. I can't test the .wav easily without getting lots of things out of cupboards and soldering up an audio cable. All the LBLA listings I have use the >718E value. I'm starting to wonder if I was actually given that .wav file by someone else, and they had a dodgy tape ...

So can you patch those addresses in Easy Bug, save it back to a new tape, and see if it then works as it should? (Although there may of course be differences elsewhere in the code.) There's a .wav file of the 'good' version at http://www.stuartconner.me.uk/ti/cassette_wavs/lbla.wav if you have the means of playing that into your TI.

I've got an original which I disassembled years ago to port to my TM990 system. It used the value >718E, which is used when entering a program to store the number of unresolved references.

To confirm the way it should work: do NEW and it should start assembling at >7D00. Enter a few instructions and labels, then SYM to check the symbol table, then END to return to the MiniMem screen. Then OLD and it will briefly flash a message about the number of unresolved references (it's not meant to do this - it's just the way it clears the screen buffer) and then show the address after the last instruction entered (with previous instructions being retained). If you then do SYM it should show the symbol table from the previous session. If you're losing the symbol table and the location counter is >7F00 - what address range are you assembling at? Wondering if you could be overwriting some of the LBLA data? What happens if you assemble just a few instructions at >7D00? You're NOT powering off between the NEW and OLD sessions (just in case the cartridge battery is flat and you're losing some data from the RAM)? Also note that there is a bug in the LBLA which can affect instructions with two symbolic addressing operands. See http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_bug for the details and a fix.

Lee and Marc, I've learned something new tonight! That's actually a handy little feature. Stuart.

I've tried to put some answers in-line above, prefixed with >>>.

If the value is zero then I believe the shi(f)t count is 16.

ftp://ftp.whtech.com/datasheets%20and%20manuals/Datasheets%20-%20TI/SBP9989_manual.pdf It's actually called the SBP9989.

(Major digression - here's a chap who apparently helped to design the 9911 - https://www.linkedin.com/in/longley/. He also claims to have done the product definition for the TMS9909 floppy disk controller, and that that chip was in full production for 8 years. For a chip that was produced for so long, it is mighty hard to get hold of one, and I don't think anyone has seen one that isn't the 'TMX' prototype version.)

Looks like the TI documentation is inconsistent with regards what's required. There's an example diagram in the 9900 data manual (as you say) with a pair of cascaded 74148's with no synchronisation. The 74148 was also sold as the TIM9907, and looking on the page for that in the Microsystems Designers handbook there's an application diagram showing a 74148 connected to a 9900, and preceded by a LS373 latch clocked by phase 3 clock. Right beside it there's a 74148 connected to a 9980/9981 with no latch. If you're using a 9901, then they are latched in that.

I've attached a corrected version. MM_LBLA_CORRECTED.rar

That's a bug in LBLA. See [http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_bug].

No voltage regulators means it is definitely NOT for the TI PEB.

Hooray, some progress! If the card is at CRU >1000, then try the XB program again but in line 20 change the *fourth* number from 17 to 16 (this number determines which CRU address is accessed). When you run the XB program the LED on the card should flash - but it may be so brief that you don't see it. If you've got a bad EPROM socket then that is very likely to be the problem. You may well find that it bursts into life when the socket is repaired/replaced. Looking at which ICs are socketed, you've got the EPROMs and PALs that will be programmed and fitted to the card after it has been manufactured, and the 9901 and FDC which, although not *expected* to fail, are perhaps the most likely to have failed if the card develops a problem. And/or fault-finding a hardware problem on the card is easier if these ICs can be removed (without damaging them).

I would say that the Geneve is so closely related to the TI-99/4A that Geneve stuff could go in the existing TI-99/4A Development sub-forum. But I would leave the decision to the poster.

I'd like to sound out opinions on a new sub-forum for TMS99xx development that is not directly related to the TI-99/4A. Potentially to cover single-board or breadboard systems like those I've produced, the Powertran Cortex and Mini-Cortex designs, and there are a couple of people doing some interesting development using the TMS99110. It would be handy to have a forum for discussions rather than using e-mail that some of us are currently using. We already have a few topics for this in the TI-99/4A Development subforum but it tends to get swamped by the TI-99 stuff, and there are probably enough TI-99 enthusiasts interested in other TMS99xx development that having it as a sub-forum (rather than somewhere else completely - not on AtariAge) is a good idea. Thoughts?

Yes, take everything else out of the PBOX before trying to access the card at other addresses.

What XB error did you get with the CC card? Even if the card is duff, I would expect the XB program to still run but return a load of 0 values. Is the function of the DIL switches documented anywhere? I would have expected the MiniMem trick to be able to switch on the card LED (as you say it blinks when trying to access the floppies from BASIC) unless one of the DIL switches is changing the CRU address away from the standard >1100 for an FDC card. You might want to try the MiniMem trick again but try different addresses C1000, C1100 (you tried that already), C1200, C1300, C1400 up to C1F00 and see if any of those light the LED. I wouldn't be too worried about the mod to the crystal yet. The crystal only provides a clock for the floppy controller IC, let's see if we can read the EPROMs first.

I don't think the XB program will work in that case unless you have 32K RAM in the console - ISTR that the XB CALL INIT won't work unless 32K RAM was available at boot time. But if you have a MiniMem cartridge you can use the MiniMem trick referenced in the link, or if you have one of the 64/128K ROM cartridge boards then burn my Mini Memory Line-By-Line Assembler, TIBUG and Disassembler cartridge (http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_tibug_disassembler_cartridge) and use TIBUG instead of the MiniMem EasyBug.