Gunners TekZone

The "irony"... In my attempt to avoid point to point soldering, I opted for the Reboot PCB option. And ended up doing exactly that anyhow to fix this boards' "issue". I can run, but I can't hide. Turns out even that repair was super simple... Although I continue to give GOD the glory for clearing the brain fog and for the insight, as was required to get this far. Here is a nice closeup for anyone wanting to do the same, but don't forget to cut the equivalent traces along that top row of the VIA (on both sides of PCB). Now I too have multi-brand computer options for my two Interface-A boards I'll fix the 2nd card as well... For when I breakdown and get a 3rd Int-A.. which apparently must happen, as I still have empty slots in the APCO

Ah, yes... that would make more sense. Perhaps "fair" in the sense of a niche product for a slim audience... But in no way for what it is component and (lack of) complexity wise. These Apple and IBM Interface cards are very simplistic in that sense. Welcome!! Join the club... Well, I guess I am the one joining the "clone" club. - APCO Apple IIe clone that needed minor trace repairs. - A "bodged to work" LEGO 9767 (reboot) card. - And (initially) a VIC-REL (reboot) Interface-A like board (minus the built in H-Bridges) - Pictured below, with my experimenter breadboard addon. But all together, I still purchased all three for less than a Blocko! I seem to be all about the Prep-to-Play over Pay-to-Play experience And yes... The VIC-REL on my VIC-20 is "relevant" as I am using it to try my hand at designing a simple routine programmable program for the Interface-A on the VIC-20. Perhaps a LEGO Lines type port in time?? But that might be outside my coding skills.

What cards??? This was just made by PCBWay based directly on a design by David M back in 2019 and posted on the Applefritter forum. Perhaps he followed the tracing of such? If so I find it odd no one else used, noticed and commented about this issue (in his layout) since. But then it is a niche but loyal market I have messaged him already about issue and fix. Oh well... Now I know and the fix (for mine at least) is a simple bodge, no need to mod a cable that must follow those cards around forever.. Unfortunately, all too ridiculously pricey for what they are. I am in about $60 CAD for two, and three more boards that I might source out VIAs for... In case I want to follow in your footsteps and use ALL the interface-A's However, I think you are the king there

Earlier I had tested with LEGO original and standard ribbon cables. But as you should be able to see in 2nd photo, it is only the 8 data wires that needed to be flipped along the long axis to "fix" it, so issue resides on the PCB, somehow. One would have to compare the traces with an original card to confirm.

I used the original cable (70412) that came with my newest Interface-A (not the one pictured, as I was swapping them around to test), and had considered that it was flipped or backwards... But by its design that would have probably put all grounds to the data pins, and put the 5v and GND on totally wrong pins. However, I was right in my observation... Somehow this PCB is reversing JUST the 8 data lines. I took some dupont wires for 5V & GND and Ports 0-7, but I reverse the port wires on the interface (Pin 6 on the PCB to Pin 20 on the Int-A... Pin 20 on the PCB to Pin 6 on the Int-A... and so on). Works as it should now!! Go fig!?! Now I can either mod a specific cable for Apple use only... Or (more likely) cut 8 traces and bodge 8 wires on the PCB to reverse the 6522 PBx lines to the appropriate ribbon cable connector pins. What a bother But now I know I can successfully run an Interface-A (or two) on my APCO Apple IIe clone

Hmm... looking at it I was starting to see the pattern... What the interface should be seeing: IN OUT 7 6 5 4 3 2 1 What it seems to be seeing: with the Inputs always TRUE and Ports 1 & 2 always HIGH IN OUT 1 2 3 4 5 6 7 Somehow the card is sending inverted bits to the interface!! But so far I can't see how... I have been tracing the lines and ribbon cable and everything seems correct, granted all I have is the schematic this PCB is modeled on.

Yes, both are SY6522A from the larger of those two IO cards I had. But I also swapped in a MOS-6522 from a VIC-20 and it is the same. So either these older VIAs dont work quite the way the "newer" support ICs (and possibly the schematic wiring) are expecting?? I can find a W65C22N6TPG-14 on Mouser (seems to be the closest "newer" VIA to the one listed on the schematic)... But at about $50 CAD, I am not planning on getting one, on just a wim.

I suspect LEGO TC Logo does that (and I did set it for the correct slot I am using #2), as it will control four of the ports (2, 3, 4 , 5) if I use their "opposite" numbers. Eg: #5 for port 2. Same results with BASIC. I can POKE the values 4, 8, 16, 32 to toggle port 5, 4, 3, 2 respectively.

Well, I pivoted... I (belatedly) realised that the person (David Mutimer) who had made the schematic I was referencing, had also designed a PCB... Doh... https://drive.google.com/open?id=1hLzV6ZpXksdaTLoTwjweyCBjj207bmnd A whopping $6 CAD later and I had 5 of them (in glorious red) from PCBWay. And the chips to make two... And so I did. So, I am testing with LEGO TS LOGO and oddly, they both have the same issue: Ports 0 & 1 are always ON, which is no good. And ports 2, 3, 4 ,5 work as expected, but are referenced backwards as 5, 4, 3, 2. And it seems both inputs register as TRUE, all the time, although they indicate properly on the Interface. Well mostly... there is odd interactions when using both, but only when plugged into the card. So... something is not playing nicely with something else on the cards. I am going over the data sheets of the support chips I picked up from Digikey (SN74LS245N and SN74ALS74AN) vs what the schematic shows. Or, perhaps it is the fact that I am running the older SY6522A vs the schematic indicated newer WD65C22 ??? Cheap, YES. Simply works? Not so much Joys of old parts I guess.

Nope*... Control Lab (which I believe was only part of the DACTA educational system) was out about 2-3 years before the RCX came out (for retail sale) with its own dedicated control system (RIS). * Not Natively... But almost anything is possible with 3rd party interfacing (Arduino, etc.) for simple remote control. I was able to control a 12v train from the Interface-B, via Control lab... By timed motorization of a 9v polarity reversing switch wired to the 12v system (Worked well, but things could get a little warm and melty if the train stalled or derailed just right to allow current to build up in that wee switch).

Honestly, I have no idea if the Interface-B used anything more than 5V TTL level serial??

The Interface will automatically start listening for the "###Do you byte..." transmission, and if that connection is successful it spits out the "Just a bit..." and a stream of port data. However this will stop after about two seconds if it doesn't get back a regular "keep awake" signal. Thus I used a TTL-USB and terminal program, set on repeat, to send out the "###Do you byte..." and then started probing to see if this date got to the CPU, and if it did, start probing to see how far did the response make it out. Now, if your scope can translate Serial signal to text, as some have the option to do, then you can easily see if the probed data is clear or corrupted along the way as you go. For myself, my scope doesn't support that, so I just used the same TTL-USB "receiving" line to do my probing analysis.

Sorry if getting off track... Although I do believe that using a "newer" hardware, running various software that can fully read and control the Interface-B is what I currently have going... To supply a summary of MQTT (as that is all I understand anyhow) is that it is a communications protocol that Publishes (sends) and Subscribes (receives) messages to and from multiple diverse devices. The MQTT Broker program acts as a central distribution hub for this process. In my case I have an ESP32 running Bliss's MQTT program for the Interface-B. This program Pubishes (sends) out Input port data and Subscribes (receives) values for the Output ports. I use this process via my "control flow" on Node-Red (which is independently doing other stuff as well). My MQTT Broker and Node-Red run on a Raspberry Pi... Thus I am using two different "modern" hardware devices and a few "modern" programming languages (Python and JavaScript) to orchestrate the Interface-B action. Personally, I am trying to do both... Control the Interface-B with anything other than Control lab on a full PC, and the RCX as a remotely controlled device under the same centralized oversight. Thus, while I have not yet integrated such, I would like to expand my existing process to also interact with RCX. Although I would probably prefer to use another ESP32, communicating to Node-Red via MQTT to control either a LEGO IR Tower (or just an IR transceiver) to send/receive RCX compatible codes. Thus a button press on an Interface-B can activate an action on one or more RCX bricks, and vice versa.

Same. Mine is a RPi3b+ that runs my MQTT broker and Node-Red service. I run it solely internal and "headless", as in no KB/display but still running the desktop with local VNC access. Node-Red can read and control all the inputs/outputs on the MQTT connected Interface-B, and handles the "logic" of what to do and when.

BTW, I can't recall if I did it on purpose, but I tapped the Serial GND from somewhere in the upper left corner of the board... See my picture showing that location, in a prior post. Also... It appears you still have the original serial circuit connected? I believe I cut mine out or the loop completely, to avoid and possible feedback/crosstalk/insert tecnobable here.