Hello Wildcat! It’s been long since i visited this forum. Didn’t use DSO203 too much.
I decided to update to the latest version of your app; v4.4.
Firstly DFU disk wasn’t showing correct - damn Windows 10 and free upgrades…
Anyways i’ve used another Windows 7 partition i have where DFU disk works.
Firstly i updated SYS to 1.64B (HW v2.81) hoping it will work with Windows 10. It did it for MACOS, why not Windows 10? (aftermath: it still doesn’t work with windows 10)
While installing the 4 slot version, DFU disk would disappear before completing copying the file. I’ve tried multiple times. I even tried TEST.zip and TEST2.zip you posted afterwards (i know you updated v4.4 zip file) to find any solution. Basically the only one that worked was the REDUCED RAM+ROM, which is a 3 slot version.
So in short, at least for v4.4 only the 3-slot version works.
What surprised me though is that even though i tried installing the 4-slot version so many times (and your test versions), PAWN app in slot 4 still stayed and works. Maybe it has to do with anything about overwriting it??
Thanks again for the awesome work!
I have also updated my PC to Windows 10. With HW2.81 and SYS 1.62, I’m not experiencing any of the problems your having with Windows 10.
However I do have the earlier DFU V3.40C, which I think may be the difference.
Are you having this problem ONLY with Windows 10? You stated “used another Windows 7
partition I have where DFU disk works”. Does this mean you didn’t have the problem with
Win 7?
By the way, ALL the versions OTHER than the one in the “3 SLOT” folder in the archive are
actually around 5 slots in length, 3 in the start section, occupying slots 1 - 3 and 2 more in either
what is called the undocumented section of the old devices or just past the halfway point in the
new 2.81 hardware…
I take it when you state “reduced ram+rom” you mean the one in the test.zip post. The 3 versions
in this are all “5 slot versions”, they have just SLIGHTLY reduced RAM, ROM or both. The compatibility
issue with HW 2.81 WITH (and only with) SYS 1.64/DFU 3.45c is that while flashing a program,
if it senses the program going past a certain point, it stops with an error. In the 3 samples, only the
“reduced ROM and RAM” stops before that point. Deleting one of the functions (to reduce RAM)
in the reduced ROM version (which was not reduced enough to stop before the limit) to produce the
“reduced ROM and RAM” version, reduced the ROM in that version to just before the limit. (This is
how I was able to determine where that limit was). The subsequently modified versions posted in
test2.zip and updated in the archive reduce ROM even more, but do so without reducing any speed
or functionality, by simply optimizing the code. So if the reduced ram+rom works, the archive or
test2.zip version SHOULD work, as they are actually a bit smaller (or more accurately end sooner).
NOTE that I am referring to the loaded program in ROM here, not the size of the HEX file, these are
2 different things.
PAWN sits in slot 4, with the redirected file functions (for the older 2MB devices) at a bit past the
middle of the ROM in the device. The second part of my program starts well after the ending of
these file functions, so PAWN (and Alterbios for the older hardware, which basically consists of
the redirected file functions without the PAWN main program in slot 4 but with a modified SYS to
access these file functions) are not in any way involved with the update, so they are not affected.
From what I understand about SYS 1.64 is that it’s an update for MAC OS compatibility. It also seems
that these SYS versions come with varying versions of the DFU. There may be issues when using a
SYS version with DFU’s it was not intended to work with. Note though that it’s not a bad idea to stop
ROM loading at a certain point, this protects the FPGA from being corrupted. As far as Win10 in
concerned, maybe looking at the properties while the drive is accessed might be revealing (for example
if the size of the volume is reported to be too small for the HEX file to fit), but otherwise I can’t imagine
why it would work with one version and not the other.
You stated you upgraded to SYS 1.64b, what was your original SYS/DFU version?
Hi, up until now my HW ver 2.81 Sys 1.62 has worked well with versions up to 4.3 but after loading the latest “fixed” 4.4 version it now locks up on the splash screen after loading the software for the second time. The firs time I loaded 4.4 it locked up with a continuous beep when any button was pressed. It now will not boot with any earlier version locking on the splash screen each time.
I cannot find where to download Sys 1.64/B to find out if this is a compatibility issue with 1.62, does anyone know where to find ver 1.64 and is there anything preventing it’s use with hardware 2.81? Alternatively is there a version of 4.4 that will work with Hardware 2.81 and system 1.62
Thanks for all the hard work, it is a huge improvement on the original application.
I take it that you don’t have a problem in loading the various versions with the DFU? In other
words, when copying the HEX files to the DFU the volume shuts down and reappears with
with a .RDY file with all the versions you have tried?
If that’s the case, and now even earlier versions fail to start, I suspect you may have a corrupted
WPT file. If you can boot with any other program that will let you access the drive (for example
the original APP file that came with the device), access the 8MB drive and delete the WPT file
(after making a backup copy!). Then after loading any of the new versions, see if the program
then starts. If so, and you have created any of the additional configs with CFG files, you can
just load one of these and save that as a #0 boot up file to restore saved calibration settings.
If that still doesn’t work, make note of any messages on the start screen which could help
resolve the problem (with the WPT file deleted, there should be a message that states “config
file not found”).
I don’t believe this is a SYS version issue, at this point I would avoid loading a different one.
However, it would help to hear from anyone else if they have successfully used V4.4 with SYS 1.62
to verify this. Keep in mind that the DFU versions also generally update as well along with the SYS
versions, and these are NOT available.
If you want to try SYS 1.64 it’s available here:
<LINK_TEXT text=“http://www.minidso.com/forum.php?mod=vi … a=page%3D1”>http://www.minidso.com/forum.php?mod=viewthread&tid=67&extra=page%3D1</LINK_TEXT>
If should be compatible with HW 2.81. Not familiar with any “/B” versions though.
The problems reported so far have been only with flashing the program using SYS 1.64
(actually with the DFU version that comes with it, not SYS 1.64 itself) and this is what the “fixed”
version fixes. There also seems there may be some issues accessing the DFU drive with Windows 10,
will have to wait on more feedback with this.
If deleting the WPT file fixes the problem you should probably reformat the 8MB drive (with 4096 sectors).
Save whatever you can from the drive first as a backup… Also, there may be some issues in using a
WPT file that was generated from a later version, so it’s best to always save these before upgrading so
the can be restored if going back to a previous version.
Everything working fine on my end still. Love the invert. Thanks again, Wildcat. You are awesome.
That said, I wonder what DFU version is the latest. My DSO quad was purchased about a month ago and it comes in a metal (not plastic) housing/case.
In my case, it was the DFU that was causing compatibility problems with Wildcat’s latest firmware… I have the DFU 3.45c. And I do have sys 1.62 though I did start out with sys 1.64. Maybe I should reinstall the 1.64 and see if I have problems then?
No, Windows 10 has nothing to do with this problem. It’s just that in Windows 10 you cannot access the DFU disk; it shows as empty even though the DFU driver installs correctly. What i think the problem is with Windows 10 is some incompatibility with the file system the DFU disk is formatted, because it takes like half a minute to access and then gives the “no disk found whatever” error message. Windows 7 on the same system works perfect and i’ve used that to upgrade your app along the sys from v1.62 to v1.64 (also 1.64"B" is the same one so sorry for the confusion)
Then if the “4 slot” version seems to has a problem installing at least on my device. This explains why PAWN was not overwrited too during the failed installation. Note that i do not get an .ERR file. While installing the normal “4 slot” version it would copy to the DFU disk about 3/4 from total, then the DFU disk disappears and breaks the copy operation, while not showing back again until i disconnect the DSO203 from usb port and connect it again. This does not happen with the “3 slot” version. Tested both with 1.62 and 1.64 sys. The only reason i updated to 1.64 sys was to check if it provided Windows 10 compatibility of the DFU disk (which it does not).
Hmm. I am running DFU v3.40C not v3.45C. Should i upgrade to V3.45C and re-test then? Also you state the “reduced ROM and RAM” version is still a “5 slot version” even though it is generally a reduced size. However like i mentioned in my previous post it does install fine!
So:
Wildcat v4.4 - “4 slot version” 424KB - fails installation
Wildcat v4.4 - “3 slot version” 271KB - installs fine
TEST1 - REDUCED RAM - 422KB - fails installation
TEST1 - REDUCED ROM - 385KB - fails installation
TEST1 - REDUCED ROM AND RAM - 383KB - installs fine
TEST2 - 424KB - fails installation
“fails installation” = DFU disk disconnects while copying the .hex file and DOESN’T come back with .ERR
So PAWN doesn’t have to do anything with this issue
Yes that is correct (regarding MAC compatibility). I did look at the properties of the drive. Like i said even though the driver installed shows correct and working, if i bring up the format dialog it shows as “Unknown capacity” and 0 bytes total size. Also if i try to access it as mentioned above it will show “Please insert a disk into Removable Disk (E:).” In addition the long accessing times of the disk are consistent with Windows behaviour accessing damaged disks from my experience. In this case however is an incompatibility with Windows 10 not actual damage to the DFU partition. Only thing i can think off is to update the DFU version and check again. But the question is, does anyone else been able to access the DFU disk with Windows 10 (also 8/8.1 i think has the same issue)?.
Finally as stated above in this reply, i had SYS 1.62 and updated to 1.64 (1.64 = 1.64B). Windows 10 incompatibility is a different problem than the problem with installing the app as it is done under Windows 7 where it is possible to access the DFU disk.
EDIT: And now i noticed…There are no DFU update files! DAMN! So i’m stuck with DFU v3.40C!
Hi again. Yes the DFU seems to be working, all the versions do convert to .RDY normally but all then hang at boot. Unfortunately it does not go past the splash screen with any version of the app I can find. The USB Drive shows as unrecognised by Windows 8.1 with the following message “The last USB device you connected to this computer malfunctioned, and Windows does not recognize it.”
I cannot at this stage find a way to mount the 8MB drive to delete the WPT file. Any suggestions gratefully accepted.
Ok I eventually tried version 2.51 and that would boot. I backed up and deleted the WPT file and reformatted the 8MB drive. It now boots with 4.3 or 4.4 but many things are not working normally, if I hold button 1 there is no CHART appearing and no beeps after the first one. It’s almost 5am here so I have to quit for the night, thanks for your help.
Are you pressing down long enough? The long press is longer now than what it was before, from what I’ve read.
I have tried for 60 seconds and it still does not come up.
DFU version is 3.40C
You can if you want to, this would help verify compatibility and hopefully help others that are having problems.
Thanks for your help in testing the various versions.
What else is not working? Are you starting the program without a config file? (On the boot screen, this would be indicated
but a “config file not found” message.) I have not tried booting the latest version without a config file, will check into it in
to see if that causes any issues.
If you are loading the config file (perhaps the previous save copied back to the drive?) then the problem could be with
this config file.
Borland stated he is using the 424KB version on his SYS 1.62/DFU 3.40C device successfully so I don’t believe it’s
a version issue. The one thing in common with the versions you are having issues with seems to be that the files are
larger than 383KB. You stated you did a “Windows properties” on the DFU with Win10 and it came up with unknown.
What does Win 7 report as the size of the drive? If the drive reports as not being large enough to hold the file
that could be why it’s not working.
From what I can tell, the DFU is a virtual disk made up of the RAM, which is 512KB minus the bootloader (DFU),
which, for example in the early versions left about 503 or so KB. It may be the new DFUs use more code, or
look at what is already installed and for some reason this leaves less room on the drive, so there just isn’t enough
room to fit the file.
An example of the changes is with this “limit” they have that prevents code from being loaded past with DFU 3.45C.
This is a good thing in my opinion, prevents corrupting the FPGA. Note though, that this is not related to the size
of the file being loaded, but to how far the file loads it’s code in ROM.
I would be really curious to see the size of the DFU as reported by Windows (or any other suitable means).
I have tried with and without a WPT file it loads the file if it is present but either way still no CHART as well as other menus not working. I also retried ver 4.3 and 4.4 but after loading 4.4 just now it locked up again and now will not start even with 2.51. Is there a way of starting from scratch and reinstalling the other components of the system as whatever happened when I loaded 4.4 for the first time seems to have caused bigger problems. It was working with no issues on earlier versions.
The DFU for hardware 2.81, Sys 1.62, DFU 3.40C reports in Windows 8.1 as 2,064,384 bytes with 1024 used, formatted FAT and showing as a removable drive.
Here’s what I have with Windows 10…
Is anyone else having issues such as this with V4.4 after a successful flash (meaning returning a .RDY file)? The only other issues so far have been with the flash process itself (with SYS 1.64/DFU v3.14 detecting ROM being loaded at too high an address, and issues with Windows not transferring the HEX file properly and shutting the volume down prematurely.
As far as “starting over”, you can reload the SYS file, as well as the FPGA, and reformat the 8MB drive once you can boot
up a APP file. At this point, you can’t reload the DFU, as it’s not available. Furthermore, this needs to be done internally
by accessing the processor directly. The FPGA usually will report an error on boot if it has been overwritten, so it’s
probably OK.
The 2 posts showing the DFU size as 2MB doesn’t make much sense to me, and this MAY be the cause of some of the
problems. For example, on my device, Windows shows the DFU drive as 503MB and completely empty. I have successfully loaded up to 500MB on this, with an attempt at 512 showing an “not enough room” error. This is with DFU 3.10 and WinXP, however…
Unless the processor is accessing some other volume I’m not aware of, I can’t imagine where Windows came up with this
2MB DFU drive. Unfortunately, since I don’t have one of these new devices, will have to rely on feedback from other users,
but will see what I can find out.
Also just checked, and no problems with booting up V4.4 without a config file, so I would suggest to anyone having problems to first run it that way.
Here’s what I have with Windows XP…