Search the Community
Showing results for tags 'grom'.
-
Do the system GROMs get their +5V power separate from the rest of the motherboard? The schematic in the back of the blue TI tech manual seems to indicate everything gets the same +5V, except for the VDP and its RAM, which has an inductor on it. I've been trying to figure out why my non-QI 99/4A is unstable. I \measured the +5V pin at the cartridge slot, and found it has 4 volts on it. This morning I opened-up the console and put a clip lead on the +5V pin that feeds the motherboard, then used an ohm-meter probe to see if there were any breaks in the power traces. At the GROM port I measured 5.5 ohms between the input +5V line and the cartridge +5V pin. Then I tried to follow the trace on the motherboard, reading about 5.5 ohms along the way, including the rail-thing along the CPU chip. I followed the trace to the motherboard GROMs, and still found 5.5 ohms. The half of the CPU chip next to the rail-thing (seems to be fed by the rail) also measured 5.5 ohms. It doesn't help that the rail seems to be a power (and maybe ground) conductor. The side of the CPU chip nearest the power connector, and the power pins on several of the TTL chips, all measured 1.1 ohms. The meter leads themselves were about 1 ohm (cheapie $8 meter). Any thoughts or hints where to look? Anything that might not be in the schematic? K-R.
-
So far, I have the following Executive and Graphics ROM images: Intellivision Master Component (standard exec) Sears Super Video Arcade Intellivision II World Book Tutorvision Standard Mattel Electronics GROM INTV88 GROM Are there any others? I don't think other clone systems like the Tandyvision One had any differences in the Exec. Creating custom GROM files should be trivial, so there might be some homebrew files I don't know about.
-
Hi! I managed to decode Personal Record Keeping to its original Basic Source Code Program. It was done using Web99. I cheated a little to find the startaddress and the endaddress of the LineTable and the startaddress and endaddress of the Basic Program Lines but it's impressive that the binary can be actually decoded. Also the line length doesn't seem to be there at the beginning of each line when compared to a standard binary for a basic program. But i simply read each line til the next 0x00. Once I get Web99 to find the 4 addresses by itsself, the tool will be able to show you the Basic Code of all Command Modules that have been programmed in Basic Language. I worked with the phm3013g.bin file (unzip the .rpk or use the attached file) where I discovered some "HCHAR" in its hexcode with the right tokens infront and afterwards, so I thought, hey this has to be decodable in some way to Basic. After accomplishing it I figured I made it more complicated then necessary since I worked with a GROM dump that had random data in the last 2K of each 8K GROM. Further the 8K blocks on the phm3013g.bin file have a different sort order than the PC99 dumps. I should have started with the PC99 files from the start, as they give you a much cleaner picture. phm3013.grm = phm3013g.bin 0x6000 - 0x77ff = LineNumber Table phm30131.grm= phm3013g.bin 0x4000 - 0x57ff = BASIC Program Lines phm30132.grm= phm3013g.bin 0x2000 - 0x37ff = BASIC Program Lines phm30133.grm= phm3013g.bin 0x0000 - 0x17ff = some other data, probaby the GPL subprograms that RPK provides to TI Basic. It could be that it's incomplete or I got something wrong. Also interesting is the use of special chars for some variables or even Subprogram Names. I had to manually replace a "LineBreak" character as Subprogram name to fix the formatting of the Source Code. Maybe the preferred to have single line characters for variables/subprograms and to save memory and they run out of standard chars. Each TI Basic program files defines the beginning of the Line Number Table in Bytes 2/3 of its binary. The End of the Table in Bytes 4/5. Both Addresses actually point you to a VDP memory. Since we are running the program from cartridge ROM, not VDP, these pointers must be different here. I still need to find those two pointers in such a Grom dump. Any help would be appreciated. In the end I would love to be able to visualize any Basic Source Code, a cartridge contains, and even decode the GPL to GPL Source. Would love to tweak around with Car Wars for example. phm3013g.bin personal_record_keeping_pc99dump.zip personalrecordkeeping-decoded2basic.txt
-
How important is the GROM address? Will the computer crash or "go nuts" if it's corrupted? A while ago, I had asked the forum about a DSR call that was giving me problems. I was just duplicating the code that Tom Bentley used in his TCIO routines, to see how to do a DSR call. Before the BLWP @DSRLNK I saved the GROM address, then restored it afterward. Not knowing any better, I did it "because Tom Bentley" did it," assuming everyone knows more about DSR calls than me. One of the responses advised that it was unnecessary to save and restore the GROM address, so I removed that part. A few days ago I was poking through a PDF file of Molesworth's "Intro To TI Assembly", which said that DSR calls will trash the GROM address, so it should be saved. I assume that things like GPLLNK (obviously) or XMLLNK use it but my programs do not directly use it. I also assume that I "know enough to be dangerous" at this point. K-R.
- 10 replies
-
- assembly programming
- dsr
-
(and 1 more)
Tagged with:
-
Hi, I am currently with Ciro in his place, we did dump his original cartridge TI Logo II - Deutsch. We did use the GramKracker device and also verified our finding by reading the grom memory when the module was in and all GramKracker functionality was off. The cartridge uses - 8K Rom - Grom 6000 (bank 3) - Grom 8000 (bank 4) - Grom A000 (bank 5) - Grom E000 (bank 7) The oddity is the Bank 6 is unused but nevertheless its memory space is reserved, as we see the last grom starts at E000 It is matching the "information" from the PC99 dump from Mike Wright, but it appears the rpk dump on whtech is using the content of bank 7 at bank6 if you examine the .bin file. Both dumps allow you to start the cartridge, but I can imagine that once the content of the last grom is required only one will work. So the question is, can the Grom Bank be modified without breaking functionality? Br Klaus
-
This console I have is thought to be a v2.2, but when I look up the GROM part numbers they appear to be from the original console. I have CD2155ANL, CD2156NL, and CD2157NL.
-
Ran accross the source code of the GPL Assembler in my files. GPLASSEMBLER SOURCE CODE.zip
-
I played the cartridge version of Parsec and the GROM emulator version (off my CF7) last night and the real cartridge 'seemed' slightly more responsive. Was that true or am I just seeing things? IS there any difference between the two.
-
With all the stuff I've lately, it got me thinking. It seems to me that a lot of things are available in the TI environment, that if brought together could really change the paradigm and set a new standard for our little ‘orphan’. The GROMS in the console for example, like Tursi showed us, with the 99/8 code floating around, we could ‘borrow’ the lower case code and replace what is already in the TI. If there are any new commands that can be ‘lifted and used’, all the better. We could possibly even change the default CYAN/BLACK screen to something a little bit more reasonable, possibly DARK BLUE/WHITE. Any of you have any ideas of something you would like to see changed or added to the basic console? It appears this may now be a possibility. Also, if there is a way to cram some extra stuff into the chips, and if the parts are available, possibly even a utility or two. (If you have not already done so, check out Tursi’s video, you’ll start drooling when you think of the possibilities he presents). Now there is that 512K UBER CART that will emulate GROM as well. Can you imagine a hacked version of Extended BASIC, or an Extended version of say RXB that had built-in routines to use and exploit the extended graphics modes of the F18A, while also staying backward compatible. Sweet!
-
I didn't want to hijack the 512K cart thread, so I thought I would post this here: I actually have a cart, custom built for me by Jens-Eike (it's with him in Germany) that is a 64K bank-switched cart with 1K of ram permanently mapped in to the end of the cart ROM space (so there is 7K or ROM per bank, and the same 1K of RAM in every bank). It also has two hardware stacks on it but there's issues with the stacks - we can do a push (post increment) but pops are proving very tricky (pre-decrement) - something to do with a lack of appropriate signals in the cart port to trigger the pre-decrement, so that might not make it into the final design. We'll have to see. It's a shame because the stacks are lovely: Simply write to an address (I think it's >7FFE) and it pushes that value to the hardware stack. Do a read from the same address and it does a pop! The RAM for the stack is taken from the 1K of RAM. Of course, you don't need to use them if you don't want them, but I want them for a TF V2.x which would have a hardware stack (and thus be faster). It's currently implemented in discrete logic, but I'd be happy to hear to from anyone that is willing to tackle the problem with programmable logic. As I say, there are issues that need to be solved. I spoke with Gary Smith about it here in the UK. He has looked at the problem and agrees that it's a tricky one. He has a tentative solution using flip-flops to induce a delay (if I have understood it correctly) between detecting a read from the stack port (triggering an address decrement) and performing the read. I'd like to get the whole thing into one chip: That is: 64k ROM, 1K RAM and all logic. If anyone is interested is doing a design please let me know. Jens-Eike and Gary has expressed an interest, but it's hard to keep the momentum going - understandable enough... We all have lives outside of the TI