ralphb

From Wikipedia: Polyvinylidene fluoride, or polyvinylidene difluoride (PVDF) is a highly non-reactive and pure thermoplastic fluoropolymer produced by the polymerization of vinylidene difluoride. Alles klar?

Well, no, you (and others) don't need the fix. Your system seemed to cope just fine, at least with your current configuration. Some controllers seem to be more tolerant than others. On the other hand, you may consider this fix for your peace of mind. It may also speed up disk access, as I could imagine that some WE signals are missed and retried, but this is pure speculation on my part. In your particular case I can do the fix for you when we do the DSDD disk thingy. For others who absolutely have no one who can solder nearby I offer the following: If you got the cart from me, send me your cart at your cost and I'll fix it and send it back at my cost.

Yes, that's correct. You could also connect those two points, which is yet another variant. For new boards the approach without cut will also work.

Ksarul to the rescue! As he pointed out, I goofed up when I copied the bank switch circuitry from the multi-cart in that I connected the capacitor to the wrong end of the resistor. When I rewire the capacitor correctly, the disk test works just fine on my "bad" system, and response time seems improved overall. And even better, it requires only a small modification to existing boards: Just wanted to get this out. I'll add a more detailed description about the fix soon. Thanks again, Ksarul, for saving my ass!

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!

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

I'd like to post this Bank Test image here as well: BANKTEST.BIN It's a thorough test for people who built their own carts. It checks every memory location in every bank in an endless loop. If things go right you should see "BANK n: OK" for n = 1, 2, 3, 4, and be able to FCTN-= any time. If you then bring up the menu you'll see BANK TEST /m, where m is the bank that is currently selected. (Personally I seem to have a talent for bringing up banks 2 and 4, but eventually all numbers 1, 2, 3, 4 will show up.) @Omega: Maybe you could edit your first post to include or refer to WHTech and this test so that people will find it more easily.

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.

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. 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".

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).

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).

Thanks, Omega ... same thing! (Sectors 1-360 contain consecutive byte values that are easy to assess, but I think it's safe to assume that Omega's system also reads exactly 16 bytes.)

That really depends on what is causing this, but ... it's not looking good. The diag program above will probably suffice.

To examine the erratic behavior I wrote a little test program that reads disk sectors and dumps them on the screen. There's a special disk image that contains well-defined sectors so that errors are easily spotted. The first image shows my main TI system with PEB that contains a stock TI disk controller, 32K, and RS232. The second image shows another system with a similarly configured PEB. In the first system, the FlashROM works, in the second system, sector reads fail. In fact, my main system passes the fbForth test. I see no difference in both systems whatsoever. But looking at the bad system we can see that only 16 bytes of sectors are read correctly, and the status code returned by DSRLNK >0A is either >22 or >23 (top right). There's also a second image that works just like the first one but moves the entire code to RAM first, so that it's running from RAM instead of cart ROM. That yields the same result, though. So whatever it is, the mere presence of the FlashROM seems to mess with disk I/O, at least with the TI controller. Right now I don't know how to interpret this, but it would be interesting to see if Matt or Omega get more or less than those 16 bytes. diag.zip EDIT: Just had an idea -- I ran the sector test from RAM, got errors, physically ripped out the FlashROM, program kept running from RAM, error gone! So the cart does influence data transfer on the bus ... I'll have to meditate on the schematics for a while.

For some reason my Lotharek only works when connected to the internal FDC connector, but on the external connector the drive is simply ignored (Disk Manager 2 reports ERROR 16 when trying to catalog a disk). Internal drives are configured as DSK1 and DSK2, and the Lotharek as DSK3. Do I need to remove the termination from the DSK2 drive? I always thought that the last internal drive needs termination, and external drives are added on top of that. (Removing the termination will be a pain, so I though I'll ask before I try.)

Thanks for the diagnostics, Matt! So we have now: TI controller: broken CF7+: works HDX: works Would be interesting to see if other controllers and the NanoPEB work or not. I'll write a program to do some systematic testing. Console Writer is easily dismissed, but I certainly would like fbForth to be working. The FlashROM is in tri-state mode unless ROMS* is low, similarly the bank switch is only enabled when ROMS* is low. So unless the TI controller is poking around in cart space I don't see yet how this could affect execution.

From all these I'd go with timing, although I don't see what a Multicart is doing differently ... Ksarul, could you elaborate on your buffers idea? Are you suggesting that the FlashROM overwrites VDP RAM used by the controller? In single image mode the FlashROM should behave exactly like a 32K-Multicart, so if the original image works with the PEB, the FlashROM should, too.

Thanks, Lee, for the explanations. So it's working fine with FlashROM and CF7+, but erratic with the PEB.

Oh, I see. I couldn't start the editor, as typing EDIT yields some error, again both in MESS and with the FlashROM, so I thought the load was bad. If this is to be expected, then it seems that the CF7+ is working. But I can confirm that the PEB with stock TI controller (no 80 tracks mod) and the Lotharek is not working -- the file is not found. Same with Console Writer -- right now I can read with the PEB, but not write, although I've written those files at some point in the past. Still, I wonder if it's working for others with a CF7+ or NanoPEB ... And what would the PEB do differently? EDIT: Now I can write with Console Writer again, same setup as before ... erratic behavior indeed!

Well ... I fed both BIN and FBLOCKS to MESS, and voila: So it cannot work on the FlashROM as is. Lee will have to provide some insight, maybe the image is using an incompatible bank switch?! Or my FBLOCKS is bad, but then I used the most recent one from the fbForth thread.

I tested the fbForth BIN posted above, with a matching FBLOCKS, and it works fine on my machine with a CF7+ (and an attached Speech Synth). So something is different about your systems ... but what? I guess we need more data points. I'll also try with the big PEB later today. EDIT: I stand corrected, when loading large amounts of data it seems to fail at some point. I don't know enough about fbForth, but it seems more like the communication between TI and disk becomes unreliable. I also noticed that the disk activity indicator on the CF7+ lights delayed for later blocks. EDIT: Just for clarification, this is working correctly, as explained by Lee further below.

Matt, have you tried Console Writer? That one is working for me with both PEB and CF7+. I'll try fbForth when I have the chance. Again, if you have non-working programs, please check with the program being the only BIN on the SD card. This eliminates potential menu interference. If it's still acting up (and I assume it does, after Omega tested it) then it appears to be some electrical problem, although I can't think of any reason from the top of my head ...

Memory again, but in this case TI memory, plus a bit of laziness. The menu software for the TI (image browser and image loader) takes up about >800 bytes. For every image entry I create an entry of 32 bytes that contains the filename, the entry name, plus some other data like the start address. 32 bytes is somewhat arbitrary, but I wanted this to be a power of 2 so that I can SLA to go from index to memory address containing the data. So 8K minus >800 bytes is >1800 bytes left, divided by 32 bytes/entry leaves 192 entries. Since I didn't know upfront how large the menu will eventually be I decided to limit myself to 9 pages (keys 1-9) of 19 entries (that looked nice) each, so 171 it was. Only later, after I added sorting, did I remove direct addressing of entry data, so I could remove the fixed 32 bytes allocation per entry. As most entries are rather short I could fit more image entries into the cart memory. Sorting is done in scratchpad RAM, which again limits the number of entries to 255, but I also have a working version that sorts in VDP RAM instead. But in the end I couldn't find more than 6 or 7 pages worth of images anyway, and I left it the way it is.

While we're at it, let's talk about the reset button. Pushing the button will reset the microcontroller and thus reset the FlashROM, which means that it will re-read the SD card and repopulate the menu, either the native TI menu or (if more than 8 entries are found) the FlashROM menu. It will NOT reset the TI 99, because my go-to supplier only had single-switch buttons. With a double-switch button you could simultaneously short -5V and RESET on the cartridge port and thus reset the TI 99. But I didn't have that, so I connected -5V and RESET permanently, like most cartridges, to trigger reset when inserting the cart. But the upside is that you can now switch modules while the TI 99 is running. You just have to make sure that you're not executing the first cart when you switch. That's also the reason that when using the FlashROM normally, you should first reset the TI 99 and then the FlashROM -- if you do it the other way around you basically rip out the cartridge while the cartridge program is running, so the TI 99 must crash.

There seems to be one kind of micro-SD Arduino shield that's as ubiquitous on ebay as the SD one. It's almost trivial to swap them out using the current PCB layout, except that the micro-SD shield doesn't do voltage regulation and requires 3.3V. So the cart would have to supply that, which again adds to the component count. I'm quite happy about those SD shields, as they're quite compact, handle all the tedious stuff, and provide a nice, clean interface. Personally, I also find micro-SD too flimsy for my grubby hands, which was the other reason why I opted for full SD.