Display List Editor Finished

The Display List Editor is now complete. Users can visually design a display list and then at the click of a button, save it for later use, insert it directly into the source, preview it or copy the generated code to the clipboard.

This should help Atari developers, particularly those who are starting out with coding custom Display Lists.

I still have to add some extra functions in the main program itself regarding this editor, but the will also impact on other areas. One of the functions I want to add is a drag and drop functionality that will allow resources to be dragged from the Project Manager directly into the source. If that item being dragged is a binary file (character set or player missile set), then a binary include function will be inserted into the source. However, because it is not as straightforward to include the display list as a binary source, if you drag the Display List file into the source, then the program will decode the display list and embed the actual source code of the display list into the program source file. Dragging a normal source file into the source will generate a source include function to be inserted.

Hopefully, this will make things that little bit easier for people.

I have also managed to reduce most of the flicker issues I was getting in the Windows version of the IDE. This means that as I am coding this in Real Studio from RealSoftware, I should be able to release the Windows version at the same time as the OSX version.

I have been receiving a lot of positive feedback from the AtariAge community regarding this project, and it is great to see people taking an interest. I am also getting a number of suggestions to help improve the IDE, some of which I have included into the Display List Editor. Some these include an editor to allow the user to edit BASIC files and the facility to export the resources for other languages (such as C, Action!, Quick, etc.). I am excited about putting these functions in, however, I would like to get this to at least beta release by the end of next month, so some of the suggestions may have to wait until version 2, and if the reception the program gets is as good as I think, then there will definitely be a version 2.

Bug Fixes and Progression

Well, the IDE has been progressing nicely. Did a bit of testing recently, which should me a number of bugs that had managed to creep in. They have now been thoroughly squished. Most of the pertained to the source navigator, but a couple reared their heads in the actual source editor itself. Nothing major to fix, but they would have been show stoppers in the finished project.

I have been also getting on with the display list editor. This has proven a bit of a challenge, not with the programming itself, but with the design of it. I want to try and create something that is relatively easy to use, whilst at the same time, allowing all possible permutations for the display list. What I have come up with is:

What you can see here is the actual editor. I will explain each section:
Firstly, the table in the top left of the window displays the line types, with various properties. This means that when you are creating your display list, you do not need to worry about adding values to the code to make a DLI or a LMS entry. Even the smooth scrolling flags are taken care of. As you can see by the pop-up window, the antic codes are selected from a list, again meaning that you do not need to remember which code it is you need. (Looking at this right now, I thing I will add additional information in the list, such as pixels/characters per line, etc).
To the right of this, you enter your address for the display list. This can be either an actual address, or a label.
Directly below the address entry, there is a little box to set the display list to one of the predefined BASIC graphics modes. This can be useful if you are going to base your new display list on an existing mode.
At the bottom of the window, we have the preview section. The large rectangle (partially obscured by the pop-up menu) gives a graphical representation of the screen. Each antic mode on the preview is represented by the colours indicated to the right of it. This will allow you to get a quick feel for how the screen is laid out.

Finally, we have the buttons in the bottom right corner. These do the following:
Copy: Copies the completed display list to the clipboard.
Insert: Directly inserts the display list into the current insertion point in the source editor.
Preview: Displays a textual preview of the complete display list.
Close: Closes the window (obviously).
Save: Saves the display list to disk.

One thing I haven’t mentioned, the table also allows you to enter addresses for LMS functions. When copying or inserting the list and an address is found on a particular line, then the Antic Code is automatically converted to an LMS instruction. The software will also append the Jump At Vertical Blank instruction to save you worrying about it. As it stands right now, there is no Jump To Address instruction, however, I will be adding this in for completeness.

Source Navigator In Place

Just to keep everyone up to date with the project.
I have now put in the source navigator. I have copied the graphics and style from the navigator in WUDSN so that it is familiar to people who have used WUDSN before.
At present, it doesn’t display equates, but if there is a call for that, I will put it in.
Anyway, here’s a new screen shot:

Now to get the find and replace dialogs and functions in. Then the editor itself is done.
After that, I will put in the code to call the assemblers and report back to the user with either success or failure options.
I will then create the links to the emulators (Atari800MacX on OSX, Atari800Win and Altirra for Windows), so that the IDE can be used as is.
The sprite editor will come after that. I plan to create an editor that will allow the user to create and preview animated sprites. They will, by default, be saved as a binary file, however, like I plan to create for the character set editor, I will introduce some code export options as well.
Although the screen shot here is still showing the New Screen button on the toolbar, this will be removed. The Atari allows us to create an almost infinite amount of different screen configurations, and with DLI’s, we can even expand on that. So, creating an effective editor would require a great deal of work, more than I want to do before I can release version 1 of this IDE. Therefore, I will be removing any functionality for that area for now.

Source Editor and Character Editor Complete

Time for a quick update on the development environment.

The Main code editor is almost complete (I think). I have written it from scratch, using a canvas, to allow me total control over it.
It has full syntax highlighting that is changeable, dependent on the assembler being used and code folding. I still have to implement the source navigation and search facilities.
The project manager is also in place and 80% functional. As I work on other parts of the project that impact on it, I will make the changes then.

The basic character set editor is now finished. At present, it only saves to binary format, so the character set can be directly included in the source, but I may also add an export facility to create source code.

The preferences window is being created as I do each area of the main program, therefore, I have done the Code Editor and Character Editor sections only, so far.

ACDS Continued...

I have been cracking on with the development environment (Horace seems to have taken a slight back seat while I do this).
So far, I have a character set editor built, the project manager and half the source editor.
I have decided to concentrate on on assemblers for now (sorry C coders), but version 2 may include C compiler facilities.
I am also not limiting it to any particular assemblers, although it will ship with default settings for ATASM, MADS and XASM. Other assemblers can easily be added to it.
One thing I didn’t mention in the original post about this project is that it will be available for both Windows and OS X. I’ve using Real Studio to develop it, which is a great cross platform development system.
Anyway, here is a pic of the startup screen for you:

Atari Computer Development System (ACDS)

As I am developing Atari software now, I have been on the look out for the best tools to help me. So far, the best I have found is Eclipse with the WUDSN plug-in. This makes coding assembly for either the MADS or ATASM assemblers a dream. For user-defined graphics, I have been using EnvisionPC (which I recompiled for Mac), which has also saved me a lot of time.
However, looking for decent tools, I came across something for Spectrum developers that would be ideal for Atari developers. There is an integrated system for the Spectrum called Tommy Gun. This incorporates graphics tools, code editor, assembler and screen editor all in one. Such a thing would be a dream for any developer, regardless of the system being developed for.
So (you guessed it), I am looking at creating something similar for Atari development. As far as I can tell, it would have to have the following:

• Code editor - This would definitely have to be for assembly (allowing for MASDS, ATASM, CA65 and XASM syntax’s), but possibly also C and maybe Effectus and Atalan. For those last two, I would need to either research the syntax thoroughly, or contact the authors directly.
• Font/UDG editor - This is a must in my opinion. Most games use some form of custom graphics or text, so the ability to design them within the development environment would be fantastic. The resultant fonts would also have to be exportable into a number of formats, including (but not limited to), various assemblers, C, Effectus, Action!, Atalan, Quick, Forth, TurboBasic and good old Atari BASIC. Also, an option to save the fonts directly as binary would be marvellous.
• Sprite editor - The Atari is well known for its sprites, or Player/Missile Graphics (PMGs), and again, these are used in most games that are compiled into machine code. Even some BASIC games use PMGs with machine language routines. Again, these would need to be exported in the formats listed above, as well as binary.
• Screen designer - Nothing as advanced as Graph2Font, but it would be useful to have a screen designer that allowed the creation of screen images in ALL of the Ataris ANTIC modes, maybe even combined ANTIC modes. These could then be used for loading screens or possible game screens for faster transitions. Right now, I am not too sure about graphics formats on the Atari, so I figure the best way would be to save these as binary and if required, a linked custom display list.
• Sound/Music editor - T this would have to be the last stage of the project. As I have no idea about accepted formats of sound or music with the Atari 8-bits yet, I will need to research these. I may leave these out altogether, depending on what I find.

So, anyway, that is my plans for I am currently calling the Atari Computer Development System, but I’m sure I can come up with a better name before the project is finished.

Time sure flies - heading into the past

Wow! March already. I guess I should make a post of what I have been up to.

Since the New Year, I have been kind of bummed out with my main projects. I felt it was time for a break, a metaphorical change of scenery. So, I have gone back to my computing roots and begun on a retro project.

I am attempting to recreate one of the Spectrum's classic games, Hungry Horace, on the Atari 8-bit computer. Originally, I was going to do this with a language known as Quick and program directly onto my Atari 800XL. I had not programmed in it before, and I had heard some really good things about it and I could see how much easier it would make things.

I began the coding, and all was going well, but then I got side-tracked (don't I always?).

On the AtariAge forums, I saw a thread where people were talking about their development environments. someone there mentioned a plug-in for Eclipse, known as WUDSN, that was created for writing in assembly to cross compile to the Atari.

I thought I would give it a look, and I liked what I saw.

To that end, I have decided to restart Hungry Horace, but this time, using the MADS assembler. I have never coded in 6502 assembly before, although I knew the basics, so it would be a good learning exercise.

Upshot is, in two days of part-time programming, I am about a quarter of the way through the project coding. I am very happy coding in assembly, it seems to make a lot more sense than higher languages. I have total control of what I am doing. I still come across a few things that I stumble across (such as only being able to use indirect-indexed addressing with zero-page addresses), but I am getting there. And using Eclipse, the WUDSN plug-in and MADS makes it a dream to code. I can honestly say, I haven't enjoyed coding like this for a long time.

If things go according to plan, and I get a successful game at the end of this project, I will almost definitely create some more Atari games (possibly the two official sequels to Hungry Horace to start with). As one of my other computers back in the 80's was also 6502 based (the Oric Atmos), I may look at writing some games for that too.

So have I given up with RealStudio and BlitzMax? Absolutely not. I will get back to some modern programming again soon, but for now, I am enjoying my time in the past.