Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    @emard I believe the Mac only uses one disk at a time.
    emard
    @emard
    @jamon I'm experimenting with prototype v3.1.4 PCB. The boards sold at mouser v3.0.8 do not support serdes and of course chips soldered are non-serdes models.
    Paul Ruiz
    @pnru_gitlab

    @lawrie Had a second look. Complexity looks manageable, but I'm not sure it translates 1:1 to the ULX3S.

    The essence of the floppy stuff is in two files: iwm.v (this implements the logic of the drive controller 275 lines) and floppy.v (this implements a model of the floppy drive, 375 lines). If I understand the code correctly, it skips (de-)serialising the data and passes bytes between the two instead - which makes sense. The floppy model implements a fake motor speed signal, which I guess is needed for the Mac ROM code to work.

    The floppy model gets its data from a parallel flash chip on the Altera DE1 board - for which we do not have a direct equivalent on our board. I think the iwm.v code can be used more or less in tact (probably it is also in the Mister code). The floppy.v code would need the flash rom replaced by an interface to the ESP32. Doable, but not a 10-line fix.

    David Shah
    @daveshah1
    @emard remove the bel attribute and replace it with (* LOC = "DCU0" *) - or DCU1 if using channel 1
    Paul Ruiz
    @pnru_gitlab
    @lawrie One way to modify the floppy code could be to replace the flash memory with a block ram large enough to hold 12 sectors + formatting (a little over 2KB, I think). Whenever the track number changes, the ESP32 is asked to refill the buffer with the new track. The code already has a bit to signal that the track change is ready, as that exists on the real H/W too. The R/W code can then refer to the buffer instead of flash rom.
    emard
    @emard
    @daveshah1 Thanx, now I'm getting different errors, this is good hint
    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.