Path: utzoo!utgpu!watserv1!maytag!xenitec!zswamp!root From: root@zswamp.fidonet.org (Geoffrey Welsh) Newsgroups: comp.sys.cbm Subject: 6510 assembly punter source anyone? Message-ID: <4528.274478BD@zswamp.fidonet.org> Date: Fri, 16 Nov 90 14:44:29 PDT Organization: Izot's Swamp BBS - Kitchener, Ontario Matthew E Cross (profesor@wpi.WPI.EDU ) wrote: >I do have description of the protocol. ... and, if you implement according to that standard, it won't work. Notes on Implementing the C1 Protocol by Geoffrey Welsh with Matthew Desmond November 13th, 1988 When Steve Punter realized that his original PET Transfer Protocol (also known as "old Punter protocol") accepted too many compromises (its checksum mode was unreliable; its 7-bit approach meant that it ran at half speed, etc.), he decided to design a new protocol that circumvented the problems of performing file transfers on a Commodore 64 and some of the problems he had seen with his old protocol. At the time, many superior protocols existed that could have been adapted to use on the C64, but Steve was not aware of them or their strengths. He could only compare his new design to XMODEM. Steve's document describing the C1 protocol does not accurately reflect much of the real information needed to implement C1 and, in some cases, is outright misleading. Hence this file to help you understand what's going on. "CRC" Calculation ----------------- Steve's "CRC" is calculated by exclusive-ORing each successive byte in the block (with the exception of the bytes in the header where the checksums go, for which one should substitute zero bytes) and then ROTATING the CRC left through 16 bits. Note that the bit that "falls out" of bit 15 must be placed back into bit 0 immediately. Synchronization Lock -------------------- Steve's "Long-Long-Short" and "Short-Short-Long" solution to synchronization lock is downright silly. All will be well (and completely compatible) if the delay in the statement-and-listen loop is always set to long when transmitting and short when receiving. Varying Block Size ------------------ I recommend that block size variation be implemented such that maximum block size - 255 bytes total - is used on clean lines, but size is automatically reduced on noisy lines. In no circumstance should the block size exceed 255 bytes total (7 header and 248 data bytes); this is implied by the one-byte next block size indicator. Although block size may fall as low as 8 bytes, it would be rediculous to spend time on-line getting only one data byte accross per block; a more reasonable lower limit might be 40 (as suggested by Steve), or 31 (start with block size = 255; shift right every time two consecutive blocks are bad and shift left with 1 in the carry every time three consecutive blocks are good). Transfering File Type --------------------- This protocol was developed for use with Commodore computers, whose DOS treats executable, sequential, and random-access file types differently. As a result, existing implementations were designed to transmit the file type before the file itself. Non-Commodore machines may or may not preserve the file type transmitted by the uploader to be sent out when sending the file to a downloader using C1, but it is essential that SOME file type be identified when sending ANY file via the C1 protocol. Any file other than Commodore BASIC or 6502 executable binaries (with one exception: see note on "WordPro Files", next paragraph) should be sent under the file type "Sequential", so the type "Sequential" should be assumed if the exact type is not known. If a file is received under the wrong file type, it is easy enough to change Commodore DOS' file type flag. Nonetheless, it is obviously preferrable to preserve the file type as uploaded. By "Wordpro File", Steve means a file compatible with the text format he used in his commercial package WordPro for Professional Software, Inc.; this file type is seldom used and really means that the file is written as a "Program File" under Commodore DOS even though it contains WordPro format text. This file type may be translated to "Program". Steve's paragraph that begins "Transmitting this single piece of data would require that TWO blocks be sent; the initial dummy block to inform the receiver that the first (and only) data block is of size 8, and the data block itself, consisting of 7 header bytes and the file type byte." is blatantly inaccurate. Existing C1 implementations send the file type in a single, 8-byte (7 bytes header plus one data byte) block before the transfer of the file itself. First you must transmit (or expect to receive) the 8-byte file-type block and then proceed through the end-off sequence, then start the file transfer with a 7-byte block zero. No matter what, a close examination of Steve's implementation is absolutely necessary to obtain the finer details of the protocol. An ASCII dump of his Commodore BASIC and 6502 implementation is available on my BBS under the name C1IMP.TXT. Also, here is all that I could find about Alan Peters' "Multi-Punter" hack; this is the third of three C1 batch standards, and not necessarily the most common. Apologies for the all-caps, it's a side-effect of a quick PETSCII to ASCII conversion. FROM : ALAN PETERS TO : DEREK JAGDEO POSTED : 1251H ON 21-JAN-87 * TECH * SUBJECT: MULTI=TRANSFER CAT : GENERAL YOU CAN GO AHEAD AND DO IT, BUT I'LL GIVE YOU SOME SPECIFICS: UPLOADING. FOR EACH TIME THROUGH A MULTI-SEND, THE FIRST BLOCK MUST CONTAIN 27 BYTES OF DATA, RATHER THEN THE FILE TYPE. THIS IS STORED AS: BYTES 0-15 : FILE NAME, PADDED WITH SHIFTED SPACES TO LENGTH 16. BYTE 16 :I COMMA (,) BYTE 17 : FILE TYPE (LOWER CASE P,S, OR U) BYTES 18-20 : FILES LEFT TO SEND, IE 045 FOR 45 FILES LEFT. BYTES 21-23 : BLOCKS LEFT, TOTAL OF ALL FILES LEFT BYTES 24-26 : CURRENT FILE SIZE. YOU THEN MODIFY THE PUNTER PROTOCOL FOR MULTI LIKE THIS: OPEN CURRENT FILE FOR READ. CALL READY RS232 REC'V ROUTINE. CALL ROUTINE TO SWITCH PROTOCOL TO MULTI CALL TRANSMIT 1 ROUTINE CALL ROUTINE TO SWITCH PROTOCOL BACK TO NORMAL. CHECK FOR ABORT ($200) IF NOT, RESUME LIKE A NORMAL SINGLE FILE TRANSFER : CALL RS232 REC'V ROUTINE AGAIN, THEN TRANSMIT 2. CLOSE THE FILE, CLEAR THE BUFFER POINTERS @ $29B/$29C, WAIT A LITTLE, THEN DO THE NEXT FILE. IF YOU ARE DONE ALL FILES, THEN YOU MUST SEND ON END-OF-MULTI NULL STRING, WHICH IS 27 "-" CHARACTERS. PUT THIS IN THE 27 BYTE BUFFER, THEN CALL THE ABOVE ROUTINES FOR NORMAL FILE MULTI UPLOAD. DO NOT CALL TRANSMIT 2. DON'T OPEN A FILE, SINCE THERE IS NONE. THIS LAST PART IS IMPORTANT, SO THAT THE RECEIVER WILL KNOW WHEN TO STOP RECEIVING FILES. THE CHANGES TO THE PUNTER PROTOCOL ARE TRIVIAL. THE ROUTINE THAT CONVERTS IT TO MULTI LOOKS LIKE THIS: TOMULTI LDA #27 STA L1+1:STA L2+1 LDA #128:STA MMODE BRN LDA HSHAKE:PHA LDA HSHAKE+3:PHA LDA HSHAKE+2:STA HSHAKE LDA HSHAKE+5:STA HSHAKE+3 PLA:STA HSHAKE+5 PLA:STA HSHAKE+2\ RTS FROMMULT LDA #1 STA L1+1:STA L2+1 LDA #0:STA MMODE BEQ BRN THE FIRST LABEL, L1 OCCURS IN THE REC'V ROUTINE @ $C4CE. YOU WILL BE CHANGING THE ADC #1 INSTRUCTION TO ADC #27 TO MAKE THE FIRST BLOCK LENGTH 27 INSTEAD OF 1. IT MUST BE CHANGED BACK TO 1 BEFORE YOU CALL THE TRANSMIT 2 OR RECEIVE 2 ROUTINES. THE MMODE VALUE IS TO ALLOW THE BUFFERING ROUTINE IN THE PROTOCOL TO MOVE THE 27 BYTES FROM THE PUNTER BUFFERS TO THE 27 BYTE BUFFER. INSERT THE FOLLOWING IN THE CODE JUST AFTER THE FILE TYPE IS STORED IN RECEIVE1: BIT MMODE:BPL RESUME LDY #0 J1 LDA PUNTERB+7,Y STA BUFFER,Y INY:CPY #27:BNE J1 RESUME..... YOU MUST CHANGE THE TRANSMIT ROUTINE AT $C517 AS WELL. THE ADC #1 WILL CHANGE TO ADC #27, THEN BACK AFTER THE FIRST BLOCK. IN THIS TRANSMIT 1 ROUTINE, LOCATIONS $64/65 INDIRECTLY ADDRESS THE PUNTER XMIT BUFFER. SO, THE SMALL MULTI INSERTION CODE LOOKS LIKE: BIT MMODE:BPL RESUME LDY #7 J1 LDA BUFFER-7,Y STA ($64),Y INY:CPY #34:BNE J1 RESUME ... THIS GOES JUST AFTER THE CODE WHERE THE FILE TYPE IS PUT INTO THE BUFFER. THE HANDSHAKE REVERSAL DOES THIS: GOO TO OOG AND BAD TO DAB. I FOUND THAT IT IS NOT NECESSARY TO CHANGE THE OTHER 3 SIGNALS. FOR THE RECEIVER, HE MUST DO THE SAME AS WITH TRANSMIT, BUT USE THE BUFFER DATA TO WRITE THE FILE TO DISK. HOPE THIS HELPS. ALAN PETERS * TECH * -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!