ckoba

Thanks for that. That's one of the methods that I tried (others being CLI via Linux and heavy cursing). The resulting .dsk is filled with 0xF6 and only 0xF6. I'm debugging the source of the Linux utility, which is a convoluted mess of interdependent libraries and non-POSIXy CLI flags. Unpleasant. Edit: attach the .hfe, because why not. broken_hfe.zip

Doh. I'll post a file as read from my TL866 later today. Didn't even think about that, got distracted following the HxC conversion problem down the rabbit hole ... ... edit: attached. It's only the stuff needed to burn the cartridge, plus Multiplan's .dsk. Set fuses the same way as documented elsewhere, or you can try to use the included config file (read from the 1284P) Thanks for reminding me that I could just read the whole thing with the TL866. Should have thought of that ... ck-multi1v1-binonly.zip

Adding a small contribution to the repository ... ... based on the UberGROM / relocation conversation I've been having with Tursi elsewhere in this forum, I've put together an UberGROM multi-GROM/ROM cart that seems to work okay. Included are TI LOGO, TI LOGO II, and Microsoft Multiplan ... i.e., the useful language and/or productivity modules that aren't available on disk or other collections. There are three GROM slots left over, and I couldn't find a suitable language / utility to put in there that hadn't been done better elsewhere. So, on to the specifics: * This cartridge must be built from the recovery bootloader on the UberGROM itself, * I had intended to provide a complete GROM ^L image, but the HxC utility doesn't seem to want to convert from .hfe -> .dsk, * Therefore, this needs to be laid out as follows with the files on multicart.dsk: * First, skip 9800 and 9804 entirely. Using them triggers the console GROM scanning bug as discussed elsewhere. Leave them unmapped. * The base files are separated into 8k chunks prefixed with (base + 2). Therefore, 1XAA goes into 9808 slot 0, 1XAB into slot 1, 2XAC into 980C slot 3, and so forth. * The EEPROM should be programmed with the contents of multicart1-eprom.bin * NB: multicart.dsk is 80-track DSSD. If your gear can't handle that, please use Fred's TI99Dir or xdm99.py to transmogrify the files into something useful for you. * Multiplan keeps its GROM base location data on disk. Included is phm3113.dsk which has the necessary modifications. This has only been lightly tested. There are more occurrences of "98 00" lying around, especially in LOGO II, but I wasn't able to trigger crashes. Bug reports are welcome. For those interested in how this put together, I've included my build and patch scripts. They expect to be run on something UNIX-like (MacOS or Linux or *BSD). Hopefully someone can take this and improve on what I've done. Cheers! ck-multi1v1.zip

*chuckle* I salute you anyway, even though I would theoretically outrank you based on last-held-paygrade at EAOS. That and six bucks will get me a cup of coffee ... ... I'm not surprised that logic 0/1 aren't at TTL levels on the TMS. It's a weird beast. SAMS schematic says voltage at mike out is 4V peak-to-peak. Close enough to TTL for Navy work Edit: no it's not. Peak-to-peak, so your 2V is about right on. Needs amplification, but tape decks of the time were expecting low voltage in and had a 741-alike to compensate.

*ding* That was exactly the answer I needed, sir. You're possibly an officer and definitely a gentleman So now I need to track down what causes a cassette interrupt. Lucky for me all of the ROM routines are disassembled and commented

"Given that code fragment, what needs to happen on the console to break that infinite loop and continue to the next instruction?" (the next instruction in all cases is "X R8", with R8 being set elsewhere to >1E19, which I think is "put +5VDC into the cassette output circuitry" ROM routine)

Understood, thanks. Further dumb question (I come from a 6502 and ARM background): with other architectures, an interrupt passes control through a vector set up beforehand (hence the term "interrupt handler"). On these beasties, does an interrupt just tell it to continue execution from the next instruction?

No, but there is a LIMI 1 in the execution path prior to the infinite loop. Path looks like this: LIMI 1 L1 SETO R4 * EENEN UITGEVEN BL @BITWR * (and let's treat BITWR as if it were inline, so:) BITWR DATA >10FF * IDLE X R8 * execute >1E19 XOR @>135C,R8 * SBO ANDI R4,>0001 JNE LA1 DATA >10FF * DATABIT = 0, VERLENG PERIODE LA1 DATA >10FF * X R8 * execute >1E19 XOR @>135C,R8 ANDI R4,>0001 JNE LA2 DATA >10FF RT LA2 DATA >10FF * DATABIT = 1, TWEEDE PERIODE X R8 * execute >1E19 XOR @>135C,R8 DATA >10FF X R8 * execute >1E19 XOR @>135C,R8 RT (so end inline there) DEC R2 * AFTELLEN JNE L1 DEC R2 * AFTELLEN JNE L1 Google Translate and a thirty-year-old German elective gets me through the Dutch (Dutch == Deutsch if shouted loud enough ) What I'm looking for is the frequency for 1 and 0. I can work it out from there. Ultimately this will be folded into my bin->tape .wav generator, I think, but Ron just wants to see it working in any way possible

I've got one coming in eventually from eBay ... if you can't find yours, I'll try the Navarone Widget method with it.

Apparently someone in the Netherlands did just that about twenty-five years ago. I'm looking at the source code, trying to work out the protocol. Assembly language guys: how is "10 FF" (i.e., "HERE JMP HERE" supposed to work as a delay loop?

It wasn't totally lost. Thierry still has the Gerber files and DSRs (with source!) at http://www.nouspikel.com/ti99/ideal.htm... and Fred Kaal has put up schematics at http://www.ti99-geek.nl/ (the site is all framed, so you'll have to go to "Projects" and click "IDE Card". So whoever takes this on would not be starting in a vacuum, as they would with the CF7/nanoPEB ...

Yeah, you're right. I seem to be having difficulty adjusting to a post-Apple-Chinese-factory mindset ... "Need to squeeze every byte out of this new routine, dammit, because we don't have enough NAND for the OS on the N94!" "But, sir, we're EOLing the N94 next quarter, right?" "You forgot about the refurb lines at (redacted factory in Pudong), idiot!" (sorry, slight rant over)

I looked into reverse-engineering the FPGA when I first got a nanoPEB (which I have since sold). The part appeared to be EOL'ed some time ago, and I couldn't find any dev kit that admitted to being able to read data from the device. I concluded that if this were to be reproduced, the right thing to do would be to clone Thierry's IDE card into a Spartan via VHDL. (Which, I suspect, is probably very similar to how the CF7/nanoPEB came about) The CF7/nanoPEB are actually IDE devices anyway, might as well go with something that's documented with gear already deployed in the field. Then I got my PEB/HxC and stopped caring

I think, but cannot prove (because I don't have a Plato module and no easy way to obtain one), that it (and other "autostart cartridges") didn't originally have anything at >7800. I think they were using some weird trampoline logic to transfer control to the ROM. I think this because the GRAM Kracker module has explicit instructions on making the Plato cartridge compatible with it, and it involves relocating the header from >6000 to >7800. Unfortunately, whoever did this procedure on the dump I (and probably you) was/were working filled the original bits (plus more) at >6000 with FF, so there's no way that I can see to reverse the procedure. Summary: I don't think it's an 8k GRAM or GRAM-alike, I think it's not a pristine cartridge dump, and that's why you had to specially assign it in MESS. That's just a WAG.

That is this change in the Plato ROM, yes? -000000f0 d8 00 9c 02 06 c0 d8 00 9c 02 06 c0 dc 60 98 00 |.............`..| +000000f0 d8 00 9c 02 06 c0 d8 00 9c 02 06 c0 dc 60 98 10 |.............`..| (i.e., "dc 60 98 10" instead of "dc 60 98 00") Am I correct in thinking that this sort of bank dependency is caused by the ROM needing to pass control back over to the GROM, and thus needs to know the GROM base address? What, in general (or in specific) should I be looking for when I'm stomping out GROM0 assumptions? "xx 60 yy 00", with xx and yy being (I assume) register load instructions? Was there a "TI standard" way to do this? (I *need* to learn TMS9900 assembly, I think. I'm looking at Logo-II, which also wants to be at GROM0, and I think this is going to be a widespread issue with GROM/ROM combo cartridges) Edit: "98 00" and "98 10". I'm not very swift today.

Plato is a weird cartridge in that it's GROM header already starts at >7800 (it's one of the rare TI 8k GROMs, I guess), because it's an "autostart cartridge" as per page 53 of the Gram Kracker documentation on Mainbyte. I wasn't getting anywhere with Plato by changing the header at >6000 to AA5A (locked at blue screen), nor with various permutations of relocating the contents of >7800 to >6000 and then editing it (garbage at selection screen), so I figured that just seeing it run on iron for the first time in twenty years was good enough for me I've attached Plato, in case you're curious. plato_courseware.zip

The multicart software works. I built a Plato cartridge with the ROM in a random bank, and it dialed right in to it and fired up fine (when chosen via "multicart" -- choosing via the TI selection menu fails, as expected). I'll get cracking on RPI later today or tomorrow. Thank you very much for implementing ROM bank selection. Multicart multicart multicart

My main console had this problem. It turns out that the wires in the ribbon cable between the main board and the keyboard had become quite brittle (actually, the connection between the cable and the connector to the keyboard header), and thus every time I hit a key it would break-and-make the connection several times. My fix was to desolder the header from the keyboard PCB and solder a new ribbon cable between the two boards. Presto, no more stuttering keyboard. I suppose I should put a connector in the middle of the cable one of these days.

*blink* That was fast. Thank you. No worries on the upload delay -- a couple of days is a drop in the bucket compared to the time these machines have been around lacking a useful multicart solution. Again, argh. I can help run these down, if you want.

Argh. I'm not competent to hand-code TI assembly. I'm barely competent to wrestle with the GPL goop in Plato's first GROM to understand it's using a powerup routine. It's okay. Console limitation, but can be worked around because ... The byte at >6003? Yes, please, very very useful. Something like "if non-zero, the value represents the 8k bank of the ROM we want (assuming Multicart program is at 0 and the final bank)". To handle multi-bank ROMS, maybe set the high bit to signify mapping 16? Again, thank you *very* much for confirming the TI bug and suggesting workarounds. I'll play with your multicart menu later today and see if I can get it to make RPI and Multiplan play nice. (aside: the reason I'm harping on about Multiplan is that it doesn't appear in anyone else's compilation. Same with all of the large cartridges, I think -- Plato, RPI, Logo II, and so forth. Just trying to do my bit for the community ) (editt: math)

This would be a version of his multicart menu program that supported GPL, which he referred to towards the end? Was that "released" (in the sense that it was attached to a post in one of the fifty-plus pages about the multicarts), or is it something that would need to be extracted from his binary releases?

(the promised third reply) None of my attempts to get Multiplan (GROM-only) and RPI co-existing on the same cartridge worked. I tried: * putting RPI into base 0 and Multiplan in base 1 (it only saw Multiplan), * putting RPI into base 0 and base1/slot1 and Multiplan in base2 (it only saw RPI), * putting Multiplan into base 0 and RPI into base 1 (it only saw Multiplan) ... so it appears that GROM multi-carts will work iff they have AA 01 at the first slot? That's unfortunate. Thanks, TI ...

Part two of two (maybe three) of my response (I don't do videos, I like text instructions, so I shan't wait ): This makes sense. Console sees same data at a different base, it assumes that it's a single-GROM cart. That I get, and I understand that the data isn't duplicated on the Atmel, it's just the same memory region mapped into a different bank. However, that effectively renders that bank useless for anything else, right? Does it stop the console from probing the rest of the UberGROM for valid AA 01, or is it just a bug with slot 0 on bank 0 and 1 not having an AA 01? I'm trying to reconcile this with being able to build a Multiplan cart, five-GROM-only, with the only difference being that AA 01 was in at >6000. Lastly, and this is an architecture question: do you reckon it would be possible to create a GROM-and-ROM multi-program cartridge by redirecting the GROM application header to point to a code snippet in an unused area of the GROM that writes the right ROM bank to >6000, then jumping to the original entry point? That's my macro goal here -- it's so wasteful to have one program per cart, and the rest of that 512k is just sitting there ...

(split-quote is acting weird, so my reply will be in two parts) This scheme works. I have a working RPI reproduction now. Thank you very much for spending time on root-cause analysis. Questions about this part of the fix: * Turning off bases essentially turns the UberGROM into a single-game cartridge, yes? * Can this be mitigated by putting a different, GROM-only application into the second base? (I can try this myself, actually, so there may be three replies to this )

Thanks for the kind words. I learned long ago that EPS was created for a reason, interpolation is ill-advised, and what might be acceptable resolution now will look like crap when DPI is doubled next year