Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    Yes, I created a c program with cat.
    Lawrie Griffiths
    @lawrie
    It has the "ed" line editor.
    Lawrie Griffiths
    @lawrie
    Not sure what server.c is doing.
    Paul Ruiz
    @pnru_gitlab
    @lawrie Yes it has ed, the original editor written by Ken Thompson himself. It is still mandated by the Unix standard, so OS X and Linux still have it. vi was initially written by Bill Joy and is too large to run on the Mini Cortex. It needs separate I/D spaces which the 9995 does not support. It is supported on the 99000 though, so it is high on my list of to-do's. I do have the s editor (I think I have it at /s) which is a vi-like editor: https://github.com/udo-munk/s
    The S editor assumes an ansi terminal, so make sure you use that. No support for arrow keys, use H, J, K and L for that (as you would in the original vi).
    Lawrie Griffiths
    @lawrie
    I have hacked your pnr password. Interesting choice.
    Paul Ruiz
    @pnru_gitlab
    @lawrie the disk image is a copy of my working disk. I was experimenting with adding the file system switch from V8 unix and add a /proc file system and Unix domain sockets. That worked, but was in a state of flux, printing kernel debug messages and maybe not stable. I reverted the kernel to my stable version from a few months ago, but some of the user land test files are still there. server.c was one of them.
    Lawrie Griffiths
    @lawrie
    # passwd ka
    Usage: passwd user password
    # passwd ka aline
    # grep ka /etc/passwd
    ka:ugiTjezp:11:1::/usr/ka:
    # passwd ka ladne
    # grep ka /etc/passwd
    ka:ugiTjezp:11:1::/usr/ka:
    emard
    @emard
    "/s" editor works! But how I regularly exit? esc :w saves but esc :wq, :q, :q! I tried to exit but none works
    Lawrie Griffiths
    @lawrie
    q exited for me.
    emard
    @emard
    Yes sometimes works sometimes not, strange but ok, generaly source changes and hello.c compiles in 13s here :)
    Lawrie Griffiths
    @lawrie
    Keyboard seems to stop working with /s.
    emard
    @emard
    I like how fast it boots and gets prompt, even exe's are short, responds fast to prompt and only 6 MHz 16-bit CPU. Wonder are elf, ld, systemd all only to counterbalance for GB of RAM and GHz of CPU... Instead of 9600 I'd like to have 115200 ... :)
    Paul Ruiz
    @pnru_gitlab

    @lawrie Yes, that delightful anecdote is how I got to use that on the Mini Cortex. The M209 cypher used on V5/V6 Unix was an assembler routine that I had to port I figured that if my implementation hashed both aline and ladne to ugiTjezp, I would have the algorithm correct.

    The cypher was already weak at the time: with a few bits of hardware it would be susceptible to a brute force attack. In V7 (1979) it was replaced by triple DES as the crypt algorithm.

    Lawrie Griffiths
    @lawrie
    BTW, I have it running on a Blue 85f.
    Paul Ruiz
    @pnru_gitlab

    The s port is something that I have not used much. It may have bugs. For sure I know it crashes if it has to load a file that is too big to fit in memory. Strange as it may sound, ed is not all bad once you get (back) into it.

    The s commands are here: https://github.com/udo-munk/s/blob/master/commands.c#L17,L40 and the address specifiers are here: https://github.com/udo-munk/s/blob/master/address.c#L17,L53 All based on ancient vi.

    To save and exit the command is Z Z.

    To understand some of the key combinations, remember that vi was written for the ADM-3A terminal keyboard:

    If you find repeatable bugs, please let me know - maybe I can fix them easily.

    Paul Ruiz
    @pnru_gitlab
    @emard hello.c compiles in 13s here :) Yes, same here (obviously). I think the main time eater is the way that my current disk code interacts with the IDE interface: it byte-bangs the sector. What I wanted on the new SBC that I was planning, was to add a TMS9911 DMA chip that can move a sector in 512 machine cycles. My guess is that implementing that will take the compile time down to 3-4 seconds. Another improvement would be to add a "ranlib" index to libraries - that was a V7 invention that I have not implemented as yet. That may slice another second of the total compile time.
    emard
    @emard
    Some speedup can also be done with increasing block size or caching more blocks to get 8KB SPI transaction, then using 4-bit mode makes some improvement
    Paul Ruiz
    @pnru_gitlab

    @emard I like how fast it boots and gets prompt, even exe's are short, responds fast to prompt and only 6 MHz 16-bit CPU. Wonder are elf, ld, systemd all only to counterbalance for GB of RAM and GHz of CPU...

    Well, the PDP-11 was a 6MHz 16-bit machine and the VAX 750 ran at 8MHz. That is the hardware both Unix and the Internet were invented with. Unix has had ld since the earliest days. I don't care much for systemd which is trying to do entirely too much - but at the same time init is too simple a solution for a world with pluggable hardware. elf (or at least dynamic libraries) are a good idea in a bigger memory space. Without it, V7 Unix has about 5KB of stdio code duplicated in dozens of binaries - surely that is not quite right either.

    emard
    @emard
    Yes how about FPGA tools, most desireable stuff is statically linked see this cutie:
    ls -alh /usr/bin/nextpnr-ecp5 
    -rwxr-xr-x 1 root root 111M kol   2 05:32 /usr/bin/nextpnr-ecp5
    Anyway I got some i2c master stuff from net and will try make rtc reader example
    Paul Ruiz
    @pnru_gitlab

    @emard Instead of 9600 I'd like to have 115200 ... :)

    That is 12 times the speed. If we hook up h/w handshaking it is possible as a minimal fix, but that of course will not get your throughput up much. The problem is that the 9902 interrupts once for each character sent and received: at 12 times the speed the CPU would have a hard time to keep up. However, other manufacturers (read DEC) had I/O boards with buffers. It will not be too difficult to make a special UART chip in Verilog with buffers so that the CPU could R/W multiple bytes on each interrupt. What do you need it for?

    emard
    @emard
    Just 115200 to have default speed with connecting to python prompt and unix, nothing else. It can be char-by-char slow
    Paul Ruiz
    @pnru_gitlab
    I'll see what I can do. Maybe with H/W flow control and the 9902 set to its fastest mode, it can do 115200.
    emard
    @emard
    If it matters something, also experminenting with PLL clock around 6MHz to get a closest multiple of 115200 may help serial dividers get correct ratio
    It's already great, 115200*54=6.22 MHz (actual 6.25 right thing)
    Paul Ruiz
    @pnru_gitlab
    The 9902 operates on an internal frequency of 1MHz. We can try to set the half-bit timer to 4: this gives a bit time of 8us, which is 8.5% off from correct. This may be within the FTDI tolerance. Look at /rom/evmfast.mem, lines 12 to 14. Change all the 0001 bytes to 0004. Recompile with the ROM filled with evmfast.
    Paul Ruiz
    @pnru_gitlab
    Come to think of it - the 9902 was designed for a DTE role and assumes that it will always be faster than the modem. Hence it has RTS/CTS, but not DTR. For your convenience, maybe a hardwired DTR signal that reduces flow to ~9600 baud equivalent is the solution.
    emard
    @emard
    You mean a serial baud converter core, that would accept 115200 and with DTR signaling reduce it to 9600?
    And also retransmit at speed 9600 when communicating to TMS9902 side (FTDI side will be 115200)?
    Paul Ruiz
    @pnru_gitlab
    Yes. Thinking a bit more adding DTR to the 9902 is not very hard either: is should de-assert as soon as a character starts being received and re-assert after the CPU has read the byte. I cannot replicate that in vintage hardware, but it would be just a few lines of Verilog in the 9902 code. Just to be sure: which FTDI flow control lines are hooked up to the FPGA?
    emard
    @emard
    All FTDI flow lines are going to FPGA on ULX3S
    Ups sorry! Maybe NOT!
    Flow lines are used for JTAG aiieee
    Only RTS and DTR lines are available to userspace bitstream, rest goes to JTAG
    Paul Ruiz
    @pnru_gitlab
    Have to read up on my RS232 again. I always forget how RTS/DTR are hooked up after RS232 became symmetric. Originally RTS and DTR were used both to signal from the computer to the modem.
    emard
    @emard
    Yes by default those are lines when FTDI outputs to FPGA by default. JTAG lines are intentionally used all default inputs in order to be high-z if FTDI is untouched so that external JTAG or ESP32 JTAG will work
    So I guess there's no return line where FPGA can say FTDI to halt transmission. Theoretically linux driver can be altered to reprogram one of RTS or DTR as input and for a different purpose than default but that would lead us to much more complicated solution than just using 9600 :)
    Gopal Kankanhalli
    @gkankanh
    High Speed A/D conversion help
    First of all thanks for the fantastic work that you guys are doing.Amazing.
    Need some general advise/tips on high speed A/D conversion on ULX3S using on board MAX11125.
    Here is what I have learned so far. Use the internal clock @ say 300MHZ to drive the AD conversion.
    What is the most efficient way to transfer the samples to a host for analysis?
    ESP32 connection to a host using UDP may be?
    I feel Ethernet would give me more throughput.
    Comments appreciated. Thanks in advance.
    emard
    @emard
    @gkankanh MAX11125 is 1Msa/s total so e.g. if you use 4ch then each channel will be 0.25MSa/s per channel. For oscilloscope it, we have ready solution at hdl4fpga/ULX3S/scopeio you will see traces on monitor. For analysis, onboard USB-serial can do 3Mbps so it could be nearly useable. For faster ADC, yes 100 Mbit ethernet ETH8720 from ebay, module for 2.2$ and for example ebay's AN108 AD/DA module 32MSa/s input, 125MSa/s output https://www.ebay.com/itm/ADDA-Module-Data-Signal-Acquisition-High-speed-Directly-pluggable-connector-/253556250998 also scopeio supports it
    Gopal Kankanhalli
    @gkankanh
    @emard Thanks for the guidance.Appreciate it.
    emard
    @emard
    youre'welcome, I also added to MANUAL.md of ulx3s about the AD/DA modules. They costed $20 but now are expensive near 60$
    @pnru_gitlab https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/i2c_master/proj here is small RTC i2c master example. It will display seconds on LEDs as BCD and full date/time on st7789 mini display.
    Paul Ruiz
    @pnru_gitlab

    Looked into early RTC chips. The first one seems to have been the OKI MSM5832, which was used on a few S-100 boards around 1980. It has an awkward 4 bit interface though. If I get around to a new SBC I will probably use the MM58167. The software interface is always the same: a bank of byte registers with the time / alarm / config data (and sometimes 50-100 bytes of nvram).

    @emard I am not sure which chip the ULX3S uses. The crowd supply page says MCP7940 but the schematic refers to the PCF8523. Both seem to have the same "bank of registers interface, though. If you can provide me with a verilog module that connects to the RTC chip and offers a bus interface similar to that of MM58167 to the CPU, I will integrate it with the Mini Cortex and write the Unix driver for it. I am not bothered if the registers don't match in number or meaning with the MM58167.

    It would be fun to have shutdown -r working on a V6 :^)

    Sometimes life is simpler than first imagined. I realized that 9600 Baud is about 1000 characters per second and the Cortex cannot keep up with even that. Luckily nobody types that fast. I did the change to the rom to set the half-bit timer to 4 clocks but the FTDI does not accept that - too far off. Then I also tweaked the internal clock of the 9902 by changing the divider from 25 to 27. Now it works fine at 115200. Just don't type at that speed.
    Paul Ruiz
    @pnru_gitlab
    The rom change is this:
    0460 0142 0009 0004 0012 0004 0023 0004 // 0x0080 // baud 115200
    0046 0004 008d 0004 0119 0004 02a4 0004 // 0x0090 // baud 115200
    7fff 0004 0d0a 4552 524f 5220 000d 0a45 // 0x00a0 // baud 115200
    emard
    @emard
    It is MCP7940N used now. Early v1.7 boards had PCF8523 but it was unreliable, forgetting time and MCP is cheaper and better. It has documented bug that setting time registers must be verified by read and retried until desired value is read there. The verilog module is here https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/i2c_master/proj however it only reads RTC. RTC will start "ticking" after it has been initialized and for this we have esp32 and ntp: https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/micropython-mcp7940n
    Verilog module can write also but I haven't implemented some "gui" for user friendly setup