Fixing the 2.72 8M Issues

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.

thx for that explanation…

this declares maybe, why wildcat in slot 1 crashes (hangs) if i put gabonator on slot 2…

to bad… i thought i can have all 4 slots filled…

1 wildcat
2 gabonator
3 logic analyer
4 quadpawn

The fourpack technique will allow 4 apps but to get there it needs the 8M capabiliy added in and different slot versions of the scope apps to be produced.

Thanks so much for this. I haven’t tested thoroughly but it installs at least.

I hope the community will continue to develop for the 2.72 hardware.

Hello there,
One year ago I returned my quad (wich was already 8M version) because of a failure on one channel.
Looking at the work done about the 8M version, I ordered another one and had another try.
Sys 1.62, Fw 2.72, APP v112 stock.
I installed the forked 8M Gabonator version from roberttidey on slot1, Wilddcat3.3 for 8M devices in slot 2, and quadpawn in slot 4.
They work, and I managed to save valid bmp/wav with gabonator. I c’ant before, so I was enthousiast.
But, after having played with gabonator calibration, Quad calibration etc, Im sorry to say I finally got the famous Assertion Failed while restarting gabonator (and lost calibration like before) : code 460 shortly and 464 source/core/settings/cpp before starting the app.
And I don’t remember how to recover from this (reinstalling Gabonator App ?)
So what do you think about that ? I’m not sure if this is an app saving conflict, or only gabonator not perfectly patched, but the 8M problem while saving seems always here.
I didn’t try to write something with Wildcat app for now.

Is there someone today who has at least one application working perfecly on 8M devices ?

Edit : I have just repaired the FAT with chsdsk /f
I did a few tests with gabonator. This is not a side effect from others slots and apps.
I succed to record several files without problems while restarting : Calib data, settings, bitmaps, wav, csv… but after a moment, they appear not readable, and finally the app corrupt the entire FAT. It is not constant, but sooner or later this happens.
I think that the corruption of CALIB.DAT is fatal.

About wildcat33 : All seems right, CFG (prepared per the manual), bmp… so perhaps the only way to go for stablity ?
Pawn is ok too.

Thanks for your comments