Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    My brother-in-law (Harry Moyes) has now got a Ulx3s, and he is a keen QL user, so I will probably have to get back to looking at the QL. I think he wanted floppy disk support and was thinking of implementing a QL expansion port.
    Erik Piehl
    @Speccery
    I have a small 240x240 display, 1.3" The pinout however on that one is different from the 96x64 system - of course I can still hook it up with cables. Is the one you're referring to something that has the same pinout?
    I also have a QL. Bought it on unknown condition, fixed it (it had problems with RAM) and I have now also a Gold card for it. The microdrives on it don't work, but I've now got a Gotek drive connected to the Goldcard and that works. The Goldcard has a 16MHz 68000 and 2Megs of RAM, so it makes for a nice QL. I'm still on the discovery phase for it, for example looking for ways to convert microdrive images to floppy images.
    Lawrie Griffiths
    @lawrie
    I had a QL when they came out, but have not used a real one since the mid 80s. My brother-in-law has some form of enhanced one.
    Compatible 7-pin 1.3" st7789s are cheap on ebay etc. The larger 8-pin st7789s are also usable. The 8th pin does not need to be connected.
    Erik Piehl
    @Speccery
    Ok thanks, need to order some then.
    emard
    @emard
    @Speccery if you have any 240x240 and it is very likely that inside is some ST7789, then yes you can connect with wires. Some have backlight on by default, some need some pin connected to 3.3V or GND to enable backlight, that's usually all the difference between them. I have some demo on ulx3s-misc so you check will yours work: https://github.com/emard/ulx3s-misc/tree/master/examples/hex/lcd_st7789_hex/proj
    emard
    @emard
    Have you seen Goran's tweeter, new v3.1.4 is assembled and passed self-test. It has some new features and needs further testing https://publish.twitter.com/?query=https%3A%2F%2Ftwitter.com%2FRadionaOrg%2Fstatus%2F1332696542499770370&widget=Tweet
    Paul Ruiz
    @pnru_gitlab

    @Speccery Excellent stuff on the Icy99 project. I'm seriously impressed.

    On the QL: If the original sound on your QL still works, it might be worth to compare its output with that of the FPGA version. What we have today is based on reverse engineering the 8049 code and creating an equivalent direct circuit -- we are not sure the output is (roughly) correct.

    On the microdrives there is an outstanding work item: implementing writes to the disk. The current FPGA/ESP32 design allows for it, but it is currently unimplemented.

    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard I am currently having a problem with the SDRAM driver for my Mac 128k/Mac Plus implementation. It is the same driver as I used for the QL and a lot of the code is similar to the QL. I noticed the problem when I switched on interrupts. The interrupt vector are copied to the SDRAM for the Mac. It writes $401A42 to address $64 for the level 1 interrupt. hen it is read back to execute the interrupt routines it gets the second 16-bit word at address $66, but the word at $64, which should be $40 is garbage. $66 might be correct because it is the last thing written. Any ideas what might be wrong.
    One thing I changed is the HDMI and SDRAM clock speeds to 125 rather than 135. I am trying putting that back. I am also trying different phase values. The code is here - https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v, but without the change that enables interrupts.
    emard
    @emard
    @lawrie first quick thing you can try is compare 12F and 85F. If it is fmax issue, 12F would perform better
    Lawrie Griffiths
    @lawrie
    I may be using too much BRAM for a 12F, but I can try a 45F.
    Lawrie Griffiths
    @lawrie
    It doesn't fit on the 12F, and seems to fail on the 45F.
    Lawrie Griffiths
    @lawrie
    Actually, the phase is irrelevant as @pnru_gitlab's SDRAM controller does not use the clock with the phase shift.
    Paul Ruiz
    @pnru_gitlab
    Can't investigate right now but it might be that the bus signals during an interrupt are different from during a normal memory read and that the sdram controller is not reacting correctly
    Lawrie Griffiths
    @lawrie
    I did think that the SDRAM had passed a memory test, so it could be something like that.
    Torfinn Ingolfsen
    @tingox_gitlab
    if I understand this correctly, ecpunpack can unpack a .bit bitstream to a .config file, which I then can repack with ecppack, for example to change idcode in the bitstream. Unfortunateky, it doesn't look like ecpunpack can do the same with a .svf format bitstream, or?
    emard
    @emard
    @tingox_gitlab No but bitstream.svf contains same bitstream reverse hex printed
    there is bit2svf.py also in trellis so you need own svf2bit, should be rather simple to make
    Simon Thornington
    @sthornington
    not that anyone here is interesting I am sure, but I got the (LiteX) wishbone debug bridge over US2 working with the main/master branch of the valenty USB core (DummyUsb endpoint). Seems reliable with cdc support enabled. But, SoC reset causes both US2 debugging as well as US1 JTAG programming to fail until unplug/replug
    Simon Thornington
    @sthornington
    random question - for ulx3s ECP5 85F, what FMAX should I be "happy with" ? Trying to recalibrate coming from Xilinx, it seems like 100MHz is quite hard to achieve ?
    emard
    @emard
    For well designed pipelined small cpu/soc 100MHz (f32c) should be possible but on the edge. For SDRAM driver 125 MHz should also easily always possible (overclocked ram test go to 180-200MHz). Small parts like video DVI shifter can do 350 MHz (overclocked work up to 600MHz, no guarantee all boards). Big soc like linux about 50MHz for CPU core, RAM 100MHz.
    Simon Thornington
    @sthornington
    Thanks, that helps
    Simon Thornington
    @sthornington
    I'm placing a small design on a big FPGA, are there any guides to encouraging nextpnr to place things closer together? for instance, I get much higher fmax targeting a 12F than an 85F
    Lawrie Griffiths
    @lawrie
    @sthornington That is impressive getting the the wishbone debug bridge working with a gateware usb implementation. Did you ever have it working on us1? There seems to be renewed interest in the LiteX SoC amongst newer Ulx3s users. I must give it a go sometime. I have recently been learning nmigen, and I have been a bit reluctant to learn migen as well. The nmigen USB device implementation in the Luna project should be a replacement for ValentyUSB.
    Which Risc-V implementation are you using with LiteX? Is it VexRiscv?
    Paul Ruiz
    @pnru_gitlab
    @lawrie Thinking about that interrupt in your MacPlus. I assume that this Mac uses interrupt auto-vectoring?
    @sthornington not that anyone here is interested I am sure wrong: I figure folks around here are interested.
    Lawrie Griffiths
    @lawrie
    Yes, I am pretty sure it uses auto-vectoring.. I am just about to push my current code, which sets auto-vectoring in the same way as the QL.
    I am planning to put back the SPI ram code that I could out from the QL version, so I can try reading and writing the SDRAM from the ESP32, as I am still not sure if it working in the normal case.
    The SDRAM test seems to be working, but does not seem to be detecting as much SDRAM as it should.
    Paul Ruiz
    @pnru_gitlab
    It could be that the autovector cycle interferes with the first vector read. If only looking at AS, UDS and LDS, the autovector cycle looks like a memory read cycle.
    Lawrie Griffiths
    @lawrie
    I push my latest changes. This is where I set vpa_n - https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L194
    I am unsure whether to set vpa_n for peripheral addresses, as I don't think the Mac needs the 68000 peripheral bus. It does not seem to make much difference if I set it for peripheral addresses or not. If I do set it, then I need to use vma_n.
    The symptoms are consistent with the first vector read going wrong, but when I added code to the cpu_din multiplexer to force the read of address $64 to return $400000, it did not help.
    Lawrie Griffiths
    @lawrie
    The symptoms are that the interrupt routine seems to be running code that makes no sense.
    Paul Ruiz
    @pnru_gitlab
    One useful test could be to replace the first 1024 bytes of RAM with block ram and see if that makes a difference. That will confirm / rule out sdram as the issue. Note that there is a typo in your ram module:
    https://github.com/lawrie/ulx3s_mac128/blob/main/src/ram.v#L8
    to force the read of address $64 to return $400000
    I assume you meant $40, to create address $0040xxxx?
    Lawrie Griffiths
    @lawrie
    Yes
    Thanks for pointing out the bug in ram.v. That must be in the QL version as well, but I am not currently using it for either project.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab i wrote the first 1024 words to BRAM as well as SDRAM so I can choose which one to set cpu_din to. It did not solve my problem with interrupts, so there must be another problem. However I still get the issue that I never see $40 read back from address $64 from SDRAM, but I do see it from BRAM.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I added the esp32 spi ram interface and the SDRAM interface seems to be working:
    >>> print(''.join('{:02x}'.format(x) for x in osd.peek(0x64,4)))                                                                                      
    00401a42
    emard
    @emard
    Could it be that 68k has some bus protocol during interrupts that on the data and addr bus appear some data related to interrupt priority and it's source, which may be fooling sdram driver which is for example only tested to work with stable bus state and clean requests when RAM data perisist on bus all the time during the RAM cyclue
    Lawrie Griffiths
    @lawrie
    That might be the case, but I am now using BRAM for low ram addresses, which ought to fix that. So my current problem is that the level 1 (VIA) interrupt does not work. It gets stuck in the rom at address $1942, but I am pretty sure if shouldn't be there. I tried patching the level 1 interrupt routine at $1A42 to do an immediate RTE, but that makes no difference, suggesting that it is jumping somewhere else for the interrupt.
    emard
    @emard
    Oh we had some VIA blues from VIC20 too, was hard to fix, mostly analyzing the code and writing fake VIA which matched to existing keyboard scan routine :)
    Paul Ruiz
    @pnru_gitlab

    I think we may have two different errors here. The first is that the sdram read appears to malfunction immediately after an autovector cycle. This I can verify in simulation. My hypothesis is that in between the autovector bus cycle and the read bus cycle an sdram refresh cycle is started, which causes the sdram read cycle to start late and hence data to arrive too late. This hypothesis can also be checked by slowing down the CPU.

    The second is that the interrupt vector seems to be interpreted wrong, regardless of whether it is hardcoded in verilog, coming from sdram or block ram. Is it possible that the interrupt signal is withdrawn too early, and the CPU is taking the "spurious interrupt" vector instead?

    Lawrie Griffiths
    @lawrie
    I agree that it seems to be two errors.
    Lawrie Griffiths
    @lawrie
    I don't think the interrupt is withdrawn too soon. It needs to execute code to write to VIA registers to withdraw the interrupt.
    It looks a bit like the SCC interrupt is executed rather than the VIA one, as the code it gets stuck in is related to the SCC (serial chip).