Netgear SSO? That's a hard no. pfSense to the rescue!

 Some time ago... a couple years, now... my trusty old cheap Netgear router breathed its last, and I bought a new one.  The new one had this pain in the ass "Single Sign On" thing that made you set up an account with Netgear in order to log in to the router.  Hard pass on that.  It's possible to log-in locally, but it's extra steps that piss me off.  I've been ruminating on switching to pfSense for my routing/firewall needs, and just getting one or more cheap Wireless Access Points to handle the WiFi.  I have enough hardware just lying around that I could have done pfSense on a dedicated x86 machine, but the power, space, and noise were things I was not crazy about dealing with.  I'd thought about installing it on a VM on my Threadripper VM Host, but the networking would be a problem without additional hardware.  I finally got a 4x1G ethernet card for my VM Host, and stood up and pfSense VM.  

The config process was not bad, per se, but it was a little opaque in spots.  I have a separate Raspberry Pi running dnsmasq, handling local DNS, DHCP, and DNS forwarding, whereas nearly all of these modern router appliances have built-in, and a pretty enthusiastic about acting as your DHCP and DNS server.  Chalk it up to paranoia, if you like, but I prefer the "component stereo" model here, if for nothing else, it allows be to keep at least some of my more complex config stuff up and running if something like a router quits.  Getting DNS forwarding through pfSense was a little bit confusing at first, but I got it worked out.

Port forwarding turned out to be easy once I figured out that refreshing DHCP leases had to be done on target boxes for return traffic to go back through the router.  I'm smart.

OpenVPN server setup on pfSense has not brought me joy, yet, but it could, still.  I remain hopeful.  Part of the problem, I think, is that my network is on another RFC-1918 network -- that is, I need to traverse another "local" network to get to the Internet.

I ran into a couple hiccups when I tried to get one of the WAPs I bought working.  They're TP-Link AC1200 (TL-WA1201) devices, and they were cheap.  I bought 3, because why not.  The "quick setup" didn't seem to stick, entirely... so I had to kind of work through "not quick setup", and it seemed to take a few tries at that, with resets in between for it to really come up and do its job.  So far, an hour into its service life, the first TP-Link TL-WA1201 seems to be doing the right things.

So, now, my private network is fronted by a VM running pfSense through a dedicated 4x1GB ethernet card, and WiFi is running of a TP-Link WAP, and with any luck, I'll never have to deal with Netgear's stupid SSO nonsense again.

The next bit of excitement for the home network is a 48-port switch.  I know, how can I possibly justify a 48-port switch?!  Well... I'm not going to pretend that I have 48 wired Ethernet machines up and running all the time, but I do have 6 machines in my rack, and 20 or so machines strewn about, and I have little "desktop switches" all over the place... I'm hoping to get away from that.  Of course, that will mean doing more home-runs, but I'm hoping it will make for less confusing networking.

The RIBBBITN3RDing BitPump

The RIBBBITN3RDing BitPump

The RIBBBITN3RDing BitPump r0.1

A little bit of background 

I've been trying quite a few new things with my RIBBBIT65 designs, and I'm running into issues which aren't making a lot of sense.  I've also been having some trouble isolating issues (e.g. "known good" components or circuits don't work *here*... and it turns out "known good" wasn't)  I wanted to have a way that I could repeatably, and quickly, put a bunch of R65 Bus signal configurations ... snapshots, if you will... on the bus to confirm the thing is behaving the way I expect.  Rather than coding something up in 6502 Assembly for every different testing scenario - and, in the process, intoroducing the possibilty that the CORE board I'm using has a problem, I thought it would be better to do something like my TTL Busy Boxes, but on steroids.  The Busy Boxes are just boards with switches and/ or lights that let you do some multiple of 8 worth of switching and/or indicating.  The first one I designed has an 8-position DIP switch, 8 mini-tac switches, and a 10-segment LED bar graph.  That's great for, say, the data bus.  There's still the address bus (16 bits) and all the control signals.  Well, controlling 32 (or more) signals via DIP switches and/or Mini-Tac switches through 20 or 30 cycles (to test an ACIA or a VIA) just seemed like a nightmare.  ...if only there was a way to repeatably send out pre-defined bit patterns over regular time intervals...

The BitPump

The RIBBBITN3RDing BitPump is intended to be an easily reconfigurable digital signal generator which can provide the bit patterns necessary for in-circuit testing of subsystems which interface with 8-bit microcomputers.  

The BitPump, configured for use with the RIBBBIT65 provides:

• an 8-bit bidirectional Data Bus
• a 16-bit output-only Address Bus
• 4 jumpered CPU Control signals (VPB, RWB, MLB, SYNC)
• Jumpered Pull-ups for 5 CPU Control Inputs (SOB,RDY,BE,NMIB,IRWB,RSTB)
• 8 bits of completely manual switching, both latching and momentary on each bit, with indicator LEDs
• 1 "bus clock" driven by a separate IO pin from the bit pattern

The BitPump uses a RaspberryPi Pico (or simlar) to drive a set of four serial-to-parallel shift registers.  

The lower 8 bits (which in the original configuration are wired to the data bus) are bidirectional, and the data direction is controlled by the same "control bit" which drives the R65's RWB (Read, Not-Write) line.  In "Read" mode, the data lines from the bus are displayed on the LEDs.

Since the BitPump is driven by a RaspberryPi Pico (or equivalent), the user has the ability to easily re-program the device to send whatever bit patterns are desired at whatever speed is desired (within the confines of 74HCTXX switching speeds and the capabilities of the sytem under test).

Uses of the BitPump

I'm planning to use the BitPump to see what's going on with my Mini-ITX design.  There's definitely something rotten in Denmark.... hopefully I'll be able to use the BitPump's lower speed, and "known good" bit patterns to isolate the problem(s).  Similar story on the "CORE Daugher Support" board, which is basically supposed to provide a serial console, IO selects, pull-ups and a few other things to the CORE Daughter board I designed for the ITX MoBo, to just make it minimally interactive and runnable.  I plan to troubleshoot both these boards using bit pattern sets delivered by the BitPump.

After that , I plan to use the BitPump to test out different ways of running the 40x4 character LCDs I have.

I can also use it for direct testing of IO and memory chips, since the "data bus" is bidirectional.

What can you use it for?  I dunno.  You could build one and try it out.

Possible updates to the BitPump

One thing I think might be nice is a knob to control the "clock speed".  This could be done easily with a pot and one of the PWM inputs on the Pico.

Another thing that might be nice is a manually controlled "RUN/STOP/STEP" thing that could be done with a couple digital inputs on the Pico.

Do you have any ideas?