Tursi Posted May 25 Share Posted May 25 It's not CRU. You haven't even touched CRU yet. That's the 9901, and it's not initialized till after the sound chip is turned off. You can safely disregard it till the sound chip is shutting up - the only thing it could possibly interfere with at this point is if it was somehow corrupting the data bus. Sniffing the data bus wouldn't hurt - we could go through the same initial bytes process and probably confirm the data coming from the GROM as well. That said, we can be quite confident that the data from ROM and data from SRAM are both valid, so it doesn't seem like there's anything interfering. "Dummy read from GROM (why do a dummy read?)" -> The GROM address is set by writing two bytes to the address port. But at powerup the internal flip-flop for first or second byte is set to an indeterminate state. Reading from the data port guarantees to reset the address flipflop. "Do some other magic stuff to finish loading GPL interpreter" -> just setting the start address in the GROM. Then it's finished initializing and started execution. >0070->0072 enable and disable VDP interrupts briefly to let the console interrupt routine function if an interrupt is pending, and >0074 fetches a byte from the GROM to start interpreting. So software-wise -- assuming we aren't getting garbage on the data bus -- things are humming along nicely. So I recommend we next focus on those first 5 init instructions. So "load speech write" is just writing a byte to >9400, which is the dedicated address of the external speech synthesizer. Per http://www.unige.ch/medecine/nouspikel/ti99/pinouts.htm#Side - pin 2 should be the speech enable pin (SBE), and it should pulse high according to the page for that write. For the sake of this diagnosis, that's all that is expected (since there's no speech synth attached, it's just a blind write.) Then the four writes to the sound chip, of course. "But, since the chip isn't shutting up and it's making a wonderful screech noise, we're losing the plot somewhere before the "set sound generators" instructions. I've actually confirmed this by checking A3, A4 and A5 as well as the chip enables coming into the LS138 that decodes that into 8400 for writing to those sound generators on the sound chip. The address never hits, and it never gets written." It should be A0, A1 and A2 that come into the first LS138, but I'd start simpler and just look at the output bit. Should be pin 11 (Y4) for the >8xxx range. I've never poked into that decode, but the output of it probably goes straight to the chip enables anyway. The Bunyard book I sent above should have 4A schematics which will be close, and I'll attach the 4 schematics I have just in case you don't already have them. I don't know how accurate they are.Schematics ti99-4 (not a)-jan-1980.pdf (I can't believe it let me post the whole thing! Thanks AA!) According to this, the primary address decode (A0-A2) should be U504 (see page 6). From there pin 11 is used to feed an enable along with A15 to the second LS138 (U505) to break the address down. The sound chip enable is fed from pin 14 (Y1), and SBE is driven by both pins 10 and 11 (Y4/Y5 - for read and write on separate addresses) through a NAND gate (U506). U506 also feeds one of the enable pins on that second LS138. So... if I understand - we have not really proven that the GROM circuits are working 100% - are we getting valid data back from the GROMs? Maybe if we can sniff the first cycles of data in the way you captured address, we should be able to suss that out? Assuming GROM is working, verifying SBE and the sound chip selection (pin 6 of the 9919 at U511) is the next step. Verify we get output pulses from U504 pin 11 first. Looking at U505 will be trickier since it includes A15 (requiring the multiplexer to work) as well as NAND gate U506. As a start I'd probably just ensure A15 is toggling without worrying too much about whether it's toggling at the right time (seems a fault would more likely leave it stalled), and check that U506 is working. Incidentally, the 138 U505 also provides the VDP decode (pins 13 and 12), so this does feel like the right area to be looking. The hardware side is not my forte, so take a lot of what I say here with a grain of salt. 4 Quote Link to comment Share on other sites More sharing options...
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.