TMIF – This is a catch-up edition of This Week In Fujinet- basically the monthly version. Its been a few weeks since my last round up and that is for a few reasons- vacation, summer slow down, other things intruding (work)- but that doesn’t mean things haven’t been progressing along in the FujiNet world. Some big leaps forward have been happening. Since I started this as a way to document, attribute, and note the weekly events in the FujiNet Discord to allow others interested in the project a condensed and entertaining summary– I will apply the same amount of refinement here but just over a longer window of time. This means this will be shorter than five single reports! This post covers well over an entire month of events on the Discord. There have been periods of silence as well as furious periods of activity. There are things I didn’t cover- please visit the Discord and catchup on anything you have questions about!
Week 32 – July 31 – Aug 6
Week 33 – Aug 7 – Aug 13
Week 34 – Aug 14 – Aug 20
Week 35 – Aug 21 – Aug 27
Week 36 – Aug 28 – Sep 3
Upcoming FujiNet appearances:
VCF Mid-West 17 – Sep. 10 & 11th – http://vcfmw.org/
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.
Interesting News and Links
Frank Rachel (Schadret on discord) created an amazing walkthru on how to setup a complete development environment to create, test and debug Atari apps that can use FujiNet:
The video is using Windows with the WSL, but most of these tips and techniques will work on a dedicated Linux machine as well (use Wine to run Altirra). He shows how to setup and get running the FujiNet-PC emulator which allows a complete running FujiNet on your modern PC. He shows examples with real Atari apps – modifying and building the Atari CONFIG app which is the main configuration tool for the FujiNEt on all the platforms.
Andy Diller (me) uploaded a short video showing a C64 booting from the Meatloaf/FujiNet mix. C64 is almost ready and has some cool suprises in store with it.
APC demoed loading FujiNet floppy images from SMB shares! This will allow people to use local PC’s and not have to setup TNFS servers for testing.
CityXen did a video walkthru of VCFSE – and had a clip on Meatload/Fujinet that was exhibited by idolpx
Link goes right to the ML/FN spot!
While there have been no ADAM fujinet updates save for an release of the firmware which fixes issues with the ISS Tracker — there is a major development going on in the ADAM space. There are a lot of people who are interested in creating a reproduction ADAM using modern components. The reasons for this are usually related to the expense and reliability of original ADAM system hardware. The major blocker for these types of projects is a certain custom chip that the ADAM uses called the MIOC.
@TICS_Game has been leading the effort to reverse-engineer the MIOC chip and has been doing a fascinating job at this with a tool of his own design:
Twitter – https://twitter.com/TICS_Game/status/1560295463332487172
YouTube – https://www.youtube.com/watch?v=uWv78Y8QzTI
Then ead0601 contributed with a verilog simulation of the chip on GH.
This snippet from ead0601 gives a simple, concise description of the chip:
This ASIC is used in the ADAM computer system. It is a custom timing and control ASIC. In order to source a replacement part, a CPLD version will be created from die snapshots that were taken.
dotmatrix on the Discord channel pulled the schematics and has been leading the local effort to realize the MIOC chip. dotmatrix ordered a CPLD dev and test board and has been diligently working on the MIOC conversion to a working CPLD device to help complete the ADAM clone.
Aug 27 dotmatrix announced he had completed the MICO design:
[5:47 PM] dotmatrix: MIOC is done!!! …now a shit load of testing…once I have it in place, I will post on how to add a test and simulate…would be neat to resolve board issues if they should ever arise….in theory we could now have a model of ADAM in verilog (would need to create models for everything else) or Z80 verilog code….and models for memory. We should be able to extend this to a system wide simulation…
seatsafetyswitch: CPLD is no problem for me, as long as we can source it. XC9572 seems really popular for 5V
sss has built his own colecoVision clone and is interested in expanding that work to become an ADAM clone. It has been the MIOC which has blocked those efforts up till now…
sss has mocked in a MIOC socket and released that on his GH pages, sss and dotmatrix continue their collaboration and the possibility of a ADAM clone (like an Amiga MiniMig) draw closer week by week.
Meanwhile Moz has been completing the sound enhancer card for ADAM and will have them available by VCFMW (next week as of this writing). They will be available here on the FN Store:
The developments in the A2 platform has been around the SPI implementation. Work being done by Jeff Piepmeier in stomping out the remaining issues with sustained writing to SP drives on FujiNet. He has embraced SPI and has been working on moving all his bit-banging code into the ESP32’s SPI high-level framework but doing it fast enough for the FujiNet to stay in sync on the SmartPort bus is the trick.
Aug 28th – Jeff Piepmeier: PROOF OF CONCEPT – successful bus RESET and INIT sequence (can get it about 1 out of 5 times right now):
Jeff Piepmeier: Almost successful. I think there’s a device 85 that didn’t make it this round.
But … this gives me hope we can make this work. The key was to start decoding (see bottom traces for the EXTRA diagnostic signal showing decoding work) while the SPI is still receiving, but not to start too soon so the SPI has a chance to start filling up the buffer. I hardcoded the timing so decoding would finish about just in time to catch the 0xc8 end of packet code and ACK soon enough.
Jeff Piepmeier: about 42us between the last edge of the command packet and the ACK … that’s got lots of margin against the 120 us requirement.
Leading up to this breakthru….
robj, mozzwald, ppuskari and jeffp spent many weeks going over the SPI code, task priorities on the ESP32, pinning code to cores, understanding critical code in the ESP32 and finally testing to expose the details of the issue and nail down stabilizing sustained read/writes on the FujiNet.
Examples from early August:
ppuskari: I’m done for the night until I get the logic analyzer hooked back up and looking at that extra line and see what’s going on. It failed writing on both SD and TNFS on PRODOS and HFS volumes regardless. Got slightly better with much longer cabling like 4 feet! but still will timeout and eventually throw the disappearing drive thing. READS seem to be good. So is there a way to implement whatever we did for reads but on writes as well?
ppuskari: Almost ripping hair out in frustration. It seems that it depends GREATLY on whether you build with debug or release and whether you turn on different logging levels and options or not whether the fujinet will mostly work or not work at all on the Rom 3 IIGS and even the Rom 1. So far on the IIgs Rom 01, Release mode with Dbug2 and Extra enabled seems to be the most solid. On the Rom 3 it is hit or miss but mostly everything has to be turned off and not connected to the usb side too for it it work. I did notice that with the TWGS installed in the rom 3 things didn’t work as easy too. So will try this again on rom 3 when I remove teh TWGS later tonight. LA being brought back out asap. ugh
JeffP is taking a break for the holiday weekend but is committed to coming back strong and finishing this for the Apple II…
Jeff Piepmeier: it helped when i changed my read packet call to the SPI version – oops… can now navigate CONFIG. oh, i need to make the SPI buffer bigger to receive an entire block
I started a new platform project! I’m interested in getting the FujiNet working on Compact, pre-scsi Macintosh running system 4/5/6. These are interesting machines and even though they have large amounts of RAM and fast CPUs compared to the 8bits they still suffer from the same issues- lots of software available for them but mechanical floppy issues and lack of modern networking make using them extremely difficult. Fujinet would greatly complement a Mac and as a bonus I won’t have to do a lot of the hard stuff as they already have a SmartPort available on a 19pin floppy port!
I have been working on the software side and starting to design a write a CONFIG for the Mac using ThinkC and MacSE that I already have setup.
The Mac will at least do a RESET on the SP buss and I’m hoping to get some more time from JeffP once he’s finished his SPI work on the codebase. Hopefully we can tweak it to support some Mac timing and get the FujiNet quickly supported on the earliest Macs.
It has been slow here, as Atari just works. Moz has released an update to the firmware to fix issues with FujiNews. Updating your FN is recommended…
sjfroos has added a CF reader to his FujiNet prototype.
The big news here is that idolpx has been pushing his Meatloaf mix into the FujiNet space and creating a mashup. His ML/FN build works now with the AppleII REV0 board and I created a short video showing a DigDug boot up on my C64:
idolpx: If you wanna list all of the games that are available for random load with “ML:GAME*” you can LOAD”ML:GAME$”,8
idolpx: to load a specific one just LOAD”ML:?????”,8,1 but specify the first part of the name of any of them or the whole name if you want. and it will load it.
TechTip- to get C64 to do lowercase old shift and tap the C= key. Now you get lowercase. Everywhere.
At the end of August idolpx reported:
idolpx: I’m getting close to having the parallel transfer stuff completed. 😃 Also reworking some of the stream buffer code. It’s starting to shape up.
idolpx will be at VCFMW along with other discord peeps – abzman, moz, myself and others.
FujiNet X86 ARM
While I use the name of the Discord channel (or close to it) for these sections I’ve always felt like this platform is misnamed. To me this amazing project from @apc should be called “FujiNet Emulator” because that is what it really is. It’s about running the FujiNet in x86 to work with a local 8bit emulation (Atari for now via Altirra). This is a special project in that it does not use a physical FujiNet. APC calls the project FujiNet-PC, which IMHO still does not do it justice for the wizardry at work here.
APC has released a new FujiNet-PC Launcher which contains a whole bunch of new re-factored goodness for the whole Fujinet-PC project. The Launcher is the entire suite of software packaged up and installed automatically for you. It should be your first choice if you are just starting this for the first time.
FujiNet-PC Launcher 2208.1
The FujiNet-PC project allows people to participate 100% in the project without buying one device or even owning a supported 8bit!
Schadret (github: frachel): Agree! [about how amazing this is] I wouldn’t have been able to do anything without it since I don’t have a working Atari 8 bit yet!
A new channel was created by TCH for the TI family. It has some links to various points in the FN ecosystem for where you’d start to tie in a new platform. The user @electriclab is there and has a working C-based toolchain to create running code on a TI. I’m pretty sure this project will go faster once the FujiNet Parallel Bus is completed by the ZX Speccy team!
Work simmers in the background on this, the usual suspects @thweasel and @thisoldnerd collaborating on the design.
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.
thweasel: 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.
Next steps may include trying to build a hardware simulation of this work in simullDE – which already has a Arduino core in it.
Another new platform channel was created by TCH as he has been working on restoring and bootstrapping a flotilla of GRiDs that he fell into. Most of the work here revolves around the specific GRiD peripheral modules, but the most interesting work resulting from the GRiDs happened in…
A major development here, TCH has written some DOS device drivers to support the FujiNet and with MOZ’s help has a prototype DOS FujiNet board being built.
In just the last week:
Thom Cherryhomes: but the goal is to provide two drivers:
(1) FUJIDISK.SYS for mounting disk images as block devices.
(2) FUJINET.SYS for providing the network driver as a character device.
Thom Cherryhomes: Rationale for the first pass of the PC design:
It uses RS-232. It will use INT 14H. It will be slower than dirt- but it will be a path to figuring out just how integrated we can make an MS-DOS based solution. it will take over the COM port, and will use the same basic technique that we’re using for all the other serial devices to communicate using a 5 byte command frame, followed by payload and acknowledgement/error just like the Atari SIO version. hopefully the CTS and RTS pins can be used together to provide enough of an interrupt interface to be able to deal with traffic.
Once IEEE-488 is figured out, a parallel port interface could potentially be figured out. (This is actually a bit of a bitch, because the only method that works with all PC parallel ports is literally to split the data and status registers, facilitating 4-bit nibble oriented transfers. You need a PS/2 machine to be able to do bi-directional transfers, and EPP (IEEE-1284 didn’t happen until the late 90s)
We’ll see what happens.
[edited to combine sentences from Discord]
TCH reports his code seems to be working and is checked into the FN master repo. Now we just wait for the first batch of boards to land back with Moz.
Ok, now we have caught back up to the ongoing work on FujiNet. It’s been a hot month for many in the US and while that may have caused a fall off in collaborative work it did allow for needed break for some and a time to regroup and sort out issues in solitude. It continues to be a fascinating and wildly collaborative effort with people from all over pitching in where and when they can. While there are many detractors of communities built around Discord I don’t think what we’ve done here with the FujiNet would be possible with other sililar platforms (Slack – too high a barrier, no reply; irc – not enough media support and async messages, hard to setup for many). Discord, for all its warts is a highly enabling technology platform that is accelerating the pace of development for the FujiNet.
Next weeks TWIF should be back to regular schedule, and I’ll be at VCF MW and have some in-person updates from the show.