+mizapf Posted October 13, 2017 Share Posted October 13, 2017 A good document to learn about the IPB (Intelligent Peripheral Bus, "Hexbus") is "Intelligent Peripheral Bus / Structure, Timing, and Protocol Specification" from TI Calculator Division, 7/3/82, rev 2.8. Section 4.3: A command message (going from the host to the device) consists of these data: Device Code (1) Command Code (1) Logical Unit Number (1) Record Number (2) Buffer Length (2) Data Length (2) Data (length) (byte count in parentheses) Every message is at least 9 bytes long (with 0 data). The device code is either 0 (all connected devices) or a byte referencing the device. For instance, the numbers 1-8 refer to tape drives; numbers 100 to 107 refer to floppy drives. In particular, the device codes 101 - 104 correspond to DSK1 - DSK4. So when you use CALL IO(5,1) you get 05 = Device #5 (one of the possible tape recorders) 01 = command "CLOSE" 00 = LUN 0 00 00 = Record 0 00 08 = Buffer length 0800 = 512 (section 3.4: little endian) 00 00 = No data Hope that helps. Quote Link to comment Share on other sites More sharing options...
brain Posted October 14, 2017 Share Posted October 14, 2017 (edited) I have some sample code operating. I can read the data stream from the cc40 into the uC *01 00 00 00 00 06 00 06 00 00 00 40 4a 49 4d 40 0000| 4a 49 4d |JIM | I am doing call load("1,jim") 01 = dev 00 = cmd (load) 00 = lun 00 00 = record #0 06 00 = buflen 06 00 = datalen 00 00 = data len of data block 40 = attributes 4a.49,4d = "jim" The data is sent, and I am now sending back a response, 04 00 <x> 00 00 00 (where x is buffer length) but it is barfing on the response, with error code 12 (buffer size error). Anyone know what the required buffer size is for a load command? I have tried 6 80 256 800 none help Jim Also, assuming I get past this spot, is there a good tiny program I can yank into my C code and send to the cc40? Edited October 14, 2017 by brain Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 14, 2017 Share Posted October 14, 2017 How are you controlling the byte stream to/from the CC40? A modern microcontroller will have no problem capturing an incoming stream given the processing speed difference, but sending data back to the CC40 might be trickier. Quote Link to comment Share on other sites More sharing options...
brain Posted October 14, 2017 Share Posted October 14, 2017 Currently, I am using an AVR 16MHz speed. Reciving the data is looking good, and I am sending the data back using the same format and timing (9uS from data enable ot HSK enable, 10uS of HSK active, 1uS wait before bringing DATA lines high, 48uS before doing the next nybble. It looks like it is reading the first byte of the buffer length, as it brings the BAV line high immediately following the first byte. I may wire up a TIIF cable tomorrow and see if I can sniff the PC conversation. If I could just get past this, I think I have all the pieces. Jim 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 14, 2017 Share Posted October 14, 2017 Oops... Buffer length 0800 of course means 2048 bytes, not 512 as I wrote above. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 14, 2017 Share Posted October 14, 2017 Isn't 00 = OPEN? At least this is according to the document that I mentioned. Quote Link to comment Share on other sites More sharing options...
brain Posted October 14, 2017 Share Posted October 14, 2017 It is, but a call load("1,jim") just does open under the covers. Jim Quote Link to comment Share on other sites More sharing options...
brain Posted October 15, 2017 Share Posted October 15, 2017 Initial attempts to fabricate a TIIF cable and run the DOS version of TIIF were not successful, so I am regrouping. I think I'll see if I can borrow a cc40 peripheral to scope, or a TIIF cable to try, and then carry on. acadiel, do you have either available for loan? I looked on eBay to just buy a unit, anything, but nothing I could find at present. Jim Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 16, 2017 Share Posted October 16, 2017 I think I may have all of the Hex-Bus peripherals Acadiel had in his collection, so I'd probably have to dig one of mine out for you to use in testing. . .PM me and I'll see what we can arrange. Quote Link to comment Share on other sites More sharing options...
brain Posted October 16, 2017 Share Posted October 16, 2017 Thanks. I got a bit further on my TI-PC cable but neither the DOS nor the Windows version works yet. Jim Quote Link to comment Share on other sites More sharing options...
brain Posted October 17, 2017 Share Posted October 17, 2017 Success! Partially my fault, as I assumed the cc40 could both send and receive nybbles at the same speed (I calculated my delays based on the data coming from the cc40). In reality, while it can chuck a nybbled out the door in 9uS, it takes sometimes up to 200uS to read one. So, I had to implement the "bring HSK high and watch for it to actually go high) as a handshake. It's in the datasheet, so my fault. BUT! The datasheet is spectacularly bad at explaining how to send data back to the cc40 (or other HexBus master). So, here it is: When the master is sending, it holds BAV low, as expected. When it finishes, it watches for line activity (or a timeout). If a data line or HSK line falls, it brings BAV high. If it then noticed BAV high, it gives an immediate error. The trick is to bring BAV low on the slave side, bring HSK low, then bring BAV high (which it *kinda* talks about in the datasheet, but makes it sound like that is the work needed to call the master and then you can send your entire set of data. In reality, you have to go through the above for every nybble). At this point, the comm in simple: LIST "45" which opens a feed for output, writes the data (list), and closes the file. Still, I'll take it. It still may be useful to get a peripheral to check timings, but at least something is working. Jim 3 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted October 17, 2017 Share Posted October 17, 2017 Success! Partially my fault, as I assumed the cc40 could both send and receive nybbles at the same speed (I calculated my delays based on the data coming from the cc40). In reality, while it can chuck a nybbled out the door in 9uS, it takes sometimes up to 200uS to read one. So, I had to implement the "bring HSK high and watch for it to actually go high) as a handshake. It's in the datasheet, so my fault. BUT! The datasheet is spectacularly bad at explaining how to send data back to the cc40 (or other HexBus master). So, here it is: When the master is sending, it holds BAV low, as expected. When it finishes, it watches for line activity (or a timeout). If a data line or HSK line falls, it brings BAV high. If it then noticed BAV high, it gives an immediate error. The trick is to bring BAV low on the slave side, bring HSK low, then bring BAV high (which it *kinda* talks about in the datasheet, but makes it sound like that is the work needed to call the master and then you can send your entire set of data. In reality, you have to go through the above for every nybble). At this point, the comm in simple: LIST "45" which opens a feed for output, writes the data (list), and closes the file. Still, I'll take it. It still may be useful to get a peripheral to check timings, but at least something is working. Jim Nice work!!!!! Sent from my LG-V530 using Tapatalk Quote Link to comment Share on other sites More sharing options...
kl99 Posted October 17, 2017 Share Posted October 17, 2017 congrats on your progress this will be useful also once speccery incorporates the hex-bus interface into his FPGA based PEB to attach to the real TI console. 1 Quote Link to comment Share on other sites More sharing options...
brain Posted October 18, 2017 Share Posted October 18, 2017 OK, I can now load and save from the cc40. JIm 3 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted October 18, 2017 Share Posted October 18, 2017 OK, I can now load and save from the cc40. JIm WOOHOO! Quote Link to comment Share on other sites More sharing options...
majestyx Posted October 19, 2017 Share Posted October 19, 2017 Very cool! I knew it was just a matter of time until someone would figure this out. BRAVO~! Quote Link to comment Share on other sites More sharing options...
brain Posted October 20, 2017 Share Posted October 20, 2017 Right now, I am trying to figure out how to force the cc40 to "wait" on me. For example, you do load "100.jim" and I need to go find the file, which could take some time. I cannot find anywhere in the spec where it supports an arbitrary "hold". It specifically mentions that hsk high to hsk low can be no more than 20ms, which could be too short to find a file on an SD card. Anyone have any ideas? I am no doubt looking at the same spec sheet everyone has, but I just can't see it. It has to be possible, as the wafertape or the disk drive would not have worked otherwise. Jim Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 20, 2017 Share Posted October 20, 2017 I find this discussion particularly valuable, since I am still working on the Hexbus emulation in MAME. I already disassembled and commented the source listing of the HX5102 floppy drive. Maybe this could also be helpful for you? 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted October 20, 2017 Share Posted October 20, 2017 I also have the DSR ROM around here somewhere for the actual TI Hexbus controller. I believe it's an 8K, and you'll just have have to disassemble it. Quote Link to comment Share on other sites More sharing options...
brain Posted October 20, 2017 Share Posted October 20, 2017 Yes, the disassembly of the drive is most valuable. acadiel, sadly, the master is not as informative, since it can hold off any slave by simply not sending all of the data to it. For now, I have determined a solution that works, by not releasing the HSK line on receipt of the byte previous to the delayed activity (so, the last byte of the PAB before reading or writing data, the last byte of the filename on an OPEN, etc.). It seems kludgey to abuse the spec like that, but I have not found another option yet. Jim Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 20, 2017 Share Posted October 20, 2017 (edited) OK then, here is my disassembly with some comments, still work in progress, but you may find your way into it. At least it allowed me to understand the operation of the HX5102 hardware. Keep in mind that the HX5102 floppy drive has an own TMS9995 CPU. hx5102_dis.zip Edited October 20, 2017 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
brain Posted October 20, 2017 Share Posted October 20, 2017 Hmm, and me not knowing much about TMS asm. Anyone care to help? Jim Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 20, 2017 Share Posted October 20, 2017 Ah, sorry, I thought you know about assembly language ... Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 20, 2017 Share Posted October 20, 2017 (edited) The datasheet is spectacularly bad at explaining how to send data back to the cc40 (or other HexBus master). So, here it is: When the master is sending, it holds BAV low, as expected. When it finishes, it watches for line activity (or a timeout). If a data line or HSK line falls, it brings BAV high. If it then noticed BAV high, it gives an immediate error. The trick is to bring BAV low on the slave side, bring HSK low, then bring BAV high (which it *kinda* talks about in the datasheet, but makes it sound like that is the work needed to call the master and then you can send your entire set of data. In reality, you have to go through the above for every nybble). This is what I learned from the specification: HSK is the handshake signal for nibble transfer. It is operated for every single nibble. BAV is one layer higher. It indicates a master-slave interaction. It is pulled low by the master (unless there are specific requests to the master) and kept low until the interaction is done. So there is no early release by the master, according to the spec. First the device code is transmitted. When a device is present on the bus that owns this code, it will listen to further HSK operations. Otherwise, if there is no matching device, no one will participate, and the server will experience a timeout waiting for the response. If there is a matching device, the master is supposed to keep BAV low until the interaction is over, which means that the command was transmitted and its results were returned. (Section 4) When BAV is pulled low, the attached slaves may expect a nibble to be transmitted, hence there is a timeout of 20 ms for HSK to go low. When the master lowers HSK, it indicates to any addressed slave that there is a nibble on the data lines. As soon as the slaves sense a falling HSK, they pull down HSK by themselves. When they have read, they typically release HSK to indicate that they are ready for the next nibble. Usually the master has already released HSK. If the master senses that HSK goes high, it concludes that all addressed slaves are ready for the next nibble. Suppose that you want to read a sector. This will take some time; the result is expected to be delivered in the response phase of the BAV low time. Now when the server has completed the transfer of the command, the slave will pick up the last nibble of the command, and then not raise HSK but keep it low until the whole sector is read. If you look closely, there is no timeout for HSK low, only for HSK high. The spec says at some positions that this is the proper way for a slow slave to control the progress of the communication. According to the spec, early BAV releasing is only done by a slave requesting service from the master. The slave pulls down BAV, which is sensed by the master; the master then pulls BAV low also, which cannot be sensed by the slave, but then the master also pulls down HSK for the first nibble, and then the slave releases BAV which is still down by the master. [Edit: BAV handling] Edited October 21, 2017 by mizapf Quote Link to comment Share on other sites More sharing options...
brain Posted October 21, 2017 Share Posted October 21, 2017 Now when the server has completed the transfer of the command, the slave will pick up the last nibble of the command, and then not raise HSK but keep it low until the whole sector is read. If you look closely, there is no timeout for HSK low, only for HSK high. The spec says at some positions that this is the proper way for a slow slave to control the progress of the communication. I noticed that, and that's how I noted I am doing the work today, but it does seem kludgey. I'd like to confirm the FDC does the same. According to the spec, early BAV releasing is only done by a slave requesting service from the master. The slave pulls down BAV, which is sensed by the master; the master then pulls BAV low also, which cannot be sensed by the slave, but then the master also pulls down HSK for the first nibble, and then the slave releases BAV which is still down by the master. And, I initially thought I could pull BAV low, wait for my data, and then pull HSK low and BAV high when it has arrived. But, If I pull BAV low, I have 20mS (as you note) to send an HSK low, or timeout will occur. Jim 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.