A few thoughts about IECHost clients

After dinner today I was thinking about the IECHost client applications and I thought: wouldn’t it be cool to also add some browsing capability to¬†these applications? E.g. inspect sector contents after a disk imaging process, extract disk name and ID, export files, etc.? Yeah, that would be cool indeed ūüôā

Luckily, a while ago I worked at libd64fs, which is the core component of my D64 browser application as per below:

D64 browser by Luigi Di Fraia

D64 browser

Along with these browsing features libd64fs provides a sector handling function within its API, as per below:

/*
 * Set raw sector contents
 *
 * param 0: pointer to a disk structure as returned by d64_new_disk ()
 * param 1: track where to write to
 * param 2: sector where to write to
 * param 3: pointer to source buffer (ensure 256 bytes of storage were provisioned)
 *
 * return: d64_result_OK on success, d64_result_fail otherwise
 */
int
d64_write_sector                       (d64disk *d,
                                        unsigned char track,
                                        unsigned char sector,
                                        unsigned char *data);

That’s exactly one abstraction I can reuse to simplify my IECHost client code and make it even easier to maintain ūüôā

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

IECHost “warp” disk imaging GUI client finished

I managed to put together the few missing bits in my IECHost GUI client and I am incredibly happy with the results of the way I implemented it in order to¬†maximize the transfer over the USB connection ūüôā

Don’t take my word for it, judge for yourself in the video below!

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | 2 Comments

IECHost GUI client draft

Before bed time today I finished the first draft of the IECHost GUI client written using¬†GTK+. The new thing I thought to try is about drawing using cairo surfaces as backing pixmap. The result seems pretty neat so far and should prove to be straightforward to compile against GTK+ version 3 too ūüôā

IECHost GUI client by Luigi Di Fraia

IECHost GUI client by Luigi Di Fraia

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

IECHost “warp” disk imaging completed

This evening I finally finished the Windows command-line version of the PC client for IECHost’s disk dumping feature.¬†That’s just one part of the good news: I also managed to port the¬†“warp” transfer to the MCU I plan to use for this project and test it there, successfully ūüôā

Luckily, after some review of my code, I noticed that the MCUs that are in the same family don’t require separate code tuning: The wiring of the IEC bus signals on the MCU I plan to use are slightly different compared to the¬†MCU I was initially using for implementing the warp transfer. Once that was accounted for, things worked absolutely fine!

Just to recap, the current IECHost client can be used on a PC running Windows in order to receive a GCR image of the data sectors from a disk spinning in a 1541 drive connected to IECHost. Such image is then converted to a D64, very similarly to what WarpCopy64 does.

Total cost of the raw materials is around 5 GBP. I will work at a PCB design after Easter. I will also optimize the client software in order to buffer all GCR data in memory, while still going through some error checking to ensure the transfer from the 1541 is error free, and then do the bulk of the conversion ahead of saving to disk.

At the moment I am¬†buffering a single sector in the PC client, converting it and saving it to disk, which on my old and slow PC slows down the receipt of data from IECHost. However, overall disk dumping times are still comparable to WarpCopy64’s ūüôā

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

IECHost “warp” disk imaging almost complete

This evening¬†I managed to put together a new version of the IECHost firmware with which I made my first full disk dump, using¬†a 7-GBP-worth hardware setup ūüôā

As the PC client is not ready yet, I am just sending over data bytes in ASCII format and logging the console output to file. At a quick glance the output is very consistent and stable: empty sectors all look alike, i.e. as they should be ūüėČ

I am going to put together the PC client at some point but for now I will use the capture I made to test¬†the packet decoder, which still includes GCR decoding as I am not using on-the-fly GCR decoding at this iteration (and might entirely avoid it as it seems it doesn’t allow a two-revolution track dumping experience anyway).

Here’s one example of decoded sector:

Sector data (decoded GCR stream):
0000: 00 FF 82 11 00 45 41 53 59 50 52 4F 47 2D 31 2E .....EASYPROG...
0010: 36 2E 33 A0 A0 00 00 00 00 00 00 00 00 00 3E 00 ................
0020: 00 00 82 13 00 55 53 42 2D 42 41 53 49 43 20 31 .....USB.BASIC..
0030: 2E 31 50 A0 A0 00 00 00 00 00 00 00 00 00 07 00 ..P.............
0040: 00 00 82 13 02 55 53 42 2D 42 41 53 49 43 20 31 .....USB.BASIC..
0050: 2E 31 53 A0 A0 00 00 00 00 00 00 00 00 00 07 00 ..S.............
0060: 00 00 82 13 05 55 53 42 42 41 53 49 43 2E 43 52 .....USBBASIC.CR
0070: 54 A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 21 00 T...............
0080: 00 00 82 0F 0F 55 53 42 42 41 53 49 43 2D 31 2E .....USBBASIC...
0090: 32 2E 43 52 54 00 00 00 00 00 00 00 00 00 21 00 ..CRT...........
00A0: 00 00 82 15 02 44 36 34 44 55 4D 50 45 52 A0 A0 .....D..DUMPER..
00B0: A0 A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 10 00 ................
00C0: 00 00 82 16 00 55 53 42 42 41 53 49 43 2D 32 2E .....USBBASIC...
00D0: 30 2E 43 52 54 00 00 00 00 00 00 00 00 00 21 00 ..CRT...........
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Data checksum (as saved on disk): E1

Sector: 1
More sectors in track: Yes

Hopefully, things will¬†get very exciting very soon¬†ūüôā

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

IECHost “warp” transfer finished

This evening I finished tuning the new very fast receiver of sector data from a 1541 drive. The data I get at the receiving side seems to be stable and decodes as expected.

Unfortunately the protocol implementation is still quite dependent on the hardware it runs on: I tried to compile the very same code for a different MCU in the very same family and clocked at the same speed, but the outcome was not as expected. This means I might have to tune the code on a different MCU for the final release. Tuning is a somewhat laborious process, but when done for the same code on different MCUs during a short period of time it should not be too hard.

I’ve managed to code the decoding side of things on a PC application at the moment and here’s an example of the output:

Sector data (decoded GCR stream):
0000: 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Data checksum (as saved on disk): FF

Sector: 2
More sectors in track: Yes

That’s all for now. Stay tuned if you’re interested in¬†disk stuff ūüôā

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

Dissecting a 2-bit transfer protocol over the IEC bus

We know that Commodore defined their transfer protocol over the IEC bus. We also know that such protocol is quite slow but that it allows multiple slaves on the bus. Some of us have also read a description of the protocol by Jim Butterfield and seen various diagrams and traces, including those showing the electric signals over the DATA, CLOCK and ATN lines.

What I am sharing today is the trace for a fast 2-bit transfer protocol, which on one side allows way faster transfers but on the other side limits the communication to just one slave on the bus:

2-bit protocol over Commodore's IEC bus by Luigi Di Fraia

2-bit protocol over Commodore’s IEC bus

Due to the electrical nature of the IEC bus it is difficult to understand which¬†device is pulling low which¬†line, so here’s some description of what is going on.

In the initial phase, at around 1061+0.65 ms, the slave (a 1541 disk drive) pulls DATA low. The master (IECHost, impersonating a Commodore 64) monitors the DATA line and as soon as it detects the line being pulled low it acknowledges the event by pulling CLOCK low. At this point the slave, upon seeing CLOCK going low, releases the DATA line (which is pulled to +5V by pull-up resistors). Finally the master releases the CLOCK line. At this point, around 1061+0.7 ms, the slave pulls low both DATA and CLOCK lines, as it is obvious from the fact they go down at the same time, and then releases both, again they go up at the same time: this is the last chance for the master to synchronize with the incoming signal without requiring the use of an extra pacing signal. In fact, both the DATA and CLOCK line from now on are controlled exclusively by the slave in order to send over data bits: the master passively reads voltage values on both lines at a given pace.

Each bit couple within the same byte is sent by the slave 8 CPU clock cycles apart, about 8 us. After the fourth couple is read in by the master, the latter has to store it, which means the slave has to delay sending the bits that form the subsequent byte for as long as it takes the master to store the bits previously received and prepare for the following receipt. Fortunately no clock cycle is wasted as the the slave has its own job to follow-up with: fetch the next byte. So the complete sequence of events is:

  • master is idle WHILE¬†slave fetches the very first byte
  • master receives bits¬†WHILE¬†slave transmits them
  • master stores byte WHILE¬†slave fetches the second byte
  • master receives bits WHILE slave transmits them
  • and so on…

The total time spent between bytes is 22 CPU clock cycles on both sides of the transfer: again the master stores a byte during that time and the slave fetches the next byte.

Here’s some code on the slave side (transmit):

        LDX #$00      
B0329   LDA BUFF,X    ; Fetch a byte to send
        TAY           
        AND #$0F      
        STA $1800     ; Send bits 1 and 3
        ASL           
        AND #$0F      
        STA $1800     ; Send bits 0 and 2

        LDA MLKUP,Y   ; Perform 4 x LSR with this
                      ; lookup (fast) to get the 
                      ; high nybble
        STA $1800     ; Send bits 5 and 7
        ASL           
        AND #$0F      
        STA $1800     ; Send bits 4 and 6

And here’s the coupled¬†code at the master (receive), which is also the fastest implementation possible (at least with documented/legal OPCodes) at 8 CPU cycles between each received bit couple:

        LDA $DD00     ; Shift DATA and CLOCK in A
        LSR           ; and retrieve the next pair
        LSR           ; from bit 6 and 7
        ORA $DD00     
        LSR           
        LSR           
        ORA $DD00     
        LSR           
        LSR           
        ORA $DD00     ; Whole byte received

        STA WBUFF,X   

There’s plenty more code around these snippets in order to achieve the initial synchronization and keep both sides synchronized in absence of a pacing signal.

That’s something for another post though. What I wanted to show here is¬†how critical timing is when implementing the master side of the connection on a hardware “emulator” of some sort, e.g. IECHost, when a fast 2-bit transfer is in place.

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment