This is part of a multipart series where we’ll be modifying a homebuilt 6502 processor computer in strange and creative ways.

In this part of the series we’ll be building a circuit to demodulate (or decode) Kansas City Standard audio and load that onto our 6502 computer.

Kansas City Standard or BYTE Standard, was a standard developed by BYTE magazine back in in the late 70’s. It was used to store computer data on standard, low-cost, audio cassette tapes. It was designed to allow common people to be able store data at home as there weren’t many options to do so back around that time. There were even radio shows where they would broadcast out Kansas City Standard formatted audio and nerds like you and I would tune in to, listen to the broadcast and record the last part of the show to “download” a new computer program!

At the conclusion of this KCS build, we’ll be able to load our Ben Eater 6502 from tape!

Part 1:
We’ll go through the history of the Kansas City Standard, some deep level details, and then an overview/theory of how the circuit works. At the end of this video, we’ll have a demodulated UART stream ready to feed into the logic part of the circuit.

We’ll also be introduced to Mr. Monostable, a refined gentleman with a short temper.

DROP A COMMENT if you’re interested in a kit to perform this build yourself. I’ll put one together if there’s enough community interest.

Part 2:

In this video we latching (or holdon to) the data coming in and we FINALLY get to see some Kansas City Standard data being decoded!

Part 3:

In this video we take the next step in our project and can finally load data from the KCS circuit! We do this by adding an additional W65C22, adding some hardware to handle more interrupts, and update some code.

I’ve published the code for these videos on my GitHub.

…he’s watching.

I recently upgraded my home Internet from Spectrum Ultra (500/20) to TDS Fiber Gigabit (1000/1000). However, when running speed tests on the new circuit I noticed that I was consistently getting speeds SLOWER than my Spectrum Circuit. I was getting around 250-300mbps.

This ended up being a configuration issue with my Ubiquiti EdgeRouter PRO-8, which is definitely capable of delivering gigabit speeds!

The very first things I checked, were to ensure I was running the latest code (v2.0.9-hotfix.5 at this time) and that hardware offloading was ENABLED:

$ configure
#set system offload hwnat disable
#set system offload ipsec enable
#set system offload ipv4 bonding enable
#set system offload ipv4 disable-flow-flushing-upon-fib-changes
#set system offload ipv4 forwarding enable
#set system offload ipv4 gre enable
#set system offload ipv4 pppoe enable
#set system offload ipv4 table-size 65536
#set system offload ipv4 vlan enable
#set system offload ipv6 bonding enable
#set system offload ipv6 forwarding enable
#set system offload ipv6 pppoe disable
#set system offload ipv6 table-size 65536
#set system offload ipv6 vlan enable
#commit

I was still seeing the issue, still had slow speeds. But, I also noticed in the GUI that when I was running my speed tests the CPU was maxing out at 100%. I jumped down to the CLI and ran “top”, to see what was pegging the CPU.

The ksoftirqd process was pegging the CPU on the EdgeRouter. This lead me to this post, which reminded me that I had played with Netflow a few years back.

$ $ configure
[edit]
# delete system flow-accounting
[edit]
# commit
[ system flow-accounting ]
Removing flow-accounting NFLOG for [eth7][ingress][post-dnat]
Removing flow-accounting NFLOG for [eth7][egress]
Stopping flow-accounting daemon [ingress]
Stopping flow-accounting daemon [egress]

[edit]
$ configure
[edit]
# save
Saving configuration to '/config/config.boot'...
Done
[edit]
# exit

After disabling flow accounting, this fixed it and I was getting really close to my Gigabit speeds!

Here are a couple ways I’ve come up with to reboot CradlePoint devices remotely. These were all tested on MBR1400 routers using v6.0.2 firmware. If you have proper HTTPS certificates installed for the web interface you can drop the ‘–no-check-certificate’ or the ‘–insecure’ options on the WGET and CURL commands. Also note that the CURL and WGET commands are using the password in the command. This can be insecure for many reasons.

Of course, you could always use the web interface too.

Using SSH:

ssh [user]@[ip address] 'reboot'

Using WGET:

wget --no-check-certificate https://[ip address]/api/control/system/reboot --http-user=[user] --http-password=[password] --post-data 'data=%221%22'

Using CURL:

curl --insecure https://[ip address]/api/control/system/reboot --anyauth --user [user]:[password] --data "data=%221%22"

Custom HTML using POST:
You can throw this code into a custom website, if you really feel the need.

<form action="https://[ip address]/api/control/system/reboot" method="post">
     <button type=submit name="data" value="1">Reboot CradlePoint</button>
</form>

Using SMS:
You can also use SMS to send a text message to the CradlePoint router instructing it to reboot. Unless you’ve changed the SMS password, the SMS password is the last eight characters of the MAC address. It’s specifically an SMS password (so it’s not tied to any user account).

The format of the text message:

[password],reboot<br />

You’ll receive a text back from the device:

Sometimes you may have a SID (objectSid) for an Active Directory object but not necessarily know which object it belongs to. You can find the object using PowerShell.

I’ve been thinking about building a plugin for MPD that would allow it to talk with Google Music for a while now. Currently, when I purchase music from Google Music, I have to download it and push the new music up to my local music share on my network. Once my music is there, MPD can stream it without a problem… I love MPD!