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?
Edited once, last by robinsonb5 ( Apr 13th 2019 ).
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?
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?
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.
OK great - is there any chance you could send me an image of a card on which it fails to load?
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.
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.
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?
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!