Jump to content

Photo

The Compact Computer 40 (CC40)


62 replies to this topic

#51 mizapf ONLINE  

mizapf

    River Patroller

  • 2,531 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

  • 119 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 OFFLINE  

Vorticon

    River Patroller

  • 2,764 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

  • 119 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



#55 mizapf ONLINE  

mizapf

    River Patroller

  • 2,531 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,531 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

  • 119 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

  • 119 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,159 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

  • 119 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

  • 119 posts

Posted Yesterday, 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

    Dragonstomper

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

Posted Yesterday, 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

  • 658 posts
  • Location:Vienna, Austria

Posted Today, 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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users