Fixing the 2.72 8M Issues

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 :confused:

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.

Enjoy and post any issues here.
DSO203HW272.zip (147 KB)

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)

Pawn always needs to load files so if it works at all, filesystem access works also. Saving is also reported as working github.com/PetteriAimonen/QuadPawn/issues/11

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.

Thanks. That is good news. One bit of clarification. Does it require the Alter Bios for this to work as there are 8M fixes in that?

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.

Thanks jpa. That’s clear for me on Pawn.

Attached here is my attempt to do Gabonator supporting both 2MB/8MB units. It contains the Hex files and the files I changed.

I replaced the constant SectorSize with a new call which returns the SectorSize 512/4096 depending on model, and I changed RAM limits.

This works OK on my 2MB unit. I won’t have a chance to try it on an 8MB unit for a couple of weeks.
GabonatorDS203Mods.zip (658 KB)

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.

Thanks for the report. That sounds promising.

Take care with calibration on the higher ranges as the changed voltage overload protection on hw 2.72 means that input voltage should be kept below 30V.

There was a missing changed source file from the previous zip. This didn’t affect the hex files.

Attached here has the missing file plus rebuilt hexes incorporating a recent small Gabonator change persisting some more settings.

I have also forked the source on Github so any further updates will be on there.

https://github.com/roberttidey/DS203
GabonatorDS203Mods.zip (659 KB)

Wildcat3.1 does not work on my HW2.72…

i just get an black screen after starting the slot 3 in my case…

Can you say exactly which Wildcat 3.1 Hex you are trying and also what other stuff you have loaded in the other slots?

i use the one from the page before…

viewtopic.php?p=19193#p19193

i had no other slots used on first try …

no the slots have following in it…

2nd Slot is Gabonator
4th Slot is QuadPawn

I’ve got the wildcat on slot 1 now… this works…
maybe the hex for slot 3 has some issue??

I have been looking at the alempert Fourpack versions of the Apps which takes an interesting approach in splitting the 2 slot Apps so they only occupy 1 slot and using the extra ROM space to hold the rest of the code. These are set up for 2MB devices so I was thinking of trying out 8MB support in there. However, it extracted AlterBios out of Pawn and instead uses the patching version. When that is installed it affects all the apps. That caused me to look more closely at the 8MB support in that version and if I understand it correctly then the method used so far to get Community and Wildcat working is in conflict.

So far the changes made to get Community and Wildcat working were to change the apps to deal with the BIOS ReadFileSec and ProgFileSec calls working with 4096 buffers on a 8MB device rather than 512 on a 2MB. It looks to me that when the AlterBios is used then the patched versions of these calls continue to use 512 byte buffers and the read and write of 4096 is hidden inside the fat fs in Alterbios. If this is correct then it seems that one should be able to use the original unmodified versions of the Apps together with AlterBios to achieve the same result.

Gabonator is different in that it uses its own internal fat fs so I think that does need the sector size changes that I have done.

I think what would be nice to get to would be to use the 1 slot split approach as used in Fourpack together with full 2MB/8MB compatibility. Merging the sector size change into the Fourpack Gabonator is straightforward. If my thought on Alterbios is correct then it should be a matter of making sure the RAM allocation maps are compatible.

OK good news on slot 1. I’ll check out slot 3 version anyway despite my previosu post on a possible different approach to compatibility.

Just re-reading your mail. You said you have pawn in slot 4. That isn’t going to work as the main scope Apps like stock, community and Wildcat take up 2 slots. So if you put Pawn on after Wildcat then it would have wiped out half of Wildcat.

This is what is interesting about the Fourpack approach it splits up larger apps so they only use up 1 start up slot and put the rest of the code in spare ROM capacity in the background.