ulx3s/Lobby

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

Lawrie Griffiths

@lawrie

@pnru_gitlab I am making some progress with the Mac Plus. I don't think it was calling the subroutine at 1BA6. I think my diagnostics, which uses the external address from the cpu just showed that address 00401AB6 was put on the bus when the RTE at 1AB$ was executed. Possibly a pre-fetch.

Lawrie Griffiths

@lawrie

I then determined that the addresses of the subroutines called at 1AAE are 1BA and 1CA, but should be 1B6 and 1CA, and both of these return the null subroutine at 1B10. If I path the value 401AC2 into 1CA from the ESP32 (after a reset and before moving the mouse), it calls 1AC2 and updates the variable containing the cursor position, but still does not cancel the SCC IRQ.

So it makes a bit more sense but I don't know why the read from RR2B seems to getting a value 2 greater than it should.

Lawrie Griffiths

@lawrie

(1AB$ should have been 1AB4, above).

Javier de Silóniz Sandino

@jdesiloniz

Hello everyone, I'm having a bit of an issue trying to build a project for ULX3S using Yosys/NextPNR (under apio). NextPNR seems to be complaining about combinational loops:

ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc.

But I don't seem to find what loops is it referring too. Forcing nextpnr to run ignoring errors, it throws this warning around 30 times. I thought it was because of how I handle FSM states but trying to follow a more "conventional" approach didn't seem to fix those. Doing so I got a seeming valid bitstream but in the FPGA it didn't work as expected (most of the signals didn't come out the expected ports at all), even though the simulations looked OK to me. So I think these timing issues could be the problem.

It's the first time that I try to create something for the board and I'm a bit lost on how to fix these issues... if anyone could help taking a look at the design and see if there's something obvious I might be missing I'd really appreciate it: https://github.com/jdesiloniz/ulx3s_numeric_display/tree/main/rtl

Thanks a lot!

Javier de Silóniz Sandino

@jdesiloniz

Just in case it helps, I've tried to add the files in the project to a new blank project one by one... and when I got to this one https://github.com/jdesiloniz/ulx3s_numeric_display/blob/main/rtl/wb_hc164.v I started to get the same amount of warning errors as before (or even more). The rest of files I haven't added are dependant on this one, so I can't discard they have their own issues too. But at least things I suspected could be the case (i.e.: the way I handle FSMs) are discarded, as for instance clk_divider.v doesn't create that issue and I could synthetize and run a small blinker on the ULX3S based on that without issues.

David Shah

@daveshah1

https://github.com/jdesiloniz/ulx3s_numeric_display/blob/dbc1ba8e7b1e7321a365c3490bd4a7a70a4bcd0d/rtl/led_display_controller.v#L242

Doesn't look right

state_next depending on itself is a combinational loop and likely to cause strange behaviour

Javier de Silóniz Sandino

@jdesiloniz

I guessed so too, but for instance isolating this file (that does the same): https://github.com/jdesiloniz/ulx3s_numeric_display/blob/main/rtl/clk_divider.v nextpnr doesn't complain at all

David Shah

@daveshah1

Thats such a simple case that Yosys might be optimising the loop away

Javier de Silóniz Sandino

@jdesiloniz

but I think I'll have to rewrite all state machines in the project, I was trying to avoid latches by not using if-else unless necessary

that's what I get for building everything based on the simulations and not trying to synthetize until the very "end" 😅

Where communities thrive

People

Repo info

Activity