Lets actually try Hybrid Emulation

[zakk4223]

Code: Select all

bool works = false;
while(!works)
{
  fix();
  works = test();
}

Getting closer... Think I just fixed one last nasty bug and, fingers crossed, it'll work this time!

I can't help but notice your test function is undefined...

[foft]

I can't help but notice your test function is undefined...

Ah, that's the problem. I thought it was the lack of a fix function all along!

I've got something weird still with the chipmem accesses. Sometimes it responds much more slowly and sometimes not at all.

[foft]

I added fast ram. Oddly I'm getting spurious memory failures when using it. This is straight from the arm, so no fpga side involved (unless the fpga-hps bridge is writing here?).

I'm mmapping 0x20000000-0x20000000+384MB. That is the correct area reserved in the DDR for fast ram right?

edit: changed to 0x10000000 and it seems happier - be good to know the 'correct' address though.

[zakk4223]

Code: Select all

#define MISTER_SCALER_BASEADDR     0x20000000

That might explain things

[foft]

Haha, that'd do it! Do you know where the fast ram should go?

I can get to the boot screen and start loading some stuff now. Though its rather crashy! Probably this chip ram timing issue I need to dig into.

[lordoftime79]

its seems you having made amazing progress!!!

[foft]

I think/hope tonight I'll get it booted to workbench.

[lordoftime79]

^^^ This I wanna see!

[foft]

OK, perhaps another day

Been getting confused by a few things. For example the 68k bus dtack_n is supposed to be asserted when the data is ready for the cpu to read. However I see in the logic that dtack triggers the sdram controller to START a read. So then there is MUCH later chip_ready, way after the data is actually ready. Anyway this looks like its because minimig.v was written to use sram, which can get a result on the same cycle and here we are using sdram. However the timing was never adjusted to wait for the sdram. I'm not sure how fx68k works though since it uses dtack_n and ... works.

Anyway I'm starting to agree with @Sorgelig that I should go with a separate core for the hybrid. Then I can strip out a lot of the extra complexity that will be taken care of on the arm side: cache, fastram, etc etc. Then it becomes just an instance of minimig.v (modified for sdram rather than sram) and the hps-fpga interface logic. Anyway will sleep on it and think what to do tomorrow!

[robinsonb5]

Been getting confused by a few things. For example the 68k bus dtack_n is supposed to be asserted when the data is ready for the cpu to read. However I see in the logic that dtack triggers the sdram controller to START a read. So then there is MUCH later chip_ready, way after the data is actually ready.

What might be confusing you is that there are two different paths into Chip RAM. I'm not as familiar with MiSTer's Minimig core as I am the MiST/TC64 variant, so I'm not sure whether it's the D-Cache or AGA settings (or both) which determine which path is taken, but one roughly equates to A500 speed, the other to A1200 speed.

When using the slower path, the CPU sends requests to the custom chips, to the kickstart and to chip RAM all via Minimig.v which in turn sends the access to the SDRAM controller's "chip" port. In this mode, the TG68's cycle is terminated by the chipready signal which the CPU wrapper generates from DTACK.
FX68 has a more traditional 68k interface so uses DTACK directly.

In turbo mode the CPU bypasses minimig.v and accesses the SDRAM directly for Chip RAM and Kickstart. These cycles are terminated by the ramready signal instead.

Anyway this looks like its because minimig.v was written to use sram, which can get a result on the same cycle and here we are using sdram. However the timing was never adjusted to wait for the sdram. I'm not sure how fx68k works though since it uses dtack_n and ... works.

Minimig.v is designed to operate on the Amiga's original four 7MHz ticks per cycle, and the SDRAM controller has a fixed cycle, completing one round per 7Mhz tick with deterministic timing, so it's guaranteed to respond on schedule.

[foft]

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

Code: Select all

wire   enable = ~l_as & ~l_dtack & ~cck;
assign rd = enable & lr_w;
assign hwr = enable & ~lr_w & ~l_uds;
assign lwr = enable & ~lr_w & ~l_lds;

i.e. when dtack goes low enable is set. This sets the read request.
Then in gary it plumbs it to ram_rd

Code: Select all

//read write control signals
assign ram_rd  = dbr ? ~dbwe : cpu_rd;
assign ram_hwr = dbr ?  dbwe : cpu_hwr;
assign ram_lwr = dbr ?  dbwe : cpu_lwr;

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.

[foft]

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).

[foft]

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?

[robinsonb5]

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.

[foft]

So attempt 4...

Not sure what to do with cacr and vbr yet.

[foft]

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

[foft]

Or at lunch:)

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

[lordoftime79]

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

[foft]

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

[foft]

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...

[foft]

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.

[foft]

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

[foft]

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!

[xolod79]

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.

[foft]

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...

[robinsonb5]

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.

[foft]

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.

[foft]

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

[jca]

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

[foft]

We have workbench. Repeat, we have workbench!!

Many thanks for the help/advice @robinsonb5!