brain

I think so. In the schematic on that page: They left off the address and data lines. That's probably OK, I just need to verify I have a pinout of the TI74 connector so I can make sure I connect all those up. If, though, you can trace one of the lines (maybe pin 13 on the IC), that would help me ensure I get things ordered right. TI's D7 being D0 for everyone else messes with me sometimes. It's a shame TI74 carts have the connector on the cart, as that means it'll be harder to reproduce. Good measurements of the pitch of the connector (if that info is not already known) and the pad size would be helpful, to see if a connector can be sourced. I've never done a TI74 cart, so maybe the above information is already known in the community. If so, a link is fine.

#3, not that I am aware, but if you can get pics and dimensions, I can make a new PCB. #4 depends on seeing the schematic (which is dependent on #3)

Planning to be there, but not until Saturday. Jim

Call me clueless, but how did it connect to the TI? Was there a standalone FDC controller? Was a PEB required?

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.

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

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

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

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

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.

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.

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.

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.

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

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