Jump to content
IGNORED

Preannouncement: Dragon Cart II


ol.sc

Recommended Posts

41 minutes ago, _The Doctor__ said:

AXstream might be a name for continuation onto the Atari platform. Glad to see you are still playing with this stuff Ol.

Thanks for the kind feedback ?

With a W5100-based PBI device being available I could imagine very well to implement it. According to my Atari knowledge, it should be (much) easier to implement and/or sound (much) better than A2Streasm.

  • Like 1
Link to comment
Share on other sites

34 minutes ago, tschak909 said:

If you don't put a processor in, there's no way you'll be able to do crypto, or more complex data processing that is now required by many of today's endpoints.

 

Please, I implore those of you that are still hanging onto this idea of "let's run it all on the host!" to let go of that. It's a dead end!

 

-Thom

 

I thought this might be the case, but am not too close to the FujiNet code, so didn't want to jump in.

 

Having an ARM CPU (or two, or dual core ARM) sitting on the PBI/ECI bus enables other stuff like graphics co-processing, offloading Floating Point operations, external memory upgrades, and anything else that can be added in.

Link to comment
Share on other sites

14 minutes ago, tschak909 said:

If you don't put a processor in, there's no way you'll be able to do crypto, or more complex data processing that is now required by many of today's endpoints.

 

Please, I implore those of you that are still hanging onto this idea of "let's run it all on the host!" to let go of that. It's a dead end!

 

-Thom

 

 

From my POV it boils down to the question if "stock" / "default" endpoints are that relevant / interesting in the first place:

 

* A2Stream streams a custom format - so it requires custom endpoints anyhow.

* FujiNet's TNFS is a custom protocol - so it requires custom endpoints anyhow.

http://68k.news/ and http://frogfind.com/ demostrate successfully that it is a viable - or even preferable - option to proxy "stock" / "default" endpoints.

 

So one could argue, that pushing the functionality in question from the host to the device is a 'soon-dead end' too. Pushing it to the cloud could be considered the final solution. As a result, all the host needs, would be access to the cloud. And for that, the W5100 is enough.

 

But if you don't like the cloud idea, you have to ask yourself, if the ESP32 really fits the bill. You easily end up wanting more:

 

* Up to date / user updatable SSL/TLS client library with true SSL/TLS certificate store incl. revocation management etc.
* Up to date / user updatable SSH client library to use your Atari as terminal to arbitrary Linux hosts.

* Up to date / user updatable CUPS implementation to support arbitrary real printers.

* ...

 

From my POV, only a Linux SBC (think Raspberry Pi) truly fulfills the needs (as danwinslow mentioned). E.g. I have my W5100 usually directly connected to the Ethernet port of a RPi. The RPi works as NAT router for the W5100. This way I get:

 

* Transparent WiFi access through the RPi WiFi module for all existing W5100 software

* Transparent internet access though the RPi NAT router for all existing W5100 software

* Direct access to all kinds of things I run on the RPi...

 

You can as well approach the last point from a totally different perspective: Question: How do I connect a Raspberry Pi to the Atari? Fast? Answer: Using TCP/IP with a W5100.

* As fast as it gets this side of DMA

* No ugly "serial" hack on the Atari

* No ugly "serial" hack on the RPi

* Totally natural/implicit end-to-end flow control through TCP sliding window protocol

* Totally natural/implicit multiplexing of streams through TCP ports

* No need for DHCP/DNS, e.g.
  * RPI always has the IP address 10.10.10.10

  * Atari always has the IP address 10.20.30.40

  * So e.g. printer: TCP connect to 10.10.10.10:1234

  * So e.g. modem: TCP connect to 10.10.10.10:1235

  * Without the need for DHCP/DNS, a printer or modem "driver" just talking to the RPi through the W5100 using TCP is less than 256 bytes.

 

And again, because of the NAT router on the RPi, existing W5100 internet software, not knowing about / not interested in the RPi, works as-is in parallel to "new" software just using the W5100 to access the RPi.

 

And finally: Quickly hacking a Python script on the RPi (of course using the 6502-machine as terminal) that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet is really bringing back the end user empowerment we had back then with BASIC. The combo of BASIC on the 6502-machine + Python on the RPi brings you back from just consuming stuff to making stuff. That's where the fun is - at least to me ?

 

Link to comment
Share on other sites

14 minutes ago, ol.sc said:

 

From my POV it boils down to the question if "stock" / "default" endpoints are that relevant / interesting in the first place:

 

* A2Stream streams a custom format - so it requires custom endpoints anyhow.

* FujiNet's TNFS is a custom protocol - so it requires custom endpoints anyhow.

http://68k.news/ and http://frogfind.com/ demostrate successfully that it is a viable - or even preferable - option to proxy "stock" / "default" endpoints.

 

So one could argue, that pushing the functionality in question from the host to the device is a 'soon-dead end' too. Pushing it to the cloud could be considered the final solution. As a result, all the host needs, would be access to the cloud. And for that, the W5100 is enough.

 

But if you don't like the cloud idea, you have to ask yourself, if the ESP32 really fits the bill. You easily end up wanting more:

 

* Up to date / user updatable SSL/TLS client library with true SSL/TLS certificate store incl. revocation management etc.
* Up to date / user updatable SSH client library to use your Atari as terminal to arbitrary Linux hosts.

* Up to date / user updatable CUPS implementation to support arbitrary real printers.

* ...

 

From my POV, only a Linux SBC (think Raspberry Pi) truly fulfills the needs (as danwinslow mentioned). E.g. I have my W5100 usually directly connected to the Ethernet port of a RPi. The RPi works as NAT router for the W5100. This way I get:

 

* Transparent WiFi access through the RPi WiFi module for all existing W5100 software

* Transparent internet access though the RPi NAT router for all existing W5100 software

* Direct access to all kinds of things I run on the RPi...

 

You can as well approach the last point from a totally different perspective: Question: How do I connect a Raspberry Pi to the Atari? Fast? Answer: Using TCP/IP with a W5100.

* As fast as it gets this side of DMA

* No ugly "serial" hack on the Atari

* No ugly "serial" hack on the RPi

* Totally natural/implicit end-to-end flow control through TCP sliding window protocol

* Totally natural/implicit multiplexing of streams through TCP ports

* No need for DHCP/DNS, e.g.
  * RPI always has the IP address 10.10.10.10

  * Atari always has the IP address 10.20.30.40

  * So e.g. printer: TCP connect to 10.10.10.10:1234

  * So e.g. modem: TCP connect to 10.10.10.10:1235

  * Without the need for DHCP/DNS, a printer or modem "driver" just talking to the RPi through the W5100 using TCP is less than 256 bytes.

 

And again, because of the NAT router on the RPi, existing W5100 internet software, not knowing about / not interested in the RPi, works as-is in parallel to "new" software just using the W5100 to access the RPi.

 

And finally: Quickly hacking a Python script on the RPi (of course using the 6502-machine as terminal) that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet is really bringing back the end user empowerment we had back then with BASIC. The combo of BASIC on the 6502-machine + Python on the RPi brings you back from just consuming stuff to making stuff. That's where the fun is - at least to me ?

 

All this, and you still wind up with something that doesn't provide things that users want out of the box. I see a lot of red herrings here.

 

Again, I have to point out, there is nothing tying FujiNet to the serial port. It can also run on PBI, just need someone to head up the bring-up, especially since I am now handling multiple system targets.

 

-Thom

Edited by tschak909
  • Like 1
Link to comment
Share on other sites

As case and point. I was able to put together a Mastodon client that displays the most recent public toot on a server, in roughly 15 minutes, this is the Coleco Adam version, the Atari version is coming later today:

1313430021_Screenshotfrom2022-05-1319-14-47.thumb.png.0f9a2662ad125a803326df7c1f160d88.png

 

This uses the TLS and JSON functionality in the FujiNet to quickly make light work of what is otherwise a very large JSON stream (each JSON object is roughly 8KB in size). Here is the code:

/**
 * mastodon - a simple mastodon client
 *
 * @author Thom Cherryhomes
 * @email thom dot cherryhomes at gmail dot com
 * @license gpl v. 3, see LICENSE.md for details.
 */

#include <msx.h>
#include <eos.h>
#include <smartkeys.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <conio.h>
#include "input.h"

#define CHANNEL_MODE_JSON 1
#define NET_DEV 0x09

const char *url = "N:HTTPS://oldbytes.space/api/v1/timelines/public?limit=1";

char response[1024];

struct _oc
{
  unsigned char cmd;
  char mode;
  char trans;
  char url[256];
} OC; // Open command

struct _scm
{
  unsigned char cmd;
  char mode;
} SCM; // Set Channel Mode command

struct _qc
{
  unsigned char cmd;
  char query[128];
} QC; // Query command

void main(void)
{
  unsigned char r;
  
  OC.cmd = 'O';
  OC.mode = 12;
  OC.trans = 3;
  strncpy(OC.url,url,256);

  SCM.cmd = 0xFC;
  SCM.mode = CHANNEL_MODE_JSON;

  QC.cmd = 'Q';
  
  eos_start_read_keyboard();
  
  smartkeys_set_mode();
  smartkeys_display(NULL,NULL,NULL,NULL,NULL,"  NEXT\n  TOOT");
  smartkeys_status("  REALLY SIMPLE MASTODON CLIENT\n  WANNA MAKE A BETTER ONE?\n  YOU CAN!");

  while (1)
    {
    reload:
      msx_vfill(MODE2_ATTR,0xF4,0x100);
      msx_vfill(MODE2_ATTR+0x100,0xF5,0x100);
      msx_vfill(MODE2_ATTR+0x200,0x1F,0x1200);

      msx_vfill(0x0000,0x00,0x1400);

      while (eos_write_character_device(NET_DEV,(unsigned char *)OC,sizeof(OC)) < 0x80);

      while (eos_write_character_device(NET_DEV,(unsigned char *)SCM,sizeof(SCM)) < 0x80);
      while (eos_write_character_device(NET_DEV,"P",1) < 0x80);

      strncpy(QC.query,"/0/account/display_name",128);
      while (eos_write_character_device(NET_DEV,(unsigned char *)QC,sizeof(QC)) < 0x80);
      memset(response,0,1024);
      while (eos_read_character_device(NET_DEV,response,1024) < 0x80);
      msx_color(15,4,7); gotoxy(0,0); cprintf("%s",response);

      strncpy(QC.query,"/0/created_at",128);
      while (eos_write_character_device(NET_DEV,(unsigned char *)QC,sizeof(QC)) < 0x80);
      memset(response,0,1024);
      while (eos_read_character_device(NET_DEV,response,1024) < 0x80);
      msx_color(15,5,7); gotoxy(0,1); cprintf("%s",response);

      strncpy(QC.query,"/0/content",128);
      while (eos_write_character_device(NET_DEV,(unsigned char *)QC,sizeof(QC)) < 0x80);
      memset(response,0,1024);
      while (eos_read_character_device(NET_DEV,response,1024) < 0x80);
      msx_color(1,15,7); smartkeys_puts(0,16,response);

      eos_write_character_device(NET_DEV,"C",1);
      
      while (1)
	{
	  switch(input())
	    {
	    case KEY_SMART_VI:
	      goto reload;
	    }
	}
    }
}

For each target, we try to use the operating system routines to do I/O transactions, for the Adam, these are AdamNet commands called via EOS, and could just as easily have been written in SmartBASIC.

 

-Thom

Link to comment
Share on other sites

12 minutes ago, ol.sc said:

From my POV it boils down to the question if "stock" / "default" endpoints are that relevant / interesting in the first place:

Sure.

13 minutes ago, ol.sc said:

FujiNet's TNFS is a custom protocol - so it requires custom endpoints anyhow

Missing something here. Its a protocol. What makes it a custom protocol?

15 minutes ago, ol.sc said:

pushing the functionality in question from the host to the device is a 'soon-dead end' too

The community is full of folks that keep ancient hardware running. Is the concern that the "new" hardware will eventually be outpaced by the network technology? I'm sure it will but I'm not sure why its relevant.

17 minutes ago, ol.sc said:

Pushing it to the cloud could be considered the final solution

What is known as "the cloud" today will not be anyone's "final solution." If by cloud you mean software / compute resources served up on someone else's hardware in someone else's datacenter.   --- But network connectivity is provided either way.

 

21 minutes ago, ol.sc said:

Up to date / user updatable SSL/TLS client library with true SSL/TLS certificate store incl. revocation management etc.

Not sure why this would be a problem. Revocation management for clients or servers? Either way a CRL file can be dropped onto a web server and any http... neh... tcp client can pull it for processing. There is enough compute power here for that.

49 minutes ago, ol.sc said:

Up to date / user updatable SSH client library to use your Atari as terminal to arbitrary Linux hosts.

Depending on "user updatable" I thought Tom actually had a ssh client library working?

50 minutes ago, ol.sc said:

Up to date / user updatable CUPS implementation to support arbitrary real printers.

Also not sure a CUPS stack would be necessary - especially for network printers which seem to be the norm... more so when talking networking/networking devices/etc. 

52 minutes ago, ol.sc said:

From my POV, only a Linux SBC (think Raspberry Pi) truly fulfills the needs (as danwinslow mentioned).

I think a PI is a great piece of hardware that works for a great amount of things --- especially in the Atari community. You can connect to it in multiple ways to include serial, bluetooth, ethernet, wifi, etc.... 

54 minutes ago, ol.sc said:

You can as well approach the last point from a totally different perspective: Question: How do I connect a Raspberry Pi to the Atari? Fast? Answer: Using TCP/IP with a W5100.

Awesome!

54 minutes ago, ol.sc said:

No ugly "serial" hack on the Atari

Who you calling ugly? lol! :D

55 minutes ago, ol.sc said:

No ugly "serial" hack on the RPi

....this is starting to seem rather subjective...

 

56 minutes ago, ol.sc said:

Without the need for DHCP/DNS, a printer or modem "driver" just talking to the RPi through the W5100 using TCP is less than 256 bytes

all sounds very interesting.

 

58 minutes ago, ol.sc said:

Quickly hacking a Python script on the RPi (of course using the 6502-machine as terminal) that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet

Not sure why the "event" being tcp socket activity is different then listening to any other type of event. Serial hack vs TCP hack?

 

1 hour ago, ol.sc said:

he combo of BASIC on the 6502-machine + Python on the RPi brings you back from just consuming stuff to making stuff.

But there are a lot of people making chat programs, news programs, web browsers, weather applications, software repositories, terminal applications, etc. using the interfaces made available via the Fujinet. Some of them require Atari programs interfacing with computer servers (wikipedia viewer for instance.) 

 

ANYWAYS... you have the technologies that you are comfortable with and I am really interested in trying the same. I just wonder if you have worked much with the Fujinet lately? I am using the netcat.xex application to kick at server ports written in perl to trigger stuff - not unlike what you are doing in Python I guess?, I successfully SSH'd to my laptop (mind blowing), I'm downloading files using not just tnfs, but also http, https, ftp, and more, I am connecting from network to network while in DOS.... 

 

Getting back on point. I am not campaigning for any solution. I am definitely interested in this project.

 

 

Link to comment
Share on other sites

FujiNet's TNFS is a custom protocol - so it requires custom endpoints anyhow

> Missing something here. Its a protocol. What makes it a custom protocol?

 

The point I wanted to make is that if you connect to an existing endpoint via e.g. HTTP, it often is only available via SSL/TLS. But TNFS endpoints are set up explicitly for FujiNet, so it's easy to set them up without SSL/TLS - thus eliminating the need to support SSL/TLS.

Link to comment
Share on other sites

Hello guys

 

We are using TNFS with FujiNet and FujiNet is being made available for other platforms than the Atari 8 bit system, which sometimes means that the ESP32 is connected to the computer via its parallel port.  So why not put the ESP32 (or something compatible but "bigger" if available) on a PCB that plugs into the PBI or cartridge port and ECI that's either able to share the bus or that only uses an address in the $D5xx area?  Using the ESP32 (or compatible) and TFNS has the advantage that we can use the code the FujiNet team is writing and that we can share servers between SIO-FujiNet and PB-FujiNet.

 

Sincerely

 

Mathy

 

  • Like 1
Link to comment
Share on other sites

Gotcha!

 

Sounds like you need a networking co-processor to help handle some of this TLS/SSL. ;)

 

I mean, you can proxy all your network connections requesting TLS if you want to run it on external hardware. That's trivial.

 

Link to comment
Share on other sites

11 minutes ago, Mathy said:

 

We are using TNFS with FujiNet and FujiNet is being made available for other platforms than the Atari 8 bit system, which sometimes means that the ESP32 is connected to the computer via its parallel port.  So why not put the ESP32 (or something compatible but "bigger" if available) on a PCB that plugs into the PBI or cartridge port and ECI that's either able to share

Well.... yeah.... but the tnfs bits are mostly about mounting disk images right? Which is why it makes sense on SIO? 

 

I like the fujinet (or any other device) on PBI, ECI... but probably less for the tnfs specific bits.... though the more protocals the better I say!

Link to comment
Share on other sites

No ugly "serial" hack on the Atari

> Who you calling ugly? lol! :D

 

Okay, likely my fault. I'm no Atari guy. Reading https://github.com/HiassofT/highspeed-sio/blob/master/README.txt left me with the feeling that serial on the Atari isn't exactly straight forward. But I easily might missing the point.

 

 

No ugly "serial" hack on the RPi

> ....this is starting to seem rather subjective...

 

Then e.g. https://www.ibeyonde.com/raspberry-pi-serial-ports.html is subjective too, right?

 

Quickly hacking a Python script on the RPi (of course using the 6502-machine as terminal) that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet

> Not sure why the "event" being tcp socket activity is different then listening to any other type of event. Serial hack vs TCP hack?

 

With serial you only have one port. If you listen to it with your hack, then nothing else works anymore. With TCP you have built-in multiplexing with TCP ports. Your hack listening to port 1234 doesn't keep all the existing stuff on their ports from working.

 

> I am using the netcat.xex application to kick at server ports written in perl to trigger stuff - not unlike what you are doing in Python I guess?

 

I was talking about Python on the RPi, are you taking about Perl on the ESP32?

 

I just wonder if you have worked much with the FujiNet lately?

 

Nope. However, as far as I understand it's still consuming what is provided by the FujiNet team. Adding something to FujiNet is still implementing it in C/C++, using the ESP32 SDK to create a new firmware and uploading the firmware to the ESP32. I see that doing way less individuals than I see logging into a RPi and writing some Python script.

Link to comment
Share on other sites

7 minutes ago, ol.sc said:

With serial you only have one port. If you listen to it with your hack, then nothing else works anymore. With TCP you have built-in multiplexing with TCP ports.

And without an OS that supports multitasking I care because....? I must be missing something.

 

8 minutes ago, ol.sc said:

I was talking about Python on the RPi, are you taking about Perl on the ESP32?

No I am talking about using Perl on a PC (PI no different.) I think what you are missing is that the Fujinet provides an interface for communicating on TCP. --- It's not all tnfs and disk images.

 

2 hours ago, ol.sc said:

that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet is really bringing back the end user

So I can write something in PERL, Python, (whatever) on the PI and it can listen on a TCP port and I can send/receive data to that port using the Fujinet and then this application/script I wrote can go off and do something cool on the internet and bring stuff back to the end user. There are lots of youtube videos and documentation and posts here about the N: handler, Fujinet with BASIC, etc. that you might want to read up on.

 

14 minutes ago, ol.sc said:

Nope. However, as far as I understand it's still consuming what is provided by the FujiNet team.

No. If you are talking about raw protocol support like TCP then definitely, no. The Fujinet project has brought forth interfaces (such as the CIO N: interface) that you can access from BASIC or whatever else on the Atari. The Fujinet folks have also provided Atari binaries and sample code to assist. I am sure this is what you are describing. Look into it... its super cool.

 

Link to comment
Share on other sites

21 minutes ago, ol.sc said:

With serial you only have one port. If you listen to it with your hack, then nothing else works anymore. With TCP you have built-in multiplexing with TCP ports. Your hack listening to port 1234 doesn't keep all the existing stuff on their ports from working.

Since Fujinet conforms to the Atari OS SIO calls you can open multiple channels/ports over the "serial port". FujiNet buffers the incoming information and provides it to the Atari when requested. With the Fujinet N: device driver you can, for example, copy a file from a FTP server to a TNFS server. You could read from an HTTP(S) server and write to a UDP port. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Using-the-N%3A-Device

 

27 minutes ago, ol.sc said:

However, as far as I understand it's still consuming what is provided by the FujiNet team. Adding something to FujiNet is still implementing it in C/C++, using the ESP32 SDK to create a new firmware and uploading the firmware to the ESP32. I see that doing way less individuals than I see logging into a RPi and writing some Python script.

We have added helpers to the firmware to facilitate easier ways to access certain things on the internet, the JSON parser for example. If you want to write your own Atari side program to parse pure JSON, you can. Just open your JSON file using the protocol of your choice and parse the data. You can access HTTP using TCP instead of our provided HTTP(S) protocol adapter, then you would need to deal with the HTTP headers in your program. You can open a raw TCP or UDP port and do what you will on the Atari with the information stream.

 

 

Link to comment
Share on other sites

With serial you only have one port. If you listen to it with your hack, then nothing else works anymore. With TCP you have built-in multiplexing with TCP ports.

> And without an OS that supports multitasking I care because....? I must be missing something.

I understand that the FujiNet provides CIO <Letter>: interfaces. Imagine this being done with a RPi, you could/would have one TCP port for each interface. So the interfaces would all work independently of each other. And you could still add you own stuff without disturbing what is already there. This has nothing to do at all with an OS or multitasking. It's about having several independent communication channels. It's like not having a single serial connection but as many serial connections as you like. On one connection you are maybe in the middle of accessing a file while on another connection you go out to some internet thingy.

 

I was talking about Python on the RPi, are you taking about Perl on the ESP32?

> No I am talking about using Perl on a PC (PI no different.) I think what you are missing is that the Fujinet provides an interface for communicating on TCP. --- It's not all tnfs and disk images.

 

Not at all. I'm pretty sure I understand well what FujiNet provides. Do you run code your own code _ON_ the FujiNet? I understand the answer is 'no'. If FujiNet wouldn't be based on a MCU but on a Linux SBC, you could easily run your own code on it.

 

that listens on some TCP socket for a request from the 6502-machine and does something cool on the internet is really bringing back the end user

> So I can write something in PERL, Python, (whatever) on the PI and it can listen on a TCP port and I can send/receive data to that port using the Fujinet and then this application/script I wrote can go off and do something cool on the internet and bring stuff back to the end user. There are lots of youtube videos and documentation and posts here about the N: handler, Fujinet with BASIC, etc. that you might want to read up on.

 

Certainly you can. But if you consider the RPi an obligatory part of the picture, then you only use the FujiNet to connect to the RPi. And that very task is done as well with a W5100.

 

Nope. However, as far as I understand it's still consuming what is provided by the FujiNet team.

> No. If you are talking about raw protocol support like TCP then definitely, no. The Fujinet project has brought forth interfaces (such as the CIO N: interface) that you can access from BASIC or whatever else on the Atari. The Fujinet folks have also provided Atari binaries and sample code to assist. I am sure this is what you are describing. Look into it... its super cool.

 

Still a misunderstanding. You consume the interfaces provided by the FujiNet team (e.g. for connecting to a remote TCP port), but you don't create your own interfaces _ON_ the FujiNet, doing something totally different. Look at Thom's recent post

- would you have been able to do that in the same way? With a MCU, it's always the few with programs ON the device and the many with programs USING the device. With a Linux SBC, everyone who likes has programs ON the device.

 

Even if you learn to program ON the device. How would you share your code with others? The firmware you built? But does your firmware contain the programs from others doing same like you do? Does it contain recent updates from the FujiNet team?

 

A Linux SBC comes with an OS and a file system. Everybody can bring his file/program and start his process. You can create a program and easily share it with others. They can add it to their SBC and run it alongside all the other programs. And the programs can all listen on their own TCP port to interact with Atari programs without disturbing each other. It's an open platform for everyone.

Link to comment
Share on other sites

5 minutes ago, mozzwald said:

Since Fujinet conforms to the Atari OS SIO calls you can open multiple channels/ports over the "serial port". FujiNet buffers the incoming information and provides it to the Atari when requested. With the Fujinet N: device driver you can, for example, copy a file from a FTP server to a TNFS server. You could read from an HTTP(S) server and write to a UDP port. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Using-the-N%3A-Device

 

We have added helpers to the firmware to facilitate easier ways to access certain things on the internet, the JSON parser for example. If you want to write your own Atari side program to parse pure JSON, you can. Just open your JSON file using the protocol of your choice and parse the data. You can access HTTP using TCP instead of our provided HTTP(S) protocol adapter, then you would need to deal with the HTTP headers in your program. You can open a raw TCP or UDP port and do what you will on the Atari with the information stream.

 

 

I think we're having a misunderstanding here. I certainly don't doubt, that the FujINet team has created really great tools. However, the team produces the tools, the users consume the tools. I guess that's just fine for just about everyone. At least that's the Out-Of-The-Box functionality that Thom always insists on - and that I presume the FujiNet owners love.

 

The only reason why I'm still writing here is, that it doesn't seem clear to everybody, that this is something pretty different to an open platform like a Linux SBC.

 

And that's BTW the point why the way, multiplexing is done, is relevant: In a rather closed environment, the few programmers can come up with any type of custom multiplexing scheme. As long as everybody does everything right, everything works. But in a rather open environment, it's important that one bogus program doesn't bring down the communication channels of the other mature programs. And there the benefit of a built-in multiplexing scheme as provided by a TCP/IP stack becomes important.

Link to comment
Share on other sites

I presume to have lost many in the discussion. I try to summarize my perspective...

 

I see basically these viable options:

 

1. A lightweight, rather stupid device like the W5100. It comes with fixed functionality, that nobody extends.

 

2. A midweight, rather intelligent device like the ESP32. It allows for extending its functionality to a rather small group for persons coordinating their work well.

 

3. A heavyweight, very intelligent device like the RPi. It allows for extending its functionality to all its users.

 

3.1 The connection to the device in 3.) is made by the device in 1.) This way 1.) serves two types of programs:

  - Programs not asking for intelligence.

  - Programs using 3.)

 

 

Link to comment
Share on other sites

I understand. I just think that...

 

3.1 a connection to the device in 3.) is made by the device in 2) serves three types of programs

- programs not asking for intelligence

- programs asking for intelligence

- programs using 3.)

 

6 minutes ago, ol.sc said:

It allows for extending its functionality to a rather small group for persons coordinating their work well.

...I believe is an odd representation. Everything is open. Not only is the goal not to be a small group --- but group members literally encourage (offer, ask, beg, facilitate, support, train, advertise, promote, etc) others to do work here.

 

But, alas.... I don't really care because I would like the W5100 solution too. 

Link to comment
Share on other sites

This idea of things not being "Atari based" solutions is silly.  The 2400 baud modem I used in 1984 to connect my 800 to a BBS was not a native solution.  The modem did all the work.  No one is looking for period correct solutions these days.  Any and all additional devices are a good thing!

  • Like 1
Link to comment
Share on other sites

20 minutes ago, ol.sc said:

that this is something pretty different to an open platform like a Linux SBC.

An esp32 and a Linux SBC are not the same hardware, but both are open platforms. A Linux SBC is likely MUCH faster and with more capabilities than the esp32, absolutely. I can see the utility of having a Linux SBC hooked up to an Atari.

23 minutes ago, ol.sc said:

However, the team produces the tools, the users consume the tools.

We create tools and release source code, anyone can add their own tools. You can take the hardware and write your own tools in Micropython if you like, or whatever language can be compiled for the esp32. 

 

30 minutes ago, ol.sc said:

In a rather closed environment, the few programmers can come up with any type of custom multiplexing scheme.

 

31 minutes ago, ol.sc said:

2. A midweight, rather intelligent device like the ESP32. It allows for extending its functionality to a rather small group for persons coordinating their work well.

If you are referring to the FujiNet project as a closed environment, you are mistaken. Everything is open. Anyone can extend, add, remove, replace if they wish. Some folks have already taken it upon themselves to change and extend FujiNet code and submit changes back to the master repo. 

35 minutes ago, ol.sc said:

3. A heavyweight, very intelligent device like the RPi. It allows for extending its functionality to all its users.

As I said before, FujiNet also "allows for extending its functionality to all its users."

 

I realize I'm just arguing to argue so I'm sorry and done. FujiNet and Dragoncart are not the same. They both offer connectivity to the outside world in different ways and the end user can figure out which works best for them. The more choices, the better IMO.

  • Like 1
Link to comment
Share on other sites

 

I realize I'm just arguing to argue so I'm sorry and done.

 

After all so do I. And what's even more important: You are arguing for something that's alive and kicking - and is a great success, while I argue for something that will almost certainly never come to life. So I have for sure more reason to be sorry than you are!

Edited by ol.sc
  • Sad 1
Link to comment
Share on other sites

1 minute ago, ol.sc said:

I'm into software, not hardware. That's the reason why I re-posted after two years in this thread to check if someone who's into hardware is interested in building it.

and I'm just a forum troll with neither hardware nor software to show to the community.... just a bunch of opinions.

 

I think, one day when I retire I might take some courses in hardware.

 

 

  • Haha 1
Link to comment
Share on other sites

17 minutes ago, ol.sc said:

That's the reason why I re-posted after two years in this thread to check if someone who's into hardware is interested in building it.

Is the hardware working/done? All I see on the first page is a fancy render and I have not skimmed thru the whole thread. If it's not done, I think you have a hard road ahead. If it is 99.9% done then maybe someone will step up and finish. If it's 100% done, send the gerbers and BOM to China and make them already :D or find someone like @Gavin1968 to make them.

 

Get those eagle files and post them here before something bad happens and they are lost forever. Make it easy for someone to roll with it.

Edited by mozzwald
eagle files
  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...