Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Paul Ruiz
    @pnru_gitlab
    @lawrie Yes, that is the Mini Cortex. I built that back in 2014/2015 with lots of input from Stuart Conner, Jim Hearne and David Hunter.
    emard
    @emard
    @headkaze yes papilio is great a kind user sent me one board when it was already not possible to buy. ZPU or generaly anything that demonstrate use of wishbone bus is really great excersise if you'd like to prepare ports for ULX3s.
    headkaze
    @headkaze
    Yeah that's one of the things I liked about DesignLab IDE was you could see the connections between modules using wishbone. I like the visual aspect of creating ciruits.
    emard
    @emard
    @pnru_gitlab additional SPI trick: as SD is mounted in 1-bit mode, some pins are free and most SD cards are then relasing this pins in hi-Z mode. So for FPGA-SPI-ESP32 communication I use pin2,14 (I think) which would not be available if SD were mounted in 4-bit mode. If ever micropython gets 4-bit more properly and it justifies use with increased SD speed, we should move SPI away from those bits.
    Paul Ruiz
    @pnru_gitlab

    @lawrie Thanks for the tip! In the mean time it runs a much enhanced version of V6 with elements taken from V7, V8 and V9 and the TCP/IP stack from BBN (that ended up in 4.2BSD). This is what I want to get running on the ULX3S. It will also be the machine that talks to the Blit, running on another ULX3S.

    For a while in 2017/2018 I was planning to do a similar SBC with a 99105 or 99110 CPU and a better MMU. But then @Speccery convinced me that FPGA's were perhaps a more interesting route to go. It took me a long time to overcome my reluctance to a multi-gigabyte vendor tool download, but took the plunge. Luckily Trellis was just around the corner, as was the ULX3S.

    @emard Which pins would you recommend, if the SD Card was using 4 bit data?
    emard
    @emard
    Good question :) if looking at my yet unprototyped ESP32 rework, I'd suggest to avoid using gpio5 first. Then for example gpio16,17,25,26 can be ESP32->FPGA and gpio32 FPGA->ESP32. This of course partially "contaminates" external bus for PMODs GP,GN 11-13 but if you haven't soldered and plugged something should be ok
    When WROVER S2 comes (it yet has to proove that its USB works) then gpio 16,17 whould not be available but gpio 21,22 will appear but this is not yet even drawn as prototype so its too far in future...
    emard
    @emard
    General idea for new ulx3s2 is to get rid of FT231X chip and use USB connectivity of ESP32-WROVER-S2. currently S2 doesnt have micropython it has some circuitpython pre-release, for esp32ecp5 we need viper mode for some speed and overall stability (no crash more than 1x per hour )
    Paul Ruiz
    @pnru_gitlab
    I'm very old school as you know and would need to get used to a board without easy serial access. Or would there be a pmod for that?
    emard
    @emard
    In some ideal world S2 should have micropython application that provides usb-serial bridge. Without this it wouldn't be practical
    Paul Ruiz
    @pnru_gitlab
    By the way, are the schematics for Goran's dual usb and second gdpi boards online? Mainly interested in which pins they use and hence to avoid in other work.
    emard
    @emard
    all should be online. external GPDI is on GP9-13 those pins are shared with ESP32, it can't plug it anywhere else as those pins are true differential capable. USB modules uses GP20-27 it uses onbard 5V and also cant plug anywhere else
    headkaze
    @headkaze
    @pnru_gitlab esden has been streaming a series on YouTube designing a dual usb Pmod EP1 https://youtu.be/Qdwt3DKcY1k and EP2 https://youtu.be/-7PLP0N6sBU
    Paul Ruiz
    @pnru_gitlab
    Wow, that collection is much wider than I realized.
    Out of intetest, why is the next gen ULX3S named ULX3S2 and not ULX4S? I thought the previous gen was ULX2S.
    headkaze
    @headkaze
    ESP32 S2
    Paul Ruiz
    @pnru_gitlab
    @headkaze thanks for those lonks!
    Links
    e2kgh
    @e2kgh
    But the WROVER S2 doesn't support bluetooth anymore. Nobody cares?
    Paul Ruiz
    @pnru_gitlab
    Trying to connect a bluetooth keyboard and mouse is on my to do list....
    emard
    @emard
    @pnru_gitlab ULX4S should be some major release like turning ECP5 chip 180° rerouting everything to serdes video in/out or putting ECP6 or similar. ulx3s2 is just a idea for prototype in which there may be some experiment where we depend on how good S2 USB support will be. No bluetooth on S2 thats a pity, yes. If S2 gets composite USB support so that for example it creates multiple usb-serial ports, usb-eth, host kbds/mouses that would be much better than FT231X can offer now
    emard
    @emard
    @pnru_gitlab I god SD card mounted in 4-bit mode. FPGA should pull all SD pins up. Speedup is not that spectacular 800->1200 KB/s SD sandisk. one no-name SD card didnt want to enter 4-bit mode. https://github.com/emard/ulx3s-misc/tree/master/examples/sdcard/micropython
    e2kgh
    @e2kgh
    @pnru_gitlab : when you write about "blit", you're talking about Rob Pike's & Bart Locanthi's "Blit", or something else?
    e2kgh
    @e2kgh
    @emard: could ULX4S get 32bit SDRAM? ;-)
    @emard: I mean, 32bit wide ...
    Paul Ruiz
    @pnru_gitlab

    @e2kgh Yes, that is the blit I am talking about. There is a nice video here: http://doc.cat-v.org/bell_labs/blit/ For some background discussion see this Blit thread on the Unix Heritage mailing list https://minnie.tuhs.org/pipermail/tuhs/2019-December/date.html

    The Blit has (intentionally!) very simple hardware: just a basic 68K system with a bitmapped b/w graphics display. I have that done. All it needs now is a keyboard & mouse interface. I have two plans for this (i) use Goran's pmod and add a PS/2 mouse and keyboard - this requires some changes in the Blit software, but that is not a hard thing to do (it is standard 1980's C source code and a little bit of 68K assembler); and/or (ii) build MicroPython 1.12 (with IP forwarding enabled) and experiment with a bluetooth mouse and keyboard - this too requires some software changes for the Blit.

    Although it is more work, I like option (ii) as it has far less wire clutter on my workbench.

    headkaze
    @headkaze
    @pnru_gitlab We were recently talking about the implementation of a BT keyboard and mouse for the ESP32. I found a couple of relevant Github repos you might want to check out https://github.com/asterics/esp32_mouse_keyboard and https://github.com/chegewara/esp32-hid-keyboard-client
    Paul Ruiz
    @pnru_gitlab
    @emard Congrats on getting 4-bit SD Card access sorted out! I seem to remember that we discussed using pull-ups last October, but concluded - erroneously, it now appears - that SD Cards already had those built in. Also, enabling the ESP32 internal pull-ups did not solve it (maybe those are too weak, or do not work on bi-directional pins). In a way also good to know that the 4-wire speed up is limited - using SPI access feels less awkward now.
    @headkaze Thanks for those links!
    emard
    @emard
    @e2kgh ULX4S could get 32-bit SDRAM chip if largest package ECP5, 445 pins are used and slightly more expensive PCB technology. Currently we are out of free pins. There are less than 10 unused and those are practically unroutable. I have a board with 32-bit SDRAM and I know that every 16-bit project also works there I tried.
    e2kgh
    @e2kgh
    @emard : pullups on sd-card, 10k or even 4k7?
    @emard: 32-bit SDRAM, did Paul look into it already ? Is it much faster (higher bandwidth) then the 16-bit version?
    emard
    @emard
    However supply choice of different vedhors for 32-bit sdram is small are chips expensive so board price will rise. To get FER-KONČAR support in prototyping and assembly, design must be low-cost, 100$ for all parts if obtained in 1-pcb quanty and currently it is 92$ https://kitspace.org/boards/github.com/emard/ulx3s/ (click mouser).
    @e2kgh 32-bit SDRAM behaves just like 2 16-bit SDRAM glued togheter. All commands are the same, there are 4 byte select inputs and bandwidth is 2x later also they come in 64MB total size. They cost around 15$ compared to 32MB 16-bit around 2$
    emard
    @emard
    @pnru_gitlab I remember pullps discussion and that was exactly what I was aiming for. ESP32 pullups are weaker, and when it engages MMC driver ESP32 either doesnt or cant enable internal pullups so they require in datasheet for SD card to be pulled externally by 10k resistors. FPGA pullups are much stronger than ESP32's, I dont know how much they exactly are but obviously make SD card work. Loose 3 free pins for 40% speedup is not very fair trade, and I dont know why micropython is so inefficient because SD card should deliver 12MB/s (120mbit) in 4-bit mode
    It could be FAT driver the speedbraker
    Maybe a raw SD sector dump should be a better test
    emard
    @emard
    FAT is not speedbreaker, if buffer is larger 8-16KB it reaches its top speed above 2MB/s which is the same arduino gets from compiled C code:
    1-bit mode SDCard(slot=3):
    
        >>> import sdtest
        ['long_file.bin']
        1056 KB in 752 ms => 1404 KB/s file read
        4096 KB in 2746 ms => 1491 KB/s raw sector read
    
    4-bit mode SDCard():
    
        >>> import sdtest
        ['long_file.bin']
        1056 KB in 492 ms => 2146 KB/s file read
        4096 KB in 1777 ms => 2305 KB/s raw sector read
    emard
    @emard
    This itself should be faster than your WDC controller but there needs to be also SPI streamng back so this speed will be reduced, I expect something 0.25-1MB/s
    Paul Ruiz
    @pnru_gitlab

    It is not difficult to be faster than a 1980 MFM hard drive. For example the ST506, which is similar to the disks on the mini-computers of the late 70's. The track-to-track seek time was ~5ms (3ms step + 15ms settle) and there were a lot of track seeks happening. The main s/w optimisation was to sort the pending disk accesses by track, to minimise the seeking. The data rate was 5Mb/s = 625KB/s. The SD Card will not be the bottleneck, and even with the SPI_IDE bridge it will be about the same.

    Many thanks for the testing & measuring - much, much appreciated!

    emard
    @emard
    @pnru_gitlab I'm glad that we can make it technically possible. According to test from practical point of view, disk image can be a seeked file in SD cards FAT, SD raw access won't provide any speed. If buffer is 512 bytes 4-bit mode is unnoticeable faster than 1-bit mode.. If buffer is 8K then 4-bit will provide a small speedup
    Paul Ruiz
    @pnru_gitlab
    @e2kgh If you need more speed, perhaps a more advanced controller gets you there quicker. If you build a controller to do a 2-word burst read/write you get to 32 bit access at the expense of one more clock cycle (which you may even have available in your use case already) - this is a minor project. As @emard observed already, what really gets you ahead is combining the controller with a simple cache. For example, to fill a 64-byte cache line using one RAS and 8 consecutive CAS cycles of 4-word burst reads takes less than 40 clocks, 280ns on a speed grade 7 device. With maybe a 90% cache hit rate and 10ns bram access, your average access time would be a little less than 40ns. It is a much bigger project though. So far, none of my projects need that kind of bandwidth.
    Goran Mahovlic
    @goran-mahovlic
    What was easiest example I could try for checking if ENC28J60 PMOD is working - I finally managed to get some time to order parts and solder them all on board
    SaxonSoc probably - but I do not remember where I should connect it
    emard
    @emard
    @goran-mahovlic I see in esp32 micropython docs somehow esp32 also has ENC28J60, i tried to load this module but my mpy v1.12 doesn't have this module https://software.open-dev.ru/docs/online/micropython/library/network.ENC28J60.html
    It's a digiowl's mod/fork of micropython maybe so