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.
  • What should i look for?

    Could you enable Fast RAM in the OSD, Reset the Amiga then run SysInfo, and see how many memory regions show up on the Memory page. With everything maxed out there should be four - one starting at 0x40000000, one starting at 0x00200000, one starting at 0x00c00000 and one starting at 0x00000000

    I suspect that you're only going to see the latter two.

    If you run the speed test you should see a speed of about 9 MIPS. If Fast RAM isn't enabled it will be significantly less.

    If the Fast RAM is showing up, then could you run the two memory testers, please, and let me know whether they throw any errors?


    Edit: and here's another core to test, please. (No actual changes except to phase shift and build settings, unpicking some more changes from troubleshooting jab76's issue, in the hope that it will behave on your Chameleon once again.)

  • the core works, but still no change regarding behaviour with fastram....


    Quote

    I suspect that you're only going to see the latter two.

    correct, one named "memory at 0x00c00000", the other "chip memory at 0x00000000". no fast ram


    speedtest in sysinfo shows 0,6Mips :)


    Quote

    in the hope that it will behave on your Chameleon once again

    btw, just to say it uncase i didnt - i always used my old sd card before, containing this older OSD. it probably never worked with the newer one.

  • I've just put the older OSD file on an SD card and tried it - I didn't realise it was quite that old! The way Fast RAM is configured has changed since then, so you won't be able to configure fast RAM with the old OSD.


    Does the new OSD work on the newest core?

  • no, newer OSD doesnt work at all, on any of the v2 cores

    OK. Well now I know that Fast RAM isn't supposed to be working with the older OSD, I no longer think it's an SDRAM problem. I suspect now that the very minimal filesystem code in the OSD CPU's boot ROM isn't properly following cluster chains - so your earlier comment about the older OSD being less than 64K could well be the reason it works and the newer one doesn't. Just out of interest, how do you format your SD cards?

  • i use mkfs.vfat usually (on linux).... i will try with a cleanly formatted 16mb card (yes i have one =D) - there is hardly anything that could go wrong then


    edit: holy maccaroni! thats it... formatted sd card, copied OSD on it as first file, then kick.rom, then some adfs.... and it works. so indeed, this very much points at a bug in the initial loader :)

  • edit: holy maccaroni! thats it... formatted sd card, copied OSD on it as first file, then kick.rom, then some adfs.... and it works. so indeed, this very much points at a bug in the initial loader :)

    That's great news - thanks for testing. A long time ago I experimented with replacing the OSD CPU with a ZPU instead of the TG68 (since the latter is quite large), and in the process rewrote the boot loader in C. I'll build that version for 68K and see what happens...

  • OK here's a new core and a new OSD file to go with it. The core contains new boot code written in C, which should deal better with following cluster chains than the old ASM code - or at least be easier to debug if it's still not working correctly. There is also a new OSD file - the only difference between this and the previous version is that the location of the stack has changed.


    (The old OSD file will still work, but its stack overwrites the boot code (which is quite a bit larger than it used to be), so when the Chameleon is reset it will lock up and fail to reboot.)

  • OK here's a new core and a new OSD file to go with it. The core contains new boot code written in C, which should deal better with following cluster chains than the old ASM code - or at least be easier to debug if it's still not working correctly. There is also a new OSD file - the only difference between this and the previous version is that the location of the stack has changed.


    (The old OSD file will still work, but its stack overwrites the boot code (which is quite a bit larger than it used to be), so when the Chameleon is reset it will lock up and fail to reboot.)

    robinsonb5 I've tried this core and OSD file and I can confirm that now Fast RAM works for me. Also, Zeewolf 2 plays a lot faster.

    With this OSD file though, if I select scanlines, they do not appear to be working. I think they worked in one of the previous combinations, but I'm not sure.

  • robinsonb5 I've tried this core and OSD file and I can confirm that now Fast RAM works for me. Also, Zeewolf 2 plays a lot faster.

    With this OSD file though, if I select scanlines, they do not appear to be working. I think they worked in one of the previous combinations, but I'm not sure.

    Glad to hear this core's working better for you.

    Scanlines only work if the scandoubler's active, and since you were previously only able to use an older OSD you had no control over that. Try holding down F1, F2, F3 or F4 on the PS/2 keyboard and pressing the reset button - that should force NTSC scandoubled, PAL scandoubled, regular NTSC (480i / 240p) and regular PAL (576i / 288p), respectively.

  • you've got PM :)

    Thanks for the disk image - annoyingly, having copied it to a suitable SD card it works just fine. So I'll do a build that checksums the menu code after loading it and compares against a preset list. I'd like to know whether it's always the same part getting corrupted.

  • Quote

    annoyingly, having copied it to a suitable SD card it works just fine.

    wow... thats surprising. it could point to the lowlevel spi code being broken, but i cant imagine in what way to result in this behaviour. *shrug*

  • wow... thats surprising. it could point to the lowlevel spi code being broken, but i cant imagine in what way to result in this behaviour. *shrug*

    Yeah, very odd isn't it? I'm inclined to think that since jab76's problem went away it was indeed an SDRAM problem, and the problem you're seeing has a different cause.


    Here's another build - the only change is that now the OSD bootloader will attempt to open a file called "checksum.bin" and if successful, compare the contents against 32-bit checksums of successive 512 byte blocks of the OSD firmware, before launching it. Any mismatches will be printed to the screen, and cancel the boot. The OSD itself is the same as the previous build.


    Could you try this, please, and let me know if it prints anythig to the screen, or whether it boots.


    If it does find any mismatches, does it fail consistently, or do the numbers change each attempt?

  • i cant really read anything, i think it prints like 2 or 3 lines of text after the "initializing sd card" and then the screen goes black

    OK, well that either means its loading, checking the checksums and believes everything's fine, and then allowing the minimig to boot, or failing to load the checksum file. I'm going to have to give some more thought on the best way to debug this by remote control!