Jump to content
tschak909

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

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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

#Atari8Bit #FujiNet The N: device allows you to easily make games that send network traffic using the UDP protocol, using nothing more than standard Atari I/O commands.

 

 

  • Like 4

Share this post


Link to post
Share on other sites

#ATARI8BIT #FujiNet developing #Assembler version of N: handler using AMAC/MEDIT. Using Amoeba for debugging. #FujiNet 1027 printer gives me a printed listing.

 

-Thom

 

20200429_132858.thumb.jpg.e292e48ff6bc2a7676147e3da887d10e.jpg

 

20200429_132938.thumb.jpg.f0616debd92d4b8cbca8d1bc901d411a.jpg

 

20200429_135022.thumb.jpg.1481bf8cc13c169e482eb9d68182a9e5.jpg

 

20200429_135404.thumb.jpg.c24b55246e472942c83564a3a9d38590.jpg

  • Like 7

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

#Atari8bit #FujiNet Shown here is the process I am using to develop the second version of the CIO handler, written in the ACTION! editor, assembled with the Atari Macro Assembler, and debugged with the Amoeba debugger.

 


 

  • Like 2

Share this post


Link to post
Share on other sites

shit, sorry, I've realized the last few videos of mine were being processed with software encoding (OBS changed settings on me), I have fixed this, and going forward, the videos should be fine.

 

Share this post


Link to post
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 8
  • Thanks 1

Share this post


Link to post
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!

Share this post


Link to post
Share on other sites

Thanks yeah, already got the software stack set up, built, installed.. Then found out I don't have any 470 ohm resistors.. :(

 

I'll have to wait for those

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
Share on other sites

I built another Fujinet(ESP32Wroom) so now I have twins.

Have one on a stock Atari 800, and the other one on a stock 800XL.

 

IMG_20200430_212935-2.jpg

  • Like 5

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
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.

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...