Daniël from 8Bits4Ever told me that the firmware for the SX-1 Mini+ is not the same as for the SX-1 and won't work properly, so I'm very hesitant to try this...
You can safely use the "1chipmsx" variant firmware from KdL (just keep a USB Blaster programmer at hand for emergency). In any case, if you are having problems with the unit please contact us by email. We are glad to help. Cheers!
I was using the sx1+mini quite a lot recently to test the diy sram pac cartridge I'm developing. Now I got it working quite well, I came across a really strange problem (not with a mfr which this thread is about, but I've also used mfr to test games that uses a pac), the problem is only with Psycho world not recognising the pac. I tried all sort of things, then realised it actually works on the real msx. It must be to do with timing (I checked the voltages already, just couldn't be bothered to hookup a logic analyzer).
So what I'm trying to say is, sx1+mini is great (it proved very useful and convenient for what I was using it for) but with all fpga msxs, they do differ from a real machine (like in timing for an obvious reason. Also it has loads of expansion in it like memory and slots used, which sometimes can make some software run differently to a basic 64kb machine), so we can't expect them to be problem free. They can be refined. It is amazing that different msxs don't exhibit this kind of problem since they do differ slightly in design from each other.
This is the key, we can't consider MSX like a single computer, is a whole standard with hundreds of models. FPGAs like OCM / Zemmix / SX-1 / ... are simply new models with their own slots configuration. It's not going to have more or fewer problems than any other MSX model, simply it's another model.
Just for example I had a MSX2+ Panasonic FS-A1WSX expanded internally to 512Kb and it was almos impossible to use MFR because of a lot of write errors in the MFR. The MFR worked perfectly in all models I had except this. Why? I really don't know.
Today I discovered a bug in the cartridge reset management of OCM-PLD. The clock was stopped so many of the cartridges could not reset properly. So I think most of the problems we've had so far with external cartridges will be fixed by eliminating this bug. It is scheduled with the next firmware.
Today I discovered a bug in the cartridge reset management of OCM-PLD. The clock was stopped so many of the cartridges could not reset properly. So I think most of the problems we've had so far with external cartridges will be fixed by eliminating this bug. It is scheduled with the next firmware.
Amazing !!!!
Just for curiosity, after this new firmware the fix of resistor will be still needed of perhaps no?
Thanks!
Today I discovered a bug in the cartridge reset management of OCM-PLD. The clock was stopped so many of the cartridges could not reset properly. So I think most of the problems we've had so far with external cartridges will be fixed by eliminating this bug. It is scheduled with the next firmware.
Amazing !!!!
Just for curiosity, after this new firmware the fix of resistor will be still needed of perhaps no?
Thanks!
Repairing 1K ohm pull-ups is a separate story and will still need to be done in my view. It is necessary to know that there is also another hardware bug on the RESET PIN of the Cyclone I machines. It has been connected externally to the Cyclone I on the hard reset button and cannot be controlled in writing by the firmware with the GETRESET /L command, therefore the external cartridges are not isolated with the HARD RESET LOCK command. This problem does not occur with the SM-X and SX-2, which work perfectly. For now I have decided NOT to provide a patch for this hardware bug of 1st gen OCMs as this feature is only used by a few people, or maybe just myself. :P
This problem does not occur with the SM-X and SX-2, which work perfectly.
So if I read this correctly, the SX-2 hardware is used differently then the SX-1 (apart from the different Cyclone chip obviously), and should work without any problem when using the MFR cartridge ?