NABU Weather and News Version 0.1

[Super_Derek]

Hello All,

I propose a NABU application designed to provide current news, weather updates, and maybe more for the user. Notably, while existing applications within the NABU network appear to be primarily static, focusing on preservation, the objective is to make NABU a more dynamic everyday utility terminal. This terminal would be free from the extensive advertisements and complex graphics typical of contemporary internet browsers.

My professional background is in IT, RF, electronics, and SATCOM, with intro level education in Assembly and C++ many moons ago, but not in BASIC. This experience, combined with my enjoyment of vintage computing, motivates my interest in enhancing the NABU's practical application. Here is a preliminary BASIC program which retrieves weather and news data via an NOAA API or other sources. This program is designed to be manageable by the NABU server and accessible to NABU personal computers. The success of this program is reliant upon my understanding of the capabilities of the NABU Server, thin client systems, and the extent of emulation.

Below is the draft of the BASIC program:

NABU Weather and News Version 0.1

10 PRINT "NABU Weather and News V0.1"
20 INPUT "Enter your city code: ", CITYCODE$

30 REM Ensure BASIC supports advanced functions
40 IF NOT SUPPORTS_ADVANCED_FUNCTIONS THEN GOSUB 1000

50 GOSUB 500 ' Subroutine for data fetch
60 IF DATA_ERROR THEN GOSUB 1000

70 PRINT "Press 'R' to refresh or any other key to exit."
80 A$ = INKEY$
90 IF A$ = "R" OR A$ = "r" THEN GOTO 50
100 END

500 REM Subroutine to fetch and display data
510 DATA_ERROR = 0
520 PRINT "Fetching data..."
530 ' Code to receive weather and news data from the server
540 ' Assuming a function GET_WEATHER_AND_NEWS exists
550 WEATHER_AND_NEWS = GET_WEATHER_AND_NEWS(CITYCODE$)
560 IF WEATHER_AND_NEWS = "" THEN GOSUB 1000
570 ' Parse the data
580 LET TEMPERATURE$ = LEFT$(WEATHER_AND_NEWS, 5)
590 LET CONDITION$ = MID$(WEATHER_AND_NEWS, 7, 15)
600 LET WIND_SPEED$ = RIGHT$(WEATHER_AND_NEWS, 5)

610 ' Display weather data
620 PRINT "Current Weather:"
630 PRINT "Temperature: "; TEMPERATURE$; "°C"
640 PRINT "Condition: "; CONDITION$
650 PRINT "Wind Speed: "; WIND_SPEED$; " km/h"
660 ' Display weather condition graphically
670 PRINT "Weather Condition:"
680 IF CONDITION$ = "Sunny" THEN GOSUB 100
690 IF CONDITION$ = "Rainy" THEN GOSUB 110
700 IF CONDITION$ = "Cloudy" THEN GOSUB 120
710 ' Code to receive and display news headlines
720 ' Assuming a function GET_NEWS_HEADLINES exists
730 NEWS_HEADLINES = GET_NEWS_HEADLINES(CITYCODE$)
740 ' Split and display news headlines
750 PRINT "News Headlines:"
760 LET NEWS_LIST$ = SPLIT(NEWS_HEADLINES, ";")
770 FOR I = 1 TO COUNT(NEWS_LIST$)
780 PRINT I; ". "; TRIM$(NEWS_LIST$)
790 NEXT I
800 RETURN

1000 REM Error handling subroutine
1010 PRINT "Error: Invalid input or data not available."
1020 DATA_ERROR = 1
1030 RETURN

100 REM ASCII art for Sunny condition
110 PRINT " .-. .-. "
120 PRINT " ( )( ) "
130 PRINT " '-' '-' "
140 RETURN

110 REM ASCII art for Rainy condition
120 PRINT " .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. "
130 PRINT " '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' "
140 RETURN

Initialization (Lines 10-20):

The program starts by displaying a title, "Weather and News."
It then prompts the user to input their city code.
Checking for Advanced Functions (Lines 30-40):

There's a check to ensure that the BASIC environment supports advanced functions. If it doesn't, the program jumps to the error handling subroutine at line 1000.
Data Fetching (Lines 50-60):

The program calls a subroutine at line 500 to fetch and display data.
If an error occurred during data fetching (as indicated by DATA_ERROR), it again jumps to the error handling subroutine.
User Interaction and Exit (Lines 70-90):

After data fetching, the program displays a message to the user: "Press 'R' to refresh or any other key to exit."
It waits for the user's keypress (A$) to decide whether to refresh the data or exit.
If the user presses 'R' or 'r', it goes back to line 50 to fetch data again; otherwise, it ends the program.
Data Fetching Subroutine (Lines 500-800):

This subroutine begins by initializing DATA_ERROR to 0 to indicate no errors.
It displays a "Fetching data..." message to indicate that it's retrieving data.
Assuming there's a function GET_WEATHER_AND_NEWS, it retrieves weather and news data based on the CITYCODE$ provided by the user.
If no data is received (indicated by an empty WEATHER_AND_NEWS), it jumps to the error handling subroutine at line 1000.
The received data is then parsed into separate variables for temperature, condition, and wind speed.
The weather data, including temperature, condition, and wind speed, is displayed.
Depending on the weather condition, it displays ASCII art graphics for "Sunny," "Rainy," or "Cloudy."
It proceeds to fetch and display news headlines using a similar approach.
News headlines are displayed in a numbered list format.
Error Handling Subroutine (Lines 1000-1030):

In case of an error, this subroutine is invoked.
It displays an error message: "Error: Invalid input or data not available."
It sets DATA_ERROR to 1 to indicate that an error occurred.
ASCII Art Graphics (Lines 100-170):

There are ASCII art representations for different weather conditions: "Sunny," "Rainy," and "Cloudy."
These graphics are displayed based on the weather condition received from the data source.
Please note that this code is a simplified example and assumes the existence of functions like GET_WEATHER_AND_NEWS and GET_NEWS_HEADLINES to retrieve data. Additionally, it utilizes a modern BASIC-like environment, and adjustments may be needed for vintage systems depending on their specific capabilities and libraries available.

120 REM ASCII art for Cloudy condition
130 PRINT " "
140 PRINT " .-~~~-.-~~~-. "
150 PRINT " (-. _ .-. _ .-) "
160 PRINT " ' - ' ' - ' ' "
170 RETURN


User GUI example:

----------------------------------------------
| NABU Weather and News V0.1 |
---------------------------------------------

Enter your city code: [User inputs city code]

Fetching data...
Current Weather:
Temperature: 25°C
Condition: Sunny
Wind Speed: 15 km/h

.-. .-.
( )( )
'-' '-'

Weather Condition:
[ASCII art representation of sunny weather]

News Headlines:
1. City Library to Host Author Meetup
2. New Bike Trails Open in East Park
3. Local Chef Wins Culinary Award
4. Upcoming Concert Series Announced
5. Science Fair Winners to be Showcased

Press 'R' to refresh or any other key to exit.


In this simplified text-based GUI:

The interface is displayed as a text-based window with headers and sections for weather data, weather condition graphics, and news headlines.

The user is prompted to enter their city code.

After input, it simulates fetching weather data (in this example, it assumes sunny weather) and displays it along with ASCII art graphics representing the weather condition.

News headlines are displayed in a list format.

The user is instructed to press 'R' to refresh the data or any other key to exit the application.


Assumptions implementing this program within the NABU network with my limited understanding involves several essential steps, given the thin client nature of the NABU computers and their dependency on a central server for software and data:

Development and Testing: The BASIC script is initially developed and tested on a suitable system, possibly a modern computer with a BASIC interpreter or emulator that simulates the NABU environment.

Transfer to NABU Server: After testing, the script is transferred to the NABU server.

Server-side Configuration: The NABU server must be configured to store the script and manage requests from NABU clients. This includes setting up processes for fetching external data (like weather and news) and transmitting it to the clients.

Running the Script on NABU Clients: Users access the script via the NABU network, operating it in their computer’s RAM of course, given the absence of local storage.

Script Updates or Modifications: Should the script require updates or changes, these are made on the development system and then transferred again to the NABU server for client access.


Potential data sources for the NABU Server include:
NOAA
https://www.weather.gov/documentation/services-web-api
NASA
https://api.nasa.gov/

Example of similar initiative can be found at Vintage Computing and StarTTY
https://web.archive.org/web/20070602225 ... artty.com/

Derek

[Super_Derek]

Hello everyone,

I wanted to return to this thread with an update because this is where I first proposed the idea in December 2023. What began as a rough “NABU Weather and News” BASIC concept has now become a completed NABU Command Center Version 1.0, a native Z80 information and telemetry console for the NABU Personal Computer.

Older video during development, v1.0 is now complete:


The final architecture is much more appropriate for the machine than my original concept. A companion modern Gateway handles HTTPS, APIs, JSON, caching, filtering, geographic calculations, and data reduction. The NABU receives small bounded records through the established RetroNET Store path and handles input, validation, state, graphics, sound, music, and presentation locally. The NABU is therefore not pretending to be a modern web client; it remains a thin, deterministic native client.

Version 1.0 includes:

Atomic Clock
Local Weather with dynamic ZIP/location resolution
NWS weather alerts and rolling weather trends
Earthquake Local and Global monitoring
NOAA Space Weather with graphical history
live Satellite/ISS telemetry
live Airspace/ADS-B tracking
automatic 60-second and manual refresh
three-page NABU Task Manager/diagnostics
native AY sound and bounded Music playback
startup splash, Help, Diagnostics, Safe Idle, and the complete graphical Page 1 interface

Production data comes from services including NIST, the National Weather Service, USGS, NOAA/SWPC, WhereTheISS, ADSB.lol, and Census/ZCTA support for location resolution. Modern provider complexity remains Gateway-side; the Z80 only receives bounded production records.

The Task Manager was deliberately made truthful rather than decorative. Displayed values are identified as LIVE, CALC, MAP, CONST, or UNAVAILABLE according to their actual source. If the application cannot genuinely measure something, it does not invent a value.

The transport foundation was qualified before the live modules were built on it. Its final qualification completed 5,000 of 5,000 bounded reads with zero missing/truncated records and no freezes. That transport milestone was then frozen rather than repeatedly redesigned.

The final Version 1.0 candidate has now been accepted in MAME 0.250 and on a physical NABU Personal Computer.

Frozen Version 1.0 identity

BUILD_ID: NCC-SPLASH-260826-LV2
000001.bin: 59,501 bytes
000001.NABU: 59,501 bytes
Byte identity: VERIFIED
SHA-256:
5D27DFBB3ED8DCD96AF828CECC7550EF546B07C10509E20A71FECFCF0CC89087

The accepted memory map places BSS_END at $FC7A with the initial stack at $FF00, leaving a documented 646-byte static-to-stack address-space margin. That is one reason I stopped adding embedded Help content rather than stripping working features or consuming the remaining margin unnecessarily.

Version 1.0 has also completed its local Git freeze. The accepted production state was captured first, then the release structure and documentation were organized without rebuilding the hardware-tested binary.

Release branch: release/v1.0
Final organized commit: 2566641c99b7b725a4f08c6c7ace9c7ce1bb2496
Annotated release tag: ncc-command-center-v1.0-physical-verified

Git integrity checks passed, the tracked working tree is clean, historical material was preserved, and no remote push has been performed. The release directory contains the exact accepted binaries, checksums, release manifest, build provenance, acceptance status, known limitations, map/listing/symbol evidence, engineering documentation, and user documentation.

Formal community publication is now the next step.

I am treating publication as a release operation, not another development phase. First I will complete the final licensing and third-party provenance review. The project license is still an Owner decision and will not be assigned automatically.

After that I will publish the frozen source, Gateway, build scripts, configuration examples, documentation, exact binaries, checksums, and release notes through a public Git repository/release. The public .NABU artifact will be verified against the SHA-256 above so the community receives the same binary that was tested on the physical machine.

I then plan to stage that exact .nabu file through NABU Cloud, add the proper description, screenshots, icon, and category, verify everything while the entry is still unpublished, and then publish it through the normal NABU community catalog.

After publication I will test the release exactly as another user would: confirm Command Center appears through the NABU Internet Adapter, load it through the public catalog, verify the visible Version 1.0 identity, and separately install the companion Gateway from a clean directory using only the published instructions. Only after that end-to-end test passes will I consider public distribution verified.

The Gateway will be distributed with the source/release package because the live-data features depend on it; NABU Cloud will distribute the native NABU program itself.

Version 1.0 will also remain immutable after publication. I will not silently replace the binary or move the release tag. Any later defect correction, provider adaptation, or enhancement will receive a new version.

Looking back at the original BASIC post, the goal survived: make the NABU useful as a live information terminal without turning it into a poor imitation of a modern browser. What changed was the engineering. The project now works from verified NABU behavior, z88dk, RetroNET, the Internet Adapter, MAME, generated artifacts, and finally the physical machine.

Thanks to the NABU community for the preservation work, documentation, tools, emulation, Internet Adapter development, and technical knowledge that made this possible.

Derek Leger
Super_Derek
NABU Command Center v1.0

Screenshot 2026-08-27 004052.png (1.82 MiB) Viewed 380 times