Jump to content

FarmerPotato

+AtariAge Subscriber
  • Posts

    2,553
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by FarmerPotato

  1. That is the interrupt workspace. Console ROM uses it for VDP R#1, pointer to sound list, others.
  2. Confirmed: the trace L_A1 has no solder mask where it goes between socket pins ROMEN and L_A11 (latched address). I find a short between its exposed trace copper and the source of ROMEN. But how? The original pad and about 3 mm of the trace for ROMEN is gone. The rest is not damaged. I thought I would find some bridge between exposed copper and a socket pin. Final option is to remove BOTH sockets, again, and inspect.
  3. Now I can't find where I read that. Maybe on MSX forum their revised V9938 book.
  4. If it were switching to G6, writing the chars, then switching to Text mode. This is theory: I've never tried it, only read it in the manual: Most modes address Bank 0 as 0000-FFFF and Bank 1 following. But 9938 needs more memory bandwidth in G6, so the even addresses go to Bank 0, the odds to Bank 1. It can get two bytes with one address setup. I think of this as "interleaved columns". Outside of G6 it goes back to linear addressing. So flipping between G6 and others will make VRAM unrecognizable. Data must be loaded *after* changing to/from G6.
  5. Could you describe "mess" or photo the "unreadable". Are there corrupted char defs in the text? Like every other byte corrupted. I wonder how they chose to emulate the DRAM, or used some cheats. Especially G6 mode has a memory quirk, that I hope nobody relies on.
  6. No real progress in days. I had replaced the even ROM socket, U22. Its ROMEN bodge-wired to odd ROMEN, U23. (Lifted U22 ROMEN pad/trace due to soldering at 570 F.) What I see now is ROMEN pulled low to read 0000, but wobbly 1-2V when reading 0002. Bus has: Cycle Addr Data Comment RSET 801E 801E acknowledges reset INTA R 0000 8000 correct data.. but is it coincidence? high bit AD15 likes to float high. WS W 8018 xxxx address of R12. Should be 801A for R13. WS W 801C xxxx should be 801C WS W 801C xxxx should be 801E INTA R 0002 0002 should be 0054. data bus probably hi-z. Might be 573 latch or CPU holding last inputs. IAQ R 0002 0002 shows that PC got 0002 AUMS xxxx locks up in infinite loop ROMEN and L_A1 are wobbly when they should be 0 and 1. Looks like a short from ROMEN to L_A1. Their traces travel together next to the destroyed pad of ROMEN. I guess I could remove the socket again and wire ROMEN up and over. And, spend equal time building on PCB #2 with lessons learned. PCB #1 may be toast. Three of the RAM data pins go wobbly in a similar way. I see a pattern that corresponds to the address being read. Possibly the same kind of short, but on L_A8. The most likely place for these traces to short is where the toaster oven landslide wrecked the '573.
  7. Yay! Copying it this thread. This will make another option for Geneve 2020. My designs for video card currently include: Easiest: hosted F18A (16K) Middle: V9958 RGB out. Got this mostly. Other: V9958 socket with no analog Hard: V9958 with built in VGA/SVGA converter.
  8. Theory: I'm suspecting that the 3 problem RAM data pins are poorly soldered or loose. If there were contention on the bus, it should manifest in other ways. If the RAM had pins shorted together, it should create problems everywhere. I might move on to building the second board copy, with lessons learned. The damage to #1 is a problem. Difficulty re-applying the wire fix for destroyed pad ROMEN on ROM U23. tested it's not shorted to its neighbors, but I may have broken another trace.
  9. Oh wow! Go for it! Navigating a board's initialization steps is confusing the first time. Then you forget and re-learn it Keep notes!
  10. If you have SRAM in the DSR, your program only has to enable the card then copy it to >4000. I can imagine a bit to enable writing else protect. If you want to write to Flash in-system, it's a 6-byte command stream to unlock it. The catch is: you have to maintain CE during the bytes. I think you can just tie CE low and gate your chip enable to OE.
  11. No closer to solving the bus contention or weak drive from RAM. There are a lot of drivers waiting on the bus, with their own OE disabled. I can't find the fan out number for the IS61..256x16 RAM. Maybe reflowing the pins will help. I replaced the PLCC with damaged pin. Also redoing the wire to pin 2 whose pad I ripped up very early. Curious thing up above. When SBO 31 reads R12 = >8080 its result is... undefined. The address emitted in the BST=B cycle /IO) is A0Bx something. The data is the usual undefined value 801F. If I get tired of the RAM problem I'll just change the CRU address to 1280 and play with that Exciting news for me: Digilent will support my NI VirtualBench 8012 scope. NI last supported VB-8012 in 2019; a promised update never got past Beta. Digilent sells VB as Analog Discovery Pro, but with their own software Waveforms. As of September 2023, Waveforms supports the old VB-8012. One new feature I'll get from Waveforms is the Impedance vs frequency chart. Thinking of how to take advantage of that.
  12. I didn't try til now. I feel like it should last longer with such light use. I doubt that it is ideal to put .025" header pins into ZIF. It pops out. A machine socket underneath. The adapters with the common 0.025" breakable header can't plug in directly. Pluggable pins would be 0.018" solder tails. (and they might cost 10 cents each?) Mostly what I want is PLCC-28 and PLCC-32 now. I wonder if I will make some in the future.
  13. Now that the data pin is cleared up. LI R12,>1380 It reads >1380 from ROM and writes >1380 into R12 at RAM >8018. SBZ 31 It reads from R12. The data bus goes wobbly. It shows 0380 .. 0080 .. 8080 .. 0080 .. 8080 and that is what is sampled. That results in a write to CRU >80BE. So no RECOGNIZ tonight. The bits that were lost are AD12,AD9,AD8 (>13). They are all very weak on the scope. It seems to just be the MSB. Something somewhere may be contending just the MSB of the bus, and it's sucking all the current out of the RAM driver. Pathetic "1" bit First pulse is ROM driving the pin. Second is CPU writing to RAM. Third is RAM emitting the 1. It looks so sad. A7 is fine. (The label wrongly says AD9) First pulse is CPU writing to RAM, second pulse is RAM emitting the 1.
  14. YES! That's the flying thing that keeps landing on my desk! How do I make it stop buzzing? Oh look, we're on page 20 of 20 now.
  15. Tonight I'm working on serial, and I think there is another short, somehow. I defined >1380 as the 9902 CRU address. RECOGNIZ matches on this in order to assert the 9902 chip enable. But I see the CRU cycles on the logic analyser going to address >1280 and up, and no chip select ever happens. It's just one bit wrong, it must be a glitch? No? Must be a loose pin, then, huh? The real pins on the 99105 are definitely carrying >1280 and up. I see the CPU fetch the instruction "LI R12,>1280" from the ROM, and then 1280 is everywhere. I pulled and verified the ROM again. 1380. Trying to guess what would cause this. I haven't noticed any other bad reads, but it does lock up frequently. Listing: 0155 * Set up the TMS9902 0156 0096 reset equ $ 0157 0096 0300 limi 0 0098 0000 0158 009A 020C li r12,conr12 cru address of port rs232/2 009C 1380 0159 009E 1D1F sbo 31 reset 9902 0160 0161 * wait minimum 11 clock cycles .... 0182 0183 * all 4 register-load bits are set after a reset 0184 0185 00BE 3220 ldcr @ser8n1,8 load the control register 00C0 0084 0186 * ldcr @intvl,8 load interval register, but don't turn on the interrupt 0187 00C2 1E0D sbz ldir do nothing with the interval register 0188 00C4 3320 ldcr @br9600,12 load the the reception rate and emission rate 00C6 0088 0094 0086 The values come from: 0125 0084 83 ser8n1 byte rcl1+rcl0+sbs1 ldcr @ser8n1,8 addresses a byte 0143 0086 001A br19k data >001a 11 bits: baud rate 19200 @ 3 MHz 0144 0088 0034 br9600 data >0034 11 bits: baud rate 9600 0145 008A 0068 br4800 data >0068 11 bits: baud rate 4800 0146 008C 00D0 br2400 data >00D0 11 bits: baud rate 2400 0147 008E bauds equ $ 0148 008E 008C data br2400,br4800,br9600,br19k 0090 008A 0092 0088 UPDATE: I poked Kynar wire into the vias along AD8, from CPU to the Land of ROM. It is a dangerous, subterranean route, a river that twists through the wreckage where a metal-slide once demolished a '573 up top. Pads and traces have been repaired with crude wires. Below the plane, the solder mask has buckled and bulged as if from a dragon's breath. But the brave little continuity signals its health from every via! It is interrupted between the top of the socket and the chip. The chip outputs a '1' correctly (yellow trace). I believe I damaged the contact with a PLCC extractor. Right next to it. It's bent out of shape and off the pad. But, repaired, it works again. (yellow = red)
  16. More about RECOGNIZ.pld . I'm calling it that now. DOS, baby. I tested that RECOGNIZ emits the correct signals when the CPU writes to special addresses. A FAULT interrupt can be raised if the BIOS is supposed to react to changed data. FAULT is how I implement the map registers and GROM address, in software. When in MDOS mode, RECOGNIZ asserts E_PAD* when it sees an address that is RAM onboard the 9995. It also asserts E_PAD* when there is a write to the Mapper or to GROM ports. E_PAD* causes the DECODER to open up a hole with RAM shining through. In the case of Write Mapper or Write/Read GROM, RECOGNIZ tells Decoder to raise a FAULT, and a two-bit fault code gets latched. Let's say MDOS writes a word to map registers at F110. RECOGNIZ opens a RAM hole, the two bytes drop in like a piece of mail, two bits of fault code are latched, and the FAULT interrupt occurs. The interrupt handler figures out what to do. The fault code tells it to look at the program's map registers in RAM. It sees that the two bytes at F110 have changed. Since these are 8-bit page numbers for Geneve 9640, it must convert them to physical pages which have 12-bit numbers. This would be a lookup table. The 12-bit physical page goes into the actual mapper register, and the fault handler is done. GROM also depends on FAULT. The fault handler figures out what to do, using the fault code and the values in those RAM holes. If the code indicates GROM Read Data, it knows that the program used up the latest byte at GRMRD, so it must fetch the next byte, increment the GROM address, and stick new bytes into the holes for GRMRD and GRMRA. If the code indicates GROM Read or Write Address, or Write Data, it does the expected grommish thing, updating all the RAM holes. So the next instruction that reads from them sees what it should. In any case, the content of GROM comes from the pages where MDOS or GPL keep it. It can't be any slower than actual GROM chips can it? I thought I'd need to build hardware for GRAM emulation, but it looks like software is a lot easier. This was one of messiest problems to solve. GPL and MDOS modes both access the mapper this way (GeneveOS can also flip to GPL mode and write to 8000.) It means they have protected memory. You'll have separate concurrent processes for MDOS, GPL, Forth, whatever. They can't possibly clobber each other's memory. More or less of the onboard RAM 1.5 MiB might be allocated to the Geneve 9640 HAL. It doesn't even have to be contiguous pages. (HAL = Hardware Abstraction Layer.) If you want, you can imagine virtual memory based on this mechanism. The fault handler could make MDOS think that it has full RAM, when it really doesn't, and pages are saved/loaded to Flash as needed (TI called this Roll Out in DX10.) There are more uses for the mechanism. For inter-process communication, a physical page can be shared. (Think of a debugger!) Multiple instances of the same program can share the original code pages--provided that there is hardware to support read-only pages and copy-on-write pages (COW). You could avoid having to load a program back into memory again. In the next board revision, I plan to implement more FAULT codes and memory trace. I will use the same CRU locations that the 990/12 has. I'm realizing that all the special CRU addresses in the 9995 or 99105 are consistent with the 990/10 or /12.
  17. The ZIF damage drives me crazy. You know they advertise that the T56 ZIF is "replaceable?" I think the big pins on the PLCC and other adapters just chew it up. Wonder what a better socket would use. My T56 started failing 4 pins on a SST39SF010A Flash PLCC32 last night. It Couldn't verify the last known good chip either. Tried two adapters! so it's definitely the ZIF. . After many tries I got it to work. Notice that the adapter pins don't sit evenly in the ZIF. One side or the other can fall in a deeper hole. I try to keep it centered.
  18. Vintage electronics toolbox. Literally. There is a fuse and AC cord coming out the back. It seems the power supply, breadboard, and ammeter are permanently mounted inside. https://www.ebay.com/itm/266449527569?hash=item3e09a12311:g:PisAAOSw8EZlJZ2c $84.99. TTL Compatible!
  19. I think those temperatures would be too high. The Sn/PB alloys start to melt at 183 °C, 361 °F. I settled on working temperature 232 °C, 450 °F, or 470 °F when it seems slow. That happens to be the MAXIMUM on the 63/37 paste temp profile. In mid-life, I put a little more money into better tools and solder. I'm using: Solder: Just 0.8mm (0.032"). Radio Shack 60/40, til it runs out. Also MG Chemicals 63/37. Paste: ChipQuik TS391AX 63/37 has become my favorite! Room temperature stable (since 2019!) Hate the metal hypo tip. Plastic cone works for me. Flux: Syringe, ChipQuik SMD291 63/37. Tack Flux. Didn't like the clear liquid. From this Kester temp chart: Mid-Range °C °F Sn60Pb40 183-190 361-374 wire Sn63Pb37 183 361 paste, wire Sn62Pb36Ag2 179 354 paste, wire Lead-Free Sn99.3Cu0.7 227 441 wire Sn96.5Ag3.5 221 430 paste, wire I tried lead-free and hated it, especially harder to de-solder (add lead to remove it.) Technique Solder: Rich said I need a finer gauge. With 1.27" spacing, I can't bring the wire to the pad. I melt the solder on the tip and REMOVE the excess before I can make a mess & that's working great for me. Paste: I had a lot of difficulty with the metal tube tip. With the plastic cone tip, I extrude a teeny drop, then "stamp" it onto the pad. After a row of pads, I scrape up any mess, using a very thin plastic ruler (Lockheed swag). Tools $ 95 Quick 957DW+. (Clones go for $60.) $120 Hakko FX-888D for temp control. Temp Control really wants to be your friend!!! Not sure I believe the readout. Experimented to get 450-470 °F. Around 550 °F, it can gouge the solder mask, lift pads and break traces like Superman! The "K" Knife tip is my favorite--it holds a lot of heat and solder, the sharp corner is great for drag solder. My favorite overall. Sold separately. However, Amanda prefers a sloped, sorta fine-tip, and I'm happy with that too. We tried the "C" concave type, but didn't see a big advantage. Heating Toaster oven, good oven thermometer: I got close to the temp/time curve, by manually toggling the on/off switch. Coffee warmer: I tried this to pre-heat small boards. Meh. Griddle: scary. Air Fryer: not going to go there. (* If I ever upgrade, I will get a Weller.) (** At that time, I got the PINBALL 33% discount off the bundle with now-$300 Hakko 300 desolder gun) Happy solder day!
  20. I've fought and prevailed over WinCUPL. The Recognizer PLD compiles. WinSim isn't crashing, and 20 test vectors pass. Very close to . To get WinCUPL to run stably, I tried very short paths. Hint: all Atmel example filenames never exceed 8.3. Welcome, RECOGNIZ.pld! We're calling from 1998! Learned: field MSB=[A15..8] as a signal lets you type hex addresses as '83' instead of 10000011 in the test input file. But bits keep their place value in CUPL (I knew that from before). GPL_PAD = MSB:'h'8300 /* true if address is in PAD */ Bad: WinSim GUI from 1990s. Last updated for Windows 98. Ugly: pretty much anything about WinCUPL. At least, the command line tools work as expected. Good: commented vectors & MSG in your input .si, then rely on .so output file: Earlier: Input: ORDER: MSB, NYBBLE, S2_FAULT, A3, GPL, MDOS, R_W, !DOP, !MMIO, !E_PAD, OUTS; VECTORS: '84' '0' L01000LHLLL /* GPL SOUND WRITE */ $MSG "GPL SOUND WRITE"; Output: 0013: 100001000000L01011HHLLL ^ [0019sa] user expected (L) for MMIO GPL SOUND WRITE Vector 10 tests that GPL WRITE PAD decodes properly. With RECOGNIZ in GPL mode, the CPU sees a hole at 8300 with RAM shining through. E_PAD* signals the mapper to open the RAM hole now. A FAULT interrupt can also be raised if the CPU is supposed to react to changed data. FAULT is how I implement the map registers and GROM address, in software. FAULT = !MMIO & S2_FAULT. (Outputs S2,S1,S0 carry multiplexed data, saving 3 pins!) The only FAULT=1 state in this test file is 11, GPL MAPPER WRITE.
  21. Hey, thanks, everyone, for the encouragement! Still making progress. Big job of compiling and testing Recognizer PLD, which glues everything together. More work on reference card!
  22. I first thought of it as BLWP : bluh-WHUHP) like in Wuss). The sound that Munch Man makes. BL was just Bee Ell though. There was also ruh-TWUHP. And luh-WUHPIE. Was it LIM-MEE , or LIMEY? I avoided CZC. Oh yeah: KO-ink. Like ko-INK-ee-dink.
  23. @newTIboyRob No one mentioned yet this way: 10 PRINT "WANNA":" BUY ":"A GRAPE?" 20 N = 18 30 GOSUB 100 40 INPUT A$ 50 END 100 FOR I=1 TO N 110 PRINT 120 NEXT I 130 RETURN TI BASIC behaves like a calculator with a roll of paper. Oddly, they included such a thing in the 99/4 (original): Equation Calculator. (Menu item 2.) A more limited TI BASIC that used the screen's upper half to show all your variables. (No programs, just single statements) I would construct elaborate PRINT statements in it.
  24. Yay! All the above bugs are cleared. CPU runs MEMTEST! Onward! TLDR; I removed 3 PLCC sockets (Surface mount type). There was a solder bridge I just could not get to, hidden underneath the 2nd one. By the way, the short between L_A6-L_A7 was within the 3rd PLCC socket, the as-yet-unpopulated Recognizer PLD. It was in plain sight. Cleaned all the pads, new paste, reflow with hot air. My paste application is improving--no shorts or loose pins. Running code looked great everywhere I checked. It runs through MEMTEST then waits for serial input! Working on serial port now...
×
×
  • Create New...