HiassofT Posted April 28, 2020 Share Posted April 28, 2020 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 1 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 28, 2020 Author Share Posted April 28, 2020 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 29, 2020 Author Share Posted April 29, 2020 #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. 4 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted April 29, 2020 Share Posted April 29, 2020 Hmmm, all of the multijoy games should convert nicely to fujinet!!! Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 29, 2020 Author Share Posted April 29, 2020 #ATARI8BIT #FujiNet developing #Assembler version of N: handler using AMAC/MEDIT. Using Amoeba for debugging. #FujiNet 1027 printer gives me a printed listing. -Thom 7 Quote Link to comment Share on other sites More sharing options...
MrMartian Posted April 30, 2020 Share Posted April 30, 2020 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! Quote Link to comment Share on other sites More sharing options...
mozzwald Posted April 30, 2020 Share Posted April 30, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Fierodoug5 Posted April 30, 2020 Share Posted April 30, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 30, 2020 Author Share Posted April 30, 2020 #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. 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 30, 2020 Author Share Posted April 30, 2020 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. Quote Link to comment Share on other sites More sharing options...
jeffpiep Posted April 30, 2020 Share Posted April 30, 2020 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: grantic.atr 9 1 Quote Link to comment Share on other sites More sharing options...
jeffpiep Posted April 30, 2020 Share Posted April 30, 2020 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! Quote Link to comment Share on other sites More sharing options...
MrMartian Posted May 1, 2020 Share Posted May 1, 2020 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 Quote Link to comment Share on other sites More sharing options...
Fierodoug5 Posted May 1, 2020 Share Posted May 1, 2020 (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 May 1, 2020 by Fierodoug5 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 1, 2020 Share Posted May 1, 2020 (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: 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 May 1, 2020 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
Fierodoug5 Posted May 1, 2020 Share Posted May 1, 2020 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. 6 Quote Link to comment Share on other sites More sharing options...
jeffpiep Posted May 1, 2020 Share Posted May 1, 2020 (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 May 1, 2020 by jeffpiep tagged jamm 1 Quote Link to comment Share on other sites More sharing options...
ClausB Posted May 1, 2020 Share Posted May 1, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
jamm Posted May 1, 2020 Share Posted May 1, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
Fierodoug5 Posted May 1, 2020 Share Posted May 1, 2020 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? 1 Quote Link to comment Share on other sites More sharing options...
jamm Posted May 1, 2020 Share Posted May 1, 2020 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? 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. 1 Quote Link to comment Share on other sites More sharing options...
Fierodoug5 Posted May 1, 2020 Share Posted May 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 1, 2020 Author Share Posted May 1, 2020 (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 May 1, 2020 by tschak909 2 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted May 1, 2020 Share Posted May 1, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
jamm Posted May 1, 2020 Share Posted May 1, 2020 (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 May 1, 2020 by jamm Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.