ckoba
-
Content Count
271 -
Joined
-
Last visited
Posts posted by ckoba
-
-
Thanks for the nice work, Ckoba. You can build the data on an Atmel and save the EEPROM and DATA sections of the chip to disk with your EPROM device. That will give you a pair of pre-built files that can be directly loaded by anyone with a programmer for the Atmels.
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 ...
-
2
-
-
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!
-
2
-
-
*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.
-
1
-
-
The console interrupt routine has a lot in it, but when it decides that it was an interrupt meant for the cassette routine, it adds 2 to the return address before returning, thus breaking out of the infinite loop.
*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
-
(snip)
Ähm ... what was the question?
"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)
-
LIMI 1 is the same as LIMI 2 in the TI console. All interrupts are hard-wired to level 1.
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?
-
An endless loop, which may be interrupted by a VDP interrupt, thus synchronising to the interrupt. Is there a LIMI 2 somewhere?
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 can probably do this, I "think" I have a plato cart.. will doublecheck this weekend.
Greg
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.Has anyone tried to make some similar to C64 Turbo Tape for the TI?
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?
-
Looks like Thierry was studying at Stanford, and of course student web space always vanishes when they graduate.
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 ...
-
Yes, it will. I think there are better ways to spend time than patching ROMs for multicarts though.
Do one for the fun of it and just don't worry about the wasted ROM afterwards. Bytes are cheap these days!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)
-
The only missing link, I would imagine, would be the fpga code. It would be a bit sweeter if we could use an fpga like the Mojo that programs easily with the Arduino on-board.
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
-
1
-
-
In MESS I had to assign the cartridge type "gromemu" to Plato to make it run. Without ever having a look into the real cartridge, I suppose it has some GROM emulation by normal ROM and a logic circuit. Apart from that, I never saw real 8K GROMs in a 16-pin package.
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.
-
Plato also runs only in GROM 0, so I patched that, but it is patched only as far as the 'load diskette' screen.
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.
-
Right, the idea for that is you would hide such software from the console menu by hex-editing its header to one so that the multicart menu recognizes it but the TI ROM doesn't. ">A55A" is defined for this purpose (replacing the "AA" in the first byte and the 'version' in the second, which is usually "01").
(Edit: although that is a problem for GROM programs that have powerup routines, DSR, or subprograms, and need the AA byte to be valid. In /that/ case, assuming a normal 6k GROM, you would change the header to ">AA5A" (ie: just the version byte), and zero out the link to the program list. You then put a new link at >7800, which is unused by a 6k GROM, and so only the multicart will find it.)
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.
-
1
-
-
Classic99's debugger makes it pretty easy to catch such cases -- just set a breakpoint as '>(6000-7FFF)' and every write to cart ROM will breakpoint. You can then edit it out in memory (and in a hex editor on the side) and continue. The trick is catching /all/ the cases. It'd be possible to make software attempt to find all hard-coded cases (which are the vast majority), but that's not coming soon. With a walkthrough of commands, I'd be happy to patch up Pirate's Isle for you, just tell me what to type. It looks like only picture loads do it.
The new multicart menu software is up too: http://harmlesslion.com/software/multicart
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
-
2
-
-
my TI keyboard stutters badly ! If I hit the keys quick and hard it is fine, but tiring, otherwise I spend lots of time backspacing and deleting characters.
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.
-
1
-
-
I tested last night with RPI and A-Maze-Ing, that was when I realized that the ROM switch was needed (so RPI could work). I implemented the byte at >6003 (bank index 00-FF, this allows for up to 2MB of ROM), but I will have to upload it after work, which will probably mean a couple of days again.
*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.
Return to Pirate's Isle will not work out of the box on a bank-switched ROM because it writes to ROM space frequently (4 times every time it loads a new picture). All of those accesses will need to be patched out, otherwise it will switch banks and crash itself. I can probably help with that too, but I'd need a walkthrough to see the whole game and ensure none were missed. But aside from that it was working.
Again, argh. I can help run these down, if you want.
-
Gazoo's loaders were all hand-coded, they didn't do any scanning, but he did use a power-up routine - see below.
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.
I'm not entirely sure why it spins in this case, it's been many years since I understood it.
It's okay. Console limitation, but can be worked around because ...
My own multicart menu program is assembly, but it scans and can launch from both ROM and GROM.
http://harmlesslion.com/software/multicart
(snip)
There is a nice unused byte in the cartridge header we could adopt... if it's a GROM we scan we could just use that byte as a ROM select. If that sounds useful let me know and I'll add it - GROM support is new and nobody but me has used it.
).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)
-
You might also want to look at Gazoo's GPL loader code. He did something in it to get around the limitation you've encountered here. . .
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?
-
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 ...
(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
):The second cure is even easier and leaves the rest of the GROM available for other things if you want. Just put the exact same code at >6000 in both the first base and second base, both at >6000. I've made a video demonstrating that.
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)
I was able to reproduce the problem... this is a lockup bug in the 99/4A init code. Basically, it has detected that you have multiple GROM bases because the contents of >6000 are different between the first and second bases, and it gets screwed up looking for GROM headers.
I had previously believed that having any header anywhere would prevent this lockup, but apparently having one in the second GROM (>8000) doesn't work.
There are two cures, and I tested both in Classic99. The first is simply to disable bases. GROMCFG won't let you go BACK at that point because the configuration tool itself won't work with bases disabled (it can not longer get to the flash device), but once it tells you BACK PROHIBITED the programming is finished and you can hit QUIT, just do that as the last step. The downside is you can't get a dump of the cart in that state.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
) -
Excellent move including the EPS (folks rarely thing of that) so that editing is simplified.
And good looking labels (always loved the clean look of the 99/4 labels...found the colour coded labels were way too busy)
Good work all around!
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
.BIN Repository - Images for cartridges that require "burning" - (NO LONGER UPDATED OR SUPPORTED)
in TI-99/4A Computers
Posted · Edited by 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