Gunners TekZone
-
Posts
178 -
Joined
Content Type
Profiles
Forums
Gallery
Everything posted by Gunners TekZone
-
Ah, sorry, I had missed that (and probably many other) details during my groggy reading stages -
Yes, I understood they can blindly all work the same. But was wondering if they could be (eventually if not already) recognised and controlled individually in Blocky... Hence my roundabout query to @Bliss However, I don't think he is able to look into this with only one RCX in his possession... So I will not worry about it myself... I am just testing for the moment as I do not have a "real world" case to use this at the moment. Alas... Too many other projects on back burners. And anyhow, making a nicely complex setup is beyond my mental/physical focus For now.
-
Yes. AFAIK this was normal operation with other programs (it is with the IR Remote Control). @BlissI did attempt to try a IF X OR Y input routine, to see if the RCX inputs act the same... But the RCX input block (or at least what looks like the closest match) will NOT connect??
-
Once I removed the RCX1 Alive? constraints, then YES multiple RCX bricks DO work (So far three of them, 2x 1.0 and 1x 2.0, all working as one)... At least as for testing outputs only (I haven't tested inputs yet, but probably the same). As for gain, well perhaps when needing to do many of the same thing. Eg. multiple track switching, lighting, etc or other motorized applications where one brick is not close enough (and without resorting to long leeds), or doesn't have enough needed outputs? Or a form of simple choreographed dance with multiple little yellow wheeled "bugs" on the floor I duno... I just like options (Granted, the IR tower range and angle becomes the limitation)
-
I have been keeping my testing simple lately... As I was making other things, and needed to recoup from that energy expenditure. So this time I am sticking with a single Int-A and an RCX Serial tower. Here are some observations... - No "Save As" option. I must remember to change the name of my saved program after the fact. - A saved program doesn't retain and reconnect device connections... This one had me doing a bunch of troubleshooting before realising that all the device allocations in my test program were listed "No RCX" and "No Lego B", thus requiring the manual reconnection and assignment of all devices in the program. Or doing such device connection (presumably in correct order?) prior to reloading a saved program. - On a wim, I tried having two RCX's online at the same time... Half expecting them to just be recognised as a single unit (for simple in-coming commands at least). But as soon as I turn the 2nd one on, the program stops running, and will not restart without turning off (any one) of the "extra" RCX bricks. Now, I was using the "While Rcx1 alive?" loop, so that might be a factor? I am guessing that in order to have multiple RCX bricks running, one needs a dedicated IR tower for each? It has been a long time since I messed with these little yellow bricks, but I thought these had some form of internal ID and could run multiples on a single tower?
-
No. But the proof of such is in the 'pudding' (AKA my 8 pin inverted swap worked ) Again, it was ONLY the eight pins 6, 8, 10, 12, 14, 18 & 20. on that connector that were "wired" as incorrectly inverted, TOP to BOTTOM in relation to the 6522's PB0-PB8. Flipping the whole connector Horz or Vert would NOT have fixed anything, but also messed up the 5v pin positions. Consider that on the "faulty" schematic, the order of a single pin from the Apple slot, through the 74LS245 to the 6522, and then to the ribbon connector is a set of flip-flopping (HIGH/LOW) pin designation inversions... Probably to keep IC placement and trace runs clean. The address for the Int-A Output Port 0: D1(Apple) to B7/A7 (74LS245) to D0/PB0 (6522) to Pin 20 (Input 7 on Ribbon connector). (the Red/Green colours represent the Input/Output Int-A LEDs) This last step shouldn't have been inverted, but the author might have just gone with the flip-flop flow. The correct last step is D0/PB0 (6522) to Pin 6 (Output 0 on Ribbon connector)... And so on for the remaining pins. I didn't realise it at the time (groggy eyes get crossed ) but there is another schematic, that is also on Evans website, that shows this correct layout. And hey, if someone posts a PCB layout back in 2019 and NO ONE seemed to notice and/or make a clear indication of it being in error (at least not on the forum I found it on)... Then how was I to know? This is me trying to make that PSA for others
-
No apologies required. Solving (or re-solving) issues is a great way to learn, and I am finding it more beneficial to my clarity of thought then I would have suspected. The PCB was simply laid out wrong in this one area of the header, as every other pin is correct in all orientations. Here is my "corrected" version of the "problematic" schematic that I think the Reboot PCB was modeled after... I hope I got it right Unfortunately, I am not well-versed (or even poorly -versed) in the art of CAD/PCB design and layout, so I can't make a corrected PCB (maybe one day... Look out $$$ Blocky). Meanwhile, now I have two cards active, one for the "Apple IIe's" Interface-A and the other to mess around with alternate interface programming. Here I have the 2nd one with all 8 ports set to output (using 3mm LEDs with built-in resistors, just jammed into the ribbon cable for expediency ) So as to display the 8-bit binary output of an input number. Super simple stuff, but great to confirm code and pin orientation. And makes a good Larson Scanner I also realised there is nothing preventing these two cards from controlling a totally customised LEGO interface with any combination of inputs and outputs. It is just opto-isolators and H-bridges. Requiring custom code of course. But think about it, one 16 port 4.5v compatible (or even 12v for trains!!) LEGOlike Interface-DIY (Patent Pending ) perhaps with 6 inputs and running 5 motors, etc... Options!
-
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).
-
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 (With Floppy Drive, and a green phosphor monitor that needs a new case) - 2X "bodged to work" LEGO 9767 (reboot) cards. - And a 2nd Interface-A (boxed with OG cable and PSU). But all together, I still purchased all three for about the same $$$ as a single Blocko card!
-
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.
-
That would be my recommendation as well... I had noted poor signal via those wires in my tests, even though they looked fine. Even the cheap dupont wires are better than those oldy moldy ribbon cables.
-
You can go a step further and put in an ESP32 in lew of the TTL-USB... Now you have a standalone WiFi capable Interface-B that is controlled via MicroPython. https://www.eurobricks.com/forum/forums/topic/200778-project-programs-to-allow-interactions-between-old-lego-control-interfaces-rcx-lego-interface-b-others/ I have one of mine somewhat like that, only externally connected via it's normal (working) Serial interface. This one acts like an MQTT client to switch a household lamp. One of my many ideas is to (eventually) embed it into the Interface-B that currently has the TTL-USB. Then with a small switch wired to a GPIO and some additional coding, make it act as a switchable WiFi capable device running MicroPython code, or just as a simple USB Serial device for use with the usual Control Lab etc.
-
Ha, yes... that's why I tapped into the corner area. 5v should be fine, but I did switch my TTL-USB to 3.3v just in-case the CPU couldn't handle the 5v long term. I also replaced ALL the ribbon cable (the remaining wires were just power and GND) to make it even more flexible to assemble. Hot glue looks messy, but it holds and can easily be removed with some IPA if needed.