hoglet67 / BeebFpga

47 stars 8 forks source link

ATOMBusmon compilation #18

Closed sharpie7 closed 2 years ago

sharpie7 commented 2 years ago

Hi Dave,

Maybe a stupid question, but does the ATOMBusMonitor option compile OK on your platforms?

I haven't spent a lot of time looking at it, but I did a quick try on my port and got errors about duplicate component defintions (6502, 65C02) and then when these were cleaned up another load of errors about multiple drivers for busses connected to the CPU.

Any hints for how to approach porting it?

Thanks

hoglet67 commented 2 years ago

It's been OK when I recently compiled the Pynq Z2 and Papilio Duo targets (which are both Xilinx).

You do need to be careful which vhdl files you include in BeebFPGA, because the 6502 does appear both in AtomBusMon/src and in BeebFpga/src/common. So you need to make sure you only include one.

Did you create your project from scratch, or did you base it on one of the existing ones?

Can you commit your broken project file to a branch? Then I can take a look.

sharpie7 commented 2 years ago

Thanks. Let me have another go and put a version where you can see it.

I managed to debug the immediate problem with SignalTap II in Quartus which was laborious, but at least I learnt how to use it. So, this isn't so urgent right now, but I would like to have ATOMBusMonitor work because it is such a good feature.

sharpie7 commented 2 years ago

I've sorted out the original problem. In the MiSTer beeb the 6502 and 65C02 are both compiled and the active one is selected in real-time depending on the menu choice of the model to be simulated. I had forgotten to allow for that.

It seems to be building OK now, but I am having trouble connecting to the AVR serial port. Symptoms suggest it is the wrong speed, but I haven't put a scope on it yet to check.

One question: what frequency should be clock_avr? I see suggestions in the code of 24MHz and 16MHz. Does anything about the phase to other clocks matter?

Also, can you confirm the AVR should be 57600 BAUD?

Thanks

sharpie7 commented 2 years ago

More info: I've broken the AVR_TXD to an IO pin rather than the internal connection to the Hard CPU in MiSTer which is what it normally does with UART signals.

With the AVR running at 24MHz I seem to be seeing serial data out at 115200 BAUD

hoglet67 commented 2 years ago

The expected speed at 24MHz is 115,200 baud.

hoglet67 commented 2 years ago

When I started work on AtomBusMon I was using slower Spartan 3E devices. The fastest I could run the AVR at was 16MHz, and at that clock speed the UART divider doesn't work out close to an integer value for 115,200 baud. Hence originally running at 57,600 baud.

When I moved to include Spartan 6, I was able to increase the AVR clock rate to 24MHz, and at that speed the ideal divider for 115,200 works out to be very close to 13 (13.021 I think).

The divider is compiled into the firmware and written to a AVR register on startup. The he precompiled firmware builds I use for BeebFPGA now assume a 24MHz clock and 115,200 baud.

This is all easy to change in the Makefile: https://github.com/hoglet67/AtomBusMon/blob/dev/target/lx9_dave/ice6502/Makefile

Dave

hoglet67 commented 2 years ago

One thing to note: ideally you would have different AVR firmware for the Model B (6502) and Master (65C02) builds, as the disassembler is different. In paractice it's no great hardware to use the 62C02 firmware for both. The disassembler is the only software difference.

sharpie7 commented 2 years ago

Thanks. On the scope it looks very much like it has the right serial data on the external pins, but trying to access the UART via the MiSTer Linux enironment is very glitchy. Can't quite work out why, but I am pretty sure it's nothing to do with your code at this point!

sharpie7 commented 2 years ago

It's all working now. Thanks for your help. I will try and get it packed for release soon.

The MiSTer platform with the on-board ARM and several memory options could support some really fancy debugging and capture options if you optimised for that platform, but I can't really see the benefit justifying the cost as far as that goes!