Jump to content
IGNORED

#FujiNet - a WIP SIO Network Adapter for the Atari 8-bit


tschak909

Recommended Posts

2 hours ago, TheMontezuma said:

I have actually done it for SIO2BT:

https://github.com/TheMontezuma/highspeed-sio/releases

Thanks, I remember the discussions about that back then.

 

The main problem with implementing that is that I simply don't have enough code space left in ROM - I'm down to about 16 unused bytes and I don't really want to drop the keyboard patch like you did in the SIO2BT patch.

 

I think the documented entry point is a pretty good compromise. It won't interfere with non-disk devices (throwing get speed byte and get status commands using various highspeed protocols at standard SIO devices like printers only slow things down), only needs 3 extra bytes in code space for the entry point JMP and gives software full control over what's going to transmitted via SIO.

 

This entry point can also be used to deliberately bypass the OS SIO when you want to make sure the command really gets transmitted at the speed/protocol you want without any autodetection happening in the background and without PBI devices possibly redirecting/modifying/... it.

 

so long,

 

Hias

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

29 minutes ago, HiassofT said:

Thanks, I remember the discussions about that back then.

 

The main problem with implementing that is that I simply don't have enough code space left in ROM - I'm down to about 16 unused bytes and I don't really want to drop the keyboard patch like you did in the SIO2BT patch.

 

I think the documented entry point is a pretty good compromise. It won't interfere with non-disk devices (throwing get speed byte and get status commands using various highspeed protocols at standard SIO devices like printers only slow things down), only needs 3 extra bytes in code space for the entry point JMP and gives software full control over what's going to transmitted via SIO.

 

This entry point can also be used to deliberately bypass the OS SIO when you want to make sure the command really gets transmitted at the speed/protocol you want without any autodetection happening in the background and without PBI devices possibly redirecting/modifying/... it.

 

so long,

 

Hias

Yeah, am in agreement here.

-Thom

Link to comment
Share on other sites

5 minutes ago, MrMartian said:

Is it still possible to build and run this on an ESP32 dev board? I've read back through the thread and see people have but it's not clear how one would go about that..

 

With spare time on my hands, this could be good to look at!

Yes, but the newer hardware is using the ESP32 WROVER modules that have external RAM not available on the previously used WROOM module so at some point the code will likely not work well on the older boards. We ran into issues with the WROOM modules not having enough storage first, then ran out of RAM when trying to enable too much at once. That said, you could whip up something with an ESP32 dev board following this schematic and it will work for now.

 

If you can find something with a ESP32 WROVER module instead you'll be better off (we are using 8MB PSRAM/16MB Flash). There's a schematic for the newer WROVER based FujiNet here but will require some more work on your part to convert the pinout to whatever dev board you use. I have not looked at any readily available WROVER dev boards myself.

  • Like 1
Link to comment
Share on other sites

The wroom version is pretty easy and very cheap to build. Check out "8 bits and more" fujinet video on YouTube, that's kinda what I based my build on. The current software is pretty good, and I am loving using it. Hopefully we get another update or 2 before they switch over to the wrover board. Would love to build a wrover board if I could.

  • Like 2
Link to comment
Share on other sites

FujiNet now has the ability to do screen captures to PNG when used with a version of @ClausB's PRANTIC. Claus wrote a new version called GRANTIC that sends the 8-bit color data to P: and from that FujiNet builds a 320x192 pixel PNG. Thank-you Claus! This is a neat capability.

 

Instructions for those following along with their own devices:

Mount the attached grantic.ATR, which is a DOS 2.5 boot disk with GRANTIC loading in AUTORUN.SYS. Boot this to BASIC.

From a browser navigate to your FujiNet's IP (homepage). Select the "GRANTIC" printer emulator from the drop down list.

There are two simple demo programs (GR2.BAS and GR3.BAS) on the ATR. Run either of those. When you no longer hear SIO traffic buzz, download the printout from the browser. 

 

The magic happens with a call to USR(8192).

Sample output:

printout_7.png.2de935d8c8a8caec036031c4875263f3.pngprintout_5.png.2b74b837c21c8cff3cf925c913c93553.pngprintout_6.png.49d6bd875f748a5d6ed0e20d292cdb18.png

 

grantic.atr

  • Like 9
  • Thanks 1
Link to comment
Share on other sites

23 hours ago, MrMartian said:

Is it still possible to build and run this on an ESP32 dev board? I've read back through the thread and see people have but it's not clear how one would go about that..

 

With spare time on my hands, this could be good to look at!

Here's instructions on installing VSCode and PlatformIO so you can get the firmware and upload to a dev board.

https://github.com/FujiNetWIFI/atariwifi/wiki/Board-Bring-up-for-PLATFORM.IO-code

 

The firmware should run without an SD card. You might run out of SPIFFS space if you print a large file. But it's worth a shot!

Link to comment
Share on other sites

1 hour ago, jeffpiep said:

FujiNet now has the ability to do screen captures to PNG when used with a version of @ClausB's PRANTIC. Claus wrote a new version called GRANTIC that sends the 8-bit color data to P: and from that FujiNet builds a 320x192 pixel PNG. Thank-you Claus! This is a neat capability.

 

Instructions for those following along with their own devices:

Mount the attached grantic.ATR, which is a DOS 2.5 boot disk with GRANTIC loading in AUTORUN.SYS. Boot this to BASIC.

From a browser navigate to your FujiNet's IP (homepage). Select the "GRANTIC" printer emulator from the drop down list.

When I change the drop-down menu to Grantic(or any of the other printers) and hit "change", I get "Header fields are too long for server to interpret"

Doug

Edited by Fierodoug5
Link to comment
Share on other sites

2 hours ago, jeffpiep said:

FujiNet now has the ability to do screen captures to PNG when used with a version of @ClausB's PRANTIC. Claus wrote a new version called GRANTIC that sends the 8-bit color data to P: and from that FujiNet builds a 320x192 pixel PNG. Thank-you Claus! This is a neat capability.

 

Instructions for those following along with their own devices:

Mount the attached grantic.ATR, which is a DOS 2.5 boot disk with GRANTIC loading in AUTORUN.SYS. Boot this to BASIC.

From a browser navigate to your FujiNet's IP (homepage). Select the "GRANTIC" printer emulator from the drop down list.

There are two simple demo programs (GR2.BAS and GR3.BAS) on the ATR. Run either of those. When you no longer hear SIO traffic buzz, download the printout from the browser. 

 

The magic happens with a call to USR(8192).

Sample output:

printout_7.png.2de935d8c8a8caec036031c4875263f3.pngprintout_5.png.2b74b837c21c8cff3cf925c913c93553.pngprintout_6.png.49d6bd875f748a5d6ed0e20d292cdb18.png

 

grantic.atr 90.02 kB · 3 downloads

Wonders if Grantic/Prantic it can drive a native star nx rainbow, okidata, or Panasonic/ tandy color printer attached to the Atari rather than network file passage. Also wonders if fujinet can just send the resulting file to a network printer... No wintel box involved :)

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

43 minutes ago, Fierodoug5 said:

When I change the drop-down menu to Grantic(or any of the other printers) and hit "change", I get "Header fields are too long for server to interpret"

Doug

oh shoot - use Internet Explorer it surprisingly works. Ugh. There's an updated file in IDF that the Arduino framework hasn't picked up yet. @jamm says to ... 

"try replacing the file <your_user_profile>.platformio\packages\framework-arduinoespressif32\tools\sdk\lib\libesp_http_server.a with the one attached here.  Make a backup of the existing file, of course."

libesp_http_server.a

Edited by jeffpiep
tagged jamm
  • Like 1
Link to comment
Share on other sites

31 minutes ago, _The Doctor__ said:

Wonders if Grantic/Antic it can drive a native star nx rainbow, okidata, or Panasonic/ tandy color printer attached to the Atari rather than network file passage.

The original PRANTIC does Epson Graftrax in monochrome. I suppose the ESP code could be made to support other printers using GRANTIC.

  • Like 1
Link to comment
Share on other sites

5 minutes ago, jeffpiep said:

oh shoot - use Internet Explorer it surprisingly works. Ugh. There's an updated file in IDF that the Arduino framework hasn't picked up yet. @jamm says to ... 

"try replacing the file <your_user_profile>.platformio\packages\framework-arduinoespressif32\tools\sdk\lib\libesp_http_server.a with the one attached here.  Make a backup of the existing file, of course."

libesp_http_server.a 263.33 kB · 1 download

Any browser that isn't Chrome/Chromium/newEdge seems to work.  If you build with that attached library then Chrome/Chromium/newEdge should also work.

 

I'll be testing some other ways to address the problem this weekend!

 

  • Like 1
Link to comment
Share on other sites

11 minutes ago, jeffpiep said:

oh shoot - use Internet Explorer it surprisingly works. Ugh. There's an updated file in IDF that the Arduino framework hasn't picked up yet. Jamm says to ... 

"try replacing the file <your_user_profile>.platformio\packages\framework-arduinoespressif32\tools\sdk\lib\libesp_http_server.a with the one attached here.  Make a backup of the existing file, of course."

Yup, it works in internet explorer, not in google chrome. If I replace that file will it work in Chrome?

 

printout.png

  • Like 1
Link to comment
Share on other sites

1 minute ago, Fierodoug5 said:

Yup, it works in internet explorer, not in google chrome. If I replace that file will it work in Chrome?

 

printout.png

Yes.  It just happens that Chromium and its derivatives create a request that happens to be a bit larger than the buffer size baked into the web server component included with the ESP32 Arduino library.  The replacement file increases that buffer size.

 

  • Like 1
Link to comment
Share on other sites

5 minutes ago, jamm said:

Yes.  It just happens that Chromium and its derivatives create a request that happens to be a bit larger than the buffer size baked into the web server component included with the ESP32 Arduino library.  The replacement file increases that buffer size.

 

Cool, I will try that tomorrow and report back.

Link to comment
Share on other sites

1 hour ago, _The Doctor__ said:

Wonders if Grantic/Prantic it can drive a native star nx rainbow, okidata, or Panasonic/ tandy color printer attached to the Atari rather than network file passage. Also wonders if fujinet can just send the resulting file to a network printer... No wintel box involved :)

 

Please. Do. Not. Ask.

 

We deliberately printed to PDF/SVG/whatever because network printing is an absolute nightmare. It is the year 2020, and we still do not have a standards compliant way TO PRINT TO A FUCKING PRINTER!

 

SMB printing requires a full service SMB stack with all the trappings of one. I've contributed code to Samba, this is NOT TRIVIAL.

Nothing new supports JetDirect, and I don't expect people to go out of their way to support an ancient network pipe. (And to all of you who will whine that I am decrying this, please move out of 1998, pls, thank you.)

IPP requires CUPS, which requires either a Mac or a Linux box, Windows does not share its printers via IPP, but it can print to one.

Google Cloud print is going byebye at the end of the year.

Apple Cloud Print is exceedingly proprietary

Mopria requires a license to even see the protocol document.

 

In short, the future for printing is completely under IP lock and key, and it pisses me the fuck off.

 

So this is a good compromise in the mean time.

 

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

7 hours ago, tschak909 said:

SMB printing requires a full service SMB stack with all the trappings of one. I've contributed code to Samba, this is NOT TRIVIAL.

Nothing new supports JetDirect, and I don't expect people to go out of their way to support an ancient network pipe. (And to all of you who will whine that I am decrying this, please move out of 1998, pls, thank you.)

IPP requires CUPS, which requires either a Mac or a Linux box, Windows does not share its printers via IPP, but it can print to one.

Google Cloud print is going byebye at the end of the year.

Apple Cloud Print is exceedingly proprietary

Mopria requires a license to even see the protocol document.

You forgot lpd in your list ? OK, just kidding.

 

More seriously, nowadays IPP should be the way to go. It's an open standard (see RFCs 8010 and 8011), based on http and for a minimal IPP client it should be enough to implement the Print-Job message (which creates a print job and sends the document data in a single call).

 

(De-)serializing the binary IPP messages requires a bit of leg-work but it's not too hard, there's even a pure javascript implementation https://github.com/williamkapke/ipp

 

A lot of network printers nowadays can handle PDF natively, so if you already have a PDF renderer you should be fine.

 

I wouldn't care too much about all the older and/or proprietary protocols or standards, they'd be a huge PITA. For those situations a Raspberry Pi running cups to handle the translation looks like a better option.

 

so long,

 

Hias

  • Thanks 1
Link to comment
Share on other sites

2 hours ago, HiassofT said:

You forgot lpd in your list ? OK, just kidding.

 

More seriously, nowadays IPP should be the way to go. It's an open standard (see RFCs 8010 and 8011), based on http and for a minimal IPP client it should be enough to implement the Print-Job message (which creates a print job and sends the document data in a single call).

 

(De-)serializing the binary IPP messages requires a bit of leg-work but it's not too hard, there's even a pure javascript implementation https://github.com/williamkapke/ipp

 

A lot of network printers nowadays can handle PDF natively, so if you already have a PDF renderer you should be fine.

 

I wouldn't care too much about all the older and/or proprietary protocols or standards, they'd be a huge PITA. For those situations a Raspberry Pi running cups to handle the translation looks like a better option.

 

so long,

 

Hias

It wouldn't be difficult to support something like IPP from the perspective of sending data to the printer, but I do think it'd be a challenge to decide when to send the "print job" from the Atari to the destination printer.  Back in the Atari days, printers had a "form feed" button you would use to move the paper forward and eject the final portion of your printing.  There typically wasn't an "end of job" message in the software, so FujiNet would need to provide an interface for that.  It would be easy to do in FujiNet's web interface, but once you're at the point of having to connect to that interface to force and end to your printing operation, are you really saving much effort compared to sending the PDF to the printer yourself?

 

There are solutions to any problem, of course (e.g. we could wait for the user to send a specific code from the Atari, either to the emulated printer or to a separate "control" device like N:), it just strikes me as a very narrow use case.  i.e. The user would have to have a network-capable printer that supported IPP, and would have to be in a situation where sending the "I'm done" command/code was easier than sending the PDF to the printer themselves.

 

(Still thinking about how we could, in theory, handle it: we could send a job to the destination printer every time a Form Feed code is received. You'd probably be breaking a single document into multiple jobs, but the end result would probably still be what you wanted.  Except for those times it wasn't...)

Edited by jamm
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...