This RAPID covers more time than some of the previous ones (September, October and the top of November)– so there is more info here in the extended cut that you’ll see in the broadsheet.

Platforms

* PR 780 – DISKII Writes (FozzTexx)
* https://github.com/FujiNetWIFI/fujinet-firmware/pull/780
* Need fix in CONFIG to allow [W] option to be selected 
* CONFIG A2 Intelligent Disk info
* Determine which Disk II drives the FujiNet represents
* https://github.com/FujiNetWIFI/fujinet-config/pull/101 
* FN-PC – builds in GH!
* Automatic GH actions to build FN-PC 

APPS

* Fujitzee Apple Updates (Eric Carr) 
* Lobby Client for Apple2 (Eric Carr)
* Lobby client allows connections to the FGS games served at a central location
* automatic selection of the Game Client Disk 

* CONFIG for IIGS and GSOS (Eric Le Bras)
* incorporating new elements for CONFIG 
* Apple2 – Lowercase project for apps (Oliver)
* IIc drive switcher – FN compatible (hardware)
* A2 SLIP Wiki Update
* https://github.com/FujiNetWIFI/fujinet-firmware/wiki/Apple-II-SP-over-SLIP 
* FN-Lib- ORCA support (fenrock)
* help from EricLB fn-lib supports building in ORAC/GG for IIGS
* clock device added to FN-LIB

* First data from Z80 bus with Parallel Interface (thweasel-Owen)

* A8CWinLib (ripjetski)
* https://github.com/Ripjetski6502/A8CLibrary
* Built some windowing w/ FujiNet bindings
* https://github.com/Ripjetski6502/A8CLibrary

NEWS

* The a2tools project – Colin Leroy-Mira
* Use a linux/pi for network access on the Apple IIc
* Ported FN Weather App over to use his SURL system
* Very cool video to show development process

Videos

* Apple SOTA https://youtu.be/DEmHSWsoe7g

* CocoFujiNet  https://www.youtube.com/watch?v=D_hhWFYepmU

* FujiNet on Serial:
* https://www.youtube.com/watch?v=ogBeHa2gXjw
* Colin Leroy-Mira live-codes porting the Apple2 Weather app for FujiNet over to his SURL project. 
* Electron Dance: Exploring SCRAM
* https://www.youtube.com/watch?v=B3XiR5tYhFo
* A video describing the gameplay of Atari’s SCRAM (1981) developed by Chris Crawford.

Lowercase Apple II

Oliver Schmidt

Given @Robert Justice’s positive feedback from the A3, I see my “Lowercase Apple II” initiative completed

To (as usual not really) briefly summarize: In general, a cc65 binary is expected to behave the same no matter on which actual machine variant it runs. So for the Apple II, there’s in general no lowercase display support for cc65 programs as there are Apple II machines which just show garbage when trying to display lowercase. However @Thom Cherryhomes was very unhappy with that and expressed as strongly as his unhappiness was

So I added to cc65 the option to deviate from the general cc65 behavior on the Apple II and just go ahead and DO display lowercase. The obvious idea is to check which Apple II variant the binary actually runs on and decide based on that to activate the new option or not. Then I added the necessary two lines of code to the “well known” FujiNet text programs which just display some text via STDIO. Additionally I modified CONFIG. CONFIG is different as it an interactive program using CONIO (instead of STDIO) to display an advanced user interface. Here a few tricks/workarounds were necessary to get the lowercase display right. And as a side effect, the horizontal lines in CONFIG are now solid lines and no series of minus signs anymore.

Fujitzee Apple2

Fn fujitzee coco.

FujiNet Booting Apple ///

Fn appleIII boot.

FUJINET_DISK_0 – ORCA Builds

 Eric Le Bras:  @fenrock while debugging sp_find_device_type on my gs, I discovered that none of my FN’s devices reported type $10. This is the types I found, starting from device 1 through 9: $01 $02 $02 $02 $12 $13 $11 $14 $15. I expected that the 1st device (‘FUJINET_DISK_0’) would report $10, but no, it is $01 (floppy disk, not surprising though). Is ther a device $10 missing on my FN? 
 fenrock: exposing $10 as the FujiNet is a recent change I made to the firmware. Let me find the commit 
Fn code DISK 10.

  It used to be (and still is for backwards compatibility) a massive hack that control/status commands were picked up by the FUJINET_DISK_0. I really hate this hack, because although it was done at the time to get things working EVERY BIT OF SOFTWARE NOW NEEDS TO ALWAYS SUPPORT IT – where’s my shake fist emoji? It still does that in firmware (to support older code that still expects it to be on that ‘device’), but I’ve also made the device available as a proper thing that gets list in CONFIG as a device on the fujinet, and properly responds itself to commands sent to device $10 (instead of them being proxied from the DISK_0 device). For the client side, I’ve kept that logic as a fallback in sp_find_fuji: (edited)  
oh, i can’t make the apple2gs target as fujinet-lib-examples doesn’t have orca compiler built into it yet

fenrock: I’m currently updating fujinet-lib-examples to support multiple compilers so apple2gs can be compiled. cmoc will have to be an exercise for others, though I’ve put the basics in.

FujiNet Clock Device

Fn clock fn-lib.

Atari

Fn clock fn-lib apple2.

Apple2

Spectrum Bus

thweasel (Owen): Still in the early stages but I seem to be catching some Z80 bus activity with some very rough and slow code. I can pick out Memory, IO, WR/RD and an address. No hot chips, the circuit seems stable (its readonly at the moment).

Fn spectrum bus blips.

DISKII Writes

Fn gh PR780.

Apple IIc Drive Switcher

Fn hardware c driveswitcher.

CONFIG Showing DISKII status

Fn CONFIG DriveChecker.

Coco FujitZee

Fn fujitzee coco.

Slip and FN Talk

Oliver Schmidt: My statement on updating the doc was NOT meant to imply that I would have considered it appropriate that you do it! However, I’m already wondering when is the right time to approach you because of that other – more complex – protocol “extension” topic. We’re not exactly in a hurry yet but it needs to be resolved before I finalize “the” A2Pico firmware.

fenrock: Ha, no implication taken, my comment was meant in the driest of humour 😄

The extension is only on the fujinet network device. I’m not entirely sure why this is wrong, and why it should be frowned upon. Are we saying the data in that protocol is holy and if so why? There’s a lot of data in it that can be used, and frankly if it upsets some device built in 1983 or some protocol about then that wasn’t given room to expand, I’m more inclined to say “I don’t care”.

Why can’t we build a new interface that realizes it’s a fujinet network device, and read the unit id off the additional parameter? Didn’t Robert mention all 9 bytes are copied or something when you raised this previously?

All genuine questions, I want to get this right, but forcing FN into complete incompatibility, trying to force the network device id in the first byte to accommodate some old way of working is not something i will do because “it’s the way everyone does it”.

Oliver Schmidt: @fenrock I’m unsure where to start best… Maybe it helps if we understand that what you did is (at least as far as I understand) based on this misconception from your side: I believe that you thought/think that what you changed is about a contract of two parties: The caller of the SmartPort firmware and the device. However, that isn’t true. What you changed is a contract of three parties: The caller of the SmartPort firmware, the SmartPort firmware implementation and the device.
If it would be otherwise, there would have been no need to adjust AppleWin at all.
But looking forward: I suggest to begin with not thinking about SP-over-SLIP at all, only about SP-over-CBus.

There I personally see two options:
Rely on the CBus implementation detail that no matter how many parameter bytes are specified, always the maximum amount of parameter bytes are transmitted.

Stay independent from any implementation details. My understanding is that we need additional piece of metadata (the channel number) for three commands: Control(), Read() and Write(). The Read() and Write() commands have a three byte Address parameter that seems well suited to carry the channel number. But the Control() command doesn’t have such a parameter. But there, we could add the channel number to the Control List. I seem to understand that you wrote that extending the Control List has the downside of not being backward compatible. However, I must admit that I think that it’s pretty unfortunate to have the Control List not being extendable. Maybe it would be best to change the Control List format once in a backward incompatible way to make it extendable in the future.

I believe you/we need to decide between the 1.) and 2.) above. From there, our approach for SP-over-SLIP follows.

FN Weather Ported to SURL

* https://www.youtube.com/watch?v=ogBeHa2gXjw
* Colin Leroy-Mira live-codes porting the Apple2 Weather app for FujiNet over to his SURL project.

This summarizes the key points and insights from a video demonstrating the process of adapting Fujinet’s weather application to function with the SURL serial protocol.

Context:

* Fujinet and the SURL approach enable Apple II computers to access network resources, but differ in their hardware requirements.
* Fujinet utilizes a specialized hardware device connected to the Apple II’s Smart Port.
* SURL operates through a serial connection to any Linux machine, requiring no specific hardware.
Objective:
* The developer aims to modify Fujinet’s weather app to utilize the SURL protocol, demonstrating its flexibility and potential.
Methodology:
1. Source Code Acquisition and Setup:
* The developer obtains the Fujinet weather app source code and integrates it into their SURL project.
* They modify the Makefile to align with the SURL build process.
1. Replacing Fujinet Network Calls:
* The core task involves replacing Fujinet’s network functions with their SURL counterparts.
* This includes establishing a connection, initiating requests, and parsing JSON responses.
* The developer meticulously adapts each function call, ensuring compatibility with SURL’s syntax and data structures.
1. Address Buffer Limitations:
* Recognizing potential buffer overflow issues stemming from unconstrained string operations, the developer introduces a larger buffer (largebuff) to mitigate risks.
1. Performance Optimization:
* Initial implementation relies on multiple individual requests for weather data, resulting in suboptimal performance.
* The developer implements batch requests, fetching multiple data points in a single call, significantly reducing network overhead and improving speed.
1. Debugging and Issue Resolution:
* The process involves rigorous debugging, addressing issues like unexpected data formats, JSON parsing errors, and logical errors in calculations.
* The developer leverages print statements and breakpoints to identify and resolve these issues.
Key Observations:
* The SURL protocol demonstrates its versatility by seamlessly replacing Fujinet’s network functionality.
* The importance of thorough error handling and buffer management is highlighted to ensure stability and prevent potential crashes.
* Batching network requests proves highly effective in enhancing the application’s performance.
* The developer showcases pragmatic problem-solving skills, tackling unexpected issues through a combination of code analysis, debugging techniques, and a touch of humor.
Notable Quotes:
* “What I like so far is that I don’t have to think and understand anything about the algorithm, I can just do a one-for-one replace.” – Reflects the initial ease of porting thanks to the SURL protocol’s similarity to Fujinet.
* “Batching things is always a good idea.” – Underscores the significant performance improvement achieved through optimizing network requests.
Next Steps:
* Testing the ported application on real Apple II hardware to verify functionality and performance in a real-world environment.
* Further code cleanup and optimization, potentially addressing remaining areas for improvement.

Conclusion:

This video showcases a successful porting of Fujinet’s weather app to the SURL protocol. The process highlights the advantages of SURL, its ease of integration, and the developer’s adeptness in overcoming technical challenges. The outcome is a faster and more efficient weather app for Apple II users, showcasing the potential of SURL in revitalizing classic computing platforms.