Jump to content

Vorticon

+AtariAge Subscriber
  • Posts

    5,824
  • Joined

  • Last visited

  • Days Won

    5

Vorticon last won the day on March 23 2023

Vorticon had the most liked content!

4 Followers

About Vorticon

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    USA
  • Interests
    Retrocomputing, electronics, astronomy, tabletop wargaming, tennis

Recent Profile Visitors

18,638 profile views

Vorticon's Achievements

Quadrunner

Quadrunner (9/9)

5.2k

Reputation

  1. Ah. That may be the issue. I used an arbitrary 20000 counter loop (>4E30) which is probably too short.
  2. I'm wondering if the timing loop was too short. But I think I'm going to leave it there as it's working well enough as it is. I now know more about Xmodem than is safely allowed...
  3. Yes, that's how I set it up. The loop is never executed if there is a character in the buffer.
  4. Making that change slowed the transfer rate considerably...
  5. This should help a little: To get a directory: OLD "100.$" then LIST DEVICE NUMBER IS 100 Power up drive then CC40 then cycle power on drive to activate. For the drive, there are two options: open #1,"100" print#1,"cd /jim/path/to/cc40/files" If using the regular open, note that the filename MUST be absent, or the system will assume a file is to be opened. Commands can be sent via print statements, and the response code will note the results. Alternatively, the "special command LUN" is available: Either: open #255,"100" print#1,"cd /jim/path/to/cc40/files" OR: open #255,"100.cd /jim/path/to/cc40/files" <and you can print more commands to perform after the open. You can also chain the commands: On either LUN: print #<LUN>,"md /jim,cd /jim" On the CMD LUN: open #255,"100.md /jim,cd /jim" I would not recommend chaining commands, as the parser will fail on the first error, but there's no way to return which command failed. On serial and printer, the non CMD LUN option is already supported, as it was part of the original standard: open #1,"20.B=19200,D=8,S=1,P=N" Such commands will set the configuration of the current serial connection. The special CMD LUN on these devices will set the global defaults: FOr instance, to set the default bps rate for all new connections that don't absolutely specify it, do: Either: open #255,"20.B=9600" or open #255,"20" print #255,"B=9600": rem set global BPS rate default to 9600. The CMD LUN offers 2 additional features on each device. To change the device number of a device, open it's CMD LUN and issue a device number change command: Either: open #255,"<devno>" print #255,"DE=<new_device_number>" or open #255,"<devno>.DE=<new_device_number>" A close afterwards will fail, because the device number changes immediately. To store new global defaults for serial or printer, or device numbers for any of the devices supported (clock, serial, printer, drive), the command: "ST" issues on the CMD LUN of any device will write the current configuration to EEPROM, which will be read when the system restarts. Drive commands: static const action_t dcmds[14] MEM_CLASS = { {DISK_CMD_CHDIR, "cd"}, {DISK_CMD_CHDIR, "chdir"}, {DISK_CMD_MKDIR, "md"}, {DISK_CMD_MKDIR, "mkdir"}, {DISK_CMD_RMDIR, "del"}, {DISK_CMD_RMDIR, "delete"}, {DISK_CMD_RMDIR, "rmdir"}, {DISK_CMD_RENAME, "rn"}, {DISK_CMD_RENAME, "rename"}, {DISK_CMD_RENAME, "mv"}, {DISK_CMD_RENAME, "move"}, {DISK_CMD_COPY, "cp"}, {DISK_CMD_COPY, "copy"}, {DISK_CMD_PWD, "pwd"}, {DISK_CMD_NONE, ""} COPY and PWD are not implemented as yet. rename is "rn newname=oldname" Note that some commands have synonyms. Note that the cc40 spec also defines a "delete" operation, like open and read, which should preferably be used for programs. This cmd is mainly for directory removal, but it (currently) also works on files. Serial Options: static const action_t cmds[] PROGMEM = { {SER_CMD_BPS, "b"}, {SER_CMD_BPS, ".ba"}, {SER_CMD_LEN, "d"}, {SER_CMD_LEN, ".da"}, {SER_CMD_PARITY, "p"}, {SER_CMD_PARITY, ".pa"}, {SER_CMD_PARCHK, "c"}, {SER_CMD_NULLS, "n"}, {SER_CMD_STOP, "s"}, {SER_CMD_ECHO, "e"}, {SER_CMD_LINE, "r"}, {SER_CMD_TRANSFER, "t"}, {SER_CMD_OVERRUN, "o"}, {SER_CMD_NONE, ""} These are all of the form <opt>=<value> Serial Option Alternates emulated from TI 99/4A: static const action_t ti_cmds[] PROGMEM = { {SER_CMD_TW, ".tw"}, {SER_CMD_NU, ".nu"}, {SER_CMD_CH, ".ch"}, {SER_CMD_EC, ".ec"}, {SER_CMD_CR, ".cr"}, {SER_CMD_LF, ".lf"}, {SER_CMD_NONE, ""} }; The above are very specific. .tw by itself means stop bits needs to be 1. The HexBus spec describes the mappings (though, you can see I disagree with some of them. Maybe folks can let me know if the official TI specs for modems and such agree with this or me: cmd = (sercmd_t) parse_cmd(ti_cmds, &buf, &len); switch (cmd) { case SER_CMD_TW: cfg->stopbits = STOP_1; break; case SER_CMD_NU: cfg->length = LENGTH_6; break; case SER_CMD_CH: cfg->parchk = TRUE; break; case SER_CMD_EC: cfg->echo = FALSE; break; case SER_CMD_CR: cfg->line = LINE_NONE; // seems wrong break; case SER_CMD_LF: cfg->line = LINE_CR; // Seems wrong break; Printer options: static const action_t cmds[] PROGMEM = { {PRN_CMD_CRLF, "c"}, // ALC printer/plotter {PRN_CMD_CRLF, "r"}, // 80 column printer {PRN_CMD_COMP, "s"}, // alc printer/plotter {PRN_CMD_SPACING, "l"}, // 80 column printer You can see the full mappings for the units in the source, which is pretty easy to read:
  6. Yes I probably should as it does tend to hang the TI if one or more bytes are missed from a packet on reception. Not an issue up to 2400 bps. Not sure how much of a performance hit I would get. Easy to test.
  7. I switched the Xmodem routines from byte to packet based send and receive and there is a definite increase in baud rate, but not nearly as much at @TheBF is reporting. For send I can go as high as 9600 bps, but for receive only 2400 bps remains reliable although I have managed a couple of 4800 bps transfers. I am not setting any character or line delays in Teraterm. Below are the assembly routines, and they are as tight as I can make them, so it's unclear to me what else I can do. ;set of routines for packet reception for xmodem ;by walid maalouli ;March 2024 .proc xsetrs232,1 ; set up the rs232 card cru base ; 1 = CRU 1300H, 2 = CRU 1500H ; usage: setrs232(n) .def cruadr,pmeret,procret,pcodeon,pcodoff,uartdis .def rs232on,rs232of mov r12,@pmeret ;save the pme pointer mov *r10+,r1 ;get desired RS232 card number ci r1,1 jne rs2322 li r12,1300h li r3,40h ;uart base address displacement jmp savecru rs2322 li r12,1500h li r3,80h ;uart base address displacement savecru mov r12,@cruadr ;save base CRU address mov r3,@uartdis ;save uart base address displacement mov @pmeret,r12 ;restore the pme pointer b *r11 cruadr .word pmeret .word procret .word uartdis .word pcodeon li r12,1f00h ;activate the pcode card sbo 0 mov @pmeret,r12 ;retrieve the pme pointer b *r11 pcodoff mov r12,@pmeret ;save the pme pointer li r12,1f00h ;deactivate the pcode card sbz 0 b *r11 rs232on mov @cruadr,r12 ;load rs232 cru base sbo 0 ;turn card on sbo 7 ;turn card led on b *r11 rs232of mov @cruadr,r12 ;load rs232 cru base sbz 7 ;turn card led off sbz 0 ;turn card off b *r11 .proc getpacket,1 ;get an xmodem packet ;usage: getpacket(bytearray) .ref pcodeon,pcodoff,rs232on,rs232of,uartdis,procret mov r11,@procret bl @pcodoff bl @rs232on mov *r10+,r1 ;get array pointer a @uartdis,r12 ;uart base cru address li r2,131 ;number of bytes to get sbz -27 ;activate cts line bufchk tb 21 ;check if receive buffer is empty jne bufchk stcr *r1+,8 ;store byte into array sbz 18 ;reset buffer cru bit 21 dec r2 jne bufchk ;132 bytes transferred? sbo -27 ;inactivate cts line bl @rs232of bl @pcodeon mov @procret,r11 b *r11 .proc sendpacket,1 ;send an xmodem packet ;usage: sendpacket(bytearray) .ref pcodeon,pcodoff,rs232on,rs232of,uartdis,procret mov r11,@procret bl pcodoff bl rs232on mov *r10+,r1 ;get array pointer a @uartdis,r12 ;set uart base address li r2,132 ;number of bytes to send notconn tb 27 ;test dsr pin. is receiver connected? jne notconn sbo 16 ;activate rts line waitcts tb 28 ;wait for receiver to activate cts line jne waitcts chkbuf tb 22 ;is emission buffer empty? jne chkbuf ldcr *r1+,8 ;send byte from array dec r2 ;are all bytes sent? jne waitcts sbz 16 ;inactivate rts line bl @rs232of bl @pcodeon mov @procret,r11 b *r11 .end and here's the new XMODEM program Still, I'm overall pretty happy with the results and it's fast enough for most transfers and much faster than whole disk transfers. Updated disk image attached. RSUTIL.dsk
  8. Ah I think I understand where you guys are going with this. STCR directly to *R1+, and since it's a byte move, the autoincrement will increase the target memory by one byte so that I end up having a byte oriented buffer. No need for using another register (R6) at all and no byte manipulation. Then in the host program declare a packed byte array that would receive that buffer. Saves a few instructions in the receive routine which is always good. I'll make the changes and do some testing later today.
  9. Seems to me it's the other way around! But hey I'm always up for a little confidence building 😄
  10. Since the return subroutine stack returns words, not bytes, that is the reason for declaring an array of integers. I suppose I could pack 2 bytes into a register in the assembly receive routine before returning, but that adds more instructions and delays. Then I can declare a packed array of bytes. Not sure there is value in doing that since it complicates things.
  11. I'm sure he'll chime in on this and give you all the gory details
  12. I for one would love to have hard copies of the back catalog.
  13. Works great with xmodem transferred code and text files. Thank you! Edit: transferred data files can be added to existing disk images with the Get Binary File option of Pcode Tool. As a background, the whole purpose of creating the Xmodem utility was to allow for file transfers to the PC for backup or sharing purposes and the other way around, particularly when when it's only 1 or 2 files. Prior to Xmodem, the only way to transfer files to/from the pcode system was by using Fred Kaal's HDX system and the DSK2PC utility which transfers whole disks, a rather slow process requiring modifications to the RS232 card. The problem encountered with Xmodem transfers however was that the files were not recognized by Pcode Tool properly and so could not be imported into a disk image. This issue has now been solved Pcode Tool is an invaluable utility for any pcode system user, so big thanks to @Rhodanaj for all his efforts. On a side note, I can definitely relate to his space-themed avatar icon
  14. The p-system is natively 80 columns, implemented on the TI with scrolling windows. It's effective enough once you get used to it. That said, support for the F18A would have been awesome though. It's not trivial to expand the system because the code is spread out between the ROMs and 2 different code pools (VDP and RAM) and minor changes can easily break it. Case in point being the Editor which practically uses nearly every last byte of the VDP. @apersson850 did expand his system with a 4th floppy drive and a couple of RAM disks as well as a hardware RTC, but it required some high level wizardry. One gets the feeling that the p-system was forcefully squeezed into the limited TI resources using every possible trick in the book at the expense of expansion flexibility. Still quite an achievement and by far the best development environment available at the time on the TI when emulation and cross-development were not available.
  15. Indeed, but I still need to SWPB prior to returning These are the relevant lines on the host side TYPE INTARRAY = ARRAY[0..131] OF INTEGER; VAR BLOCK : INTARRAY; PROCEDURE GETPACKET(PACKET : INTARRAY); EXTERNAL; BEGIN ... GETPACKET(BLOCK); ... END. According to what you said then, this should work fine. In that case it must be a transmission issue somewhere. I'll do some more digging.
×
×
  • Create New...