This Week in Fujinet covers two weeks- and while things are grinding on in certain areas it’s been a relatively quiet two weeks. Apple, C64, RS232 move towards their release while some Atari app support (NOS) continues with some nice utilities and advances.
This Week in FujiNet covers two weeks in September:
Week 37 – September 11 – 17
Week 38 – September 18 – 24
September 15: The Apple IIɢꜱ was released on September 15, 1986
You can find more information about the FujiNet project and purchasing a device at these locations:
- FujiNet Official Site
- Buy A FN Device from Vintage Computer Center
- Buy A FN Device from Arcade Shopper
- Antonio @masteries on AA Sells FujiNets from Spain
- GH Project Wiki Pages for Devices Hacking & Coding
- Join our Discord and learn and contribute
- The FujiNet Facebook Group has interesting discussions
Check Mr. Robot’s Live Fujinet Server Status – where to connect with your FN
FujiNet Flasher – keep your FN up2date for best results.
DaBaDa79 made some nice contribs to lib/fnjson/fnjson.cpp and improved the JSON parsing done by the FN for useful networking programming on the native platforms. Mapping to international charset functionality was added it and will allow the fnJSON parsing to handle a wider array of json responses from around the globe.
Jan Krupa continued his work with SIO over UDP. Jan is responsible for the FujiNet on PC- the virtual FujiNet device that allows FN development work without even having a FN device with the Altrirra Emulatore for Atari 8bits.
Jeff Piepmeier had many, many, commits in the ongoing work for SPI reads and writes for SmartPort support for the Apple2 platform.
goltmans and dotmatrix continued work on the MIOC emulation. This will emulate the rare MIOC chip for new ADAMs.
dotmatrix: got EN245 to toggle…
goltmans: : According to adamem source… writing to IO port 0x60 is the normal MIOC bank select. Writing to 0x42 selects the third party ram pages. I think this is a 64k page though, so the same 64k page is swapped out for the entire expansion ram. I haven’t tried that to be sure though. So there would be a constraint on selecting pairs of lower and upper 32kB bank pairs to the same 64k page if I’m not mistaken.
Ron Klein announced that he now has an ADAM. Ron has done huge amounts of work testing FujiNet with Apple2 and will hopefully be working and exercising the FujiNet with the ADAM and the Apple and the Atari…
Ron and Henry R discussed various ADAM issues. CPM, serial consoles, PSU replacements. Ron and Henry talked about the F18a – a video chip replacement that gives the ADAM VGA output.
Mytek announced in AtariAge that he was building a Colecovison NUC, similar in size to the Atari NUC he created. This seems like it won’t be a full ADAM (no MIOC or tape control, ADAMnet) but interesting to track. Seatsafetyswitch in the discord has created a CV clone and is just waiting on a replacement for the MIOC chip to enhance it to become a complete ADAM system.
Andy Diller (me) plugged a FN into the back of a Macintosh. It didn’t work but the FN saw the Mac. There needs to be some work done, and hopefully when JeffP is done with his Apple2 SPI work he can help adjust some timings for the Mac. The Mac has the same IWM chip as the IIGS and IIC+ and the pin outs are almost the same, however, it’s not exactly SmartPort. We will first have to decide to emulate a floppy (400 or 800k) and then tackle the DCD (Direct connected Disk, aka HD20) support that the early Mac supports on the Floppy port. I am also starting to code something up on the Mac using ThinkC for System 6. We will have to have a local CONFIG written and this is a good project for me to dabble in. More to come.
dreamkat and robj have been helping with critical Mac floppy and DCD (HD20) information from their experiences.
FN does 68k:
First Crude attempt at a macintosh CONFIG:
Rory McMahon brought up a working IIe with FujiNet and began to help test releases, as JeffP continued his work on SPI reads and writes to ensure sustained workouts on the read and writes on the SmartPort – with varied timing across the various implementations (IIGS, softSP, Yellowstone).
dreamkat also brought up a FujiNet device for apple iic and began to hack and of course eventually did the VS code setup and ran some cutting edge code on her Apple.
SPI work continues with JeffP working on timings for each device and using the SP testing utility to test writes to the SD card from the network…
mozzwald and dreakat discussed the pros and cons with board design, dreakcat wants to design a new Apple2 FN board that is as small as possible. RodneyR joined them and they talked about things like copper pours which seem like something something does by it self and another thing makes you do by hand for something.
mozzwald: I don’t appear to have an option for Clear all pours
dreamkat: OK so I changed them to unpour and it still looks like I have a bucnh of airwires
RonK and JeffP went thru another few rounds of SPI adjustment, SP test runs and trace outputs.
Ron Klein: @Jeff Piepmeier Performed latest WRITE test using testsp_v2 (SD card) and was able to capture a trace (including the DRV2 pin). You can find it here in the ‘2022-09-15-testsp_v2’ folder:
Ron Klein: It errors out fairly quick — consistently.
Ron and Jeff had different outcomes despite both testing on ROM01 IIGS. Much back and forth and config testing and verifiaction to ensure the .ini files matched in both environments…
Moz explained the firmware creation process:
mozzwald: If you want to package up your own firmware build for someone else it’s fairly simple. Get the current zipped build from https://fujinet.online/firmware/ in releases_apple and extract it. Edit the version, version_date, build_date, description and git_commit in release.json. Replace the files bootloader.bin, partitions.bin, firmware.bin and spiffs.bin with yours from fujinet-platformio/.pio/build/
/ and compress them into a new zip file. To flash it, run /path/to/FujiNet-Flasher /path/to/newfirmware.zip
Debugging SPI timing continued…
Jeff Piepmeier: @Ron Klein @Thom Cherryhomes I think it’s possible on the last compile round that read packet routine got stored in SPI RAM. I just put the IRAM directive in the heading and now it works again for me. I will push.
RonK still had issues w/ that push however…
Jeff Piepmeier: Interesting paradox going on here. The failed WRITE commands are what drove me to SPI-based reading – the data volume was so much we were bound to get a bit error. Now, the SPI reads of the WRITE payloads are just about perfect. It’s the commands that I’m having trouble with, esp. on the IIgs. Here are traces of the beginning of a command – see the late start up of the SPI capture; and the beginning of the WRITE payload where the SPI is on it because there’s a longer pause before the IIgs sends the packet:
Then Jeff realized something….
Jeff Piepmeier: major facepalm – I was still printing phase state changes to the debug monitor … so when the apple2 “enabled” the bus, the fujinet printed “enable” to the debug monitor. That’s real helpful to see what is going on, but takes SO MUCH TIME! Without it, i’m now getting 3 us entry into the read packet routine.
Jeff Piepmeier: so fast, you can barely see it happen
Ron Klein: WRITE test is working!
What a difference from just a few days ago when it seemed like I had the only machine with an issue….
With the IIGS nailed JeffP moved over to the Apple2 and Yellowstone to get that working again….
Jeff Piepmeier: FYSA: @robj and I got the YS card working in the thread I broke off. Struggling with Liron. Turns out each system has its own timing and there are multiple timing parameters we have to adjust.
With Yellowstone squared away, it was back to SoftSP…
Jeff Piepmeier: the DIY SoftSP using SSC timings are certainly different. The byte periods alternate between 32 and 35 us, with an average of about 33.5 us. Fortunately, it doesn’t seem to have a strict ACK timeout like the original SP firmware. I’ve got CONFIG mounting and booting running OK. I can’t get a 512-byte WRITE going yet – checksum error on the FN receive side. But still progress!
Work continues but SPI seems to be tamed save for timing issues on all the various SP implementations.
Michael Sternberg showed off NOS on the XEP-80II. Work continues on that project. NOS is a facinating project in that it will remove a common problem with Atari systems and disk handling- the Filesystem. I didn’t realize what exactly NOS was attempting to do the last time I reported about it but am now a bit more familiar with it.
What is NOS again?
NOS seeks to do something very simple- replace the concept of 90k floppies that have a Atari DOS filesystem on them and require DOS in order to manipulate those files with the network itself. Imagine that all the files on all the Atari floppy disks were now stored on a network share. TNFS, SMB, HTTP – NOS uses those protocols (TNFS for now) to access and manipulate files that are stored on the remote filesystems (that NOS and the Atari know nothing about). You can load, copy, edit manipulate the files as you would in any DOS or shell (for UNIX people) but across the network. You are not limited to 90k disk images loaded into Slots on the FN- all your files are there on a gigantic disk. This requires both read and write access to work – for now that is accomplished via TNFS and WebDav access for writes. But the future will introduce more network file system choices and the FujiNet will work with them as well as NOS.
Thanks for MichaelS and TomCH time in explaining NOS to me like I’m a fifth grader!
Michael Sternberg: @andy diller
I’ve taken an ATR file and exported its contents into a folder on my TNFS server.
Then I CD to the folder and work with the program as if it were the floppy.
Schadret has moved from 100% emulation based work (hacking on CONFIG) to working on a real system- a 1200XL. Nice upgrade!
Schadret (github: frachel): Now that I’m moved and have my real hardware (1200xl) set up I am getting back into coding stuff and have a workflow question – since I did everything previously all locally with fujinet-pc and Altirra, what’s the most efficient way to test changes rapidly on the real hardware? If I set up a TNFS server on my PC, when I compile the config program can I just mount it (would it be the autorun.atr or the config.com?) on the real hardware to D1: and boot? Or do I have to put in on the SD card in the FujiNet, or flash it?
He was looking for the most efficient setup for build and running on real hardware and got some tips. XEX is the way to go here.
mnemo completed his utility to dump real Atari floppies to an ATR, using the Atari itself…
mnemo: Exactly. Create an ATR from a physical disk directly on the Atari without the need for an empty virtual destination disk.
but not having to create the ATR beforehand- it copies the blocks over to a new ATR image that is assembled on the fly by his new utility. And the new NOS system helped him do this in record time:
mnemo: Yes, that was a quick turn-around. Thanks to doing the coding on a modern machine, emulators and FujiNet plus NOS for rapid testing. Just „make“ and copy the .COM to the TNFS server. So cool.
Most if the time was spent getting the parameters for CIO and SIO right and the stupid multiplication that was not automatically extended to long. 🙂
Thom Cherryhomes: @mnemo yup, dev was one of the use cases for the nos. 🙂
I made a short video about using the XEP80 as HDMI upscaler while playing the new interactive fiction game Hibernated…
Creating a new blank disk via the FN WebUI was discussed.
Mnemo continued work- trying to detect different density disks and the Percom block size.
seatsafetyswitch got his new, revised (aka ‘fixed’) cards back. SPI echo program is not completely working yet for him.
thweasel gave an update then one quickly followed from That Old Nerd — things are progressing….
thweasel: General update, we had a discord call over the weekend and discussed That Old Nerd’s extension of the RAM based IO Address decoder. The original idea was to provide a way to trigger a WAIT signal to stop the Z80 and give the ESP time to pull the BUS (Control/Address/Data); decode the IO request and respond. However, the SPI driver sucks and at just over 1uS (1000ns) just to setup the transaction hitting WAIT to process IO is going to kill time critical applications.
So, in light of more problems than solutions, That Old Nerd has expanded the RAM decoder to provide alternative IO options. Every IO address (all 16-bits 64K) will map to 64K of RAM (IO decoder map), every address will have one 8-bit word for configuring how the IO address works.
That Old Nerd: Just an update from my side. I believe I figured how to integrate comparators so that we can eliminate overwriting data. This weekend I want to try and nail down the flow so I can confirm the logic and start working on the timing.
moz finished his initial testing of the RS-232 FN and then shipped one to TCH…
fnConfig::load No config found - starting fresh! disk UNMOUNT disk MOUNT IMG MOUNT RS232 SETUP RS232 Setup Flush Available heap: 4383003 Setup complete @ 333 (329ms) WiFiManager::start() complete WIFI_EVENT_STA_START RCV: i RCV: t RCV: w RCV: o RCV: r RCV: x RCV: z RCV: z RCV: z RCV: z RCV: ! RCV: !
mozzwald: it’s working enough that I’m gunna send you this tomorrow
TCH has the FN and after sorting out serial cables has started to do his work on testing and bring up.
Thom Cherryhomes: ok sooo
Thom Cherryhomes: am rolling my own RS232 (8250) routines.
Thom Cherryhomes: I love coding on the grid
And with that we are done another two weeks of FujiNet progress. Things continue to shape up for the Fall with good work going on with SPI and Apple2, Meatloaf and Fujinet is happening behind the scenes and RS-232 is taking its first steps on a grid.