One week after the release…

Another week has gone after the release of E.P.S.S. The Atari Community Version on Valentine’s Day and no, it was not really deliberately planned for that day ๐Ÿ™‚

Lots of downloads of the E.P.S.S. ACV has been registered and I see new users every day signing up for the download which is great!

Note that I will not use your emails for any other purpose than to occasionally mail out news regarding E.P.S.S. so sign up with real emails and not fake if you want to be kept “in the loop” ๐Ÿ™‚

Some feedback:

  • It seems like the version doesn’t really play anything on any real hardware other than STe and Mega STe and possibly Falcon in ST Compatible modes. TT is currently NOT working. This has to do with that the version is really a version to be used in 50Hz demos and hard coded to be used on a 50Hz VBL, i.e. not on 60Hz VGA or TT High or any other resolution. We are currently investigating and looking for a workaround.
  • I will have now put up a version of E.P.S.S. that is separate files in a .ZIP instead of just an .ST floppy image. You find it on the download page. This will simplify for users wanting to copy E.P.S.S. to for example SD-card or floppy from their download computer, PC, Mac, Linux etc.

In the mean time I have been working on some smaller bugs and some features. I have for example now implemented support for loading of 16-bit WAV files as well as supporting the extended sized 8 bit WAV files (extra long header). Some other bug regarding load and save of samples have been sorted out as well.

I also started to look at using a more “standard” Sample Rate Conversion (SRC) method that will allow for implementing pitch bend, i.e. continuous pitching of the samples. One of the optimizations done in E.P.S.S. was to use only the standard notes and nothing in between to get faster executions on the STe, and I will look at the impact of having variable pitching. Maybe a middle way would be to mark specific sounds as “pitchable” and then use the variable SRC, we will see…

Release Candidate 2 built and out for test

Bug fix of an AES error occurred when opening it as an ACC after it has been initialized so now it is looking quite good as I have no known bugs left on my list.

Cleaned up some example source code how to include the player in your own code and test run it and everything worked fine on Hatari.

Just need to get some feedback of the tests on real hardware. Anybody wants to test the RC2 on their own hardware before release? Comment here and let me know what you want to test it on!

Weekend work

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:

  1. 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
  2. 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ย (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!

February Updates

It is progressing. I have now compiled up versions with 4, 8 and 16 (!) channels.

I have prepared a Release Candidate and we have started to do some testing.

It seems like a great thing that Hatari 2.1 is just released. Maybe the issues I had before was due to some timing issues in the Hatari? But we tested it on a real TT as well and experienced the same issues.

After the first batch of testing in Hatari 2.1, I am happy to announce that EPSS 1.03 with sound drivers 3.4 and 8 channel sound driver works with the following setups without any known issues:

  • TT 32MHz VGA 60Hz + TT High 71Hz
  • Falcon 16MHz VGA 50Hz (why 50Hz?)
  • MegaSTe 16MHz Mono 71Hz
  • STe 8MHz RGB 50HzI only found one setup that caused issues in these tests:
  • Falcon 16MHz Mono 71Hz.
    It sounds like it has some issues with the buffers, similar to the problems I had with the TT on the Hatari 2.0

We will continue with testing on real hardware…