After an extended period of crippling downtime, the BosaikNet forums have been restored to their state from December 2016. Unfortunately, no content has been lost. BosaikNet switched servers towards the beginning of 2017 and the database migration did NOT go smoothly; I figured out what went wrong and, in tandem with @Crawdad , fixed it. It now runs on phpBB 3.2. There may be some link rot that hasn't been fixed, but post there if there's any problems and they'll probably get ignored for a week before getting fixed.

if this is miscategorized, pls fix

I still don't know what to call this.


It'll be some kind of information terminal accessible over 70cm amateur radio, using both text-to-speech and speech-to-text. So far, I have code to get the current weather conditions written for it, well before I finished any of the backend components. It's designed for Orange Pi One (it's cheap \o/), but can work on normal RasPi or even Windows! Once I can tell that code is at least marginally functional, it'll be open-source on my github page. I also need to make sure that the Orange Pi One can do what I need it to with its limited USB, since I need both a sound card and wireless networking.

I want this project to be:

• flexible - work on many different platforms and radios,
  
• extensible - allow users to add functionality,
  
• simple - use as few hacks as possible,
  
• inexpensive - entire build under $55, and
  
• legal - when operating on the air, reading all that FCC legalese is necessary.

STATUS:

• Audio Flow: 12%
  
• GPIO: 75%
  
• Radio Control: 0%
  
• Power Monitoring: 0%
  
• Voice Input: 0%
  
• Voice Output: 50%
  
• Weather: 100%
  
• Date and Time: 0%

Because I like RS232, I'm writing a Python library for RS232 communication with Uniden DMA scanners (BR330T, BC346T/XT, BCD396XT). Being 5 lines long in an early stage of development, I don't have a whole lot to say about it, but in the end it should allow complete programming and monitoring of the scanner via serial, and maybe even include a simple bridge for TCP/IP relaying. It'll be more of a SDK with a demo included once it's done.

This will be a progress thread as I figure out an increasing number of silly things I can do with this level of automation.

In pursuit of bettering what is already TI's greatest invention since the integrated circuit, I'm writing a new ti82.inc based on TI's ti83asm.inc and BrandonW's ti83.inc, targeting the SNG shell. SNG only has 30 ROM calls documented in its standard include file sng10.inc, and was the most complete one until now. So far, I have identified 138 ROM calls, using a Python script that follows call tables to compare the code of the routines mentioned in ti83.inc to the call table at the end of the TI-82's ROM page 0. It does not find calls that are on page 0; I need to do this manually, so those will take longer to identify.

RAM equates were fairly straightforward, except for the StatVars saferam area. Because the statistics implementation for the TI-82 is not nearly as advanced as the TI-83's, there will be significantly less saferam available there (279 bytes at most, compared to 531). Finding IY flag equivalents should not be terribly hard if I can find ROM calls common to both models that use a particular flag.

The latest version of the include file can be found here. Addresses here are for ROMs 15.0 and 16.0.

There are some necessary changes to ROM_CALL() that need to be made to support all of these calls. With the TI-83, TI introduced indirect calling, allowing the user to access some lesser-used functions outside of page 0. However, as user assembly wasn't implemented in the TI-82, there is no directly way to access these calls from page 0. Instead, you have to ROM_CALL(___bank_call) \ .dw addr \ .db page. You'll notice that this requires looking ahead three bytes, and ___bank_call (in ROM 16.0, at $2E46) does this by looking at the stack. This isn't compatible with the existing ROM_CALL() routines. For reasons of efficiency I will probably use a separate BANK_CALL() macro for this. Furthermore, to achieve compatibility with ROMs before 15.0, the ROM_CALL() routine needs to be updated with the new values for each of those ROM versions and take account for the missing values in the call table. Since all of this will happen within the shell, this is less important.

PROGRESS:

• ☑ Find names for page 0 call table functions
• ☑ Find TI-82 calls not on TI-83 page $0C
• ☑ Find RAM equates*
• ☐ Find IY flag equates
• ☐ Add in key code equates
• ☐ Test the ROM calls, RAM equates (I need people to test the uncertain ROM calls)
• ☐ Find address corrections for ROMs before 15.0

*RAM equates may be of different size

I'm not responsible for any RAM clears or property damage (probably through user rage) that results from using this experimental include file.

Find a line or two that just works better without any context? Put it here!

Quote from: #codewalrus[06:44] <jacob> mine is like 15cm I think

Introduction
A while back I acquired a TI-81 showing ribbon cable failure between the LCD board and the mainboard. I thought I had fixed it, but recently it started failing again. After popping it open, I found that two more connections on the cable have failed and needed replacement. I soldered some 30 gauge wrapping wire across the ribbon cable in the failed locations, and functionality is restored. I'll explain how I did this in this topic.
   
The leftmost picture shows the broken test pattern;  the center picture shows the post-repair ribbon cable;  the rightmost picture shows the correct test pattern.

Symptoms
The specific symptoms vary from calculator to calculator. On all of them, contrast can be erratic, or the calculator may not turn on. TI-81 in light blue housing, TI-85, and TI-86 manifest cable failure in garbled and/or misplaced text. TI-81 in dark blue housing, TI-82, and TI-83 series will also show garbled and/or

text, but can also show

, have an entirely black screen, or enter LCD test mode (a blue or purple line on the screen).

will also show the erroneous display. The dark blue TI-81 also frequently shows

, not to be mistaken with failure of the LCD <--> display driver cable; pixels in the affected region should be connected but not [properly] addressed, appearing slightly darker than the LCD's border areas.

Failure in the light blue TI-81, TI-85, and TI-86 is uncommon for some reason. In cases where the calculator does not turn on, the ribbon cable should be tested.

Repair Preparation
On a clean and generally dust-free desk, disassemble the calculator, removing the PCBs from the housing. With a multimeter, check the resistance across the ribbon cable at the PCB pads or the row of test points above the LCD board connection. Resistances above 20 ohms are potentially failing, and anything over 35 ohms should be repaired. Note that on older port-mapped models (TI-81 dark blue, TI-82), the fourth pin from the left is not connected.

Repair
When doing a full repair of a ribbon cable (recommended if several connections are failing), peel the clear tape on the front of the PCB off both the LCD board and mainboard, then flip the calculator back to the side with ICs and peel the ribbon cable off. When doing a partial repair, use a razor blade to cut notches into the ribbon cable on both sides of the high-resistance connections, then peel/push back the plastic film of the ribbon cable to expose the pad on the PCB. Be careful not to take out any innocent bystanders. Repeat for the other side of the ribbon cable, then check the resistances of the low-resistance cable connections again now that the high-resistance connections' pads are exposed. Repeat as necessary.

Now that the affected cable connections' pads are exposed, apply a little flux to them and tin them with a soldering iron. Take about 3cm of 28 gauge or smaller wire (the length should be a bit longer than the ribbon cable, strip and tin both ends, and put

into it so it lies flat against both PCBs. Solder the wire to the corresponding pads, being sure to solder to the correct pad and not create any solder bridges. Repeat until all necessary connections have been made.

Post-Repair
Clean up the area you soldered; loose solder can bridge connections that shouldn't be bridged, and leftover flux can corrode contacts and traces. Check the resistances with a multimeter again to make sure all connections are solid and any existing ones have not been damaged. Wipe any debris off of the front of the LCD and inside of the LCD cover, if present (this region scratches VERY easily!), and reassemble the calculator. Be careful to not bend the wires too much, as they may break. Run self-test to make sure the calculator is functioning, and the calculator has been successfully repaired!

Connect to: mc.bosaik.net

BosaikCraft is a Spigot-based Minecraft server recently started by Bosaik, Crawdad (he's in IRC), and myself, whose parent community is a CodeWalrus affiliate; featuring Towny, PvPManager, BetterShops, and ChairsReloaded, BosaikCraft provides a plugin-augmented vanilla experience with a focus on building and community. The server is still new, so minor problems are to be expected and will be corrected by administration as soon as possible after an issue is reported.

The Coruscant-themed spawn took over six months of dedicated efforts by about 10 players to construct, so spawn alone has numerous activities and shops.

We are on IRC on EFnet at #bosaikcraft. Minecraft chat/join/part is linked to IRC with the CraftIRC plugin.

Speaking on behalf of BosaikNet, we welcome CodeWalrus Minecrafters to BosaikCraft! Thoughts, opinions, etc. can go here but server issues and suggestions should be posted at BosaikNet Forums to reduce community fragmentation. Happy crafting!

I took some highly detailed PCB pictures of the Pasco PS-2002 Xplorer GLX. Pasco hasn't really published anything about its hardware so I do not have much to go off of (unlike Vernier, Pasco doesn't talk much about their hardware). I've worked out the following info:

• The CPU is clocked at 50 MHz. I don't even know which IC the CPU is, and I don't know what type of CPU it has; Pasco calls it a "floating point CPU." I hope it isn't in the FPGA.
  
• There's a FPGA in there, and it makes the most heat. It's an Altera Cyclone EP1C12F256C8N.
  
• 8 MB FlashROM
  
• There's a bunch of RAM chips. One of them is a 32 KB SRAM, and somewhere the system has a 16-ish MB RAM chip (11 MB available to the user). It could be the BGA IC below the FPGA, I haven't worked out its identity.
  
• The system uses six NiCad/NiMH batteries in series to receive 7.2V. The system expects those batteries to be present, as there are numerous warnings to not connect the system to power without batteries installed.
  
• There's a TI MSP430F147 in there, I think it is used to decode PasPORT data but I'm not sure. It has its own 512KB FlashROM.
  
• The LCD is not made by Pasco. It uses a Powertip PG320240H-P2 LCD module glued to the front housing.
  
• A TI AIC28I handles audio I/O. The GLX has a microphone, speaker, and speaker-out port.

I also wrote down the names of the ICs on the LCD and keyboard-audio PCBs:

LCD board:
IC1         Row driver: Sitronix ST8024F4 AOG659.1W8B1187703
IC2/IC3 Column drivers: Sitronix ST8016F3 AOM275.1 AS9500Q
IC4          EL Driver: ZSP4\403L [ZSP4403]

555-0894O-D Keyboard/Audio board:
U1            Microcontroller: (TI)96A2PKT G4\M430F147\REV N [TI MSP430F147]
U2            Serial FlashROM: 25P40VP
U3                           : BY42
U4           Audio Controller: AIC28I\TI 96W\Z13N G4
U5/U6                  Op-amp: BB OPA\2340UA\96JQD
U7                           : Not present
U8          Voltage Converter: [National Semiconductor logo]CHAB\LMC76\96JQD [LMC7660]
U9                           : PDP
U10                          : R2B
U11 Instrumentation Amplifier: AD623A\[Analog Devices logo]#0926\1654476


Should anyone be bored enough to try and reverse-engineer or hack this device, the above information should be helpful.

So far I have found three bugs in the TI-OS for the TI-82.

PlotN( Bug

Affected versions: 3., 8.0, 9.0. Believed to be present on all versions whose version number does not end in an asterisk (4*, 7*, etc.)
Setting up a stats plot through the Plot1/Plot2/Plot3( functions results in the mark always being the square mark, regardless of what was specified.

Menu:getKey Bug

Affected versions: all versions up to and including 17.0.
getKey called after a Menu( results in getKey catching the ENTER keypress from the menu item selection. To fix this in programs, call getKey before you start a getKey loop.

Shade( Bug

Affected versions: 15.0, 16.0, 17.0, 18.0; altered behavior on pre-15.0 versions
I didn't discover this bug, it has been known since 1996. Execute the command Shade(1,2,6 with no closing parenthesis and a dirty graphscreen. While the calculator redraws the graph, ON-break it. A number will appear in tiny font at the top of the screen. Type something in, press ENTER, and the calculator will crash dramatically.
On pre-15.0 versions, the calculator will not crash. Instead, the graph screen will be drawn over the home screen and the calculator will work normally.

If you find any more, post them here and I'll add it to the list.