Shift838 Posted December 23, 2022 Share Posted December 23, 2022 does anyone have a clear easy to read schematic for the P-Code 4.0 card? The one I downloaded off the FTP site is kinda hard to read like everything is in bold. Quote Link to comment Share on other sites More sharing options...
+dhe Posted December 24, 2022 Share Posted December 24, 2022 Do you know what the actual take over mechanism is? I know when the switch is in one position, p-code is silent bob, flip it to the other and it totally takes over? Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted December 24, 2022 Share Posted December 24, 2022 I may have an original full-size schematic in a set of stuff I bought earlier this year. I'll look (and scan, as needed if I have one). 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 24, 2022 Share Posted December 24, 2022 2 hours ago, dhe said: Do you know what the actual take over mechanism is? I know when the switch is in one position, p-code is silent bob, flip it to the other and it totally takes over? DSRLNK powerup routine in the ROM starts it up. Not sure what the switch does, I always assumed it disabled the ROM. 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted December 24, 2022 Share Posted December 24, 2022 I don't remember seeing it, is there a memory map of what the TI looks like once the P-Code OS is loaded? RAM Usage Here: https://www.unige.ch/medecine/nouspikel/ti99/pcode.txt Anders via Nouspikel: Shows RAM Usage, but not the who memory map. I must assume, ROM, GROM, Memory Mapped I/O, DSR space remain constant, and only the RAM usage changes? Is there a disassembly of the ROMS/GROMS on the P-Code Card - like is available in "The Intern"? Quote Link to comment Share on other sites More sharing options...
RXB Posted December 24, 2022 Share Posted December 24, 2022 I have been asked to disassembly the GROM a couple times. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted December 24, 2022 Share Posted December 24, 2022 (edited) switch grounds the groms i think http://unige.ch/medecine/nouspikel/ti99/pcode.htm 74LS244 +5V---WWW---, ,-WWW--+5V +-----+ Switch 1M | | 1K A0>---| |--->A0 Gnd---o o---WWW---+---|>---+ . | | . 100 Ohms| '17 | . | | . Gnd--||--' | . | | . 10 nF | . | | . _ | . | | . A4---| ) ~~~ | A7>---| |--->A7 A6---| ) +---|>---+ Gnd--|EN* | A7---| ) ~~~ | +-----+ A8---|'30 )o-, | 74LS244 A10---| ) | | +-----+ A11---| ) | | A8>---| |--->A8 A12---| ) | | . | | . A13---|_) | ,----------' . | | . _ | | . | | . A4---| ) | | 12L6 . | | . A5---| )_ | | +--------+ A15>--| |--->A15 A6---| ) | | '-|12 | Gnd--|EN* | A7---|_) | | | | +-----+ 74LS21 | '---|7 | 74LS244 _ '------|5 13|--->ROM2* +-----+ Bit0---| ) | 14|--->ROM1* AMA>---| |----------| )_____________|1 16|--->Gsel* AMB>---| |----------| ) | | AMA>---| |----------|_) | 17|--->CruSel* CLKOUT*>---| |--------------CLKOUT* | | MEMEN*>---| |---------------------------|11 | CRUCLK*>---| |---------------------------|8 | DBIN>---| |---------+--------+--------|9 | Gnd--|EN* | | '--------|18 | +-----+ | A0---, 32 | | 74SC245 | A2---=)>---|2 | +-----+ | A1---------|3 | | DIR|<--------' A3---------|4 | D0<--->|B0 A0|<--> D0 A5---------|19 | . | | . A9---------|6 15|--, . | | . +--------+ | . | | . | . | | . | . | | . | . | | . | D7<--->|B7 A7|<--> D7 | | OE*|<------+-------------------------------' +-----+ | | RDBENA*<-----------------<|---Gnd '125 Edited December 24, 2022 by arcadeshopper Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 24, 2022 Share Posted December 24, 2022 Ah... looks like it disables the entire input PAL so none of the chip selects are generated. 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted December 24, 2022 Share Posted December 24, 2022 6 hours ago, RXB said: I have been asked to disassembly the GROM a couple times. Why would you need to dis-assemble them more than once? 😃 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 25, 2022 Share Posted December 25, 2022 4 hours ago, dhe said: Why would you need to dis-assemble them more than once? 😃 I mean more then 2 people have asked for the GROM GPL code disassembly. 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted December 25, 2022 Share Posted December 25, 2022 31 minutes ago, RXB said: I mean more then 2 people have asked for the GROM GPL code disassembly. isn't there a gpl disassembler? Quote Link to comment Share on other sites More sharing options...
RXB Posted December 25, 2022 Share Posted December 25, 2022 1 hour ago, arcadeshopper said: isn't there a gpl disassembler? Yea but it gets all the address backwards and all the code is backwards putting source and results in odd orders that has to be fixed to be usable. 1 1 Quote Link to comment Share on other sites More sharing options...
Fritz442 Posted December 25, 2022 Share Posted December 25, 2022 (edited) I have this one... p_code_card.zip Edited December 25, 2022 by Fritz442 7 Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 25, 2022 Share Posted December 25, 2022 17 hours ago, arcadeshopper said: isn't there a gpl disassembler? It's just a dump until someone comments all the code. THEN it's a disassembly. 4 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted December 28, 2022 Share Posted December 28, 2022 On 12/24/2022 at 1:16 PM, dhe said: I don't remember seeing it, is there a memory map of what the TI looks like once the P-Code OS is loaded? RAM Usage Here: https://www.unige.ch/medecine/nouspikel/ti99/pcode.txt Anders via Nouspikel: Shows RAM Usage, but not the who memory map. I must assume, ROM, GROM, Memory Mapped I/O, DSR space remain constant, and only the RAM usage changes? Is there a disassembly of the ROMS/GROMS on the P-Code Card - like is available in "The Intern"? The p-code card doesn't change anything that's in the hardware, of course. It has no way to do that. The takeover at startup is handled by the p-code card showing that it contains a startup routine. Then it simply doesn't return from that. That's the reason the p-code card has the highest CRU base of them all. The rest should all be able to complete their startup before the p-code card takes over. The RAM usage I showed in the file Nouspikel once got from me is mainly the 8K RAM, since that's most interesting. The operating system (p-system) uses that part of the RAM for its own business. VDP is the normal screen data, the primary code pool and the disk buffers. 24 K RAM i the heap, the secondary code pool and the stack. ROM and GROM are in the DSR space. @RXB @arcadeshopper @Tursi There's no GPL code in the p-code card, so a GPL disassembler isn't useful. You can use DECODE to disassemble parts of the GROM. I've disassembled the 12 K ROM, which does contain normal 9900 code, but only to paper listings which I've then commented by pencil. Not all of it, but the parts I've found interesting. 5 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted December 29, 2022 Share Posted December 29, 2022 To expand on this a bit, I'll make this list of what's needed to disassemble/inspect the p-code card, in case you're interested: For normal DSR ROM page, you need a disassembler which can disassemble TMS 9900 code and keep CRU bit >1F00 set while doing it. For optional DSR ROM page, you need a disassembler which can disassemble TMS 9900 code and keep CRU bits >1F00 and >1F80 set while doing it. Only the area >5000->5FFF changes when the bank switch bit >1F80 is set. Note that the GROM access addresses are in this block too, regardless of the bank switch bit. They are fully decoded and the assembly programs simply jump around them. To inspect the part of the GROM that contains the operating system, you can start with the Filer and give the Dir command on OS: volume. To inspect SYSTEM.CHARAC you can use the program PATCH. To inspect SYSTEM.PASCAL you use DECODE. Some procedures in some segments aren't properly addressed, so DECODE can't find them. If this is by accident or to make inspection more difficult I don't know. It's possible to use LIBRARY to copy the offending segment(s) to disk, then use PATCH to fix them and finally DECODE to disassemble. Note that some part of SYSTEM.PASCAL is (should be) on the root volume too. What's there overrides the corresponding segment of SYSTEM.PASCAL on the OS: volume. The file SYSTEM.MISCINFO is best inspected by using SETUP. Then there's a code repository in GROM, which contains TMS 9900 code that's transferred to the 8 K RAM. This is done twice, first during startup, when initialization code is transferred to 8 K RAM and run there, and then again when the initialization has been completed. Then code used for runtime support is transferred to 8 K RAM and stays there as long as the system is running. To disassemble this code you need to find out the addresses in GROM and then run a TMS 9900 disassembler which can keep CRU bit >1F00 on and read code from GROM. That's the only reasonable way to disassemble the initialization code. The runtime support code can be disassembled from 8 K RAM when the p-system is running, using a TMS 9900 disassembler that runs under the p-system. There's also code in the ROM on the p-code card that's transferred to the RAM PAD (>8300) now and then during execution. This is the inner part of the PME (P-Machine Emulator). It's moved to RAM PAD for speed reasons. The reason for this happening several times is that it doesn't look identical for code in CPU RAM, GROM or VDP RAM. Explanation of the files mentioned. Filer is the p-system's disk manager. PATCH is the p-system's disk editor. DECODE is the p-system's p-code disassembler. SETUP is the p-system's configuration utility. The settings are stored in SYSTEM.MISCINFO. LIBRARY is the p-system's code file handler. It's used to build or recompose units. The TMS 9900 disassembler you have to write (I've done that, in Pascal), since there's no one delivered with the system. SYSTEM.CHARAC is the p-systems default character font. SYSTEM.PASCAL is the operating system's highest level (except for the functions that are implemented by separate programs, like the Editor, Filer, Compiler and so on), mainly in p-code. The PME and BIOS are implemented in assembly on the p-code card. The SYSTEM.xxx files can be copied to the root volume (* or #4:). If they are copied to that volume, they override the original files on the p-code card. Thus you can for example change the default character set by modifying SYSTEM.CHARAC and store the new copy on the root volume. If you want to do updates to SYSTEM.PASCAL, you can do that to just one segment at a time. Thus you don't have to copy the huge SYSTEM.PASCAL file to the root volume. Note that changes to any segment in SYSTEM.PASCAL implies that it must be loaded into the machine's RAM to execute. The PME is able to run p-code from any kind of memory, so it saves on CPU RAM by executing parts of the SYSTEM.PASCAL file on the p-code card directly from GROM, without first transferring the code to CPU RAM. GPL is nowhere to be seen, even if some people believe it is, just because the GROM chips are used as a storage container. 5 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted December 29, 2022 Share Posted December 29, 2022 On 12/25/2022 at 5:08 AM, RXB said: I mean more then 2 people have asked for the GROM GPL code disassembly. But was this under the false assumption that these GROM chips actually contained GPL code? Or to look for something else? 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.