+mizapf Posted October 3, 2016 Share Posted October 3, 2016 I'm planning to add CF7+ capabilites to TIMT and MAME. As I understood, the CF7+ stores 1600 sector volumes one after another on the CF card (only using 256 bytes out of 512 bytes). Since there was no way to achieve a write access from my Java-based tool to the CF card (I tried all the suggestions and links that you once sent me), TIMT does not offer to read from or write to a device anymore. This may be less comfortable, but it is also safer: If you provided the wrong device, you would be able to damage your computer file systems. So this is now on your own, TIMT won't make that easier for you. :-) In Linux, where this was actually working, it was necessary to run TIMT as root or to grant the user direct access to the disk drives - both of which definitely lower your karma, in case you are concerned about that. One question to CF7+ users: What does working with CF7+ and the PC look like? Do you have a way to copy the CF contents to your computer disk and back again? If so, things would work like this: (a) Dump the CF to your PC, (b) use that dump in MAME/TIMT, © write the dump on the CF again. Linux users would want to use the dd command for that; I don't know if there is already a suggested procedure for that, though. I'd need such an image for testing the implementation, with some defined volumes with sample files. So maybe someone could send me an image, or give me a link where to download it from. And: Does CF7+ belong to the nanoPEB, or are there separate CF7+ installations with the standard PEB? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 3, 2016 Share Posted October 3, 2016 ... One question to CF7+ users: What does working with CF7+ and the PC look like? Do you have a way to copy the CF contents to your computer disk and back again? If so, things would work like this: (a) Dump the CF to your PC, (b) use that dump in MAME/TIMT, © write the dump on the CF again. Linux users would want to use the dd command for that; I don't know if there is already a suggested procedure for that, though. The programs that copy to/from the CF7+/nanoPEB are copying 400KiB/1600-sector images, not (to my knowledge) dumping/loading the entire CF image. Fred Kaal's TI99Dir and Jaime's CF2DSK and DSK2CF do the transfers that way. I'd need such an image for testing the implementation, with some defined volumes with sample files. So maybe someone could send me an image, or give me a link where to download it from. Again, TMK, it is a matter of copying individual DSK images back and forth. And: Does CF7+ belong to the nanoPEB, or are there separate CF7+ installations with the standard PEB? AFAIK, the only difference between the two is that the CF7+ has a parallel port and the nanoPEB, a serial port. Otherwise, they are the same. ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 3, 2016 Author Share Posted October 3, 2016 The programs that copy to/from the CF7+/nanoPEB are copying 400KiB/1600-sector images, not (to my knowledge) dumping/loading the entire CF image. Fred Kaal's TI99Dir and Jaime's CF2DSK and DSK2CF do the transfers that way. Hmm ... it does not make sense to first use Fred's program just to copy from CF, then use TIMT - you could possibly do anything after that with TI99Dir. I hope for a simple solution; I'm checking "dd for Windows" (not WinDD) which may be helpful here. AFAIK, the only difference between the two is that the CF7+ has a parallel port and the nanoPEB, a serial port. Otherwise, they are the same. Sorry, my question was somewhat unclear. I meant to ask: Can a CF7(+) user have a PEB (possibly with all other cards) attached, or does a CF7+ user always have a nanoPEB (which, to my understanding, does not allow for a PEB to be attached)? This is important for MAME. It would not make sense to emulate a CF7+ device like a PEB card if this is impossible in the real world. (Remember that MAME does not try to be better than the original. ). For example, you could decide to write a program that is stored on an emulated CF7+ which also expects a Horizon Ramdisk to be present, or a P-Code card. This would be an emulation artifact that has no meaning on real iron. So if it means: CF7+ "yes" means "no" to Peripheral Expansion Box, this enhancement will get lower priority. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 3, 2016 Share Posted October 3, 2016 Neither the CF7+ nor the nanoPEB provides a pass-through connection for the PEB. That said however, folks here have inserted a short Y-cable to effect just such a scenario (Jim Fetzner, for one, I believe). You just need to be careful of conflicts with the 32KiB memory expansion and disk controllers. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 3, 2016 Author Share Posted October 3, 2016 Ah, OK, I just saw that I mixed some things together. I believed that the CF7+ is a part of the nanoPEB because the latter one also uses a CF card with the same format, but they are two different devices. What seems true is that from the handling of the CF, both are equal, and neither of them allows for connecting a PEB without the said Y-cable. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 3, 2016 Author Share Posted October 3, 2016 (edited) OK, stop this thread ... I just found my own thread from a year ago, delivering enough information for now. Edit: OK, maybe one more thing: Where is the difference between CF7, CF7A, CF7+, and CF7A+? Which of these is compatible to the nanoPEB (so you could swap the CF cards)? Edited October 3, 2016 by mizapf Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 3, 2016 Share Posted October 3, 2016 As far as I'm aware the CF Card format is the same across all of those, the differences were minor hardware revisions and changes to the external interface (parallel port on one, and at least two versions of the serial UART for the serial one). I'm afraid I don't know which was which. The name "nanoPEB" and "CF7" are somewhat interchangeable for at least one of those versions... 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 3, 2016 Author Share Posted October 3, 2016 Sounds as if it would suffice to define one "CF7 format" to suit all kinds. This is good news. Also good news is that "dd for Windows" (http://www.chrysocome.net/dd ) does what its name says, and since it is GPL-licensed and TIMT also, I can put a copy into the package and have it called from Java by Runtime.exec. A bit scary is that I was not asked by Windows to run that tool as administrator, but I was still able to write on the CF card. Maybe this is possible because the CF card is not mounted by Windows. 2 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 4, 2016 Share Posted October 4, 2016 Anything that has CF7 as part of its name has a parallel port, 32K, and a CF disk. Anything that has NanoPEB as part of the name has no parallel port, as this was replaced with a serial port. The early version had a 9902, the later ones had a 16550. Both versions also have 32K and a CF disk. One note, all of the devices in this family respond whenever a call goes out the side port, so you cannot use them with a "Y" cable and a PEB with cards other than serial, 32K and Disk controllers. It does not work. Chris Schneider, Bob Carmany, and I tried several different options--none worked. Even with the CF7/NanoPEB shut off, it messed with the signaling. . .to the point where nothing worked. 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 4, 2016 Author Share Posted October 4, 2016 Eventually, I will have to model the I/O port in MAME as a slot device, similar to the GROM port. Currently, in MAME you get a TI system that seems to be an unseparable "console-PEB", but we know that this is somewhat different with the firehose cable. In future there could be an option "-ioport" expecting some values like "peb", "cf7", or sideport games (maybe also sideport devices). What I don't like about that idea is that this would add another element to all device path qualifications (like "-ioport:peb:slot8:hfdc:h1", denoting the hard disk connector 1 on the HFDC in slot 8 of the PEB at the I/O port"). On the other hand, once you defined it, you will soon forget about that. Maybe there is a way to simplify the addressing, have to think about that. Quote Link to comment Share on other sites More sharing options...
Stuart Posted October 4, 2016 Share Posted October 4, 2016 (edited) In future there could be an option "-ioport" expecting some values like "peb", "cf7", or sideport games (maybe also sideport devices). What I don't like about that idea is that this would add another element to all device path qualifications (like "-ioport:peb:slot8:hfdc:h1", denoting the hard disk connector 1 on the HFDC in slot 8 of the PEB at the I/O port"). On the other hand, once you defined it, you will soon forget about that. Maybe there is a way to simplify the addressing, have to think about that. Are we on the way to "-ioport:sideportsplitter(union(peb:slot8:hfdc:h1),(peb:slot2:rs232))"? Edited October 4, 2016 by Stuart 2 Quote Link to comment Share on other sites More sharing options...
Stuart Posted October 4, 2016 Share Posted October 4, 2016 One note, all of the devices in this family respond whenever a call goes out the side port, so you cannot use them with a "Y" cable and a PEB with cards other than serial, 32K and Disk controllers. It does not work. Chris Schneider, Bob Carmany, and I tried several different options--none worked. Even with the CF7/NanoPEB shut off, it messed with the signaling. . .to the point where nothing worked. When putting together my sideport EPROM programmer which co-exists with a CF7+ on a Y cable, I found that the CF7+ was pulling the CRUIN line high when the CF7+ was not being accessed, so nothing else could pull it low so you couldn't read over the CRU bus from another device. Cutting the track to pin 33 on the CF7+ and inserting a 1K resistor sorted it. I told Jaime about it and not sure if he fixed it for the nanoPEB. Might explain the problems with other PEB cards with the CF7 on a Y cable? 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 4, 2016 Author Share Posted October 4, 2016 Are we on the way to "-ioport:sideportsplitter(union(peb:slot8:hfdc:h1),(peb:slot2:rs232))"? Well, not yet. But I don't know what is inside the heads of the other MAME devs ... But the TI is a system that is particularly expansion-based, with slots and components following each other. This brings the otherwise reasonable notation to its limits... Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 8, 2016 Share Posted October 8, 2016 Stuart, that may be exactly where the problem lies when using a splitter with the CF7. I will have to test that theory soon. . . Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted October 8, 2016 Share Posted October 8, 2016 I wonder if a card adaptor for a real PEB would work. For someone with a PEB and a CF7, connect the CF7 to this PEB card and insert card in PEB. As opposed to using a Y splitter. 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted October 8, 2016 Share Posted October 8, 2016 hmm, maybe just connect the CF7+ or Nano to the Speech-in-a-PEB-adapter ? 1 Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted October 8, 2016 Share Posted October 8, 2016 hmm, maybe just connect the CF7+ or Nano to the Speech-in-a-PEB-adapter ? Whoa. 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted October 8, 2016 Share Posted October 8, 2016 No, better not Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 9, 2016 Author Share Posted October 9, 2016 I'm currently adding CF7 dump support to TIImageTool; it is already working in the way that you can open the CF dump, select one of the defined volumes, and then proceed as usual (as if you have opened a simple dsk file); see the attached screenshot. I assumed that all volumes offer 1600 sectors, with 20 sectors/track, 40 tracks, and two sides. However, with the CF7 image that I did my tests with, many volumes have inconsistent Volume information blocks: stating that the sector count is 1600, but having 9 sectors/track, 40 tracks, and 1 side, just like a SSSD disk. This was the information that TIMT displayed and which is caused by the actual bytes in the volume. Moreover, all sectors beyond 360 are allocated, which does not match the sum of sectors in the visible files. As I read, there are two utility programs, dsk2cf.exe and cf2dsk.exe, which are used to import/export disk images to/from the CF. I would interpret the result in the way that the dsk2cf program just copies the disk contents into the CF file, only changing the sector count to 1600, but not properly changing the allocation table and the geometry data. Accordingly, the volume still shows the geometry data of the original floppy disk image. My question to the CF7 users: If you import a full SSSD disk into a volume of the CF, do you have free sectors in that volume? Or do you have something like 0 sectors free, although the sum of allocated sectors is only 360? And: Would you like to have a feature in TIMT that fixes this issue? (I can leave everything as is, but it is likewise simple to fix the filesystem, since TIMT already has this function.) 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 9, 2016 Share Posted October 9, 2016 I would suggest fixing the file system so that it uses the whole image properly. That way, we have something robust, instead of a partial kludge. . . 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 9, 2016 Share Posted October 9, 2016 Is this kludge used so that users can more easily transfer disks back to their original format? I can't think of any other "valid" reasons for the different information. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 9, 2016 Share Posted October 9, 2016 I have always presumed that the CF7/nanoPEB images should be 1600 sectors. Anytime I want to copy a disk image that is fewer sectors, I have created a blank 1600-sector image and copied files from the smaller disk image to it. Having TIMT do that for me would be just peachy keen! ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 10, 2016 Author Share Posted October 10, 2016 When you use cf2dsk you must expect to get an image file of 1600 sectors which does not fit on a real floppy disk anymore. I did not find anything in the CF7 manual that could prove some intention to keep the original floppy geometry. Thus I would say it is simply a shortcoming (bug?) of dsk2cf. Maybe I'll add a warning pop-up in TIMT that recommends to run the file system check to get the full capacity of that volume. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 11, 2016 Share Posted October 11, 2016 When you use cf2dsk you must expect to get an image file of 1600 sectors which does not fit on a real floppy disk anymore. I did not find anything in the CF7 manual that could prove some intention to keep the original floppy geometry. Thus I would say it is simply a shortcoming (bug?) of dsk2cf. Maybe I'll add a warning pop-up in TIMT that recommends to run the file system check to get the full capacity of that volume. I suppose another possibility is that the hardware creator did not (does not) have sufficient knowledge about disk formats to correct disks being imported. Freeing up the bitmap and changing disk geometry isn't difficult but it does require manipulation of sectors 0 and 1. Then again, he may not have seen it as an issue within the constraints of the device. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 12, 2016 Author Share Posted October 12, 2016 Does CF7 support directories? I guess not. In that case I have to lock out that feature for CF7, or you would be able to create invalid images. 1 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.