Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    nextpnr-ecp5 --timing-allow-fail --12k --package CABGA381 --json serdes.json --lpf ../../constraints/ulx3s_v31.lpf --textcfg ulx3s_12f_serdes.config
    ....
    ERROR: no DCU location 'DCU0' in device 'LFE5U-12F'
    ERROR: Packing design failed.
    David Shah
    @daveshah1
    You need to use LFE5UM5G-12F
    • LFE5UM5G-25F
    and then change the idcode back in ecppack
    emard
    @emard
    Yes yes how to specify option with parameters exacty?
    David Shah
    @daveshah1
    --um-25k
    emard
    @emard
    ahaaa
    David Shah
    @daveshah1
    and then --idcode 0x21111043 to ecppack if the device is a LFE5U-12F
    emard
    @emard
    Super, --um-25k passed, and with idcode it will be easy now
    yes it is 12F :)
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I am currently working on the SCC code for the mouse, which is turning out to be a lot more than a dozen lines. The Mister/PlusToo code describes the SCC register access as semi-insane.
    Paul Ruiz
    @pnru_gitlab

    @lawrie I suppose the chip is pin constrained and hence has indirect addressing of its registers. The TI 9918 video controller from MSX has something similar. Inconvenient? yes; insane? maybe.

    It would seem to me that we are in luck that the DSD bit is located in register 0, which is the one that is selected by default. So, I would think that all that is needed in a minimal implementation is to respond to reads with ab[2] = D/C = 0 (i.e. control, not data) and ab[1] = A/B to select between X1 (A channel, 1) and Y1 (B channel, 0). The DSD bit (which is wired to X1/Y1) is bit no. 3.

    Lawrie Griffiths
    @lawrie
    This what I currently have by copying what seems to be the relevant code from the Mister project - https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L234-L258 and https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L436-L483
    Paul Ruiz
    @pnru_gitlab
    That is indeed more solid code, also implementing the reset functionality - which is probably a good idea. They seem to implement just a few of the write registers (0, 1, 9 and 15). Unless it is yours, the diagnostic lines can be removed I suppose. Maybe I am missing things, but it seems that there is no code for register reads yet?
    Lawrie Griffiths
    @lawrie
    Yes, the diagnostics is mine. I am just seeing what paths it is following.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I have added some SCC read code now. I don't think I am triggering the interrupt yet. I need to check all the logic.
    Paul Ruiz
    @pnru_gitlab
    @lawrie This doc may be useful: http://www.zilog.com/docs/serial/ps0117.pdf
    For the real part to generate an interrupt, the "master interrupt enable" (bit 3 in R9), the "external interrupt enable" (bit 0 in R1) and the "DCD interrupt enable" (bit 3 in R15) need to be on. You may see logic like this in the Mister code. Note that R9 is shared between channel A and B.
    On the read side, apart from bit 3 in R0 you also need to have R3A implemented: it has the bits to indicate whether the interrupt came from channel A (bit 3) or channel B (bit 0).
    Still not sure how INT is cleared. It may be through the autovector bus cycle, it could also be a software clear: set bit 5 in R9 to enable software clearing, and read R2 to actually clear.
    Paul Ruiz
    @pnru_gitlab
    Had another look at your code: it seems the Mac is reseting a channel to clear the interrupt - so that is already covered. It also seems to only look at the DCD IE bit in R15, and take the other two IE bits for granted. If it works on the Mister, it must be enough.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I pushed a new version with some fixes. The SCC irq is definitely triggered now. Not sure if it is cleared correctly. The led that shows it set is staying rather bright, but that might just be because it is lower priority than the VIA irq. I was hoping that the cursor would move round the screen, but that is not happening. The"?" on the floppy disk is also not flashing, but I was assuming that was because IWM was not yet implemented.
    Lawrie Griffiths
    @lawrie
    I have added the iwm and floppy code unchanged from the PlusToo project. It currently builds and runs as far as before. So most of the code is there now, I just have to make it work.
    Paul Ruiz
    @pnru_gitlab
    I'll have a look. The SCC interrupt line staying active does not sound right: if the mouse does not move I would have expected it to be completely off.
    Lawrie Griffiths
    @lawrie
    I think the mouse should move, so I suspect something is wrong. The variable that holds the mouse position does not change. But I can see that it is executing the SCC interrupt routine, as I can press a button to cause a CPU halt and see the address in the level 2 interrupt routine on the lcd diagnostics. It spends a lot more time in the vblank VIA interrupt. I believe the SCC interrupt is supposed to update the variable and the vblank interrupt is supposed to redraw the mouse pointer.
    The level 2 interrupt routine is at address 1A84 in https://www.bigmessowires.com/rom-adapter/plus-rom-listing.asm
    Lawrie Griffiths
    @lawrie
    The code says it is reading RR2B.
    Paul Ruiz
    @pnru_gitlab
    Is this correct? I think maybe it should be x1/y1?
    https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L493-L494
    Lawrie Griffiths
    @lawrie
    You are right, I am rebuilding.
    The Mister code uses positive and negative clock enable signals and does some things on the negative edge. I will look at that to see if I can see why.
    I don't think the PlusToo code does that.
    Lawrie Griffiths
    @lawrie
    I think I probably need to implement register read 2b and implement rr2_vec_stat.
    Change to correct mouse values made no obvious difference.
    Paul Ruiz
    @pnru_gitlab
    Yes, it seems that register is used to calc a jump table. Sjeesh, the datasheet for RR2B is clear as mud.
    Lawrie Griffiths
    @lawrie
    This is the jump table 00401b1000401ab600401b1000401b1000401b1000401ac200401b1000400040
    If it jumps to entry 0, it will do nothing.
    Yosys is now crashing if I make minor changes. If I remove --abc9, it hangs.
    Paul Ruiz
    @pnru_gitlab
    The value to return for RR2B would seem to be 0x02 for a channel B int, 0x0a for a channel A int and 0x06 for no int. A takes priority over B. Don't think the Mac ROM requires more to implement.
    Lawrie Griffiths
    @lawrie
    I think that is what I tried, but didn't seem to make a difference. I will check. I then tried implementing register 2 to do it the way Mister does it, and that is when I started getting yosys errors.
    Paul Ruiz
    @pnru_gitlab
    I checked the jump table against the ROM listing and the values 0x2, 0x6 and 0xa make sense: no int is a no-op and the other two are the expected routines at 00401ab6 and 00401ac2 (the register value is doubled into offsets 4, 12 and 20 decimal).
    Lawrie Griffiths
    @lawrie
    This is what I tried, but it didn't seem to work:
      wire [2:0]  rr_vec_stat = ex_irq_ip_a ? 3'b101 : ex_irq_ip_b ? 3'b001 : 3'b011;
      wire [7:0]  rr2_b = {4'b0, rr_vec_stat, 1'b0};
    Lawrie Griffiths
    @lawrie
    I'll have another look at all this tomorrow.
    Paul Ruiz
    @pnru_gitlab

    OK. Your attempt seems correct to me. If the branch is correctly taken, the instruction at 1AE0 (a write of 0x10 to WR0) resets the interrupt. Maybe worth to check tomorrow if that write indeed happens. Immediately after that, the ROM code updates the mouse position.

    Just to be sure, you updated this too? Maybe a RR2A vs. RR2B typo?
    https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L261-L263

    Lawrie Griffiths
    @lawrie
    Yes, I did update that, but I will check it all again.
    emard
    @emard
    @daveshah1 I'm trying to apply REFCLKP,N to serdes RX reference clock for clock recovery. I think I need to instantiate EXTREF module (not sure), but do I need some compiler directive ( something ) to specify which REFCLK input for pins Y11 and Y12 (last page from https://github.com/emard/ulx3s/blob/master/doc/schematics_v314.pdf) and do I need something in LPF file about refclk pins constraints
    emard
    @emard
    So far, only "effect" I see is that same bitstream blinks LEDs on v3.1.4 board while it doesn't blink LEDs on v3.0.8, which have all serdes bank pins and power tied to GND.
    emard
    @emard
    First what I want to achieve is REFCLK clock recovery, then is receiving TMDS 10-bit symbols (8b10 ?) which I will internally generate with fake differential bitbanger to pins (OLED) that are on PCB connected (shared) with serdes RX, with series C=22nF
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab There were various bugs in my code, and I have pushed a new version of the Mac Plus. The SCC reset was all wrong. But I have not made progress in getting the mouse working. After a mouse movement the SCC interrupt routine is executed and it gets to address 1AB6 but not to the next instruction. It is as if it exits the interrupt routine there. So the interrupt is never reset, so keeps occurring.
    Paul Ruiz
    @pnru_gitlab
    I think the 68000 has prefetch, and hence it may be executing the RTE instruction at 1AB4. That in turn implies that somehow it is not reading RR2B correctly.
    Is the problem perhaps here:
    https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L532
    Maybe that should be { rdata, rdata }, or { 8'h00, rdata } ?
    Paul Ruiz
    @pnru_gitlab

    Ah, no, the issue is that your SCC runs at 8MHz and the CPU takes 4 clocks for a R/W cycle: the register index gets reset to zero before a read completes and hence reads the wrong value.

    I think the fix is to transfer rindex_latch to rindex only if ASn is high (deasserted) here:
    https://github.com/lawrie/ulx3s_mac128/blob/main/src/mac128.v#L475
    I mean if (cpu_as_n) rindex <= rindex_latch;
    This way the index change side effect is deferred until after the end of the read or write.

    Line 532 is correct: the SCC is on the high byte of the word.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I had no idea that the SCC read value not being stable for the required number of cycles could cause an effect like that.