+mizapf Posted March 8, 2017 Share Posted March 8, 2017 (edited) Short question: By chance, has anyone got a broken, non-functional HX5102 device? Any if you had, would you offer it for lab experiments? :-) The HX5102 is the Hexbus floppy device (controller + drive). I am currently analyzing the ROMs because I want to create an emulation in MAME. I am almost done with the analysis; I think that I have a quite good idea how the system works so that an emulation is within reach. However, there are some points that I got a bit stuck on. In particular, this concerns the CRU bits; there are some SBO/SBZ/TB that I cannot make a good sense of. I have some high quality photographs from Jens-Eike's device from which I hoped to get some enlightenment. But the circuitry is pretty complex, and there are many traces running beneath circuits, which make it almost impossible to follow. The other challenge is that I have no emulation for the Intel 8272A; I believe that I understood the overall operation, though. But as you see this is a real challenge: I can only rely on the software for a system that I have no schematics for, using a chip that does not have an emulation yet. [Edit: What I find really creepy is that 5 minutes after posting this message, I searched Google for HX5102, and found this very message at second place.] Edited March 8, 2017 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted March 8, 2017 Share Posted March 8, 2017 You've probably already found this stuff, but in case any one else is curious.... It would be cool if someone was thinking of re-creating this stuff for real hardware in the TI community. HX 5102 Info (TI Related).zip 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 9, 2017 Author Share Posted March 9, 2017 I do have the included PDF and BIN files, not the JEDEC files. Is there a way to retrieve the logic from the JEDEC files? --- Here's my current state of disassembly; I focused on the low-level routines at >2000 and higher; the code at lower locations is copied from the standard TI DSRs. As you can see, this has got quite far already, but as I said, some points remain unclear. Maybe I have to simply try to implement it with some optimistic assumptions. I could just ignore the unclear CRU flags and see whether something is missing. hx5102_dis.zip Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 10, 2017 Author Share Posted March 10, 2017 OK, got some nice progress in the meantime, but still some way to go. You may want to have a look if you are interested: http://www.mizapf.eu/files/board.xcf (caution, this file is more than 60 MiB large, to be opened in GIMP) 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted March 10, 2017 Share Posted March 10, 2017 Wow, that full sized image is IMPRESSIVE! I wish I had more time to admire it, but I have to leave for work now. It's a work of art. I think I'll print up your full-sized version it up and stick it on the wall in the den. Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 18, 2017 Share Posted April 18, 2017 Hi mzapf, how is the research going on? I was impressed by your efforts with Jens-Eike on the TI Treff in Birkenau 2 weeks ago. So please share a bit on your progress so far.Are you really sure you have all the DOCS existing? BR Klaus Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 18, 2017 Author Share Posted April 18, 2017 Almost done; this is the result of my CRU analysis. CRU read: 0 Controller INT line1 Motor spinning (monoflop 1)2 Timeout for disk operations (monoflop 2)3 -4 Drive 0 cylinder count (0=40, 1=77)5 Drive 1 cylinder count6 Drive 2 cylinder count7 Drive 3 cylinder count CRU Write:0 -1 Motor2 -3 Step direction (1=inwards)4 When 1, assert DACK* (DMA acknowledge) to clear a pending DRQ5 Step pulse (up)6 Trigger timeout monoflop (2)7 RESET* the controller (put state machine in idle state, i.e. stop working with disk)8 Drive select drive 0 (DSK1)9 Drive select drive 1 (DSK2)10 Drive select drive 2 (DSK3)11 Drive select drive 3 (DSK4)12 Separate Motor line for internal drive (not used)13 Unknown, obviously not connected on the board but used before sector I/O, format track, reset drives; turned off once when reporting status14 Arm READY circuit15 Unknown, possibly in test mode only, not connected The last discoveries were the meanings of CRU bits 4 and 6, both of which are pulsed (SBO/SBZ) at a few locations. CRU bit 4 leads to the DACK* input of the controller. This is pretty interesting and unexpected, but now I seem to understand. You can see it on the attached picture. The purpose could be to clear a pending DRQ before starting the sector access. With an asserted DRQ, the READY line would be high, which would cause a miss of the first byte. I was wondering about the reason to do this, but it probably makes sense when we consider that a previous sector access may have timed out, and since this is detected by the circuitry on the board, not by the controller, the DRQ may still be high on the next attempt. The DMA access is done in an interesting way. Instead of getting access to the RAM circuits, the controller talks to the 9995 CPU which pretends to be the DMA controller. It works like this: First, the CPU must be halted; this is done by leading a 0 to the READY line; this can be done by accessing a particular address, which (via the PAL) leads to an AND circuit. Then the controller collects the incoming bits from the floppy and raises the DRQ line. This unlocks the CPU, which proceeds to the next command. This command is a MOVB instruction, picking up the value from a special address, which is decoded by the PAL to assert the DACK* line. When it does this, the controller puts the value on the data bus, so it will be received by the CPU and then written to a location in RAM. Then the loop continues by locking the CPU again. In the case that the read operation fails (because the sector header is not readable), the CPU will stay locked in that loop, and hence it cannot free itself. For that reason, the monoflop 2 must be triggered before the operation. When it drops to low, it will raise READY and thus unlock the CPU. After that loop (with 256 iterations for all bytes in the sector), the CRU bit 2 is checked, which reflects the monoflop state. When it is 0, the monoflop has expired, so the loop was left because of a timeout. When it is still 1, all 256 bytes were read. Taking a look at the code 226A: SBO 14 226C: BL *R9 (R9=F090) Read: F090: CLR @>F7EC F094: MOVB @>F7E2,*R2+ F098: DEC R6 F09A: JNE >F090 F09C: RT Write: F090: CLR @>F7EC F094: MOVB *R2+,@>F7EA F09A: DEC R6 F09C: JNE >F090 F09E: RT 226E: LI R9,>EFC0 2272: SBZ 14 2274: TB 2 2276: JEQ >2282 2278: BL @>271C 227C: BL @>2764 2280: DATA >6400 ====== 226A: Arm the READY circuit226C: Branch to the routine in on-chip RAM which must have been copied there (read or write) (for read)F090: Connect DRQ to READY; DRQ must be 0 at this point. The PAL is to decode that address. The monoflop must have been triggered before and DACK* must have been pulsed (not shown) F094: When we reach this position, the controller has obviously raised DRQ and unlocked the CPU. The address in this MOVB operation must cause DACK* to become asserted (0), again achieved by the PAL. The CPU reads the data bus which expects the data byte to be made available by the controller. Then, the value is written to a RAM location pointed to by R2. The assertion of DACK* makes DRQ return to 0, which must have been disconnected from READY by these operations. F098/9A: While there are more bytes (initially 256), continue 226E: Reset R9 to the usual value (was 8300 in the TI FDC)2272: Unarm the READY trap2274: Check the monoflop state. When 0, we are here because a timeout occured.2278: Try a different density or stepping (single/double). Repeat, if not already done.227C: No luck, report error >6400 --- Next things are to understand the Hexbus protocol, then I can start implementing it. When I am done with it, I will publish the disassembled ROM listing on my website or on Ninerpedia and send a copy to Thierry. 3 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 18, 2017 Share Posted April 18, 2017 (edited) the CRU information might be taken from page 5 of this internal specification for DSDD? ftp://ftp.whtech.com/datasheets%20and%20manuals/Hardware/TI%20DSDD%20FDC%20Manual%20and%20DSDD%20FDC%20GPL%20Interface%20Manual.pdf Edited April 18, 2017 by kl99 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 18, 2017 Author Share Posted April 18, 2017 (edited) The CRU bit definitions are not identical, but from a quick glance I see that the overall concept is similar, since they also used an Intel floppy controller with DMA. I will study that document in addition. We may assume that TI engineers did not invent every wheel from scratch, so they may have used that concept for the HX5102. Section 4.6 nicely describes the DMA handling (here involving the console TMS9900 processor); when you read it you can see that I seem to have come pretty close. :-) I need to correct a minor thing in the above description: As the code portions that drive the DMA transfer are running in the on-chip RAM, and the workspace is also in on-chip RAM, there is no need to detach READY after F094, because READY does not affect on-chip RAM operations. Thus, the READY trap works as expected next time the CPU reaches F090. Edited April 18, 2017 by mizapf Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 18, 2017 Share Posted April 18, 2017 The Hex-Bus is sometimes referenced as ALC or ALC I/O, in later specs it is referenced as DOC-BUS, DOCK-BUS or IPB [intelligent Peripheral Bus]. These documents might be of service as well: DOUBLE SIDED, SINGLE DENSITY DISK CONTROLLER PCB DISK CONTROLLER THEORY OF OPERATIONS DSSD DISK PAL12L6 ftp://ftp.whtech.com/datasheets%20and%20manuals/Specifications/Peripheral%20Expansion%20System%20Theory%20Of%20Operation%20and%20Technical%20Traning%20Guide%201982-09-03.pdf DSR Choices of PAB Processing 99/4A and 99/Dillo ftp://ftp.whtech.com/datasheets%20and%20manuals/Hardware/DSR%20Choices%20of%20PAB%20Processing%2005-16-1983.pdf TI-99/4 and /8 Disk Peripheral ftp://ftp.whtech.com/datasheets%20and%20manuals/Hardware/TI%20DSDD%20FDC%20Manual%20and%20DSDD%20FDC%20GPL%20Interface%20Manual.pdf Hex-Bus DSR commented Sourcecode (the TI-99/8 version) ftp://ftp.whtech.com/datasheets%20and%20manuals/99-8%20Computer/TI%2099-8%20Hexbus%20DSR%20Source.pdf TI-99/4A Home Computer Hex-Bus Interface Peripheral Software Functional Spec v1.0 ftp://ftp.whtech.com/hexbus_cc40_ti74/994a%20Hexbus%20Interface/TI-99_4A%20Home%20Computer%20HexBus%20Interface%20Peripheral%20Software%20Functional%20Spec%20V1.0%2010-24-1983.pdf Software Spec for the Hex-Bus Floppy Disk System ftp://ftp.whtech.com/hexbus_cc40_ti74/Software%20Specification%20for%20the%20HexBus%20Floppy%20Disk%20System%20V1.0%2008-02-1983.pdf Hex-Bus Floppy Disk System Product Spec ftp://ftp.whtech.com/hexbus_cc40_ti74/Hebus%20floppy%20product%20specification.pdf Hex-Bus Drive/Controller HX-5102 User Manual ftp://ftp.whtech.com/hexbus_cc40_ti74/Hexbus%20Drive-Controller%20(Model%205102)%20Manual.pdf Hex-Bus Specification ftp://ftp.whtech.com/hexbus_cc40_ti74/Hexbus%20Specification.pdf Hex-Bus Specifications ftp://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus%20Specifications.pdf DOC-Bus Specification ftp://ftp.whtech.com/hexbus_cc40_ti74/Intelligent%20Peripheral%20Bus%20Structure,%20Timing,%20and%20Protocol%20Specification%20V2.8%2007-03-1982.pdf TI-74 Technical Data Manual ftp://ftp.whtech.com/hexbus_cc40_ti74/ti-74/TI74%20technical%20data%20manual.pdf TI-99/4a Hex-Bus Interface PHP1300 User Guide ftp://ftp.whtech.com/hexbus_cc40_ti74/cc40%20ti74%20hexbus.txt Further documents are in The Cyc (cadd99.com): TI-99/4A Hexbus Interface DSR commented source code (not the 99/8 one from whtech) \vendors\ti\hexbus\dsrsrc\dsrsrc.pdf DOC-BUS INTELLIGENT PERIPHERAL BUS STRUCTURE, TIMING, AND PROTOCOL SPECIFICATION v4.0 from 1988 \vendors\ti\internal\docbus\docbus.pdf 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 18, 2017 Share Posted April 18, 2017 I might have the schematics for the DSDD Hexbus controller around here. 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 23, 2017 Share Posted April 23, 2017 I just found this schematics document for the Hex-Bus Disk Controller while sorting my files. I must have got it from Labtech1 alias Lee, a former owner of a 99/8. Sorry for not bringing this up earlier... Hex-BusMiniFloppy.pdf 4 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 23, 2017 Author Share Posted April 23, 2017 (edited) Well, that seems to be the drive indeed - together with PAL equations. I'll have a closer look. I'd say: Better late than never... Tausend Dank! [Edit: It is. Have a look at the last page where the CRU definitions are noted and compare with my analysis above ... this feels just like the reward for all that work .] Edited April 23, 2017 by mizapf 2 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 23, 2017 Share Posted April 23, 2017 Nice! I didn't have a copy of this one, Klaus! I'll have to work on making a new one like the others I redrew a while back. . . Lee sold his 99/8? His had the only flat cable Armadillo Interface board I'd ever seen with it. Do you have any idea where that machine went? Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 23, 2017 Share Posted April 23, 2017 (edited) .. here's a schematic for you too This is one that Michael Becker cleaned up and used to make his HX5102 clone. Ksarul now owns that device. I have most of the files too for the ROMs, save a couple. HX5102M.pdf hx5102m.zip Edited April 23, 2017 by acadiel 3 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 24, 2017 Share Posted April 24, 2017 Nice! I didn't have a copy of this one, Klaus! I'll have to work on making a new one like the others I redrew a while back. . . Lee sold his 99/8? His had the only flat cable Armadillo Interface board I'd ever seen with it. Do you have any idea where that machine went? Yes, Lee sold his 99/8 setup. I sent you a private message about details. It went not(!) to me Nice that these documents find some fruits. Michael Zapf will figure this HX-5102 beast out! I am sure! Quote Link to comment Share on other sites More sharing options...
Retrospect Posted January 17, 2019 Share Posted January 17, 2019 (edited) Hi, how do I address the Hexbus 5102 on the 99/8 emulator in mame? Just got it set up, but I keep getting * I/O error 66 when I try to save my program? ( I have created a floppy disk image and called it newdisk.dsk but I aren't having any luck) Edit: I can hear the drive activating and spinning but still keep getting that error 66 Edited January 17, 2019 by Retrospect Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 17, 2019 Share Posted January 17, 2019 What size is your newdisk.dsk image. I've got no familiarity with the system, however I had a vague recollection that perhaps the system for DS/DD used 16 sectors per track for a 320K disk image versus our more TI-99/4a standard of 18 sectors/track 360K for a DS/DD disk. Beery Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 17, 2019 Author Share Posted January 17, 2019 Please try DSSD first (180K, 9 sectors/track). Try to load some program from that disk that you saved on the TI-99/4A (emulation). The DSDD disks are indeed 16 sectors/track. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 17, 2019 Author Share Posted January 17, 2019 Here is a DSDD image (16 sect/track) which contains a HELLO program that I saved to disk. You should be able to load it using OLD. Try to save it again by another name. For the sake of compatibility with the 99/4A I recommend to use DSSD disks. ti998_2a.dsk Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted January 18, 2019 Share Posted January 18, 2019 There are only a few controllers that can read the 16-sector disks: Hex-Bus, TI DSDD PEB card, Myarc FDC, and Myarc HFDC. The CorComp, Atronic, and BwG controllers don't have that capability unless they are in a Geneve. Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted January 18, 2019 Share Posted January 18, 2019 (edited) I beg to differ - the BWG has a built-in CALLs that allow it to read either 16 or 18 disks. The CALLs are: CALL 16SPT (for 16 sectors per track) and CALL 18SPT ( for the normal state of 18 sectors per track). Edited January 18, 2019 by atrax27407 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted January 18, 2019 Share Posted January 18, 2019 Aaahhh! That must be from a later version of the EPROM, as mine wouldn't do that initially! Thanks for the tip! 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.