+arcadeshopper Posted June 8, 2016 Share Posted June 8, 2016 test from rom https://goo.gl/photos/GAYfoPA2vskagFYb6 test from ram https://goo.gl/photos/Pb9m4qnj1VhpVDL3A 4/a with peb, corcomp disk controller + sams card + hdx/rs232 card + personality card 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 8, 2016 Author Share Posted June 8, 2016 (edited) test from rom https://goo.gl/photos/GAYfoPA2vskagFYb6 test from ram https://goo.gl/photos/Pb9m4qnj1VhpVDL3A 4/a with peb, corcomp disk controller + sams card + hdx/rs232 card + personality card Thanks for testing, you're fine as well. There's another test I want to run tonight, which will provide additional insight on whether this is an electrical problem or a logic problem. EDIT: BTW, I think I forgot to mention that you can page through sectors by pressing , and . (like the FlashROM). Edited June 8, 2016 by ralphb 1 Quote Link to comment Share on other sites More sharing options...
+Torrax Posted June 8, 2016 Share Posted June 8, 2016 Is the intial CRU state of the TMS9901 being affected?? As the silver consoles allow access to this from the cartridge port. This was removed from the beige units. Best bet is to try the TI FDC/PEB setup with a beige console. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted June 8, 2016 Share Posted June 8, 2016 I have a Corcomp sidecar expansion system with a FDD and HxC. Will look through thread to see what I need to do to test. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 8, 2016 Share Posted June 8, 2016 (edited) My console is beige w original groms(not qi) Edited June 8, 2016 by arcadeshopper Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 8, 2016 Author Share Posted June 8, 2016 I found the issue (I think), and it might even be fixable (I hope). It's the bank switch that mangles WE* on the bus, as WE* is the only signal not shielded by the line drivers. (I haven't seen this, but I concluded this from my tests.) But then this isn't really different from multi-carts, which is why I hope this could be fixed. I'll discuss this with the multi-cart experts. Still, I'd be interested to see which controllers are affected by this, so if you have a card not mentioned previously please do report (likewise if your experience differs from the report here). 2 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 8, 2016 Share Posted June 8, 2016 . So maybe I could check the Atronic CPS99, the DDCC-1 (Standard), and the NanoPEB v2 tonight. Can I copy this test-disk.DSK with the DuskUtils 4.2 as sector-copy to a real floppy ? Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 8, 2016 Share Posted June 8, 2016 . So here is the 1st result, on the Atronic CPS-99: Do I have to press the "." up to the end, or can I see an error right on the first screen (sector 0) If so, I think I have to repeat the test with the other controllers from yesterday, as I did not know abot the "." and more sectors. In this test here, I did 3 sectors on both tests (without and with this "RAM"-entry) Test1 without "RAM": Test2 with "RAM": xXx Quote Link to comment Share on other sites More sharing options...
+acadiel Posted June 9, 2016 Share Posted June 9, 2016 I found the issue (I think), and it might even be fixable (I hope). It's the bank switch that mangles WE* on the bus, as WE* is the only signal not shielded by the line drivers. (I haven't seen this, but I concluded this from my tests.) But then this isn't really different from multi-carts, which is why I hope this could be fixed. I'll discuss this with the multi-cart experts. Still, I'd be interested to see which controllers are affected by this, so if you have a card not mentioned previously please do report (likewise if your experience differs from the report here). Without digging too much into it, remind me... when we write to cartridge space, doesn't ROMG* go low? This enables the bank switch chip in what we've used with the 377/378/379, and that latch is now enabled and responding to clock inputs. WE* is then pulsed low, which clocks the bank switch chip, and then sets up the outputs that are hooked to address lines, enabling or disabling certain 8K areas of the chip. When we're done, ROMG* goes back high, which shuts off the bank switch chip, right? I think what happens the next time the cartridge space is then READ, ROMG* goes low again. But there's no clocking, so I believe it remembers the last outputs, so you get a specific 8K bank that you last selected as available. Any messing with the WE* would mess with the cartridge banking, but only if ROMG* is low and the bank switch chip is responding to clock inputs? What happens if you try to mess around with WE* when ROMG* is high? You can probably pretty easily tell the difference.... have a 'native' 16K cart that reads/writes to the cart space and brings ROMG* low multiple times while reading/banking, and see what kind of effects that has versus one of the 32K cartridges that 'copies to RAM' and then executes, never again reading or writing to the cartridge space, and never messing with ROMG* (or writing to the cart space and messing with WE*). I'm quite a bit tired, so some of this might be wrong, but I'll leave it up to Tursi, Stuart, and others to correct me and slap me into shape if I'm wrong on any of it. 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 9, 2016 Share Posted June 9, 2016 For the TI controller, what do you see in >8370? It should be >37D7. Add 1 to whatever you get and check the first 6 bytes at that VRAM address. In hex, they should be AA3F FF11 0300 If the value in >8370 is not >37D7, check the first 6 bytes at VRAM >37D8, anyway. What are they? Ok, to close the loop, I get all of these same values. 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 9, 2016 Share Posted June 9, 2016 There *MAY* be a simple & acceptable hardware based 'workaround' for the TI-FDC issue if a software based fix proves impossible. Since it appears the programs are just loaded off the cartridge, and run PROPERLY once the cartridge is removed, how about just simulating the removal of the cartridge? Would it be possible to just sever one or two traces on the cartridges connector and install a switch? Granted we would probably NEED a decent 3D printed case to mount the switch on, but you have to admit, it might be a very simple and cheap solution. https://www.youtube.com/watch?v=Gsd323cJMQ4&feature=youtu.be 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 9, 2016 Share Posted June 9, 2016 As for my sectors/diag output, I occasionally see a 22__ in the status output. The sector load is particularly slow too just before an error. It is perceptibly slower than I'm used too. When I remove the cartridge with the sector viewing program running from expansion ram, it becomes faster, and I don't see anything but 00__ in the status output. -M@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 9, 2016 Share Posted June 9, 2016 There *MAY* be a simple & acceptable hardware based 'workaround' for the TI-FDC issue if a software based fix proves impossible. Since it appears the programs are just loaded off the cartridge, and run PROPERLY once the cartridge is removed, how about just simulating the removal of the cartridge? Would it be possible to just sever one or two traces on the cartridges connector and install a switch? Granted we would probably NEED a decent 3D printed case to mount the switch on, but you have to admit, it might be a very simple and cheap solution. ... That would be fine for programs that just load into expansion ram off the cartridge. However it wouldn't work for loading the favorites file from Stuarts browser, or the fblocks and font files for fbForth. TurboForth should work from this cartridge as well, and would have the same problem, as these programs all reside on the 32k ram in the cartridge at execution time. -M@ Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 9, 2016 Share Posted June 9, 2016 That would be fine for programs that just load into expansion ram off the cartridge. However it wouldn't work for loading the favorites file from Stuarts browser, or the fblocks and font files for fbForth. TurboForth should work from this cartridge as well, and would have the same problem, as these programs all reside on the 32k ram in the cartridge at execution time. -M@ I cannot say about fbForth or TurboForth as I've not tried them but IT DOES work with loading the favorites file while using Stuart's browser. I did that experiment about 1/2 hour ago and even commented about it on the TI-Chat while I was doing it. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 9, 2016 Author Share Posted June 9, 2016 Without digging too much into it, remind me... when we write to cartridge space, doesn't ROMG* go low? This enables the bank switch chip in what we've used with the 377/378/379, and that latch is now enabled and responding to clock inputs. WE* is then pulsed low, which clocks the bank switch chip, and then sets up the outputs that are hooked to address lines, enabling or disabling certain 8K areas of the chip. When we're done, ROMG* goes back high, which shuts off the bank switch chip, right? Yes, and yes to everything else you wrote. This is not what I meant, though. WE* on the bus is directly connected to a resistor and a capacitor on the cart, in order to delay the signal for the bank switch. But wouldn't this delay the signal for the entire bus, even when the cart is offline, i.e., ROMS* is high? That's what I meant with "mangle WE*". When I remove resistor and capacitor the cart works fine on my bad system, but of course bank switching no longer works. It seems that the TI FDC is really sensitive to WE*, whereas other controllers appear more lenient. how about just simulating the removal of the cartridge? I've tested this, and it doesn't work. That's why I concluded it must be the WE*, as that is the only signal that cannot be "removed". Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 9, 2016 Share Posted June 9, 2016 I've tested this, and it doesn't work. That's why I concluded it must be the WE*, as that is the only signal that cannot be "removed". Well, that SuX! Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 9, 2016 Author Share Posted June 9, 2016 Do I have to press the "." up to the end, or can I see an error right on the first screen (sector 0) Thanks for the results, as thorough as ever. Sector 1 using the ROM test is sufficient. So far you can also tell from sector 0, unless the "stuck byte" would happen somewhere in "FF"s, which is why I put a non-repeating pattern in sectors 1 and up. The RAM test was meant to test if running from the cart was causing this, but by now it's been established that this is not the reason for the issue. 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 9, 2016 Share Posted June 9, 2016 ah thanks I´ll try to do the other tests today. ... OMEGA, great find you are a hacker Maybe it is woth a try NOT to >Eject< the cartridge at this point, BUT to press the >Reset<-Button on the cart ?? Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 9, 2016 Author Share Posted June 9, 2016 (edited) Well, that SuX! Well, your hack does work if you place your switch after the WE* pin ... but it's not a general solution, just for those images that move to RAM or do not use bank switching (i.e., 8K images could still run from cart ROM), and it requires physical interaction. Still, we might be able to do better than that, just give it some time. EDIT: clarified why it's a hack Edited June 9, 2016 by ralphb 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 9, 2016 Share Posted June 9, 2016 WE* on the bus is directly connected to a resistor and a capacitor on the cart, in order to delay the signal for the bank switch. Ouch ... that sounds ugly ... Wouldn't it be a better choice to use some latching and READY control? I don't have a complete solution in mind, but I'd try to delay using the clock line. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted June 9, 2016 Share Posted June 9, 2016 Ouch ... that sounds ugly ... Wouldn't it be a better choice to use some latching and READY control? I don't have a complete solution in mind, but I'd try to delay using the clock line. Well, the capacitor is just a simple filter capacitor. If you look at the original V3 64K board schematic, it simply filters between GND and CP. All the original bank switched carts by Atari and Databiotics used this, probably to keep the signal in tolerance for the LS379. The spec sheets on the 379 do assume a CL (capacitor - as part of test conditions), I'm guessing for this very reason. Now, the resistor, I don't know for certain. It's connected through from CP to WE* per the schematic below. However, this was a design choice made based on the Atari and Databiotics bankswitching methods. I do know that I did try without it, so there must have been some technical reason between the CP on the 379 and the WE* signal that they needed it to get WE* to trigger CP properly. I did have a hard time getting it to work without that resistor in place, so I'm gathering engineers of the past put it there for reason. I just never looked into it and the technical details of why it was there. Quote Link to comment Share on other sites More sharing options...
Stuart Posted June 9, 2016 Share Posted June 9, 2016 The spec sheets on the 379 do assume a CL (capacitor - as part of test conditions), I'm guessing for this very reason. I always assumed that the capacitor in the test specs was there to simulate the track capacitance you'd get in a typical 'real world' circuit. May be wrong though! If /WE needs to be delayed for the bank switch, I'd suggest getting a hex TTL inverter and feeding /WE through successive pairs of inverters, and see if the propagation delays provide a long enough delay. You're then not affecting /WE to the rest of the console. Could probably wire up the inverter without having to hack the board about. 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 9, 2016 Author Share Posted June 9, 2016 If /WE needs to be delayed for the bank switch, I'd suggest getting a hex TTL inverter ... IIRC, WE* is just a pulse, and the RC circuit widens that pulse and thus delays the rising edge. I like the inverter idea, but If playing around with R doesn't help then a 555 might take up less space on the board. Time to experiment! Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 9, 2016 Share Posted June 9, 2016 Still, we might be able to do better than that, just give it some time. No problem, I'll be lurking, as I really don't have much to contribute to this thread. I will tell you this, when I purchased the thing, I figured it was just going to be a glorified, easy-loading, mega-games cartridge. I had no expectations of using it with a disk drive or running cool programs like Stuart's Internet Browser, TIMXT, DM2K, DMII, etc. so that's all a happy bonus in my book. So WHEN the solution comes to fruition, I'll be doing the happy dance. 1 Quote Link to comment Share on other sites More sharing options...
ti99iuc Posted June 9, 2016 Share Posted June 9, 2016 (edited) As i wrote in one of previous post in this thread i worked on the labels These are my own labels for the FlashROM 99if someone interested i can post there the images to print. 1) Label for ROMOX Shell - Standard Mod 2) Label for TI Standard Shell Edited June 9, 2016 by ti99iuc 6 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.