Minimig Discussion Forum

Got it! Very cool! Thanks so much everyone, for the firmware and the help.

Thanks again.

Hi,

I see you are testing firmware, thank you. I didn't had enough time to fix errors in last few days, hopefully I'll find more time during weekend.
Anyway here is latest list of detected bugs just to have it in one post. I have returned error reading writing adf files to the list because there are still problems there.

Left for fixing:

• It is also possible to select any directory name as Master / Slave hardfile name. In this case the Kickstart (3.1 here) crash into some Guru.
  
• Also in floppy image selection list, the 1st entry of sd-card root directory (here) is "D UNREAL2.ADF". Actually there is an "UNREAL2.ADF floppy image file present in sd-card root, it also is listed below as normal .ADF file.
  In fact this "D UNREAL2.ADF" is a sub-folder and should be called "DEMOS". By enter this "wrong named" folder, all 310 demo .ADF file is present and selectable(!). Afer returning into root directory, there is no more "demo" or wrong named folder present.
  After exiting and re-enter the OSD, the same thing repeat again
  
  This all may be caused by some wrong sd-card access timing or code. I really dont know much about this but swapping folder name and file name could be an indicator of some wrong code handling.
  I was able to reproduce this, thanks boing4000, now I need to fix it
  
• Oops, yes I can confirm this.
  Just started a simple kickstart 1.3 workbench and copy "prefs" folder via drag&drop from df0: to a blank df1: image.
  After that the original source wb13.adf was damaged, no program could be load any more and even reboot failed with "Key 888 already set" requester.
  
  Findings until now:
  The same effect as in OSD file list seems to appear after some normal AmigaDOS disk write. In main root of "wb13.adf" an endless repeating loop of some file/directory entry appear. Even if this disk was only read out in df0: its data is currupted.
  
  Using DosControl (any version) DiskCopy /w verify function also certified this:
  Random track report verify error. Seems PIC internal stack/ram (or disk-sync) handling is not right.
  Additional tested with Kickstart 3.1: Same ADF damage is present. Until now HDD support works fine, no damage data is to report.
  This one is obviously not fixed
  
• @Quille
  Thanks for your hard work for PIC, Im about to test your new firmware!
  Until now I have encounter several "Volume <name> has a read/write error" after writing data on it.
  Using DosControl function "format" or "optimize" did destroy content of just processed adf image, it appear as "not a DOS disk". I loocked at the adf image using PC hex editor: It seems only partial written!
  From offset $00000000 up to offset $00058000 new formated data (correct) is present.
  From offset $00058000 up to offset approx. $0005F000 OLD data (incorrect) is present.
  Same repeats itself at the end of adf image. I guess there is some adressing error present while writing a full disk image.
  
  Also copy files from df0: to df1: (using drag&drop or DosControl) will mostly result a file content error (using diff function of DC). I will check this out more detailed and report if found some possible cause etc.
  I'll investigate this.
  
• @Namek
  Confirmed. If AR3 is set "enable" and there is no "ar3.rom" file present in sd-card root, PIC report a 7-times led blink error.
  This can be avoid by holding down MENU botton on Minimig pcb. Still firmware should better skip loading ar3.rom file if enabled but not present.
  
  Remember to PGM rerset or re-power Minimig board after changing AR3 setting in OSD! Only the initial bootprocess is able to change fpga internal AR3 module function.

That is all for now, I hope I'll at least part of these issues during weekend.
Thank you all once againg for testing and reporting errors.

Quille

Hi all!

I have managed to make fixes during weekend so here is what is fixed. Pic code is now biggest ever and I'm afraid that will not be able to fit in any new features. Attached here is latest pic hex.

Here is what is fixed ..

• It is also possible to select any directory name as Master / Slave hardfile name. In this case the Kickstart (3.1 here) crash into some Guru.
  I have added check for HD file extension. Now it is also possible to reset HD file selection same as floppy. When hd file is selected if you press select again it will be reset. If you reset hd files and save settings, during real minimig reset (PGM Reset) minimig will try to open default hdfiles HDFILE00.HDF and DHFILE01.HDF.
  
• Also in floppy image selection list, the 1st entry of sd-card root directory (here) is "D UNREAL2.ADF". Actually there is an "UNREAL2.ADF floppy image file present in sd-card root, it also is listed below as normal .ADF file.
  In fact this "D UNREAL2.ADF" is a sub-folder and should be called "DEMOS". By enter this "wrong named" folder, all 310 demo .ADF file is present and selectable(!). Afer returning into root directory, there is no more "demo" or wrong named folder present.
  After exiting and re-enter the OSD, the same thing repeat again
  
  This all may be caused by some wrong sd-card access timing or code. I really dont know much about this but swapping folder name and file name could be an indicator of some wrong code handling.
  I was able to reproduce this, thanks boing4000, now I need to fix it
  UPDATE: I have transferred sources to PC and debugged routines on PC, now works ok with boing4000 sd card file list and all my cards. It is really hard to debug routines using only printf on pic. Anyway I think this is finally fixed along with few other errors.
  
  
• Oops, yes I can confirm this.
  Just started a simple kickstart 1.3 workbench and copy "prefs" folder via drag&drop from df0: to a blank df1: image.
  After that the original source wb13.adf was damaged, no program could be load any more and even reboot failed with "Key 888 already set" requester.
  
  Findings until now:
  The same effect as in OSD file list seems to appear after some normal AmigaDOS disk write. In main root of "wb13.adf" an endless repeating loop of some file/directory entry appear. Even if this disk was only read out in df0: its data is currupted.
  
  Using DosControl (any version) DiskCopy /w verify function also certified this:
  Random track report verify error. Seems PIC internal stack/ram (or disk-sync) handling is not right.
  Additional tested with Kickstart 3.1: Same ADF damage is present. Until now HDD support works fine, no damage data is to report.
  This one is obviously not fixed
  OK I have found huge bug in WriteTrack routine, it was working fine when making disk copy simple format etc but copying files from floppy to floppy failed big. This is also fixed please let me know if there are still problems.
  
  
• @Quille
  Thanks for your hard work for PIC, Im about to test your new firmware!
  Until now I have encounter several "Volume <name> has a read/write error" after writing data on it.
  Using DosControl function "format" or "optimize" did destroy content of just processed adf image, it appear as "not a DOS disk". I loocked at the adf image using PC hex editor: It seems only partial written!
  From offset $00000000 up to offset $00058000 new formated data (correct) is present.
  From offset $00058000 up to offset approx. $0005F000 OLD data (incorrect) is present.
  Same repeats itself at the end of adf image. I guess there is some adressing error present while writing a full disk image.
  
  Also copy files from df0: to df1: (using drag&drop or DosControl) will mostly result a file content error (using diff function of DC). I will check this out more detailed and report if found some possible cause etc.
  I'll investigate this.
  This is actually same bug as bug previously described, so hopefully this is also fixed.
  
• @Namek
  Confirmed. If AR3 is set "enable" and there is no "ar3.rom" file present in sd-card root, PIC report a 7-times led blink error.
  This can be avoid by holding down MENU botton on Minimig pcb. Still firmware should better skip loading ar3.rom file if enabled but not present.
  
  Remember to PGM rerset or re-power Minimig board after changing AR3 setting in OSD! Only the initial bootprocess is able to change fpga internal AR3 module function.
  I have fixed bug when AR3 is enabled but not present on SD card, minimig will now only display boot message disable AR3 and continue to boot. However you still need to press PGM reset when you enable AR3 and save settings. This could be done same as loading kickstart but I'm running out of memory on pic I might try to fit this in later on.

As always I have uploaded source to google code for everyone to see or fix
Currently bug list is empty, so please test if you can and let me know how it goes.

For the future I would like to change OSD to hires (it is supported) so I can display longer filenames in file selector.
I would also like to try to optimize code a bit to free some memory for future fixes.

Anyway that's it, hope you'll like it

Quille

Thanks for your weekend work

I have Download this file 3 times but always get same error while unpack:


Extracted file is only 74702 byte in size and unable to flash in TinyBootloader.
Could you pack and upload it again please?

+1 I can't get it to unpack. Thanks for the effort.

Same problem here.

Hi, uploaded again, here and on original post.

Thank you. I've been using the last beta most of the week and it's nice. I have a couple of small problems but I'll wait until I try the new beta and see if you've fixed them already.
Thanks again.

Thanks for this new version.

ECS / OCS switching is present and working fine

But if once selected a *.HDF file name, I can not pick any other one. Master or Slave setting goes "disabled" and there is no way to get back to HDF file selection list. At some strange way I managed once to select another Master HDF file again, but Slave will auto-select the same file at once and can not be changed.

At first file select after PGM reset or power-up one have to press <enter/space> twice to reach file selection list for Master. First <enter/space> at Slave will automatically select "any" existing .HDF file (perhaps first in directory list) anc can not be changed.
As soon as Master HDF is selected, Slave will automatically take its name by attempt of selecting some Slave HDF file and can not be changed by hand.

Im sorry for reporting bugs again...
Everything else seems to work fine and most of the prev. bugs is fixed!
I think this little one may not be hard to find, keep it up

Maybe it´s not a bug but the hfd file which i have created loads very slow.
Opening a folder which contains nearly 30 files takes severals minutes(10 min.) on the workbench.
The hdf file has a size of 700Mb.
Is there a way to increase the loading speed ?