Jump to content

brain

Members
  • Posts

    620
  • Joined

  • Last visited

3 Followers

Profile Information

  • Gender
    Male

Recent Profile Visitors

4,775 profile views

brain's Achievements

Dragonstomper

Dragonstomper (6/9)

465

Reputation

  1. They are both in the build, but I can't guarantee your specific device has them both enabled in the compile. If you use the hex/bin files from the github, I turn all of them on (clock, parallel, serial, disk) Serial is on the serial port. 5V parallel is available as a serial stream (not enough pins on the unit for a real parallel port) on portD, pin 5. You'll need something that can handle 5V TTL serial to use it Yes, SD is hotplug compatible. It will corrupt files if they are open when you change disks. I see someone else copied in the instructions for md/cd/rd jim
  2. Actually, it doesn't need to be. Just wire up a second port attached to the first, or use a Y-cable, and you can add devices after it. Jim
  3. Yes, but not because of the adapter. The issue is that some card creators implement "just enough" of the standard to respond to Windows/MacOS/Linux. Sometimes, if the sd2iec code differs in any way in initializing the card, these cards fail, because the are not expecting commands in a different order, etc. The SD->MicroSD adapter is purely passive, so it's mainly the code in the card itself, mico, mini, or full. Jim
  4. Cool! This gives me some initiative to finish the Pi Zero W HEXTIr Display adapter I started. I was working on porting the HEXTIr code to the Pi, and got busy with other things.
  5. Good sanity check. I think all the bootloaders are FAT32 compliant. BUt, as I said earlier: The normal SD card routines, even for read, take up far too much code, so the code was stripped and simplified for the 4k limit of the bootloader (the size of the space for one). As such, there are more restrictions on the bootloader being able to init a card. The most likely answer is lack of bootloader, as you initially surmised. Msot folks should be able to program the unit or might even be able to put a bootloader on it.
  6. The lack of update can be due to the firmware being mismatched for the hardware , not being able to open the sd card, or lack of boot loader. Note that the boot loader often uses a different way to access the sd card so normal operation of the sd card in the h it does not absolutely guarantee the boot loader can read it.
  7. I would try it with and without the spaces after the commas, it looks like I trim, but my se=21 is broken, so perhaps the space trimming is as well. This is from the Specifications PDF, which is what I wrote against.
  8. OK, well, that at least does not look like debug info, so there's that. Here's a few things we can try, before I get home, if you can program your unit with a new binary. 1) we can program an debug binary, and you should see debug information (that would at least validate the serial port is working) 2) I can pre-open a serial connection and send some test data our on bootup. Jim
  9. The defaults in the code are: https://github.com/go4retro/HEXTIr/blob/51ea22df26cbc6beedb13e90dd0e530246948a9c/src/serial.cpp#L569-L584 _config.ser.bpsrate = 300; _config.ser.echo = TRUE; // TODO see exactly what this means. _config.ser.length = LENGTH_7; _config.ser.line = LINE_CRLF; _config.ser.nulls = 0; _config.ser.overrun = _cfg.overrun; _config.ser.parchk = FALSE; _config.ser.parity = PARITY_ODD; _config.ser.stopbits = STOP_0; _config.ser.xfer = XFER_REC; The XFER_REC should cause an issue, as defined by the HexBus-Specifications.pdf doc, page 242, but it looks like I did not implement it at all, so all XFER_* behave like XFER_CHAR, which is char in, char out... See if those settings help. If not, I'd hook it up to a terminal program and boot the system. It might be that your build has debugging, which is either 57600 or 115200/n/8/1, and it overrides serial. If so, my bad. I try to turn it off when a build is ready, but I might forget at times. If you need debugging, I can help, but it'll be a week, as I can't get to my lab this week. Jim
  10. Yep, I forgot some of the designs used the FETs in lieu of the '06. The FETs sink more current (320mA sink capability), but it doesn't looks like that design actually drives to ground directly. I know not everyone is an electronics guru, but a Metal Oxide Semiconductor Field Effect Transistor (MOSFET) is not hard to understand, and you can think of it link a valve or a switch. https://www.electronics-tutorials.ws/transistor/tran_7.html In general, the "gate" (G) is the little top line of the MOSFET, while the "Source" (S) is the part where the arrow line connects to, and the Drain (D) is the line you are trying to control. In your schematic, the gate is driven 100% of the time to be ON, because it's connected to VCC, while the Sink is connected to the AVR. The Drain is hooked to the bus. In this mode, it looks like they are using the FET to "convert" voltages (perhaps the AVR is running at 3V, while the IEC bus always run at 5V. But., since the FET can only drive to ground through the AVR pin (by setting the pin to output and setting it to 0, I think you are still limited to 20mA (in a design, the sink current is equal to the weakest element). In general, the sd2iec designs with separate *_IN and *_OUT lines are best. Here's one that's not too bad. https://www.hackup.net/wp-content/gallery/sd2iec-plug-1/schematics0.9.png Look at the schematic on that slideshow. Notice that IEC_CLK comes in, goes into the Drain of the FET directly, just like in your schematic above, but the Source is connected to ground through F8 (18ohms). 18 is pretty small, so mainly a short. The designer was trying to protect the FET by not allowing an infinite amperage to flow across the FET (our V = I * R equation ... or voltage = current * resistance, can be rearranged to voltage/resistance = current, so 5V/18ohm = 270mA, less than the 2n7002 can handle, and much less than the IRLML2803 can handle ~1A). If 5V is presented to the gate via AVR PA6 (port A, bit 6), the IEC Clock line will be pulled to ground. Otherwise, it's left to float. But, also notice the R10/R11 combo connected to IEC_CLK and then feeding into PA2. That's a dedicated input line (2 AVR pins are used to handle IEC CLock line, one is a dedicated input, the other a dedicated output). The reistors are there because the AVR in this schematic is running at 3.3V, so the 5V needs to be "cut down" to a lower voltage. Two resistors like this allow you to passively lower voltage. It's not perfect, but it does work. THere's a calc to figure these out, but I always use an online calculator, like https://ohmslawcalculator.com/voltage-divider-calculator If we drop in 5V, 10000 ohm, 22000 own, we get 3.438V at the AVR input pin, well within tolerance for a 3V3 uC. In my opinion, this is a better design, as it allows the bus to be driven to ground hard (270mA) and even better than an 7406 (but, in this case, the 7406 in the 1541 or the printer becomes the limiting factor and thus limits the number of devices on the bus. So, if you build a new sd2iec, I'd use this version of the circuit (you can re-use the 2n7002 fets in lieu of the IRLML2803), and adjust the firmware accordingly. Keep bugging me to put the uIEC/SD design up on my github. It should be there, as the unit is open source. Jim
  11. I think it depends on the type of sd2iec unit you buy. There are lots of hardware variants, and some omit the 7406 "driver" IC found in the 1541. If the proper 7406 is there, You should be able to turn off at least 2 devices in a 4 device chain and still have the unit function. However, if a "weak" 7406 (74hc06, or 74ahc06) are used, all devices have to be on (and the number of devices allowed on the bus goes down a lot. Nowadays, most folks only have 1-2 devices on, but you were able to do 5 devices (+ PC) in the olden days. Tre trick is the specs for the 7406 variant in use. https://www.ti.com/product/SN7406 Look at the Iol (max). That is the important number. 40mA is a lot. LS and ALS also do 40mA If we look at the myriad of options: https://www.digikey.com/en/products/filter/gates-and-inverters/705?s=N4IgjCBcoKxaBjKAzAhgGwM4FMA0IB7KAbRAGYAOAJjABYJ9Kba4BdfABwBcoQBlLgCcAlgDsA5iAC%2B%2BKrQDs8EEkhoseQiXIwAnPPkUQ7EN14CRE6bPkA2JSrU58RSKSoAGCjZ06Q%2BMN7uYL7%2Bge52%2BDDeAX4gtBQUekacPJD8QmKSMiA2NorQyigYTpqu5Dq5bClmGZbZHjq09kXqzlp2xqZpAJKiXNji2IJWIAC0VM2QQgCuGi6kbNmjvgUqM3NaEKxS9VpiAG5D-cPGdgXCACa8uhPVaeaZsVwAnhzYvKiYSDtAA We see values in Current-Output Low from 8-40mA Most designs use ones that don't source 40mA (they are no doubt more expensive), and that is an issue on a heavility loaded bus. Not using the 74XX06 at all means the AVR is responsible for the bus, and I think it tops out at 20mA per pin. You want to see 32-40mA options for this bus driver. I suspect your version uses a cheaper and less capable driver, hence the issue with multiple devices. I know I, when I was adding CMD style commands to the sd2iec firmware for the uIEC/SD, wanted to make sure it played nice on my bus, which has 2 1541s and a CMD HD on it already, when some of them are turned off. Not a sales pitch per se, just information. FOr most folks, the lack of a strong buffer is no big deal, and it saves production costs, as does skipping the IS entirely. But, if you want a more close replacement to the CMD, you might have to go up in pricing a bit. Jim
  12. Well, you can also just wait to type something, or do a FORT=1TO1000:NEXT 🙂 TO avoid the issue entirely, you can have someone reflash the AVR uC so the bootloader is not there (it's not required for normal operation), though you do lose the auto-update feature if you do so. I may add a feature in uIEC/SD (my sd2iec variant) to have a jumper to disable the bootloader (skip over it), to speed things up, and you can remove the jumper (or put a switch on it) to optionally run the bootloader. The reason the 1541, CMD HD, and CMD FD don't have the issue is that they all contain a "kludge" for the ATN accept line. Normally, the ATN ack needs to be done in a short enough timeframe that the code in the 1541 (and other devices) can't handle it in software all the time. So, CBM engineers put an "auto-ack" in the hardware design to compensate. Now, the AVR in the sd2iec is much faster and doesn't have the same issue, but the "auto-ack" also helps on boot if the user tries to access the bus before the 1541 is done with self test. Since the AVR didn't need the extra HW, it was not designed into the schematic. It could be added, but it's 2 more ICs, and that can change pricing quite a bit, with it being as cheap as it is already.
  13. I'd see if it's a timing issue. Most sd2iec devices have a bootloader that runs first, so they take 2-5 seconds to boot, depending on the SD card contents/directory entries. On a uIEC/SD, you will notice the green light goes on, goes off, and then goes on and off again. Only after the second on/off is the drive ready to use.
  14. In general, for the Commodore serial bus, devices need to be on at all times. Because the bus is an open collector (drive to 0 hard, float to 5V via a resistor), any device turned off tends to pull the bus down to ground via the resistors dragging the bus down.
×
×
  • Create New...