Jump to content
IGNORED

The Compact Computer 40 (CC40)


Recommended Posts

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.

Link to comment
Share on other sites

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

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

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

hx5102_dis.zip

Edited by mizapf
  • Like 1
Link to comment
Share on other sites

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

 

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

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.

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

Loading...
  • Recently Browsing   0 members

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