Jump to content

Photo

The Compact Computer 40 (CC40)


347 replies to this topic

#51 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Fri Oct 13, 2017 3:58 PM

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.



#52 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Fri Oct 13, 2017 9:11 PM

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 by brain, Fri Oct 13, 2017 9:15 PM.


#53 Vorticon ONLINE  

Vorticon

    River Patroller

  • 2,817 posts
  • Location:Eagan, MN, USA

Posted Sat Oct 14, 2017 12:39 AM

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. 



#54 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Sat Oct 14, 2017 12:48 AM

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


  • jhd likes this

#55 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Sat Oct 14, 2017 2:46 AM

Oops... Buffer length 0800 of course means 2048 bytes, not 512 as I wrote above.

#56 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Sat Oct 14, 2017 11:38 AM

Isn't 00 = OPEN? At least this is according to the document that I mentioned.



#57 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Sat Oct 14, 2017 11:43 AM

It is, but a call load("1,jim") just does open under the covers.

 

Jim



#58 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Sat Oct 14, 2017 10:08 PM

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



#59 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,238 posts

Posted Sun Oct 15, 2017 8:27 PM

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.



#60 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Sun Oct 15, 2017 8:31 PM

Thanks.  I got a bit further on my TI-PC cable but neither the DOS nor the Windows version works yet. 

Jim



#61 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Mon Oct 16, 2017 9:00 PM

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



#62 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,035 posts
  • www.hexbus.com
  • Location:USA

Posted Mon Oct 16, 2017 9:30 PM

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

#63 kl99 OFFLINE  

kl99

    Dragonstomper

  • 677 posts
  • Location:Vienna, Austria

Posted Tue Oct 17, 2017 2:51 AM

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.



#64 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Tue Oct 17, 2017 6:21 PM

OK, I can now load and save from the cc40.

 

JIm



#65 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,035 posts
  • www.hexbus.com
  • Location:USA

Posted Tue Oct 17, 2017 8:06 PM

OK, I can now load and save from the cc40.

 

JIm

 

 

WOOHOO!



#66 majestyx OFFLINE  

majestyx

    Chopper Commander

  • 161 posts
  • Location:Port Carbon, Pennsylvania

Posted Thu Oct 19, 2017 11:37 AM

Very cool! I knew it was just a matter of time until someone would figure this out. BRAVO~!



#67 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Thu Oct 19, 2017 8:40 PM

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



#68 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Thu Oct 19, 2017 11:58 PM

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?



#69 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,035 posts
  • www.hexbus.com
  • Location:USA

Posted Fri Oct 20, 2017 5:26 AM

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.



#70 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Fri Oct 20, 2017 10:56 AM

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



#71 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Fri Oct 20, 2017 11:31 AM

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.

Attached Files


Edited by mizapf, Fri Oct 20, 2017 11:33 AM.


#72 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Fri Oct 20, 2017 11:36 AM

Hmm, and me not knowing much about TMS asm.  Anyone care to help?

 

Jim



#73 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Fri Oct 20, 2017 1:24 PM

Ah, sorry, I thought you know about assembly language ...



#74 mizapf ONLINE  

mizapf

    River Patroller

  • 2,636 posts
  • Location:Germany

Posted Fri Oct 20, 2017 5:58 PM

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 by mizapf, Fri Oct 20, 2017 6:05 PM.


#75 brain OFFLINE  

brain

    Chopper Commander

  • 231 posts

Posted Fri Oct 20, 2017 6:58 PM

 

 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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users