Jump to content

Photo

Need more info about HX5102


15 replies to this topic

#1 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,587 posts
  • Location:Germany

Posted Wed Mar 8, 2017 5:09 PM

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, Wed Mar 8, 2017 5:21 PM.


#2 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,617 posts

Posted Wed Mar 8, 2017 5:49 PM

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.

Attached Files



#3 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,587 posts
  • Location:Germany

Posted Thu Mar 9, 2017 5:50 AM

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.

Attached Files



#4 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,587 posts
  • Location:Germany

Posted Fri Mar 10, 2017 7:45 AM

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)



#5 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,617 posts

Posted Fri Mar 10, 2017 7:59 AM

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.

Attached Files



#6 kl99 OFFLINE  

kl99

    Dragonstomper

  • 676 posts
  • Location:Vienna, Austria

Posted Tue Apr 18, 2017 1:34 AM

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



#7 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,587 posts
  • Location:Germany

Posted Tue Apr 18, 2017 4:37 AM

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)
 
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 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.

Attached Files



#8 kl99 OFFLINE  

kl99

    Dragonstomper

  • 676 posts
  • Location:Vienna, Austria

Posted Tue Apr 18, 2017 6:17 AM

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 by kl99, Tue Apr 18, 2017 6:21 AM.


#9 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,587 posts
  • Location:Germany

Posted Tue Apr 18, 2017 7:54 AM

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, Tue Apr 18, 2017 7:55 AM.


#10 kl99 OFFLINE  

kl99

    Dragonstomper

  • 676 posts
  • Location:Vienna, Austria

Posted Tue Apr 18, 2017 9:32 AM

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



#11 acadiel OFFLINE  

acadiel

    Dragonstomper

  • 981 posts
  • www.hexbus.com
  • Location:USA

Posted Tue Apr 18, 2017 11:16 AM

I might have the schematics for the DSDD Hexbus controller around here.

#12 kl99 OFFLINE  

kl99

    Dragonstomper

  • 676 posts
  • Location:Vienna, Austria

Posted Sun Apr 23, 2017 10:57 AM

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...

Attached File  Hex-BusMiniFloppy.pdf   2.62MB   13 downloads



#13 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 2,587 posts
  • Location:Germany

Posted Sun Apr 23, 2017 11:25 AM

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, Sun Apr 23, 2017 12:20 PM.


#14 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,216 posts

Posted Sun Apr 23, 2017 1:57 PM

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?



#15 acadiel OFFLINE  

acadiel

    Dragonstomper

  • 981 posts
  • www.hexbus.com
  • Location:USA

Posted Sun Apr 23, 2017 4:21 PM

.. 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.

 

Attached Files


Edited by acadiel, Sun Apr 23, 2017 4:23 PM.


#16 kl99 OFFLINE  

kl99

    Dragonstomper

  • 676 posts
  • Location:Vienna, Austria

Posted Mon Apr 24, 2017 5:09 AM

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!






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users