Got time for more coding and testing in the weekend.
One thing that always bugged me with EPSS-Control was the need to have different compiled versions for ST Medium than higher resolutions. I also had to make a special “MultiTOS” version that had a more modern look when the TOS supported 3D buttons, i.e. Falcon, MultiTOS etc.
I always used embedded RSC-files in EPSS-Control but as I created the additional RSC-files from the original RSC-file, the files always kept the same constant names for its controls so I could therefore not include more than one RSC header file at a time and had to control it with compiling flags and output different versions and so on.
But I realized that it was not theoretically difficult to change it, just a mindset of not using the absolute constants in the code. Two things were therefore needed:
- Edit all RSC-files and change names of the constants to have them unique for each RSC-file, preferably with a prefix, like H_xxx for constants for High RSC file, M_xxx for constants for Medium RSC file and so on, and
- to use variables instead of absolute values to refer to the controls. I then had to write subroutines to fill in the correct constants to the different variables depending on the RSC file in use, as I no longer could use constructs line “dc #constant1” and “move #constant2,” etc.
Editing the RSC files would have been a bit easier if I had remembed you could step to the next control with Alt-N in the RSC Editor Interface I used 🙂 And also Hatari 2.1 seems to crash randomly in Interface 2.3 that I use, so I had to revert back to Hatari 2.0 as it seemed more stable. But it was not too difficult as I can use exactly the same Hatari config file for both 2.0 and 2.1, so it is just a matter of starting the right exe.
Most of them time had to be spent rewriting all use of the constants in the code as I had about 200+ constants for each RSC file and then have three different RSC file and it was spread everywhere. Lots of testing after each rewrite was also needed to ensure nothing broke. I spent quite a bit of time to find a missed + in a (a0)+ statement which resulted that all variables I initialized were misaligned and controls in dialogs stopped working etc.
Also when doing this rewrite I realized it was necessary to have some kind of version control so everything is now on http://www.bitbucket.org (private repository for now, sorry) and I use Source Tree to push and pull and it works very good and fits into my workflow.
I also had to streamline my workflow a bit to make changes and testing quick and easy. I currently use a Win10 laptop where I have a location c:\…..\GemdosHD. Here I have directories for C, D, E, etc and I have copied and replicated all my Atari harddrives here. I then use trusty old emacs for editing the assembler code straight under the GemdosHD location in Win10. For me, nothing beats emacs when editing code and it has a nice assembler mode that works ok with 68000 assembler in Devpac format as well. And the emac’s keyboard macro functionality was amazing to automatically convert long lists of constant variables to move-statements.
I then use Hatari to point to the GemdosHD directory, and therefor C, D etc is directly accessible as drives when booting up Hatari. I can then have Devpac running and then just re-load the source, compile and run straight after I save it in emacs. If I decide to do a little change in Devpac, due to some compiling error, I can do it there so and then reload the load in emacs as it will autodetect that is has changed. Or I just go back to emacs and change it and then Ctrl-W (close window) and Alt-L (load) in Devpack and reload and assemble it again. And running Hatari in TT High give me a nice big screen are in Devpac as well.
I then have SourceTree (a git client for BitBucket) pointing to the GemdosHD so it easily detects any changes I do in the source files, so it is quick to pull, commit and push the changes.
This works really great for me but if you have any additional tips or ideas to improve this, just leave your comments!