Jump to content

brain

Members
  • Posts

    624
  • Joined

  • Last visited

3 Followers

Profile Information

  • Gender
    Male

Recent Profile Visitors

4,778 profile views

brain's Achievements

Dragonstomper

Dragonstomper (6/9)

468

Reputation

  1. Call me clueless, but how did it connect to the TI? Was there a standalone FDC controller? Was a PEB required?
  2. Well, I thought doing the display adapter would be a good test. Once the HexBus protocol is in place, additions would be much easier. Mainly I felt the Pi0 was one of the cheapest options with HDMI already on board, with a low cost. It's vastly overkill, but HDMI is hard to design into something, due to the licensing fees. Still, with the Pi, pretty much any peripheral is possible. To your philosophy, I did intend for 2 variations of the display. One would be local (HDMI) and one would be remote (ANSI as one sub-option and web display as another). But, local seemed fastest to implement.
  3. Yes (there's a command to "save" the config. That said, I know there's a bug in the se(t) command for device IDs. It's been a zoo here, but let me see if I can fix that bug. Obviously, you can mod the code and recompile, which is what I did to temp fix. Jim
  4. 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
  5. 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
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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
×
×
  • Create New...