ralphb

Well, no, I follow the chain of linked menu items, and stop at >0000, just like the TI menu does. Are you sure that your modified image does show three items? What do you see in the TI menu if you press FCTN-=? Have you modified the menu in all banks? The "number of programs" byte is ignored, as most sources indicate that this is "optional".

Sure, go ahead, but please update the project to use board revision 2!

Sorry to hear that. Your SD seems to work just fine. If that were the issue you'd get the Red Blinking of Death (or whatever your color of LED is). The first thing to do is try the Bank Test: banktest.bin Then we'll see from there. (My first guess is that you're using bad images -- see here for a collection of good ones.)

There's a new, fixed Revision 2 of the PCB layout on GitHub now where the wiring has been swapped. I also created a page that describes how existing Revision 1 boards can be fixed, i.e., converted to Revision 2 boards. Same as described here. Finally, the homepage has been updated.

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.