Today is July 18th, Monday, and TWIF again covers events for the past week on the FujiNet Discord Server. I pay careful attention so you don’t have to, but lets be honest, I enjoy this if you haven’t noticed.
July 10 – 16, the 28th week in 2022
Upcoming FujiNet appearances:
July 19 – 24 – KansasFest 2022
If you are attending virtually or in person make sure you see the 4pm session on FujiNet for Apple II by JeffP. Jeff will talk about the REV0 board.
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
- Wiki Pages for Devices & Coding
- Join our Discord
- The FujiNet Facebook Group
FujiNet Flasher is here – keep your FN up2date.
Summer is here, the US is experiencing a big heat wave this week. How did that influence events last week for FujiNet? Not at all. But the Apple II testing has definitely shifted into user space as a solid core of early users are putting the REV0 boards thru all sorts of configurations and applications. A nice healthy backlog of issues is there to tackle, time permitting. The Spectrum team continues to do their deep work for FujiNet on a bus. FujiNet was on display at the VCF South East show that just wrapped up yesterday. Kansas Fest is this week and the FujiNet talk is 4pm this Friday.
New Discord Room
A new channel was created, hard-problems, to discuss hard problems that the team is tackling and wants to separate from any one platform’s ongoing work. The recent grappling with the ESP32’s SPI implementation with it’s high latency is what kicked off this targeted area. TCH and thweasel were talking about SPI and what can be done to increase the speed of it’s use for FujiNet on the Spectrum.
thweasel: After configuring the driver (SPI), the transaction called is spi_device_polling_start(); which calls another method in the same layer (Driver layer) then drops down into the hal layer. The hal layer calls through to spi_ll.h the third layer ll (Low Level, I guess).
So there is a 3 layer stack between code and hardware, all doing a bunch of checks, which we might not need. However, we don’t want to totally throw out Espressif’s design as part of the stack is leveling the hardware.
thweasel: The plan would be to start working through the code, and seeing how much of it can be reduced into a “fuji” SPI driver; or something even more simple for just running data in and out as bytes without the protocol parts “command address data bytes”.
There was a lot of discussion on the Apple II room this past week. Not all of had to do directly with the Apple II. This was the room where people were spending most of their time and so discussions sprang up not only about FN but other topics as well. All for the sake of collaboration.
With the Rev0 boards out in peoples hands there is a lot of user testing happening and documenting the rough edges continues. The hardware works amazingly well for a first POC, but there are some rough parts of the software that are coming to light for this platform. Both the Atari and the ADAM had their months of polish to get to the level they are now. For the AppleII this is just starting. It boils down to a number of issues that will be worked on in the coming weeks:
- CONFIG – getting directory transversal working again (going into dirs errors)
- WEBUI – need to setup a more refined way for the web ui to interact with the Apple functions available
- GSOS FST – File System Translator. Essentially a file system driver for GS/OS. Need one for Fujinet device?
- Yellowstone – FujiNet isn’t recognized at boot from the YS. Need to get it to boot CONFIG.
- Disk Image support – currently CONFIG recognizes .hdv and .po but enabling more diverse disk image formats makes sense
- IIGS ROM3 issues – ROM3 seems to have changed the timing in the SmartPort and nothing seems to work, this will need investigation into the SP timings
JeffPiepmeier has been gathering resources (images, video, tibits) for his up coming Kansas Fest talk – this Friday at 4pm. Consider attending virtually or if in person find the area where they are showing Jeff. Jeff himself will be presenting remotely, and from what I’ve seen so far he should have an entertaining presentation.
No significant code has been checked in for the FujiNet Platform itself; with the proper pin defs set for the REV0 FujiNet board people have been testing it across a variety of devices. Myself and Ron Klein have been testing on IIGS ROM1. PetarP has joined in and is testing on ROM3 IIGS. He has also confirmed the REV0 board works on both the Grappler and the SuperSerial with the SoftPort ROMs. It’s just ROM3 IIGS and Yellowstone that have roadblocks.
oliverschmidt created a PR for AppleII ISS tracker application. He really polished the IIS tracker C code created by TCH with his contributions. It now is smaller in size, reduced overhead I/O, fixed color fringing artifacts for the world map and added in support for Apple II ethernet cards for data. So if you don’t have a FN but have ethernet you should pick up this Prodos bootable disk image and try it out. It’s available on the apple-apps.irata.online TNFS server, and a direct download is available via oliver’s web site.
Left is the previous ISS, right is after de-fringing. This is not a good comparison as the left image is composite out to a LCD while the right image is from an Apple RGB CRT.
Getting older AppleIIs on SmartPort
Even though there are plans to have FujiNet emulate a regular DiskII (non-spartport) there is still another path – providing a super low-cost SP card for all those systems- perhaps even a package deal with the FujiNet. There are a number of projects around (softSP from KBOO is one) but these products seem to be out of stock often and as closed source projects there are no other vendors to produce more if required. If people know MFA/Kboo kindly suggest that they license or open up the design of this board so that other Apple II enthusiasts can more easily enjoy SoftPort (and soon the FujiNet) in their AppleIIs.
Differences in the SoftSP implementations were discussed:
mozzwald: what makes the grappler+ card with softsp different from the SSC or this new softsp card?
robj: the difference between the ssc and the grappler is the mapping of the rom. the ssc has a 2k rom and the grappler+ a 4k rom. The A2 has a so called 256 byte slot rom that is always mapped in for a card. And then there is a shared 2k rom space that a card can switch in its own one.
the ssc and grappler cards differ in how they derive/map the 256byte slot rom from the image . I think that the softsp code was tight to fit into 2k, so the version that runs on the grappler has a bit more room to move, so it has had the updates/bugfixes done it it. Not sure what the softsp card has on it, i assume it has the bigger rom setup
Petar has confirmed the REV0 FujiNet works fine with both grappler and SS.
Andy Diller (me) and Ron Kline discussed using the FujiNet with the MDT hard disk card installed in the IIGS. Having to hold down ESC at power-on every time to skip the MDT was annoying – as the FujiNet uses ESC to boot, and if you held it down too long you end up just booting what was the last virtual disk in CONFIG instead of getting into CONFIG.
Smolderer had the great suggestion to set the boot priority to the FN – slot 5 (the built in SmartPort on the IIGS) via the IIGS control panel. I tried that and it solved all my issues. Now the FN happily boots first with no issues. My issue now is that my IIGS battery is dead and won’t save this setting, but I’m going to fix that soon with a replacement battery.
The CONFIG app has a maximum of 128 characters for any path to an image, with long file names that path limit can be exceeded. The Web UI will allow you to mount those images, but CONFIG won’t be able to boot them. This caused some confusion but the remedy to eventually change file names into something that ensures they and the path to them on the TNFS server remains below 128 characters.
Smolder has some ideas about Yellowstone issues with Fujinet:
smolderer: “First it says “The reason drives may not work with the IIgs ROM 03, IIc Plus or Macintosh LC //e emulator card is because around the introduction of the Apple IIc Plus, Apple changed the Smartport protocol to where each device hooked to it, (be it 5.25″ drive, 3.5″ drive or a Smartport compatible hard disk) needs an ID Byte. The UniDisk 5.25″, DuoDisk and most 3rd party drives DO NOT CONTAIN this needed ID Byte rendering such drives unusable with the newer Smartport protocol.” This implies that ROM 03 requires ALL drives to be intelligent SmartPort drives. ”
ppuskari joined in with more info as well. He has a YellowStone and will continue testing and probing for what is blocking the Fujinet boot:
ppuskari: Found the message! From Robert Justice discussing the issue with the fail to boot on Yellowstone and the firmware change he made to the smartportsd firmware device so it would boot on the Yellowstone card. I hope this helps @Jeff Piepmeier
“Good to confirm you found the same. It’s to do with the way the Yellowstone is sending the start of the data bitstream. It seems to have an additional transition and gap before the data starts. The firmware really should handle this, but it’s never been a problem before. Following along with the fujinet guys has helped a better understanding of whats needed. I’ll see if can attached the update here for you to try”
robj also has some info about Yellowstone and the FN (he’s using it on his AppleIII):
robj: I thought the Yellowstone would be ok with the Fujinet, but seems its not based on the comments from @ppuskari. The issue with the SmartportSD was that is was coded to expect the exact number of sync bytes before it gets the start packet 0xc3 marker. YS seemed to add an extra toggle of the read line, then some delay before it starts sending the bitstream. I updated the code to just keep reading bytes until it gets the start marker and run from there. It looks like the fujinet code is doing the same, so maybe some thing else?
obj: I have a YS here, I’ll try and test it out later today.
robj: This was what I was seeing from the YS when the SmartportSD was receiving the packet before I updated it
Here’s our packet!
0000: 80 7F FF FF FF FF C3 81 80 80 80 80 82 81 80 85 -……▒▒▒▒..▒.
0010: 82 80 80 80 80 80 80 80 80 AF EA C8 80 -.▒▒▒▒▒▒▒▒…▒…
Not our ID!
robj has SmartPort support and FujiNet booting on the AppleIII with his hacks to A3 Business Basic
robj: This has taken me a long time to battle through this, but finally some success this morning. Needs quite a bit of cleanup for my driver, i have hacked a few things just to get it going. Its using A3 Business Basic and a provided invokable module called request.inv to do the calls to the SP network device. This is quite picky on how its used, and not documented very well.
We had a nice voice chat on Sunday to talk with JeffP about his upcoming presentation. It was a relaxing change to talk instead of type everything and there are plans to do this again sooner rather than later.
jeffmazur popped in as the 7th REV0 tester and is using a IIc for his tests. He had issues with SD cards -not showing up in CONFIG- and some wifi slowness. Sandisk cards are known to work with a number of users and if in doubt a FAT32 formatted SD card is what the FujiNet wants to see. The FujiNet works with the internal IIc connected, but hasn’t been tested fully with actual floppies in the drive. For now it’s best left empty.
Quiet this week, just some discussion about Atari DOSes and densities.
Feoh came in to thank TCH for his wiki directions on getting FN to work nicely with SDX and U1MB. He’s going to update the ATRs with the current versions of the F tools that control the FujiNet from cli DOSes like SpartaDos.
Quiet here as well, sjfroos has to do real-life work for some crazy reason! But he did eke out some wins:
sjfroos: Recap: I managed to sent bytes from the ST to the esp32 but not at any huge speed.
sjfroos: 19200 bps seems like a hardware limit on the serial. Really slow compared to SIO.
idolpx was at VCD South East with a combined FujiNet / Meatloaf table. He is still working to complete the integration of Meatloaf into a Fujinet branch to combine the powers of each project.
seatsafetyswitch showed his prototype FujiNet card for the PC-8801. It’s unpopulated but it is a real board and looks like it will contain all the right FN bits to make something happen.
thweasel and That Old Nerd were joined by skonkfactory and mskelley_lscc in their continuing discussions about how to get the FujiNet to exist on the Spectrum bus, not make the computer any slower, and respect other arbitrary systems that also may be on the bus (most notably the wafer drives).
skonkfactory: I feel like we ought to try to coexist with the Interface 1 at least so that people can image their Microdrive carts
thweasel took a suggestion from mskelley_lscc and made a working decoder for testing:
thweasel: Poor mans changeable address decoder (8bit), set switches/jumpers for the address to be decoded. It works in simulation, now can I make it work on a real machine. This is a development tool, not a proposal for the Fuji 🙂
thweasel: Second simulation of the day, pair of Registers to make a bi-directional IO connection between ESP and Z80. Both ESP/Z80 can check the flip-flop states to see if a register was written/read, before they write or read.
ESP flips data from the Registers to the S-Register and releases the register for the Z80 while it drains the Shift register. This arrangement should avoid clashes between the Z80 and ESP while data is being moved slowly in and out of the shift registers.
thweasel: Yes, the register has a fixed address and wouldn’t need a WAIT signal, so no timing disruption. Given the limitations on timing with the any IO address, a none blocking method is needed. Consider it as more the primary communication method for Fuji aware software.
Another week has gone by, this one clearly has been the AppleII FujiNet week. The REV0 boards are getting people excited and with some software polish up and fix for the Yellowstone we’ll be one step closer to the public release of the retail AppleII boards for FujiNet.