Jump to content

Need more info about HX5102


Recommended Posts

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 by mizapf
  • Like 1
Link to comment
Share on other sites

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.


Link to comment
Share on other sites

  • 1 month later...

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

Link to comment
Share on other sites

Almost done; this is the result of my CRU analysis.


CRU read:


0 Controller INT line
1 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 count
6 Drive 2 cylinder count
7 Drive 3 cylinder count


CRU Write:

0 -
1 Motor
2 -
3 Step direction (1=inwards)
4 When 1, assert DACK* (DMA acknowledge) to clear a pending DRQ
5 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 status
14 Arm READY circuit
15 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)
    F090:     CLR  @>F7EC
    F094:     MOVB @>F7E2,*R2+
    F098:     DEC  R6
    F09A:     JNE  >F090
    F09C:     RT
    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 circuit
226C: 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 trap
2274: 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.


  • Like 3
Link to comment
Share on other sites

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 by mizapf
Link to comment
Share on other sites

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:







DSR Choices of PAB Processing

99/4A and 99/Dillo



TI-99/4 and /8 Disk Peripheral



Hex-Bus DSR commented Sourcecode (the TI-99/8 version)



TI-99/4A Home Computer Hex-Bus Interface Peripheral Software Functional Spec v1.0



Software Spec for the Hex-Bus Floppy Disk System



Hex-Bus Floppy Disk System Product Spec



Hex-Bus Drive/Controller HX-5102 User Manual



Hex-Bus Specification



Hex-Bus Specifications



DOC-Bus Specification



TI-74 Technical Data Manual



TI-99/4a Hex-Bus Interface PHP1300 User Guide



Further documents are in The Cyc (cadd99.com):


TI-99/4A Hexbus Interface DSR commented source code (not the 99/8 one from whtech)





  • Like 1
Link to comment
Share on other sites

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 by mizapf
  • Like 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 1 year later...

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 by Retrospect
Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...