#FujiNet Hardware Discussion

[Mr Robot]

Most terminal programs have a phone book built in. I was going to add a bunch of good BBS's to them on the comms disks on my TNFS server but when I asked for some good BBS's I got no answers so I didn't bother. 

 

 

[+DrVenkman]

This is really off-topic since it's not hardware-related, but there's this thread stickied to the top of the forum. Of course it's 75 pages long now. It would be much more useful if it was just a single stickied post that is updated once a month or whenever someone has a change to report.

 

https://atariage.com/forums/topic/174831-atari-8-bit-related-bbss/

[Fred Olivas]

On 10/21/2020 at 5:40 AM, Mr Robot said:

on the terminal screen, type AT and hit return

if it replies OK you are in the right place

type ATDTbbs.fozztexx.com and hit return

This has been quite helpful however after I get online the BobTerm program states NO CARRIER and drops me. I'm sure it's just a setting on the terminal program I'm missing.  Any help would be appreciated.  Question: Do I set Atari, Ascii or what?

 

 

 

[Mr Robot]

On 10/3/2020 at 3:51 PM, mozzwald said:

I've finally got a 'working' prototype built using 2 sn74ls07 buffers to separate the FujiNet from the Atari. The buffer chips are only powered when FujiNet is ON by using some transistors and this fixes the back power issue.

 

 

I unfortunately have a new issue with this setup. The FujiNet alone on the SIO bus works great, but when I connect another drive there is some questionable boot sounds. Also, I've noticed this on the v1.1 boards I made with the 2 line buffer. Any ideas what is happening here

Is there any reason you can't use a switch, something like this https://www.digikey.com/en/products/detail/renesas-electronics-america-inc/QS4A110QG/1916077 to just disconnect the fujinet from the SIO lines? Just thinking out loud

 

 

 

[+mytek]

I was having a private discussion with Mr Robot about the following, and thought it might be good to share this idea over here.

 

Topic: SIO noise issue when FujiNet switched off booting.

 

What about disconnecting the analog connection to the SIO Audio-Input with an analog switch such as the CD4066 (or better yet the newer 74HC4066). These bi-directional switches will pass either analog or digital information. When the CTRL input is high, the analog switch will be closed. Think of it like a relay.

 

Since there are 4 switches in the 74HC4066 package, the other 3 might be useful for something as well (substitute for individual gate in 74LS07) . Here's an example as to how that might be applied.

 

 

Still one left over analog switch ? .

 

EDIT: I stand corrected, apparently the strange high pitched noise occurs when FujiNet is powered ON and booting a device. So in that case maybe the audio going to the SIO audio input can be disconnected during this booting state instead of when it's powered off, as I showed it above.

 

EDIT2: The 74HCT4066 might be a better choice when the CTRL signal is less than 5V. Also another interesting variant would be the 74HCT4053 which has 3 x SPDT switches instead. And last but not least, two 4066 chips could be used to simply disconnect everything between FujiNet and the SIO as Mr Robot was suggesting, by using them as parallel connected switches (you would want pull-ups on the FujiNet side). Additional note - the switch IC that Mr Robot linked to would also work quite well and is capable of both digital and analog switching, but is a considerably more expensive chip due to its extremely high speed signal spec which would not be required for SIO.

 

[+mytek]

I did a bit more thinking about SIO isolation and came up with this as a possibility...

 

This by far would be the simplest and cheapest solution ($0.78 for two 74HCT4066 chips), but wouldn't work out of the box for the present FujiNet design, since it requires inverted SIO data from FujiNet. Although that would be a fairly simple firmware change, it would break compatibility with older version hardware. You'll notice that it also gets rid of the diode in series with the DATA-IN line, since that would no longer be required.

 

[+mytek]

I promise this will be my last one for a while.

 

In this proposal no inversion of the SIO data is required, thus allowing the firmware to maintain compatibility with the old and new hardware. Although I believe the isolation will be better in the previous diagram with less tendency to back feed when FujiNet is off. However not having a real circuit setup to test, this one might be perfectly good as well. It does require an enable, although that could be done by using the FujiNet power as the gating signal. If the switch enable is handled by an IO pin, then the diode could be eliminated - in fact that may be preferred so that FujiNet SIO coms are only present when needed in order to avoid all conflicts.

 

[Dinadan67]

I got my #Fujinet from the brewing academy today. It works fine out of the box. But as you can see on the photo, on my expanded 800XL (thanks FlashJazzCat!) the PS/2-Sockets are above the SIO-Port, so i can't use my external keyboard with the #Fujinet attached directly to the computer. I tried to solve that by putting the #Fujinet on my SIO-Splitter, but despite the red LEDs on the splitter indicate SIO-access, and the white LED on the #Fujinet glows, the computer won't boot. Any idea?

[tschak909]

14 minutes ago, Dinadan67 said:

I got my #Fujinet from the brewing academy today. It works fine out of the box. But as you can see on the photo, on my expanded 800XL (thanks FlashJazzCat!) the PS/2-Sockets are above the SIO-Port, so i can't use my external keyboard with the #Fujinet attached directly to the computer. I tried to solve that by putting the #Fujinet on my SIO-Splitter, but despite the red LEDs on the splitter indicate SIO-access, and the white LED on the #Fujinet glows, the computer won't boot. Any idea?

Try connecting the cable to the other end of the FujiNet, and plugging cable into the Atari? The connectors are essentially pass-through.

[Mathy]

Hello dinadan

 

Try plugging the FujiNet into the second SIO connector on for instance a 1050 or a 1010.

 

Sincerely

 

Mathy

 

PS something tells me Thom's methode of plugging the cable into the connector on the other side won't work.  If I'm not mistaken, the upper left pin would become the upper right pin, etc.

 

Edited October 26, 2020 by Mathy

[Gavin1968]

I was told there is a known issue with using it with the splitter, perhaps I read that wrong, but I could have sworn @mozzwald said it would not work.

[Dinadan67]

The direct connection by plugging the cable in the rear port of the #FujiNet works, thanks!

[+ZuluGula]

I would like to know if the issue is with the splitter or with with the #FujiNet? There was similar question asked on another Atari forum, and the answer was that #FujiNet will work fine when connected to splitter in Atari disk drive (CA2001 to be exact). 

[Dropcheck]

On 10/23/2020 at 2:12 PM, mytek said:

I promise this will be my last one for a while.

 

In this proposal no inversion of the SIO data is required, thus allowing the firmware to maintain compatibility with the old and new hardware. Although I believe the isolation will be better in the previous diagram with less tendency to back feed when FujiNet is off. However not having a real circuit setup to test, this one might be perfectly good as well. It does require an enable, although that could be done by using the FujiNet power as the gating signal. If the switch enable is handled by an IO pin, then the diode could be eliminated - in fact that may be preferred so that FujiNet SIO coms are only present when needed in order to avoid all conflicts.

 

I see connection for the Audio, but not for Mtrl_Ctrl.  On the original schematic Audio is not run through the RN, but the Mtrl_Ctrl signal is.  Is that a mistake, a senior moment?

[manterola]

My understanding of the splitter is that the first connector is for the Atari computer. So it should go there. Now given the shape of FujiNet, the only other option is connecting the FujiNet to the last port (#4), blocking all other ports, except the one that goes to the Atari. Like in the picture. 

Another option is using a standard SIO cable to connect on side to the "back port" of the FujiNet and the other side direct to the Atari computer (or to the splitter) 

 

[Dinadan67]

45 minutes ago, Dinadan67 said:

The direct connection by plugging the cable in the rear port of the #FujiNet works, thanks!

correction: i am able to boot of the device by directly plugging a SIO-cable in the rear port of my FujiNet, but it behaves not reliable. The connection freezes randomly while accessing directories or loading programs.

[Teapot]

On 10/23/2020 at 12:12 PM, mytek said:

I promise this will be my last one for a while.

 

In this proposal no inversion of the SIO data is required, thus allowing the firmware to maintain compatibility with the old and new hardware. Although I believe the isolation will be better in the previous diagram with less tendency to back feed when FujiNet is off. However not having a real circuit setup to test, this one might be perfectly good as well. It does require an enable, although that could be done by using the FujiNet power as the gating signal. If the switch enable is handled by an IO pin, then the diode could be eliminated - in fact that may be preferred so that FujiNet SIO coms are only present when needed in order to avoid all conflicts.

 

If the 4066's get power even when FujiNet is switched off you could add a pull-down resistor to the enable line and have everything disconnected by default.

[+mytek]

4 hours ago, Dropcheck said:

I see connection for the Audio, but not for Mtrl_Ctrl.  On the original schematic Audio is not run through the RN, but the Mtrl_Ctrl signal is.  Is that a mistake, a senior moment?

I left off motor control because I assumed (maybe incorrectly) that it wouldn't require disconnection from FujiNet. It's an open collector PNP transistor output.on the Atari side. Only chance of back feeding FujiNet would be if it were switched ON. Since nothing is actually requiring current from that output in FujiNet, a high resistance serially connected resistor would certainly suppress any back feed.

 

[+mytek]

4 hours ago, Teapot said:

If the 4066's get power even when FujiNet is switched off you could add a pull-down resistor to the enable line and have everything disconnected by default.

Yes something like a 4.7 k would do the trick, assuming that enable was connected to FujiNet switched power.

 

[Teapot]

2 hours ago, mytek said:

Yes something like a 4.7 k would do the trick, assuming that enable was connected to FujiNet switched power.

 

It would also be useful if it was connected to an ESP-32 pin as it would establish a disconnect state while the processor is booting.

[Dropcheck]

Would this one chip solution work?  The 3.3v power to the ESP32 is already switched on/off.  With the R1 resistor holding the OE pin in a low state until the 3.3v is high enough and stable, the outputs are held in a high Z state, effectively disconnecting the ESP32 from the SIO bus. 

 

[+mytek]

1 hour ago, Dropcheck said:

Would this one chip solution work?  The 3.3v power to the ESP32 is already switched on/off.  With the R1 resistor holding the OE pin in a low state until the 3.3v is high enough and stable, the outputs are held in a high Z state, effectively disconnecting the ESP32 from the SIO bus. 

 

That looks like a very good solution, and eliminates the need for the inline resistors due to the voltage level translation. Also the price is very reasonable at close to $1. Good find.

 

[Teapot]

14 hours ago, Dropcheck said:

Would this one chip solution work?  The 3.3v power to the ESP32 is already switched on/off.  With the R1 resistor holding the OE pin in a low state until the 3.3v is high enough and stable, the outputs are held in a high Z state, effectively disconnecting the ESP32 from the SIO bus. 

 

That looks like a better option to handle the bus.  But are SIO signals TTL?  The data sheet for the TXS0108 says high-level inputs must be >= Vcc - 0.4 for each side.

 

Does the audio line need to have the same Hi-Z ability?  My long memory is that any audio capable device I ever plugged in (e.g. 410, Alien Voice Box) was always the dead end of the chain so there couldn't be two devices trying to drive the line.  But with the pass-through any of those could now share the line with the FujiNet.

 

And does the audio line need to have level conversion?  I looked at the FN1.0 schematic and there's a resistor on that line but wouldn't that make the signal even lower than 3.3V?  Or is the audio signal always lower?  It's a detail I don't know.

[Dropcheck]

11 hours ago, Teapot said:

That looks like a better option to handle the bus.  But are SIO signals TTL?  The data sheet for the TXS0108 says high-level inputs must be >= Vcc - 0.4 for each side.

 

Does the audio line need to have the same Hi-Z ability?  My long memory is that any audio capable device I ever plugged in (e.g. 410, Alien Voice Box) was always the dead end of the chain so there couldn't be two devices trying to drive the line.  But with the pass-through any of those could now share the line with the FujiNet.

 

And does the audio line need to have level conversion?  I looked at the FN1.0 schematic and there's a resistor on that line but wouldn't that make the signal even lower than 3.3V?  Or is the audio signal always lower?  It's a detail I don't know.

TTL is a logic level family, usually used to describe most older chip families even if they have a SMT as well as a DIP/SIP footprint.  The Atari line of computers are most definitely in that logic family as are almost all chips powered by 5V.    'A TTL input signal is defined as "low" when between 0 V and 0.8 V with respect to the ground terminal, and "high" when between 2 V and V_CC (5 V)'

 

A bare ESP32 module operates on 3.3V,  so is not directly TTL compatible.  It has usually been depicted in most tutorials and youtube videos as needing logic level converters to interface with TTL logic, such as the UNO boards and other +5V devices.  The RN used in the Fujinet provides a very simplistic level converter, but it's not really smart enough to handle power on/off,  and when the Fujinet power is turned off acts as a load on the SIO bus, breaking the passthrough feature.  It also doesn't isolate against feedback power. 

 

As far as the audio line needing to be filtered/logic level converted...... The original schematic does not have the signal going through the RN to drop voltage, instead it goes through C3/R5.  I'm assuming that those two parts are doing the same thing as the RN to drop the voltage to something the ESP32 can handle.  I'm not an engineer, so all I can say is that it's very possible it will need to handled by an additional isolate/buffer chip line as well.

 

Which unfortunately takes us back to a two chip solution.  Or maybe one chip and something discrete to handle the Audio In line. 

 

There are far better electronics savvy members than me that can weight in here to correct my assessment if I am materially wrong. 

[Teapot]

Sorry - my fault for being too succinct and thus vague.

 

13 hours ago, Dropcheck said:

TTL is a logic level family, usually used to describe most older chip families even if they have a SMT as well as a DIP/SIP footprint.  The Atari line of computers are most definitely in that logic family as are almost all chips powered by 5V.    'A TTL input signal is defined as "low" when between 0 V and 0.8 V with respect to the ground terminal, and "high" when between 2 V and V_CC (5 V)'

Right.  The TXS0108 data sheet, in table 6.3, lists a "high" value minimum of Vcc-0.4V for that side.  So on the 5V side it's looking for at least 4.6V.  It also lists a maximum "low" value of 0.15V.  It isn't clear what happens with an input in between these values.

 

I found the related LSF0108 which mentions TTL in the data sheet.  But said data sheet doesn't have an equivalent table of voltages for comparison.

  

13 hours ago, Dropcheck said:

As far as the audio line needing to be filtered/logic level converted...... The original schematic does not have the signal going through the RN to drop voltage, instead it goes through C3/R5.  I'm assuming that those two parts are doing the same thing as the RN to drop the voltage to something the ESP32 can handle.  I'm not an engineer, so all I can say is that it's very possible it will need to handled by an additional isolate/buffer chip line as well.

 

Which unfortunately takes us back to a two chip solution.  Or maybe one chip and something discrete to handle the Audio In line. 

Audio_In is an output from the bus device (ESP-32) and an input to the Atari.  So if level conversion were needed it would need to go from 0-3.3V to 0-5V.  And it's a further different process because it's an analog signal.

 

I only bring these things up because my recent hobby projects are a lot of classic ICs and I have to pay attention to the TTL vs CMOS levels.  I don't have any SIO experience and couldn't find any good spec-like documents to read so I can really only contribute indirectly.