D1 Screen support

[Mik-S-UMS]

Continued from Reddit here

I had a bit of a play around in DGUS with Voxelabs project from their D1 screen repository here
Problem is they never documented what each variable or element does on the screen so these are all at default values when created.

This is the software they used to create the screen FW so should be possible to create one to work with Mriscoc even if it has to be built from scratch. This would give more flexibility with screen orientation and fonts.
I don't know if they used the same program for the standard colour screens with the knob, it may have been an earlier version.
If it was then somewhere there must be the original project files used to make it. If we had that for the DWIN_SET that is currently used it would be a lot easier to add the touch functionality.

I don't know how the communication works between the board FW and the screen. My guess is on the standard screen all the logic and navigation is done in the FW and this is sent to the screen.
I think for the D1 screen most of this is done on the screen itself and only the variables is sent back to the FW on a change.

The main problem is translating the way these work and I think that is what they did for Desuuuu by making a library for this while leaving the Marlin code alone. This should work fine for their DGUS-reloaded screen FW but may have to remap variables to work on Mriscoc. It could at least be a good starting point for making a new display FW.

They has to be something in Voxelabs D1 FW that could be used here too.

DGUS does have a simulation of the screen for testing but does need external communication with a board and it allows you to set up a serial port for this. I have a UART to USB somewhere that I was thinking could be connected to the RX and TX of the display socket of my spare motherboard to feed into this, but the problem is it is a H32 chip and the D1 has the N32 so its FW will not run on it.

I'm currently going though this Youtube playlist of how to use DGUS so maybe it will show another way for testing.

[classicrocker883]

if someone want to basically turn the ProUI into touchscreen, that would require incredibly extensive work. it would first require someone to customize a touchscreen layout (using their software and I dont know which one)
a quick look and the one labled HMI software on a video shows DMG80480C070_04WTC, i think that is close to the same screen, i think someone on an Issue posted theirs, could be T5L idk

what I did was look at the original Marlin 2.0.9.3 which is what D1 is based on. Then Used "Meld" program to compare both Marlin folder and Aquila_D1. this showed the exact differences/changes made by Voxelab.

I used that as a way to then copy over into the most recent Bugfix of Marlin (technically this MRiscoCProUI branch)

ps. dont forget there is a big difference between these Repo's

1. https://github.com/Voxelab-64/Aquila_D1

• FW used on Board

2. https://github.com/Voxelab-64/Aquila_D1_screen

• FW used on Screen

[classicrocker883]

here is what I was able to do to update https://github.com/classicrocker883/MRiscoCProUI/tree/Aquila_D1

this is what I hope someone can test and if so, then thats great. we wouldnt have to worry about remaking a WHOLE NEW UI

[Mik-S-UMS]

The software is DGUS_V7648 but will probably need NET Framework 3.5 too if you don't already have it installed. I did not get it from here, windows downloaded and installed it when running DGUS for the first time.

I think the screen in that video could be the one but would help if we had pictures of the screen from D1 users. I asked on Reddit if that OP could do some. Correctly identifying it will help a lot going forward.

I'm not a programmer so don't know where to look but what part of the code controls the screen?
If I could get some idea of how it works with the standard screen and on the D1 screen then I might be able to alter their screen FW, or at least make changes to make it easier to use like naming variables and text fields etc.

Would it be possible to compile their D1 firmware to run on the H32 board? If so then I could probably use mine for testing and feed the serial data in to the simulated screen in DGUS.

How far did you get with the D1 code? did it just not work or did not compile?
Do you still have the results from the "Meld" program?

[classicrocker883]

this is how far I was able to get, I uploaded as a branch here.
so far it compiles well. it did take quite a while; this was a couple months ago but what I think I did was copy over the lcd/ code portion - and tweak the names of the functions since they were outdated. since the Aquila_D1 repo just doesn't compile as-is, first I used Meld and compared the original 2.0.9.3 Marlin - that shows you the exact differences and changes Voxelab made. then I think I either pulled from the current bugfix, or maybe I just copied the differences over while still comparing in Meld. it was trial and error after that.

as for H32 board being compatible, i dont even know how that would be possible. the board is barely capable to handle two screen types. i think the question comes down to if something like Creality 4.2.2 or 4.2.7 can run the same touchscreen and stuff, i dont see why this board wouldn't - it all depends on how or even if the pins_BOARDNAME.h has code for it.

what I did was leave the code that controls the screen as original as possible. mainly because the screen FW depends on it. that said, I supppose its possible to just run completely different screen FW (the UI will be different) but at least you can run updated Marlin and it will be easier to maintain/update.

another thing is it used N32 chip. so I looked through the differences and while I might be able to program some things, that type of code is out of my league. im not able to mess with anything unless im able to understand why a change was made and what it means and what it does.