Jump to content

brain

Members
  • Content Count

    423
  • Joined

  • Last visited

Community Reputation

304 Excellent

About brain

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male

Recent Profile Visitors

3,926 profile views
  1. Wow! I buy DIN6 all the time for projects, and they used to be $.50-$.90/unit. Not sure what is going on with the $3.XX pricing. But, if there's a need, I buy them in bulk now for cheaper prices. Still, eBay has you covered: https://www.ebay.com/itm/Circular-DIN-Jacks-Right-Angle-PC-Board-Mount-6-Position-NEW-Qty-5/200766611764?hash=item2ebe9f6134:g:G4UAAOxye5BREkvs And, there's a footprint in EAGLE which can be easily converted. Jim
  2. It's not hard gold, but I've had units in production and use for years with ENIG and no issues. If it does wear away, there's copper below it, which might get a bit of patina on it, but nothing a quick run with an eraser or something won't fix. Unless the item is a collector unit, I am not sure the extra cost of hard gold on the fingers is worth the expense. On the other hand, depending on PCB house, hard gold on the fingers may not cost that much, so if folks care a lot, a batch of 100 PCBs might only be only $.50/PCB more for hard gold. For my money, though, I don't think it's justified. Jim
  3. PAL and NTSC use the same power supply outputs, so just use a NTSC PSU. Unlike the 64, I don't believe the 50/60 Hz issue plays a part. Jim
  4. I agree with @arcadeshopper, merges tend to be a bear, unless they are automatic, at least for me. That said, it's unclear if the poll is: 1) how many people use online version control in general or 2) How many people use github.com versus gitlab, bitbucket, or other options It's probably not: 🙂 3) How many people use online source control as opposed to a offline set of repos or 4)How many people use source control at all As for me, I have used source management for many years, standing up SVN long ago on the main home Linux server and periodically publishing tarballs/ZIP archives of my working files. But, since I release almost all of my projects as open source anyway, tools like github are attractive as they automate some of these things and make it easier to be transparent about project efforts. For some projects that I don't share publicly, I use bitbucket, mainly because at the time they allowed private repos for a lower cost.
  5. I question your statement that there are not 32K options at economical prices, but there's a few projects online to build your own: https://github.com/dikdom/VIC-20-RAM-ROM-Expansion I know there's a design that fits completely in the space between the edge connector and the edge of the case, but I can't find the list. I know I also designed VICMem for some folks at ECCC/VCF-MS a few years back, and cna put the project files up.
  6. IN a word, no. You *might* be able to create a specialized serial connection to replace it, but it would require probably FPGAs on both sides, and a VERY fast clock speed. The idea would be to marshall all of the PEB signals at the TI very quickly and then shift them out via a serial line to the same kind of thing on the PEB side, which would then unmarshall them and present them to the PEB as before. Then, close to the end of the cycle, do the reverse, taking into account that certain lines need to be handled special because they are IO lines (address never needs to be sent back, but data does on a read cycle, and the CRU stuff needs to be handled special as well). Possible, yes. practical, less so. A better bet would be to shrink all of the PEB functionality and move it to the TI, like TIPI and other solutions do. Jim
  7. 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: https://github.com/go4retro/HEXTIr/blob/master/src/drive.cpp#L350 (350-429) https://github.com/go4retro/HEXTIr/blob/master/src/serial.cpp#L44 (44-280) https://github.com/go4retro/HEXTIr/blob/master/src/printer.cpp#L51 (51-127) I hope that helps. Let me know if others are needed.
  8. Additional testing looks good, one more bug fix for reading a directory via program, so I've merged the code into master. Evidently, I cannot create a Github release on a generic commit on a branch, which was where 0.9.2.0 and 0.9.2.1 was, so I bumped the version to 0.9.3.0 and created a release: https://github.com/go4retro/HEXTIr/releases/tag/v0.9.3.0 Jim
  9. Small fix for serial routines (code was not allowing bps rate change) and a minimal implementation of reading the firmware version back (open the command channel and read a string). Version bump to 0.9.2.1. Have not heard anyone testing the code, so not sure of status, but my testing has been successful, and I am currently considering the system feature complete. I also uploaded the working bootloader for the non Arduino (standalone) version of the device (https://github.com/go4retro/HEXTIr-bootloader). With this, a self contained professionally produced unit that automatically updates itself is possible. Let me know if there is any interest. Expected cost would be around $50.00. Jim
  10. Is there any additional data on this? Unless the design itself is marginal, I would not think a 3MHz design would need impedence matched traces. @Phoenix, I think the newest EAGLE (post 7.X) does them. I don't know for sure, since I keep a hold of my purchased 7.X version of EAGLE instead of the new subscription version.
  11. HEX-TI-r (pronounced like the person's name, Hector :-)) Updates Configuration and per device commands enabled: Peter Engels contributed code to enable disk commands: chdir, mkdir, rmdir, rename. Old configuration device (#222) is gone (code never was complete) and replaced with per device global configs open #255,"<device>[.<optional commands>]" print #255,<commands>" close #255 Where commands are: "DE=<devnumber> and ST (store config in EEPROM) Drive can also be opened in command mode via open #<1-254>,"<device>" (no filename) Both global commands and disk ops can be combined via comma: "chdir /jim,mkdir jim2" All known device-specific options supported (B=300 and such for serial, L=N for printer) on open string Set global serial and printer defaults via #255 LUN (open #255,"20.B=19200,D=8,P=N" for example ST command will save all global defaults and current device numbers to EEPROM, which will be loaded again on next boot. A bunch of code cleanup and code size minimization The serial device (#20) is routed to the USB serial device on the Arduino, which will be available when not uploading new code. This means one can run multiple HEXTIrs on the same bus, daisy chaining them, after setting the devices to be unique. Code size is approach 32kB on Arduino build (strangely, native Makefile build is only 29K), so we are approaching feature complete state. I have been testing here on my Arduino, so I think all should be good, but I'd always like a few more testers before we merge into master: https://github.com/go4retro/HEXTIr/tree/eeprom Due to the need to use 255 for CMD mode, RAW mode LUN is now 254. (I realize I still need to get updated BASIC programs for the BASIC repo directory that use the new LUN). Jim
  12. My understanding is that the cassette routines used the pins, but not the protocol, so the cassette unit must be the only device on the bus (no daisy chain). The key to getting this work is whether the CPU ROM routines have any "traps" or "exits" that can be used to extend the functionality. If not, it'll be extremely difficult to add the capability. If there are, it should be a simple matter to put the 74 routines ona ROM card, patch them into the traps, and there you go. However, I will say the idea has no appeal to me (sorry, lots of things are academically interesting, but that's as far as I take them), so I'd invite someone else to tackle. Jim
  13. Peter says: "RWRAM.B40/74/C40/74 allows to read/write/verify RAM/ROM 8/32k images. ROM is clearly r/o." They would be in the same dir as the other BASIC programs I linked to.
  14. I'll try to have Peter write a little app to show how to use 255 (which is not set in stone, as we found a use case that makes 255 potentially better to send drive commands, so we might move it to 254). Jim
×
×
  • Create New...