Being frustrated with not being able to run my new DSO with the community software, I thought I would take a look and see if my inner geek still existed. I have made some modifications to try and support the 8M disk. I started with github.com/pmos69/dso203_gcc and looked at the new “factory” code.
Warning: I don’t know what I’m doing, I don’t know this software or hardware and have never even run the community addition. My C skills are so rusty the rust has rust. But, here is the first try. The enclosed .zip has the 3 files I changed and a .HEX file for app 3. If your brave, give it a try and lets see what works and what doesn’t.
What I found: the only change that should matter is the sector size going from 512 to 4096. Files.c was hard coded to the old hardware and depends on sector size (unlike the normal C libraries). Based on comparing the new and old files I made adjustments in files.c and file.h and computed SectorSize and flash_mode the first time a file is opened (could call that from main, but I was looking for minimal dependencies to start with). So, this SHOULD still run with the old hardware.
I have never run the old version so it is a bit hard to know if it is running correctly.
This is running on the factory 1.6 “SYS”. There are some changes to sys for the community version - I have not looked at those. Anyone who knows about all the dependencies may want to take a look. Perhaps the dependencies can be removed.
Other changes due to the 8M can be found in the file “FAT12c”. I don’t think they change anything in the application, but here they are just in case:
//-------FLASH-----W25Q64BV--------------------------------------------------// #define FILE_BASE_8M 0x7000 // ÎļþÇø¿ªÊ¼µØÖ· #define ROOT_BASE_8M 0x3000 // ¸ùĿ¼¿ªÊ¼µØÖ· #define FAT_LEN_8M 0x1000 #define FAT1_BASE_8M 0x1000 // FAT1Çø¿ªÊ¼µØÖ· #define FAT2_BASE_8M 0x2000 // FAT2Çø¿ªÊ¼µØÖ· #define SEC_LEN_8M 0x1000 // ÉÈÇø³¤¶È #define FAT1_SEC_8M 0x1 // FAT1ÉÈÇøÊý #define FAT2_SEC_8M 0x1 // FAT2ÉÈÇøÊý #define FAT_END_8M 0x7FF // Á´½Ó½áÊø
//----------------------------------------------------------------------------// #define FILE_BASE_2M 0x8000 // ÎļþÇø¿ªÊ¼µØÖ· #define ROOT_BASE_2M 0x4000 // ¸ùĿ¼¿ªÊ¼µØÖ· #define FAT_LEN_2M 0x1800 #define FAT1_BASE_2M 0x1000 // FAT1Çø¿ªÊ¼µØÖ· #define FAT2_BASE_2M 0x2800 // FAT2Çø¿ªÊ¼µØÖ· #define SEC_LEN_2M 0x200 // ÉÈÇø³¤¶È #define FAT1_SEC_2M 0x0C // FAT1ÉÈÇøÊý #define FAT2_SEC_2M 0x0C // FAT2ÉÈÇøÊý #define FAT_END_2M 0xFFF // Á´½Ó½áÊø
//----------------------------------------------------------------------------// DSO203HW272.zip (59.3 KB)
I suspect the issues have more to do with the modified SYS, but I have not been able to find out what it does or locate the source code. If anyone has a link, please post it or update it based on the factory SYS.
Also, I would also like to try the “wildcat” version. Does it have SYS dependencies?
The standard community app uses a modified SYS (25116) whose main difference is to use a different table of multipliers in generating the frequencies of the sig gen. Without the modified SYS then the frequencies are wrong as you noted. The Wildcat version uses the standard unmodified SYS and has slightly restricted top frequency for the sig gen. Wildcat will run using the modified SYS 25116 but then its sig gen frequencies are wrong.Other than that they effectively use the same SYS.
bobtidey: Is the SYS 1.6 you provided the one modified for the community application? If so, I can’t find the modified table or any additional functions. It is very similar to the current “factory” SYS except for the 8M changes. In the fixed community app there is also something odd going on in the FFT function that may have to do with SYS. Without a debugger it is a bit hard to say.
The “Gabinator” application is completely different, and looks like new (cleaner) code. It should be easy for him to make the sector size a variable.
I compiled up the Wildcat version with your changes and it seems to run fine on my 2MB version including file saving loading using the standard unmodified 2MB sys.
I can’t check it on my relative’s 8MB version for a few days.
Thanks a lot for sorting this out. I am sure 8M owners will be pleased that the path to the other apps is opening up. Hopefully these changes get put into the ‘official’ versions of the apps. If not then we can make versions available.
Could you post the Wildcat version? I tried to do it as well and it crashed on load, even without running any new code. When I change the buffer size (to the old value), it worked. I suspect it may be running out of memory but perhaps it is something else.
I’m not sure how to build the SYS you posted, is there a makefile? I may be running out of what I can do without really understanding much
For those of you interested in using this with the 2.72 hardware, it seems to be working (with the exception noted below) and not harming the hardware. All the file I/O functions seem to work. Enclosed are the .HEX files for app-1 and app-3 as well as the modified source files. This works with the factory SYS, the dependencies on the modified SYS have been removed (with the hint from bobtidey). The SYS for 2.72 must be used (also included in the .ZIP, unmodified) if used with the 2.72 hardware. It should also work with older hardware.
The only issue I have found is that the FFT functions don’t work - when moving to those menus it hangs in a beep. I don’t know why and hope the original authors will be able to better debug it. But, at least this is a mostly functional community version. The problems I had with Calibration/accuracy are much better.
The enclosed .zip also contains the modified source files, these could update the main branch or be a hint for the other open source applications.
I don’t think I had merged all your changes into the Wildcat version of files.c correctly first time round so the sector buffer was still at 512. Now I have redone that I get same behaviour. I can get LARGEST_SECTOR_SIZE up to about 3300 bytes and it behaves OK so it does look like it is a memory issue like you said, but it’s not far off. It probably needs the lds files adjusted a little.
I attach my Wildcat files.c for comparison.
The only build environments I have seen for the SYS are the factory ones which use IAR Embedded workbench. In principle it should be possible to do it with the same toolchain as for the APP but I’ve haven’t seen a makefile for that. Files.zip (6.22 KB)
So as a first quick experiment I adjusted the main.lds so that _estack = ORIGIN(ram)+LENGTH(ram)-0x1C00; instead of the default -0x2000. This reduces the stack space from 8K to 7K. I don’t think any of the large data structures are put on the stack.
With this change and the LARGEST_SECTOR_SIZE set back to 4096 then Wildcat starts up and seems to run OK although I didn’t tested it that much.
There are a few things to think about in the RAM allocation.
When I generate a memory map during linkage of Wildcat it shows RAM usage from 0x20003000 to 0x2000a9c8. That’s worrying as I think some of the variables are still overlapping the stack space. The top ones are a few flags and quite a bit of the fft variables. So I think this still not be a good allocation.
There are a number of possibilities here.
The start is set to 0x20003000 which I think is allowing for the bottom 12K to be used by the SYS and I don’t think it is using that much so it is possible the start could be lowered a bit.
The other thing is that the memory assumes the 48K RAM present on the processor whereas I think that this is actually 64K in practice. This is a bit like the Flash ROM where it is nominally 256K for this processor chip but in practice 512k is present and usable.
I tried the latter approach as I don’t know the top of the SYS memory. I restored stack size to 0x2000 and changed APP1.lds as attached to assume 48K Ram length ( 12-60K)and generated the Wildcat APP01.
That also seemed to work OK and I did a test of the fft with this one which worked OK. app1.zip (66.5 KB)
Based on this memory map extracted from a SYS1.6 8M version project, it looks like highest address used by the SYS is around 0x20001620. This should mean that it would be Ok to move the RAM base of the App down from 0x20003000 to say 0x20001800 freeing up 6K at the bottom end. That would be plenty to accommodate the increased filing buffers within the nominal 48K RAM space.
I haven’t tried that yet as I’m comfortable with increasing the top end of the RAM limit. DS203SYSmap.zip (7.61 KB)
Bobtidey - Changing the RAM to 48k seems to work as you suggest. As far as I can tell this is now fully functional. I have included the source and updated .HEX files one more time, but do need to find a way to post these somewhere! Since I took out the dependency on the modified SYS, perhaps this version and your “wildcat” version have the same functionality?
So, for anyone watching, you should not be able to use the “community version” with the new hardware. DSO203HW272.zip (149 KB)
It is looking like Community and Wildcat are in reasonable shape for 8MB now. I attach my version of the Wildcat31 with these mod. That includes the modded source (re-organised into same tree as Community) and compiled hexs for slot 1 and 3. I haven’t tested them on an 8MB device.
Wildcat and community are both similar being based on the same root code. However, Wildcat version does have additional refinements.
From an 8MB point of view that still leaves the Gabonator main App and Pawn as the larger items.
The Gabonator App is reported to run on 8MB devices but doesn’t save / load correctly. The code is completely different from the community App and exploits the extra 256K ROM available to have a nice GUI and build in a lot of extra functionality. It looks like the main change needed for 8MB is to adjust the SectorSize. Currently, this is an enum in the FILEINFO structure and set to 512. This makes it a little awkward to change. As an experiment I just compiled a version with the enum SectorSize set to 4096. This ran out of memory. Checking the map showed that 2 SectorSize buffers seem to be used so the memory needs had grown by 7KBytes. I adjusted the lds to give it 7K more room as there was still space at the top using the 64K actually available. This then compiled OK. I attach this here but again it is untested. If this works then it would be best to put in the device test and make the SectorSize a variable like you did in the Community app. It is slightly less obvious where to put that.
Pawn again is supposed to run on 8MB devices OK but I haven’t seen any reports of uses which involve loading and saving to disc. I suspect those would fail on an 8MB device without similar adjustment. GabonatorBin.zip (634 KB) WILDCAT31.zip (327 KB)
Logic Analyzer saving does not work on 8MB. Pretty simple to fix, but haven’t bothered so far. There is a lot that could be improved about logic analyzer and I just haven’t felt like doing it.
QuadPawn always installs non-patch version of AlterBIOS for itself, as it needs it to work at all (on any device, 2M or 8M). The separate AlterBIOS .hex also patches the default bios, but I’m not sure if anyone has tested the patch stuff on 8M. Not much need for it, maybe.
Thank you very much bobtidey for the great work and thank to cory.play also, for starting this post.
I have a very new MiniDSO HW 2.72 with stock SYS and FPGA, Device FW Upgrade 3.12C and with the stock APP it was very limited.
I installed the last wildcat3.1 in slot 1 and the modified gabonator in slot 3. I have to make a better calibration, then I’ll start a complete test, but at a first use it looks that all is working fine.
I also have the QuadPawn in slot 4 and it looks it is working well also, but I have intensively tested just the Frequency Response.
Just a note: when I tested the first release from cory.play (AP8MG251_1.hex) I had to rename the application files with a shorter name (AP_1.HEX), otherwise the application was not able to start. I’ve done the same for the other applications I tested. It can be is is a known issue, but I report it for the newbies like me.
