Mine is DFU v3.45c
Thanks Wildcat. Seems like your support ends here. But out of curiosity the test version would be cool too.
OK, well, here’s 3:
In each folder, 1 each with reduced RAM, ROM, and one with Both reduced.
Reduced RAM eliminates the SAVE/LOAD .DAT function, which came from the original authors, I don’t feel is very useful, SAVE/LOAD .BUF is much better in my opinion. Could probably restore the function anyways with less RAM. Performance
remains the same as speed optimization is retained.
Reduced ROM reduces speed optimizations, however some of the functions suffer at their highest speed.
Knowing whether excessive RAM or ROM usage (or both?) is contributing to the problem would let me know in what
direction to go to ensure compatibility with this latest SYS 1.64/DFU combination.
The test cases are brilliant.
Reduced Ram – no work, no difference.
Reduced Rom – no work, but stuck splash screen is modified (I can see “Wildcat v4.4” somewhere within).
In both cases, I get that app1.err file when I check after installing, and in both cases while hooked to the computer via USB I get an USB not recognized error.
However, the third case, Reduced Rom & Ram works. No issue.
OK, thanks for checking this out.
For wotsac (or anyone with hardware 2.81 AND SYS 1.64) If you could try this version.
If it works, let me know. You can keep it on your device if you wish, it’s a fully operational
version 4.4 will all speed optimizations, same as last one posted.
It works! Now I’m curious. What was causing the firmware install to fail on my machine? And how did you figure it out?
Since the problem came up when flashing the program, I doubted RAM usage had anything to do with it, since
the only thing in RAM after flashing is the bootloader itself, so I looked at which versions worked and which didn’t
on your device, including earlier and the 3 slot versions. The one thing in common with all the ones that didn’t work
was that the last part of the program code went past a certain address, some 18KB before the start of the FPGA.
I figured the bootloader probably stops and gives an error if it detects code trying to load past that point, for whatever
reason, possibly to prevent overwriting something there, or the FPGA further down, so I shifted some of the code
around so it would end sooner and stay clear of that point.
Anyone writing programs for these devices should be advised to keep their code below address 0x58000 The FPGA
reportedly starts at 0x5C800 on HW 2.81
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.