Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.
    I knew if was a potential problem because of this comment - https://github.com/MiSTer-devel/MacPlus_MiSTer/blob/master/rtl/scc.v#L132-L134
    Your solution seems to stop the SCC irq being generated at all. I am investigating.
    Lawrie Griffiths
    @lawrie
    I also tried the Mister solution using fx68_phi1 for cep and fx68_phi2 as cen, but I am not sure if they are equivalent. With that, the irq was generated, but I got the same problem as before.
    Lawrie Griffiths
    @lawrie
    I am not sure why the low byte of SCC and IRQ is set to 8'hef, I copied it from the Mister project - https://github.com/MiSTer-devel/MacPlus_MiSTer/blob/master/rtl/dataController_top.v#L135-L144
    I think the reason that the if (cpu_as_n) rindex <= rindex_latch change is not working if that it prevents register 1 from being written.
    Lawrie Griffiths
    @lawrie
    If I initialize wr1_a and wr1_b to 1, then the scc interrupt gets generated, but the original problem is still there.
    Paul Ruiz
    @pnru_gitlab
    Would in not make sense to run a simulation and see what is going on?
    Lawrie Griffiths
    @lawrie
    There are a lot of external interfaces to simulate including SDRAM and the mouse interface, so setting up a simulation environment doesn't look that easy.
    Lawrie Griffiths
    @lawrie
    I did confirm that the next rom address after executing the instruction at 1AB6 is 2424 which is the tight loop waiting for the floppy, so that is consistent with an RTE being executed.
    Paul Ruiz
    @pnru_gitlab

    There is an sdram simulator here, in the Mini Cortex test bench:
    https://gitlab.com/pnru/cortex/-/blob/master/sys_tb.v#L292-385
    Note that it only does 512KB of sdram as written, but making it larger is simple tweak.
    Maybe for a test it is easier not to simulate the mouse, but to generate eg. x1 directly and have a minimal test program in the ROM.

    If I have time tomorrow, I'll see if I can set up a test bench using the simple M68K system and the SCC code.

    AndrewCapon
    @AndrewCapon
    Hi Guys, So I just got an 85 and after a few hours of swearing have managed to get the makefile and apio stuff going on my mac. fujprog seems pretty slow though, setting the baud rate seems to make no difference at all. This is even more annoying with apio as the bitstreams are so much bigger (why is that?). Is there anything I can do to improve flashing speed? Cheers Andy.
    emard
    @emard
    @AndrewCapon of course, ulx3s usually ships with micropython on esp32 already installed so you just need to setup a password for your wifi by writing a new main.py and then you can use ftp over network to program, flash and even manage sd card. https://github.com/emard/esp32ecp5
    Torfinn Ingolfsen
    @tingox_gitlab
    also, if everything you need is in the bitstream, you can just upload it to RAM (omit the -j from fujprog) for testing, this is quicker (than flash) @AndrewCapon
    Lawrie Griffiths
    @lawrie
    @AndrewCapon When you start building large bitstreams, it takes so long in yosys and nextpnr, that you hardly notice the time that fujprog takes :)
    Lawrie Griffiths
    @lawrie
    Also apio might not be using --compress on ecppack.
    AndrewCapon
    @AndrewCapon
    Hi Guys, thanks for all the info. I will look at the esp32 route, I didn't realise this was enabled on the board, I had looked at the instructions to get it installed and thought "Maybe tomorrow" ;)

    Also apio might not be using --compress on ecppack.

    Nice, I will look at that. the bit files are many times bigger

    emard
    @emard
    @AndrewCapon All is instealled on esp32 and should work, but maybe the version is a bit older so if you have bugs, upgrade ecp5 files and micropython to v1.12. If no bugs, let it as is