+mizapf Posted October 21, 2017 Share Posted October 21, 2017 It may depend on how you interpret "handshake". Maybe TI thought of handshake as "I'm ready for the next nibble" when it is released, going high. So if you send a load operation by the master, with the last nibble in the message the slave does not say that, but instead waits for the data to be loaded. The floppy drive has an internal buffer memory where it stores the sectors, and as soon as they are available, the slave starts to transmit the result. I'll have a closer look at the source code at that point. However, it may also be that this HSK handling is hidden in hardware, since there is a custom Hexbus chip inside. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 21, 2017 Share Posted October 21, 2017 The logic schematic for the OSO chip in the 99/8 may be of use here if the HSK handling is hidden in the hardware. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 21, 2017 Share Posted October 21, 2017 Yes, I know that one ... I just need to look more closely, particularly asking for how much is done in hardware and in software. What could be more interesting than OSO is the chip in the 5102 floppy, which is a simpler one. Quote Link to comment Share on other sites More sharing options...
brain Posted October 21, 2017 Share Posted October 21, 2017 It may depend on how you interpret "handshake". Maybe TI thought of handshake as "I'm ready for the next nibble" when it is released, going high. So if you send a load operation by the master, with the last nibble in the message the slave does not say that, but instead waits for the data to be loaded. The floppy drive has an internal buffer memory where it stores the sectors, and as soon as they are available, the slave starts to transmit the result. I'll have a closer look at the source code at that point. However, it may also be that this HSK handling is hidden in hardware, since there is a custom Hexbus chip inside. The controller ICs referenced in the specs are pretty simplistic, but I am not sure if the FDC used one of them or not. JIm Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 21, 2017 Share Posted October 21, 2017 There is definitely a Hexbus controller chip in every Hexbus device. As a side note, you can still get the chips here. The site seems to be having issues today though, as I haven't been able to successfully connect to it for the last hour or so. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 21, 2017 Share Posted October 21, 2017 The document ftp://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus%20Specifications.pdfdescribes the Hexbus signals and the custom chip in detail. See particularly pages 61-72 and 103-152. I did not yet have a chance to go into deep detail there. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 21, 2017 Share Posted October 21, 2017 I did some reading there, the chip I have seen in most Hexbus devices was the 1052911 that I provided the link to for NOS chips. It is a 22-pin chip in a .400 package, and described on pages 75 to 102 of the document Michael linked to. It also documents a 28-pin, TP0370 Hexbus controller chip on pages 103 to 131. A set of flow charts showing each type of Hexbus transaction runs from page 134 to 152, and would be applicable to both chips. Note also that the document Michael linked to pretty much contains all of the known Hexbus documentation in a single concatenated file. There are lots of great data nuggets in there. 1 Quote Link to comment Share on other sites More sharing options...
brain Posted October 22, 2017 Share Posted October 22, 2017 (edited) The document ftp://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus%20Specifications.pdfdescribes the Hexbus signals and the custom chip in detail. See particularly pages 61-72 and 103-152. I did not yet have a chance to go into deep detail there. I have. I have that doc open on my PC and have been poring over it in detail to work on this project. I have already found errata in the doc as well. Jim Edited October 22, 2017 by brain Quote Link to comment Share on other sites More sharing options...
+helocast Posted October 22, 2017 Share Posted October 22, 2017 There is definitely a Hexbus controller chip in every Hexbus device. As a side note, you can still get the chips here. The site seems to be having issues today though, as I haven't been able to successfully connect to it for the last hour or so. It's certainly unique in width and pin count dimensions - a bit of history in its own right Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 22, 2017 Share Posted October 22, 2017 I did some reading there, the chip I have seen in most Hexbus devices was the 1052911 that I provided the link to for NOS chips. It is a 22-pin chip in a .400 package, and described on pages 75 to 102 of the document Michael linked to. It also documents a 28-pin, TP0370 Hexbus controller chip on pages 103 to 131. A set of flow charts showing each type of Hexbus transaction runs from page 134 to 152, and would be applicable to both chips. Note also that the document Michael linked to pretty much contains all of the known Hexbus documentation in a single concatenated file. There are lots of great data nuggets in there. Good point! I thought those were duplicate pages, but these are about two different chips! In the schematics and the specifications, the chip on the HX5102 (shown above) is only called IBC (Intelligent Bus Controller). What shall we take as its official type name? L1A0037 or 1052911-X? The third line is presumably the date code. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 23, 2017 Share Posted October 23, 2017 My HX5102 has the 1052911-X chip in it, Michael. I call it that based on the fact that the drawing number for that chip, as identified on page 75, is 1052911. Quote Link to comment Share on other sites More sharing options...
+helocast Posted October 23, 2017 Share Posted October 23, 2017 Realize the conversation is primarily Hex-bus, but couldn't find topic. Apologies in advance - not stealing thread. Here's the PCB basics for all 32K CC40 carts (Express PCB) for those that don't want to start from scratch and haven't jumped to KiCad. Obvs no EEPROMs pin compatible with the mask rom, but it won't take much effort to sub a programmed AT49F040 + dip switch block to store/select multiple 32K images instead. There's room. I'll update with progress if it doesn't become one of my many hardware projects I have in the pipe. CC40cart.zip 4 Quote Link to comment Share on other sites More sharing options...
brain Posted October 23, 2017 Share Posted October 23, 2017 Do you have a PDF of the schematic, perchance? Happy to redo the board as a FLASH ROM board, but need the schematic. JIm Quote Link to comment Share on other sites More sharing options...
brain Posted October 23, 2017 Share Posted October 23, 2017 Update: Spent the last few days pulling the sd routines from the sd2iec project, as I feel Ingo Korb did a great job with the SD/SDHC support in that project, and it uses FatFS. Got all of it out and into my project last night, so adding in the code to open/read a file. With FatFS, not too hard to finish that... I don't see a way to CATALOG on the cc40. Anyone with a drive or wafer tape have any idea how to do so? I thought perhaps it was a CALL SUB CATALOG or something like that. Jim Quote Link to comment Share on other sites More sharing options...
Casey Posted October 23, 2017 Share Posted October 23, 2017 It looks like, based on reading through the Wafertape manual and the Hex-Bus disk drive manual (both on whtech) that you need to write a BASIC program to read the catalog. (It's the same on the 99/4A if you don't have Disk Manager plugged in). The disk drive method is exactly the same as that documented in the 99/4A disk drive manual (the directory is read by opening for input a no-named filed). The Wafertape manual has a program for CC-40 BASIC that generates the proper PAB and uses that to retrieve the directory from the tape. The disk drive manual also has a CC-40 BASIC program to catalog a disk. But there is no CATALOG command like other BASICs have. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 23, 2017 Share Posted October 23, 2017 Yes, this is what I would have suggested, too. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted October 23, 2017 Share Posted October 23, 2017 Realize the conversation is primarily Hex-bus, but couldn't find topic. Apologies in advance - not stealing thread. Here's the PCB basics for all 32K CC40 carts (Express PCB) for those that don't want to start from scratch and haven't jumped to KiCad. Obvs no EEPROMs pin compatible with the mask rom, but it won't take much effort to sub a programmed AT49F040 + dip switch block to store/select multiple 32K images instead. There's room. CC40cart.JPG SS3007.JPG I'll update with progress if it doesn't become one of my many hardware projects I have in the pipe. ooooh! That's be easy to make into a CC-40 multicart now (hardware switches, though). Thanks for laying that out! 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted October 23, 2017 Share Posted October 23, 2017 Update: Spent the last few days pulling the sd routines from the sd2iec project, as I feel Ingo Korb did a great job with the SD/SDHC support in that project, and it uses FatFS. Got all of it out and into my project last night, so adding in the code to open/read a file. With FatFS, not too hard to finish that... I don't see a way to CATALOG on the cc40. Anyone with a drive or wafer tape have any idea how to do so? I thought perhaps it was a CALL SUB CATALOG or something like that. Jim If I recall some of the 'catalog' programs that catalog'd the Quick Disk, there seemed to be some machine code in the BASIC program that did it. Ksarul would have to verify as he has my old Quickdisk and the catalog program. Quote Link to comment Share on other sites More sharing options...
brain Posted October 24, 2017 Share Posted October 24, 2017 Update on progress: Finally plumbed the SD and FAT routines to my HEXBUS code. implemented open, read file, and close. Managed to get master.pgm to load and ran a few rounds of that game. I am having an issue with my code glitching HSK and BAV lines, due to the lack of true open collector outputs on the AVR uC I am using. So, I need to step back a bit and re-implement BAV and HSK so they use transistors or OC buffers. But, the code is looking OK. Lots of timing assumptions being made that need to get cleaned up later. JIm 5 Quote Link to comment Share on other sites More sharing options...
brain Posted October 25, 2017 Share Posted October 25, 2017 (edited) Update: Fixed the glitching HSK and BAV lines, added some more error handling, and now I have reading to and writing from SD card working. I was able to read in mastermind numerous times and play the game, and then save it back to the SD card. Next steps: Create a video of unit in operation Add support for multiple open files. Ignore any non-disk-drive IDs, and configure device to listen to 1 ID (100-109) Handle reset bus function (right now, I read it, and ignore) (close open Add timeouts (if bav low and hsk high for 20ms+, timeout.) Add directory/catalog support, and also add a simple "old "100,$" pseudo file to make directories easier to manage Add some type of command to mkdir/chdir/rmdir. Longer term list (need programs written to test each of these): Add null op (0xfe) support Add support for delete open file (will be a close and then delete) Add error support for format media (will simply error out) Add delete support Add minimal support for verify command (no op) Add support for relative files (not even sure how that looks on the wire) Add support for internal display type? Handle trying to read from a write only file (should error), or write to a read opened files (error, again) Add support for restore Add "return status" support Add write protect file support In parallel: Wire up a RAM expander cart so I can test some of the other apps. Rework code/schematic to run at 8MHz and use 3V operation. Not sure if I will add service request support, as I am not sure why a disk drive would need that. Edited October 25, 2017 by brain 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 25, 2017 Share Posted October 25, 2017 I've been waiting for someone to do this for a long time! How do you envision your end-product? I love the CC40 and am looking forward to programming it again once we have this mass storage solution finalized. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 25, 2017 Share Posted October 25, 2017 This will also be helpful for those with a 99/8 but lacking a floppy drive. Also, the TI-74 BasiCalc uses Hexbus. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted October 25, 2017 Share Posted October 25, 2017 I have a cassette player interface for my TI-74 BasiCalc, but that's a bit tedious to use... Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 25, 2017 Share Posted October 25, 2017 This will also be helpful for those with a 99/8 but lacking a floppy drive. Also, the TI-74 BasiCalc uses Hexbus. Indeed! I do have the PCIF interface for the TI74 which I adapted to use on the CC40 (just changed the connector on the CC40's end), but it was clunky at best and required a DOS PC. What Jim is doing is so much better... Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted October 25, 2017 Author Share Posted October 25, 2017 Yes,yes,yes! It would be really neat to have storage for a CC40. Quote Link to comment Share on other sites More sharing options...
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.