<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Another solution is to use (at a very low cost) an ESP8266 or ESP32 to bridge on the net throug WiFi. This is the kind of solution used with The ULX3 board (see <a href="http://radiona.org/ulx3s/">http://radiona.org/ulx3s/</a>).<br><br><div dir="ltr">Guy</div><div dir="ltr"><br><blockquote type="cite">On Jun 10, 2020, at 11:03 AM, Jörg <joerg.straube@iaeth.ch> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Daniel</span><br><span></span><br><span>Pipistrello is a small FPGA-based board, with 1 MB of SRAM and 64 MB of DRAM and an HDMI output</span><br><span>https://sigrok.org/wiki/Saanlima_Pipistrello_OLS</span><br><span></span><br><span>I have it at home, run Oberon on it with more than 1MB and have a TCP/IP stack for this external board https://www.wiznet.io/product-item/wiz550io/ </span><br><span></span><br><span>br</span><br><span>Jörg</span><br><span></span><br><span>Am 10.06.20, 16:07 schrieb "Oberon im Auftrag von Daniel Schmid" <oberon-bounces@lists.inf.ethz.ch im Auftrag von daniel.schmid@bluemail.ch>:</span><br><span></span><br><span>    Dear Oberon-Mailing-Listeners</span><br><span></span><br><span>    I'm rather new in using Oberon (AOS/A2), nevertheless i found it to be very straightforward.</span><br><span>    Currently i'm writing a server app to read out smart electricity meters over tcp/ip and it works</span><br><span>    fine. Now i read about this "Pipistrello" - could anybody tell me what it is about - i'm looking for</span><br><span>    a device/box/board to implement an smart IoT-Node to enhance smart metering further to a smart grid.</span><br><span></span><br><span>    Many thanks in advance for any explanations</span><br><span>    Daniel Schmid</span><br><span></span><br><span>    Am Donnerstag, den 28.05.2020, 12:00 +0200 schrieb oberon-request@lists.inf.ethz.ch:</span><br><blockquote type="cite"><span>Send Oberon mailing list submissions to</span><br></blockquote><blockquote type="cite"><span>    oberon@lists.inf.ethz.ch</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>To subscribe or unsubscribe via the World Wide Web, visit</span><br></blockquote><blockquote type="cite"><span>    https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br></blockquote><blockquote type="cite"><span>or, via email, send a message with subject or body 'help' to</span><br></blockquote><blockquote type="cite"><span>    oberon-request@lists.inf.ethz.ch</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>You can reach the person managing the list at</span><br></blockquote><blockquote type="cite"><span>    oberon-owner@lists.inf.ethz.ch</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>When replying, please edit your Subject line so it is more specific</span><br></blockquote><blockquote type="cite"><span>than "Re: Contents of Oberon digest..."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Today's Topics:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>   1. Project Oberon running from LPDDR memory on Pipistrello, now</span><br></blockquote><blockquote type="cite"><span>      with 8 bpp and 16 bpp color display modes (Magnus Karlsson)</span><br></blockquote><blockquote type="cite"><span>   2. Re: Project Oberon running from LPDDR memory on Pipistrello,</span><br></blockquote><blockquote type="cite"><span>      now with 8 bpp and 16 bpp color display modes (Magnus Karlsson)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>----------------------------------------------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Message: 1</span><br></blockquote><blockquote type="cite"><span>Date: Wed, 27 May 2020 15:50:42 -0700</span><br></blockquote><blockquote type="cite"><span>From: Magnus Karlsson <magnus@saanlima.com></span><br></blockquote><blockquote type="cite"><span>To: oberon@lists.inf.ethz.ch</span><br></blockquote><blockquote type="cite"><span>Subject: [Oberon] Project Oberon running from LPDDR memory on</span><br></blockquote><blockquote type="cite"><span>    Pipistrello, now with 8 bpp and 16 bpp color display modes</span><br></blockquote><blockquote type="cite"><span>Message-ID: <af111d4b-b57f-9599-19d2-ecdcf62144fc@saanlima.com></span><br></blockquote><blockquote type="cite"><span>Content-Type: text/plain; charset=utf-8; format=flowed</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have made updates to the code on github with the following changes:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* The code now has it's own repository with a master branch and two </span><br></blockquote><blockquote type="cite"><span>versions with color display added</span><br></blockquote><blockquote type="cite"><span>* The mono display buffer in BRAM is now 160 KB, big enough for a </span><br></blockquote><blockquote type="cite"><span>1440x900 display</span><br></blockquote><blockquote type="cite"><span>* The CPU clock is now coming from the memory controller PLL, leaving </span><br></blockquote><blockquote type="cite"><span>the video PLL free to implement any frequency needed by the video controller</span><br></blockquote><blockquote type="cite"><span>* The cache is now 64KB (2-way, 128-set, 256 bytes/cache line) to make </span><br></blockquote><blockquote type="cite"><span>room for the larger mono display buffer</span><br></blockquote><blockquote type="cite"><span>* The color version have 8 bpp or 16 bpp color video added in parallel </span><br></blockquote><blockquote type="cite"><span>with the mono display.? 8 bpp needs 1.5 MB memory, 16 bpp needs 3 MB </span><br></blockquote><blockquote type="cite"><span>memory for display buffer</span><br></blockquote><blockquote type="cite"><span>* The color buffer can be at any place in the 15.75 MB lpddr memory </span><br></blockquote><blockquote type="cite"><span>space (aligned to 16 bytes) controlled by a color buffer address register</span><br></blockquote><blockquote type="cite"><span>* When using color display the cache needs to be flushed.? There are </span><br></blockquote><blockquote type="cite"><span>several ways to flush the cache - on demand by software, on every vsync </span><br></blockquote><blockquote type="cite"><span>and using auto-flush where a cache line is flushed every 1024 CPU clocks.</span><br></blockquote><blockquote type="cite"><span>* The selection between mono display and color display is via a register </span><br></blockquote><blockquote type="cite"><span>bit.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>J?rg Straube have successfully shown the code working in both 1440x900 </span><br></blockquote><blockquote type="cite"><span>mono display mode and 8 bpp color display mode.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>https://github.com/Saanlima/RISC5Verilog_lpddr</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Cheers,</span><br></blockquote><blockquote type="cite"><span>Magnus</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 5/15/2020 7:53 AM, Magnus Karlsson wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>The project have been updated at </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This version is based on the current RISC5 verilog code (dated </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>11.12.2018).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>System info:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Cache size: 128 KB (2-way 256-set).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Cached area: lower 15.75 MB of the RISC5 memory map is mapped to </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>cache/lpddr memory.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The non-cached area (top 256 KB of the RISC5 memory map) is used for </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I/O (top 4KB), boot prom (next 4KB), then a free 248 KB area where the </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>video display buffer can be relocated .</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Video buffer is in BRAM and is located at the default place at power </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>up but can be relocated anywhere in the memory map by simply writing </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>to a new 24-bit video base register.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Since the video frame buffer is in non-cached BRAM there is no need to </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>flush the cache, which btw uses write-back policy.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The system will be slowed down by cache misses but there is about 11% </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>gain by having the video buffer in BRAM (no cpu stalls due to video </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>controller memory access).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Magnus</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Message: 2</span><br></blockquote><blockquote type="cite"><span>Date: Wed, 27 May 2020 16:05:49 -0700</span><br></blockquote><blockquote type="cite"><span>From: Magnus Karlsson <magnus@saanlima.com></span><br></blockquote><blockquote type="cite"><span>To: oberon@lists.inf.ethz.ch</span><br></blockquote><blockquote type="cite"><span>Subject: Re: [Oberon] Project Oberon running from LPDDR memory on</span><br></blockquote><blockquote type="cite"><span>    Pipistrello, now with 8 bpp and 16 bpp color display modes</span><br></blockquote><blockquote type="cite"><span>Message-ID: <3327a10d-9360-08d1-8bec-dc79a8020a73@saanlima.com></span><br></blockquote><blockquote type="cite"><span>Content-Type: text/plain; charset="utf-8"; Format="flowed"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Correction:</span><br></blockquote><blockquote type="cite"><span>8 bpp needs 0.75 MB memory, 16 bpp needs 1.5 MB memory for display buffer</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 5/27/2020 3:50 PM, Magnus Karlsson wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>I have made updates to the code on github with the following changes:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The code now has it's own repository with a master branch and two </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>versions with color display added</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The mono display buffer in BRAM is now 160 KB, big enough for a </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>1440x900 display</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The CPU clock is now coming from the memory controller PLL, leaving </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the video PLL free to implement any frequency needed by the video </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>controller</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The cache is now 64KB (2-way, 128-set, 256 bytes/cache line) to make </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>room for the larger mono display buffer</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The color version have 8 bpp or 16 bpp color video added in parallel </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>with the mono display. /8 bpp needs 0.75 MB memory, 16 bpp needs 1.5 </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>MB memory for display buffer /</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The color buffer can be at any place in the 15.75 MB lpddr memory </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>space (aligned to 16 bytes) controlled by a color buffer address register</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* When using color display the cache needs to be flushed.? There are </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>several ways to flush the cache - on demand by software, on every </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>vsync and using auto-flush where a cache line is flushed every 1024 </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>CPU clocks.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* The selection between mono display and color display is via a </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>register bit.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>J?rg Straube have successfully shown the code working in both 1440x900 </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>mono display mode and 8 bpp color display mode.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>https://github.com/Saanlima/RISC5Verilog_lpddr</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Cheers,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Magnus</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 5/15/2020 7:53 AM, Magnus Karlsson wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The project have been updated at </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>This version is based on the current RISC5 verilog code (dated </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>11.12.2018).</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>System info:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Cache size: 128 KB (2-way 256-set).</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Cached area: lower 15.75 MB of the RISC5 memory map is mapped to </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>cache/lpddr memory.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The non-cached area (top 256 KB of the RISC5 memory map) is used for </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I/O (top 4KB), boot prom (next 4KB), then a free 248 KB area where </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>the video display buffer can be relocated .</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Video buffer is in BRAM and is located at the default place at power </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>up but can be relocated anywhere in the memory map by simply writing </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>to a new 24-bit video base register.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Since the video frame buffer is in non-cached BRAM there is no need </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>to flush the cache, which btw uses write-back policy.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The system will be slowed down by cache misses but there is about 11% </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>gain by having the video buffer in BRAM (no cpu stalls due to video </span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>controller memory access).</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Magnus</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>-- </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-------------- next part --------------</span><br></blockquote><blockquote type="cite"><span>An HTML attachment was scrubbed...</span><br></blockquote><blockquote type="cite"><span>URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200527/fc6ac11a/attachment-0001.html</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Subject: Digest Footer</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>--</span><br></blockquote><blockquote type="cite"><span>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</span><br></blockquote><blockquote type="cite"><span>https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>End of Oberon Digest, Vol 192, Issue 43</span><br></blockquote><blockquote type="cite"><span>***************************************</span><br></blockquote><span></span><br><span>    --</span><br><span>    Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</span><br><span>    https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br><span></span><br><span></span><br><span></span><br><span>--</span><br><span>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</span><br><span>https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br></div></blockquote></body></html>