FujiNet on the 1090XL Expansion System?

[reifsnyderb]

Are any FujiNet developers interested in working together to create a FujiNet board for the 1090XL expansion system?  Thus far, we've got the ability to add memory, 80 columns, the CX85 numeric keypad, and other firmware changes on the 1090XL.  Having a 1090 FujiNet card would be really cool and would take it off of the SIO.  I am willing to work with any developers as far as board design and sharing my knowledge of the 1090XL expansion system is concerned.  All Fujinet 1090XL boards would be open source, of course.

 

Here's the parallel port document I've been working on that describes the functionality and capabilities of the parallel port and 1090XL:

Parallel Port Guide v0_92.pdf

 

Here's a link to the thread on the 1090XL:

 

https://forums.atariage.com/topic/318373-1090xl-remake/

 

 

[tschak909]

Just now, reifsnyderb said:

Are any FujiNet developers interested in working together to create a FujiNet board for the 1090XL expansion system?  Thus far, we've got the ability to add memory, 80 columns, the CX85 numeric keypad, and other firmware changes on the 1090XL.  Having a 1090 FujiNet card would be really cool and would take it off of the SIO.  I am willing to work with any developers as far as board design and sharing my knowledge of the 1090XL expansion system is concerned.  All Fujinet 1090XL boards would be open source, of course.

 

Here's the parallel port document I've been working on that describes the functionality and capabilities of the parallel port and 1090XL:

Parallel Port Guide v0_92.pdf 288.49 kB · 0 downloads

 

Here's a link to the thread on the 1090XL:

 

https://forums.atariage.com/topic/318373-1090xl-remake/

 

 

The ESP32 needs a generic 8-bit bus interface, for this to work.

 

The ZX-Spectrum team in our Discord is working on such a circuit, and they've lifted it from successful simulation to a breadboard. So it's coming.

 

But basically, once a workable interface is worked out, a PBI ROM that exposes the sub-devices will also be needed. @flashjazzcat would be indispensable here. 

 

Then a workable PBI version of #FujiNet could be done.

 

For reference:

 

Hardware: https://github.com/FujiNetWIFI/fujinet-hardware

Firmware: https://github.com/FujiNetWIFI/fujinet-platformio

 

-Thom

[flashjazzcat]

4 hours ago, tschak909 said:

@flashjazzcat would be indispensable here. 

At last!

[reifsnyderb]

I joined the Discord for FujiNet.  It appears that testing of the ZX-Spectrum will happen soon.   🙂

 

[+x=usr(1536)]

Would it be possible to consolidate other upgrades onto a potential FujiNet card?

 

While there's nothing wrong with having its functionality on the PBI, it would be something of a zero-gain proposition in terms of port usage since it's only trading SIO (which it can pass through anyway) for PBI.  Either way, a port or slot is in use.

 

But if the FujiNet card could also provide other functionality, that would make it more compelling for a 1090 installation.  Something along the lines of having its SD card be shared as a PBI-attached HDD, or SIDE3 support, perhaps?  More RAM?

 

I'm not suggesting that it turn into a jack-of-all-trades, master-of-none card, but it does seem as though the idea's at least worth considering.

[_The Doctor__]

pbi will only make FujiNet Faster and could still have a SIO cord so disk images are happier, but we also have a chance to have or use TONG drive board firmware/hardware to do PSIO maybe. Let's face it BugiNet needs all the help it can get, it's spread to other platforms and has struggles trying to be all things on all platforms causing it no end of schizophrenic episodes. No doubt one day it will all come together, I'd love to see it evolve from jack of sort of some trades master of none- to Master of all things. At this point I think the AVGcart project might be more nimble and fast approaching blowing most other items away wholesale. FujiNet SAM and WIFI are about all that's mainly working afais. Nice networking toy atm.

[reifsnyderb]

1 hour ago, x=usr(1536) said:

Would it be possible to consolidate other upgrades onto a potential FujiNet card?

 

While there's nothing wrong with having its functionality on the PBI, it would be something of a zero-gain proposition in terms of port usage since it's only trading SIO (which it can pass through anyway) for PBI.  Either way, a port or slot is in use.

 

But if the FujiNet card could also provide other functionality, that would make it more compelling for a 1090 installation.  Something along the lines of having its SD card be shared as a PBI-attached HDD, or SIDE3 support, perhaps?  More RAM?

 

I'm not suggesting that it turn into a jack-of-all-trades, master-of-none card, but it does seem as though the idea's at least worth considering.

I am not sure.  It really all depends on what's required for a PBI Fujinet card.  Looking at the pictures, on Discord, even a PBI FujiNet card may be pretty large without CPLDs.  Until CPLDs are readily available, PLCs and 74xxx glue logic is the way to go to make it happen now.

 

My thought is that taking something off of the SIO port is a good thing.  Going from Atari's proprietary, and hard to source, SIO connector to a simple card edge is a bonus.  Also, having an extended 1090 main board with 8 slots is quite possible.  (I think, and am guessing, the 5 slot limitation was current based.  Given the lower current requirements of newer chips, I think 8 slots would be easy.)

 

[+x=usr(1536)]

20 minutes ago, reifsnyderb said:

I am not sure.  It really all depends on what's required for a PBI Fujinet card.  Looking at the pictures, on Discord, even a PBI FujiNet card may be pretty large without CPLDs.  Until CPLDs are readily available, PLCs and 74xxx glue logic is the way to go to make it happen now.

Those are good points, and ones that hadn't come to mind before I asked my question.  Appreciate the answer.

21 minutes ago, reifsnyderb said:

My thought is that taking something off of the SIO port is a good thing.  Going from Atari's proprietary, and hard to source, SIO connector to a simple card edge is a bonus.  Also, having an extended 1090 main board with 8 slots is quite possible.  (I think, and am guessing, the 5 slot limitation was current based.  Given the lower current requirements of newer chips, I think 8 slots would be easy.)

All of which I agree with.  The perspective I was thinking from was more along the lines of, 'well, since there's this extra space on the card...,' but the CPLD situation pretty much nixes that.

 

All of that notwithstanding, you'll find no argument from me for 8 slots vs. 5 

[Mathy]

Hello guys

 

Size shouldn't matter much during development (although it would be nice if you can still see the screen during development ...   ).

 

FujiNet on the 1090 would mean that the case either shouldn't consist of metal (as in Faraday's cage)  or should have an external antenna.  But an (working) ethernet connector would work too.

 

Sincerely

 

Mathy

 

Edited April 20, 2023 by Mathy

[+x=usr(1536)]

2 hours ago, Mathy said:

FujiNet on the 1090 would mean that the case either shouldn't consist of metal (as in Faraday's cage)  or should have an external antenna.  But an (working) ethernet connector would work too.

Why not both? 

 

Putting an SMA connector or similar on the card's outward-facing side should be fairly straightforward - and there would be room on the same plane for an RJ-45 jack...

[tschak909]

11 minutes ago, x=usr(1536) said:

Why not both? 

 

Putting an SMA connector or similar on the card's outward-facing side should be fairly straightforward - and there would be room on the same plane for an RJ-45 jack...

You guys are doing this all out of order. sigh. I really want to say so much here, but I'll come off like an arsehole, so I'll just bite my lip for most of it. 

 

I will say, The bus interface will let you know HOW many pins you have to work with, and thus whether you'll actually have enough to put e.g. a PHY on the back.

 

-Thom

[reifsnyderb]

On 4/20/2023 at 10:45 PM, tschak909 said:

You guys are doing this all out of order. sigh. I really want to say so much here, but I'll come off like an arsehole, so I'll just bite my lip for most of it. 

 

I will say, The bus interface will let you know HOW many pins you have to work with, and thus whether you'll actually have enough to put e.g. a PHY on the back.

 

-Thom

Are there any schematics available for the zx-spectrum FujiNet yet?  I didn't see anything on GitHub...

[tschak909]

3 minutes ago, reifsnyderb said:

Are there any schematics available for the zx-spectrum FujiNet yet?  I didn't see anything on GitHub...

Not yet, but the schematic is coming together in the FujiNet discord, channel #zx-spectrum:

https://discord.gg/7MfFTvD

 

I have asked them to pin the current set of schematics to the channel.

-Thom

 

[+mytek]

On 4/20/2023 at 11:01 AM, reifsnyderb said:

Until CPLDs are readily available, PLCs and 74xxx glue logic is the way to go to make it happen now.

Atmel ATF1502AS is available in a PLCC-44 package, is 5v tolerant and will run from a 5v supply. Microchip has over 2,000 of them (Digi-key also has stock). JTAG programmable.

[AtariGeezer]

On 4/20/2023 at 10:28 AM, _The Doctor__ said:

Nice networking toy atm.

Yep, I get the impression from David Murray "The 8-Bit Guy" that he feels disappointed that fujinet isn't as robust of a device than it is.

Especially after donating a Commander X-16 and getting a toy in return...

[+DjayBee]

1 hour ago, AtariGeezer said:

Yep, I get the impression from David Murray "The 8-Bit Guy" that he feels disappointed that fujinet isn't as robust of a device than it is.

Especially after donating a Commander X-16 and getting a toy in return...

If you follow the Discord, you will get a very different perspective. 

The X-16 has several hardware (dunno how to say this correct) problems/quirks/weirdnesses which drove Thom close to crazy because nothing works well enough to lead to a usable solution. 

[tschak909]

1 hour ago, AtariGeezer said:

Yep, I get the impression from David Murray "The 8-Bit Guy" that he feels disappointed that fujinet isn't as robust of a device than it is.

Especially after donating a Commander X-16 and getting a toy in return...

Let's set some things _VERY_ straight:

He did not donate a development board. He loaned one (of less than 20 out there right now).   I gave it back to him, this Saturday, for reasons I will detail below.

 

Initially, he had asked that I implement using the I2C bus, to which I obliged. In the process, I exposed bugs in the I2C implementation that crop up when lots of packets get sent from the computer. (The whole implementation is bit-banged).

 

I had also asked for kernel code to be added to make usage of the FujiNet easier for users, which was denied on account of having insufficient space in the KERNAL bank, for it. It would have been extremely difficult to use for users, much less any developers, which really goes against our philosophy. So it was shelved.

 

Meanwhile, work had already been ongoing with the IEC bus implementation, thanks to @idolpx's MeatLoaf project. I was able to pivot, and get something working well enough to demonstrate that the IEC bus could be used on the X16, as well as the Commodore 64, and Plus 4 (still don't have a VIC-20 to test).

 

In the process, we uncovered a number of flaws in our IEC bus implementation, that we've been working through and fixing, and on the X16 it was discovered, that the resistors attached to the CLOCK and DATA lines on the IEC were borrowed from the VIC-20 schematic (Kevin's admission), without taking into account that they were attached to CMOS parts, causing issues with devices connected to the IEC, which necessitate a board fix.

 

Most of the X16 users don't run into this, because they aren't plugging in their 1541's to their X16, they're using the card slot, or more accurately, they're using the filesystem interface exposed by the available emulator.

 

So when David said there was another hardware peripheral developer who needed the dev board, I obliged, and agreed to return the board to him the next day at the DFW Retro meet-up. I let him know what was happening, and he said, "oh, then maybe you should keep the board?" to which I replied, "it's okay. We'll resolve the timing issues on our end, you guys can modify the board with the proper resistors, and we can meet back in the middle soon." I figured it was the most diplomatic solution given the situation.

 

(as an aside, he did offer compensation for developing the FujiNet implementation for the X16, I explicitly declined the offer, and thanked him.)

 

Quote

FujiNet SAM and WIFI are about all that's mainly working afais. Nice networking toy atm.

@_The Doctor__ That is an unbelievable insult to the almost 5,000 FujiNet units out there in use. What have you actually attempted to use? What have you asked for help on? You have carried on with this rhetoric, ever since we announced we were branching onto different platforms.

 

-Thom

 

Edited April 25, 2023 by tschak909

[_The Doctor__]

No it's not an insult to 5,000 inanimate objects, and it's a pretty good picture of the current state of things.

 By your reasoning is it an insult to all the cars that get recalled due to problems or defects in their firmware and or other issues as well?

 

Just because you've sold X of a thing doesn't make it something more in any way... They sold millions of robotictwist jar openers and they all open a couple of jars/bottle just fine before they have issues. Long term use reveals it's got issues.

 

My experience has been that if you seriously try to use it, SAM and WIFI work well enough, and it's a network toy. It hasn't reliably done anything else for me or others when used longer term doing lots of work, If we want to load a game or something for quick use sure it's mostly fine. That's the truth of it. You know that.

 

I am sure it will get there one day, however mostly working but not completely working over time seems to sum up most of what's offered. If anyone gets to seriously talking about the issues they get the IT guy answer and maybe they should code and fix it.

 

Midi Maze fails after some time of trying to play a networked game, file operations and slots fail if you seriously try to use it for more than a few iterations of anything, folks can probably peruse the many threads were this issue or that gets mentioned and the list will continue to grow. I have tried to wrestle with the thing more than once over time and have given them away... currently I also try to remotely deal with issues that crop up trying to run a BBS with it. I went back to a Lantronix in my endeavors, but my buddy still is trying to use one for his, the results are not very good... trying to serve filebase from TNSF through FujiNet is a fail... but they can always TNFS to get some things mostly. Storing files on the SD card and swapping disks around doesn't end well. The BBS is better off using the SIDE, IDE, MIO, or BlackBox for almost any of that at them moment.

 

It is a great Networking toy at the moment and it's fun to use the Atari with a network server or some of the APPs that folks have made to interface with stuff on the internet. Sam is very nice. take the compliments for what appears to work well... and accept that many other parts only partially work, and you are well aware of it. Ignoring all of that and going on to support this that the other thing or platform isn't helping anything IMHO unless someone figures what the fixes are from that greater resource pool. That hasn't happened yet. I am happy to see others have worked to make the FujiNet and Bridge for Emulation and other fixes/ innovations from that, real progress. I understand some people like to just keep moving on to the next thing the next thing the next, and it all sort of works. If that honest look is bothersome, only you appear insulted, none of the owners or devices that I know of are capable of being insulted as they didn't do it, and inanimate objects don't have feelings. You don't want the slightest report of issues, and people constantly tell you of them and then apologize for doing so. That's very strange that they feel the need to apologize like that and it speaks to much that it is that way.

Edited April 25, 2023 by _The Doctor__

[reifsnyderb]

I've been watching the ZX-Spectrum FujiNet for months.  It's clear there is no ETA at all on this.

 

How about converting a serial FujiNet to work on a 1090 card?

[tschak909]

18 minutes ago, reifsnyderb said:

I've been watching the ZX-Spectrum FujiNet for months.  It's clear there is no ETA at all on this.

 

How about converting a serial FujiNet to work on a 1090 card?

If you can find a way, go for it.

-Thom

[reifsnyderb]

2 minutes ago, tschak909 said:

If you can find a way, go for it.

-Thom

Converting a serial device to work on a 1090 card is, conceptually, rather simple.  It's how I got the XEP-80 Raspberry Pi Pico to work on a 1090 card.  Part of the serial component gets swapped with a single bit in an address on the 1090 card.  i.e.  Use $D1C9, bit 0, for serial communication between the computer and the 1090 card.  So only the serial communication code needs to be changed.

 

From your response, would I be correct in believing there is no interest in doing this?

[massiverobot]

14 minutes ago, reifsnyderb said:

Converting a serial device to work on a 1090 card is, conceptually, rather simple.  It's how I got the XEP-80 Raspberry Pi Pico to work on a 1090 card.  Part of the serial component gets swapped with a single bit in an address on the 1090 card.  i.e.  Use $D1C9, bit 0, for serial communication between the computer and the 1090 card.  So only the serial communication code needs to be changed.

 

From your response, would I be correct in believing there is no interest in doing this?

 

From what I read you have interest (and probably others as well) and you seem to have the knowledge. I think Tom is inviting you to try doing it. The FujiNet project works by people contributing, and then iterating, on new features and devices.

 

[tschak909]

30 minutes ago, reifsnyderb said:

Converting a serial device to work on a 1090 card is, conceptually, rather simple.  It's how I got the XEP-80 Raspberry Pi Pico to work on a 1090 card.  Part of the serial component gets swapped with a single bit in an address on the 1090 card.  i.e.  Use $D1C9, bit 0, for serial communication between the computer and the 1090 card.  So only the serial communication code needs to be changed.

 

From your response, would I be correct in believing there is no interest in doing this?

As @massiverobot said, we are a public project, come in, and work on it. We'll help where we can.

 

-Thom

[reifsnyderb]

15 minutes ago, massiverobot said:

 

From what I read you have interest (and probably others as well) and you seem to have the knowledge. I think Tom is inviting you to try doing it. The FujiNet project works by people contributing, and then iterating, on new features and devices.

 

I think that, given the popularity of FujiNet, that a 1090 card would be a great addition.  From a hardware standpoint, it would be nothing more than just plugging a card into the 1090XL.  The 1090XL card could even supply any firmware.  There would no longer be a requirement for the proprietary SIO connector, either.

 

I fully understand that the FujiNet project is open source and have written open source code myself.  (At one time, I was writing code for the FreeDOS project and wrote the Free FDISK program.)  However, I have zero experience with the FujiNet source code.  Presently, it would probably take me at least 6 months to get a development environment up and running, figure out the FujiNet source code to the point of being able to modify it, test it, etc., etc., etc.  On the other hand, I already have a Raspberry Pi Pico 1090 card developed that should work the first time.  It would be easy to convert it to use the ESP32 and I'd be willing to open-source that 1090 card.  It would be a win-win.  Instead, I get the feeling that the attitude is that if I want to do it, I am completely on my own.

[tschak909]

You seem to be finding every excuse not to do it.

 

Again.

 

Listen to what we're saying:

 

Come by the discord, https://discord.gg/2Ce9guX Let's talk in #Atari8bit.

We exist as a group, and yes, we're all working on our bits, but we are all there to share our knowledge and expertise, and this includes dealing with the codebase. Of which, there is documentation on how to set up the build environment and get running.

 

And yes, if you want a feature, you're the owner of it. you drive it forward. But we are there to help.

 

-Thom