Minimig on v2

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
  • Tobias , Thanks for the info.

    @robinsonb5. Thanks for the tips. I will check the monitor, but it's an old Medion monitor and you can't change a lot on this thing. I will also try the overscan prefs in the Workbench

    Anyway, I'm already happy that the minimig core is working.

    Great job

  • celco001,


    Can you please summarize what files are you using to start Amiga core with TC? Can you include the links where you downloaded them from? (if you are not infringing copyrights).


    Also, what is the right documentation to use.


    Thanks in advance for your help.

  • Mem corruption? Wrong phase relation between SD-Ram clock and SD-Ram address/commands and/or SD-Ram data? The Winbond RAMs are very forgiving if it comes to overclocking and setup/hold times, so they may "appear to work" even if the clock phase is off by 150 degrees.

  • Mem corruption? Wrong phase relation between SD-Ram clock and SD-Ram address/commands and/or SD-Ram data? The Winbond RAMs are very forgiving if it comes to overclocking and setup/hold times, so they may "appear to work" even if the clock phase is off by 150 degrees.

    It certainly looks like an SDRAM issue since the scrambled data isn't deterministic. The clock / phase relationship should be OK, though, since it hasn't changed since the V1 core, and the SDRAM signals meet IO timing in TimeQuest (they're about the only part of the core that does meet timing!).


    jab76 , could you do a couple of tests for me, please? Could you enable fast RAM in the OSD, then boot a workbench / system friendly disk of some kind, and let me know if it's stable? (When SDRAM timing's off, it's possible for single reads to work fine, but burst reads to fail - and Fast RAM uses burst reads.)

    Also could you see if Zeewolf 2 works, please? (That's a game I use as a smoketest, since it takes advantage of Fast RAM, and is also made more playable by the Turbo ChipRAM option.)

  • robinsonb5 : Certainly.


    I've enabled fast RAM and booted into Workbench. Both 1.3 and 3.1 and with kick 1.3 and 3.1. I didn't notice anything not working. I did think that the memory was displayed weird though as I'd enabled fast RAM, but avail didn't show any (not even after a reset).


    Oh, and I played some Zeewolf 2 and that also seemed to work.


    The strange this was that after I had accessed the video settings and the screen had scrambled up and the system had frozen on me, I waited for about a whole minute and after that I could read the items in the list and change them. The rest also would work fine again. Only now the file browser was all garbled.

  • I've enabled fast RAM and booted into Workbench. Both 1.3 and 3.1 and with kick 1.3 and 3.1. I didn't notice anything not working. I did think that the memory was displayed weird though as I'd enabled fast RAM, but avail didn't show any (not even after a reset).

    OK, well if the Fast RAM's not being reported in workbench after a reset then the Amiga's detecting that the RAM's not working properly and thus not adding it to the pool. So that's more evidence for an SDRAM problem.

    I'm guessing Zeewolf 2 doesn't run as smoothly/quickly as this? https://youtu.be/twFhmBbL2vc?t=156

    That's how it should run with Fast RAM and Turbo Chip RAM enabled.


    I'll do a couple of builds with the SDRAM clock shifted each way by half a nanosecond and see if it makes any difference.

    EDIT: Attached - two .rbf files. Both work fine on my TC64v2. Please test them both with the non-working OSD_CA01.sys file, and repeat the workbench / Zeewolf 2 tests.

  • You're right, it didn't run as smooth as in the video. I'm not familiar with the game, so I didn't know how smooth it runs with more ram.

    OK, thanks - it's all useful data.


    I've updated my post above with a couple more cores to try - when you get a chance please let me know if either of them performs better.


    Also, just out of interest, how are you powering your Chameleon?

  • robinsonb5 : thank you for providing the other cores. I've tried them out, but with the non-working OSD_CA01.sys file. Both also result in a red screen.


    When I remove the non-working OSD_CA01.sys file both cores do show a blue screen, but of course, there's not much to see then.


    I am using the TCv2 in cartridge mode connected to a C64 Reloaded MK1 with the power supply that came with it. I've also tried it in stand alone mode powered through a laptop. There's no difference with the cartridge mode.

    Furthermore, I've tried unpacking the non-working OSD_CA01.sys file with another program (WinZip), but that made no difference.


    I've tried the two cores with the working OSD_CA01.sys file and then they work fine, but Workbench still doesn't show any fast RAM.

    I've also tried Zeewolf 2 like that, but that doesn't seem any quicker. Certainly not in cartridge mode. I cannot test this in stand alone mode very well, because I don't have a docking station and therefore cannot connect any joysticks.


    Finally, with these two cores the video settings aren't garbled like the first core. I've saved a configuration and when I load up that configuration with the first core first and then access the video settings, then they aren't garbled. Of course this is all with the working OSD_CA01.sys file.


    Weird that I get a red screen with the non-working OSD_CA01.sys file and others don't seem to.

  • Weird that I get a red screen with the non-working OSD_CA01.sys file and others don't seem to.

    I think because the non-working OSD_CA01.sys is larger, it's placing a different part of the code in the portion of SDRAM that's causing trouble, so changing the symptom to a boot failure rather than a corrupted menu. Same cause - SDRAM problem - but a different symptom because the code layout is different.


    Could you try with the attached OSD_CA01.sys file, please? It won't boot the Minimig, but instead it will conduct a memory test (of just the portion of memory visible to the OSD module) - could you let me know whether you get loads of bad addresses scrolling by, or just a few, and maybe post a screenshot of the output?


    Also, could you try this core - http://wiki.icomp.de/w/images/d/df/Chameleon_hwtest.zip (make sure you use the V2 version of the core) - and let me know whether the middle animated stripe remains green at all times or goes red at all?

  • robinsonb5 I've tried with the attatched OSD file. There are no addresses scrolling by. Just a blue screen.

    And with the memcheck core, the stripe stays green.

    OK - well that reinforces the idea that the problem is with burst transfers. Here's yet another build (which, again, works fine on my TC64V2) - this time I've phase shifted the SDRAM clock a bit further, and also tightened the timing constraints. Could you let me know, please, if you see any change in behaviour with this version?

  • Also, another thought that struck me today: I remember another project where I had SDRAM issues which were cured by reducing the drive strength of the SDRAM signals. Here's a build with all signals reduced to 4ma drive strength (the default's 8). Again, will be interesting to find out if it makes any difference.