MiSTer FPGA Forum

Thanks, that clarifies a few things.

I had taken the approach of plumbing in the 'almost avalon slave' interface into the cpu_wrapper.v then basically plugging it in into the cpu selection mux to replace the fx68k. My initial approach had worked 'mostly' ok. I cleaned/tidied some stuff up and then ... nothing worked ... despite my signals appearing to be ok in signal tap.

I was thinking that the aga/ocs switch was independent of this cpu mux. So was confused by this not affecting chip ram speed via the minimig.

Seems like instead of putting it in the mux I should put it in in place of the tg68k for now and take advantage of all that plumbing. Though I will 'steal' fast ram accesses upstream on the arm side.

re: dtack vs sram vs sdram
In the m68k bridge I saw this:// synchronous control signals i.e. when dtack goes low enable is set. This sets the read request.
Then in gary it plumbs it to ram_rd So ram_rd is only set at the time of the stack set. This then goes out of the sram interface. With I guess the assumption that the ram read completes on the dtack low cycle itself, by sram.

Thought it'd be easier to discuss with the hardware description...

cpu_wrapper.v.zip was my initial attempt at cpu_wrapper.v, which got as far as allowing diagrom to work.
Some clear mistakes here (e.g. wr is inverted), which I attempted to tackle in v2...

My second attempt didn't work at all! Not sure why yet... Here I had tried to clean things up and had high hopes! I looked at like a gazillion traces on signal tap...

So onto attempt three, which is just using chip and this doesn't work at all... Here I decided to bypass everything and just go straight to chip. I didn't try to debug this yet.

So onto attempt 4, following your explanation above (thanks). Here I'm going to ditch the mux change and try to plug in at the tg68k level. Which seems to be what I need if I want the aga speed up logic to work and to potentially take advantage of the chip ram caching. Since I'm mmapping the hps bridge with O_SYNC in its entirety (for the time being).

In terms of starting bus cycles should I be ok with the current glue to start on any clk cycle? Or should it only be on ph1 or ph2 enable for example?

foft wrote: ↑Wed Apr 14, 2021 7:41 am In terms of starting bus cycles should I be ok with the current glue to start on any clk cycle? Or should it only be on ph1 or ph2 enable for example?

I'm at work now so can't look in depth until tonight, but if you're replacing the TG68 then when you're accessing the SDRAM controller directly any cycle should be OK - and the logic at the end of the cpu_wrapper synchronises the CPU to the Minimig's 7Mhz cycle when necessary for chipset (or slow chip RAM / Kick) accesses.

So attempt 4...

Not sure what to do with cacr and vbr yet.

Yep, I'm also going to have to stop this and resume tonight after work.

Or at lunch:)

Clearly I missed the complete signal on that v4. Added that...

how do i use this? I thaught the zips contained a core but it dosnt seem to be the case.

Sorry this isn't a release yet, this is hardware description for dev discussion.

I managed to switch it to the tg68k interface and get it running for my simple test cases.

I'm still getting some bus transactions dropped on the floor, which I think is what was causing it to fail to boot properly before. I'll capture all the signals in/out of the 'hybrid 68k interface' in signal tap and post the capture here. Hopefully it'll be clearer to someone else who worked on the core before what could be going on.

I will also get the code so far uploaded to a GitHub fork for others to look at. Used to working on fpga stuff by myself...

So this is the hang I see intermittently, I make a request to access memory and there is never a response. Be curious if other minimig developers can see anything obvious in this capture.

Note that capture is on the 4x clock, so there may be some glitches within 1x clock cycles.

Now I posted that I see cpustate looks iffy, perhaps that is the problem

I changed that and don't think its hanging now, but I can't boot DiagROM or even change background colour now. Writes/reads to chipram are working and reads from rom are working. So better add yet more signals to signal tap so I can try to figure this out!

foft wrote: ↑Wed Apr 07, 2021 7:33 pm Hybrid has been talked about for years:
https://www.atari-forum.com/viewtopic.php?f=117&t=32674

I am very glad that there was a person who decided to take and try what they talked about so much. I watch the progress with interest.

I can change background colour actually, I had commented those lines in my test at some point.

So chip write/read and rom read and hardware write are now working. However it doesn't boot.

Musashi has a disassembler built in so guess I'd better see what is going on with that...

One thing to bear in mind: when the Amiga first starts up the Kickstart ROM is overlaid at location zero (until the relevant bit is cleared with a write to one the CIA registers) - the "Minimig" path knows how to handle that, but the direct-to-SDRAM path doesn't - so you should take the "minimig" path for Chip RAM accesses at bootup until the overlay's cancelled. I'm not sure how that's signalled to the CPU wrapper on MiSTer - I'll take a look...

Edit: OK - it looks like the fast path for chipram and kickstart is disabled via the cachecfg signal, the lower two bits of which are controlled by the kickstart overlay - so as long as you're using the slower "minimig" path any time the TG68 would have used it, this shouldn't be causing your problem.

I think perhaps the mem_ready, chip_ready is controlled by some of the things I'm outputting. I'm trying remove that from my cpustate signal, so cpustate is driven from registers only.

Its going to work this time, its going to work this time! I think that every time

So far you made incredible progress in the blink of an eye.

We have workbench. Repeat, we have workbench!!

Many thanks for the help/advice @robinsonb5!

One week since your original post
Did you get any sleep lately?
Congratulations!

So, ran sysinfo. Says its only half the speed of a 68040! Hmmm....

foft wrote: ↑Wed Apr 14, 2021 7:12 pm We have workbench. Repeat, we have workbench!!

That's just awesome news - well done!

FPGA history is being made in this thread!

foft wrote: ↑Wed Apr 14, 2021 7:28 pm So, ran sysinfo. Says its only half the speed of a 68040! Hmmm....

From (turbo) Chip RAM or ARM-side Fast RAM?
Didn't you say you were using Musashi? That doesn't do JIT, or does it?

As a baseline can you run a Dhrystone or something entirely ARM-side to see what the emulator itself is capable of on the SoC?

Well I have 8MB fast ram set up arm side.

Yes Musashi, looks like it pre-compiles a jump table then runs through those.

Yeah, investigating:-)

I actually don't have any vhd setup yet, so its all off adf files. Need to work out how to get lha archives on here!

Let me wire up reset then I'll upload a version to play with.

OK, here is the github fork for the hardware:
https://github.com/scrameta/Minimig-AGA_MiSTer

Here is also the latest test core.

NB how to use:
i) Start new core from the menu
ii) Set core to 68020, 2MB chip, 8MB fast and reset
iii) ssh into mister and start ./musashi_68020_mister

Should now work. Though when you reset it you currently need to restart musashi_68020_mister. I need to finish plumbing in reset.

Clearly very early version so likely lots won't work.

So tomorrow evening:
i) Wire up reset to make it less annoying to use!
ii) Wire up some settings so you can e.g. select fast ram
iii) Try to make it faster

That’s inspiringly awesome! Would love to get started with fpga stuff...

Tomorrow I’m going to try out Michal Schulz’s Emu68
https://github.com/michalsc/Emu68
Wish me luck!