Here is the second TWIF – and it’s another interesting week for the AppleII and Spectrum platforms. If you missed the first one it’s here and following that process these are all my notes and impressions about what has gone on in the past week in the FujiNet Discord server. There are tons of interesting discussions, support, breakthroughs, and pitfalls– all happening in real time with a core set of committed individuals who continue to show up and talk, hack, and test their way thru the evolution of this wonderful device. Actual quotes are those of the authors and attributed, everything else is in my own words- so let me know if there are omissions or errors and I’ll correct this record.

Atari at 50

Today in 1972 Nolan Bushnell and Ted Dabney formed Atari Corporation in Sunnyvale CA. The rest we all know.

This edition of TWIF Covers June 19 – 25 of 2022

You can find more info at these locations:

• FujiNet Official Site
• Buy A FN Device from Vintage Computer Center
• Buy A FN Device from Arcade Shopper
• Wiki Pages for Devices & Coding
• Join our Discord
• The FujiNet Facebook Group

FujiNet Flasher is here – keep your FN up2date.

FN Platform work

FujiNet N Handler

Lots of changes in N handler centered around the AppleII expansion of the N device by TCH. The N handler is the killer feature behind all the FN flash and sizzle. Creating a new N (for network) device for these old platforms allows them to utilize the modern web without out any of the necessary heavy lifting for things like a TCP/IP stack, wifi encryption, web protocols like HTTPS, even JSON parsing. It’s all done on the ESP32 and exposed on each platform by the hand-crafted assembly and c glue to expose the N device to things like a local BASIC version. This allows the magic to happen.

Some stats this week on this project alone – excluding merges, 1 author has pushed 7 commits to master and 7 commits to all branches. On master, 47 files have changed and there have been 4,787 additions and 1 deletions. Thanks TCH.
Code

8-Bit HUB

Moz has started commits to enable the config of a new 8-bit virtual hub via the FN web interface. It looks like the Lynx platform will be the first to take advantage of this, as it already has a number of multi-player games designed for shared play across Lynx.
Code

CONFIG – the App that manages the FN device

Schadret has been working deeply on refactoring the Atari side of CONFIG – the primary app that manages and configures the FN device from the local platform. When the first config was created by TCH it was just CONFIG – for Atari – as there were no other platorms. But when the ADAM appeared the CONFIG app had to be abstracted for various platforms, which it was, and as a result there was the new CONFIG and the original Atari 8bit CONFIG. Features have been added to the FN Config and rather than updating the Atari code Schadret is ‘porting’ the FN CONFIG back to the Atari, so that all platforms will be at the new standard baseline for CONFIG.

In his own words:

I am implementing the Atari version of it (I believe it currently supports the adam and the apple). First step for me is getting it working and looking like the existing config program (then it will be at least 3 systems on the “common config” code). I’d say I’m about 90% done.. Once that’s all done and it hopefully becomes the official config program, THEN I’ll move on to try some of my ideas to make the UI a little more “Atari” (ie, more ATASCII).

CONFIG has it’s own repo, as it’s an essential app that has to be ported locally to each hardware device:

• Original Atari Only CONFIG Code.
• Platform Independant CONFIG Code.

Platform Progress

ADAM

MMarcoux66 showed up and needed some help w/ his ADAM FN. There was discussion on how exactly he had gotten a FN since he said that ‘he got it from the guy that sold him his ADAM…’ And it turns out that I can solve that mystery myself- I sold my ADAM at the recent VCF Swapmeet and included the FN in the sale so that the new owner would enjoy the benefits of the FN. There is only so much space that I have, and the AppleII stuff dictated that the ADAM had to go.

Apple II

The Apple II platform again leading the way with break-thrus this week. TCH advanced the AppleII integration with FN with his start on the core n-handler routines patched into BASIC and DOS. This is allowing simple basic programs on the Apple to treat the FN like a char-based device. Basic routines to find your FN, open, close and read connections now make it possible for some interesting games and programs… in BASIC. Even across platforms.

robj is working on a prodos1 disk image that works on the Apple3. He has an A3 with LIRON card and soshdboot setup to use FN as a network-based drive that can boot the Apple3. Soshdboot is Rob’s own project on GH and allows A3 harddisk booting.

Dean Claxton and Jeff Piepmeier sorted out defining some bus code abstractions for the FN card version that Dean is working on. Jeff is sorting out all the IOs in code to correspond to the new Apple FN 1.0spec Jeff created (see last week TWIF).

TCH

Thom Cherryhomes: I am going to need a crash course in the monitor routines.
Thom Cherryhomes: ok, I need to take a long exploration of command processing in BASIC.SYSTEM. To make it easy to write #FujiNet applications for the #Apple2, we are extending AppleSoft BASIC (BASIC.SYSTEM) with a series of commands that will add network communication functionality, making the smartport calls automatically.

key to this functionality are the:

Default I/O vectors. These may be changed by the user to remap slots for nondisk devices. When the system is booted, all slots not containing a ROM are considered not connected and the default vector is left to point at the appropriate error handling routine.

TCH committed the first Apple2 code for the nHandler in the git repo on June 22. He worked out ncd, nopen, nclose, sfind and nfind.

NCD – Mount or unmount a remote directory to a network device (N1: through N4:). The remote directory must be hosted using one of the supported FujiNet protocols (primarily TNFS).
sfind – how to find the smartport dispatcher
nfind – which finds the first network device

TCH gave some samples of how easy this is to now use in Apple BASIC:

10 ? CHR$(4);"NOPEN N:TCP://1.2.3.4:6502/"
20 ? CHR$(4);"NWRITE"
30 ? "HELLO"
40 ? CHR$(4);"NCLOSE"

To read some data:

10 ? CHR$(4);"NREAD"
20 INPUT A,B,C,D
30 ? CHR$(4);"NCLOSE"

On deck for TCH is more work on his command parser to handle more than one command.

atari16bit

sjfroos continues the work on some software to support the hardware prototype. We saw the first FN logo bootscreen on the ST. He has compiled and run some of the first code running natively.

Lynx

Moz has pushed some support for a virtual 8bit hub, with some support for 8bit Slicks- but over the Internet via the FN.

JohnBuell has received new lynx flash cards and has distributed them to the core testers for the FN Lynx, more to come as they start to use them w/ FN.

Discussion around the need for eventual support of a keyboard input for the Lynx, in order to configure the FN and assign it a wifi network.

Some remote gaming was attempted, but it seems like home networking (firewalls) prevented full participation by all the players. Remember UDP is a valid networking packet, no matter what your ISP tells you.

commodore

The C64 push with Meatloaf has been a little quiet lately, but idolpx is planning on attending VCF SE on July 15,16,17 and has a table for display of C64 FujiNet. He’s getting a banner made up and will revisit the code for a push to wrap up the work done at VCF East in order to have something interesting to present at VCF SW.

fujinet-pc

Schadret was doing work with his CONFIG abstraction project and was setting up a number of concurrently running virtual FNs for Atari. Multiple running VMs with fujinet-pc and Altirra solved his needs for now.

Heathkit

This channel saw some action this week and DarrellH89 popped in and has pulled down the GH repo and begun to examine the FN codebase. a BUILD_H89 def. was created and so we can say that this project has definitely started.

zx-spectrum

thweasel and ThatOldNerd continue to move mountains getting FN onto a parallel bus. They both are riffing off each other in a distributed virtual pair-programming symbiosis that is moving the project along. TON is waiting for some prototype boards he’s designed to come in from China. They both discussed ways for the ESP32 to talk to the Z80- IO registers (Thweasel) or BIOS hooks (TON). thweasel is focused on handling the bus, and is just trying to get something to control it via his Arduino_BusJacker project. Baby steps.

skonkfactory also popped in and was bouncing ideas in the group.

thweasel: My thinking for the IO registers, is that it would be a clean way to interact between both systems without having to pull a BUSRQ and pause the Z80. Or without having to dodge/brute-force the ULA in that lower memory space.

But yes, I get your idea with using a custom ROM image in SRAM with a bit of communication buffer space. It would likely be worth adding as a feature in complement to the IO registers. However, the 128K speccy machines also have Banked ROMs; this could complicate the approach?

Next sub-project IO in/out registers will cover:

• Responding to a Z80 with-in Speccy timings for IO Requests.
• Writing an IRQ for an Ardunio (for the first time).
• Introduction to Address decoding in the IO space on the Speccy.
• Multiplexing IRQs and scanning inbound Control signals.
• Dabbling with IO Bus protocol ideas for chatting between Speccy and Fuji.

theweasel and TON discussed address decoding and how that could be done virtually in software, on the FN (ESP32).

thweasel: Enabling software decoding on all line would mean the Fuji could jump in on any address and act as a Virtual device. For example, we could have the Fuji listen on the IO address of the ZX printer (bus version), it would then be able to catch the data intended for a printer 🙂

Which sounds exactly like what the FN is supposed to do for these classic platforms.

thweasel: The way I have been looking at the problem is with these 3 questions. How well these questions are answered will basically limit what we can and cannot do.

1. How can I read or write to the system memory to enable fast loading like a DIVMMC?

2. How can we decode Addresses in the IO space, and have the ESP talk to the Z80 (either directly or via a register)?

3. How do you replace the ROM chip with your own RAM chip, programmed with your own code and jump the processors execution to it?

And lastly some discussion about the speed of the gpio pins in the ESP32 vs. Ardunio. Perhaps the ATMega could be used on a Spectrum FN, with the ESP32 programmed at power/boot by the ESP32 as needed. skonkfactory thinks you can get the speed from the ESP32 itself with bypassing all the fancy libs on the ESP32 as “people generate PAL video in software by bitbanging IO ports on ESP32s…” JeffP was able to chime in here and talk about some of the speed work he did on the ESP32 for timing on the SmartPort.

There is a ton of deep work being wrangled out on the zx-spectrum platform, this was only a taste of what is going on. Clearly, the evolution of the FN onto a parallel bus brings with it a lot of fresh issues but some clever people who are willing to solve the problem have found their way together to the server and are hashing thing out in a highly productive way.

And that wraps up this week in FujiNet. It’s a special day posting this on the 50th anniversary of the Atari, a platform so ahead of its time that its persisted and even grown – while not in actual systems at the very least in hacking and appreciation of its genius.