New GUI for the Atari 8-bit

[flashjazzcat]

Which C compiler do you use for Windows stuff Dan? I'm not sure whether to go for VS 2013 or MinGW. VS is absolutely huge but also free. Not doing any GUI stuff yet, but I have some C console stuff to port that I previously wrote using XCode.

[danwinslow]

I actually use VS C# express for nearly everything I write for windows. If the target is anything with a GUI in it, I'd prefer the VS over minGW any day. minGW is handy but its kind of kludged together as a mini virtual linux under windows. It's good if you are a linux/unix person and want something familiar, but in general I'd stick with VS. You should consider C#, Jon, it's got an extremely powerful library. It's like Java, in that it can be insanely complex but for small stuff you can just stick with basics and leverage the libraries as you need them. Plus, I'd go insane if I had to code a GUI from scratch without the VS designers. Incidentally, C# can be run on linux natively using the Mono toolkit without even having to recompile.

 

Of course, I think you can use linux GUI tools like Glade and stuff like that to design things under minGW, too. Glade works pretty well, but its not as seamless as the VS designers.

[flashjazzcat]

Thanks for the pointers Dan.

[pixelmischief]

I actually use VS C# express for nearly everything I write for windows.

 

I write C# for a living and I have to say, what VS offers in terms of template-driven code generation, .Net integration, and data access abstraction with EF simply can't be beaten. Most of this can be recreated in other IDE's, but why do it when VS is freely available. Now, when it comes to C/C++ on Windows, I actually prefer a good CodeBlocks setup to VS. I think it's because when I write C#, I am resigned to the bloat. But when I write C/C++, I want to write lean. VS sucks at lean.

[joyfulcoder]

I'm also not a fan of VS's huge size so I use MinGW with Code::Blocks and then use ResEdit for GUI resources. I recommend looking into these if you choose MinGW.

 

Which C compiler do you use for Windows stuff Dan? I'm not sure whether to go for VS 2013 or MinGW. VS is absolutely huge but also free. Not doing any GUI stuff yet, but I have some C console stuff to port that I previously wrote using XCode.

[danwinslow]

Yah that sounds like a good option too. If I wasn't already hip deep in VS I'd probably check that out.

[phaeron]

For simple command-line stuff like this, MinGW is fine. As long as the program is written in portable C -- which there is no reason not to -- anyone who needs to could quickly rebuild it with VC++. Just make sure to open all files in binary mode.

 

For more complex stuff, you'll want to consider using Visual C++ if you expect to need help from other Windows programmers, as dealing with a MinGW build is a pain. However, you're a long way off from having to worry about that.

[flashjazzcat]

Thanks for all the suggestions. VS 2013 is already installed (after a laborious two hour process the other night) so I might as well try it and see how it fits. A ROM editor (similar to the SDX Imager) might be a nice simple GUI project for later on.

[flashjazzcat]

Relocatable stand-alone Profiler is coming in at 4.7KB. This includes all the menus, bitmaps, buffers, GUI control records, and around 0.5KB of relocation table (which is jettisoned). It should be around 6KB when it's done, which bodes reasonably well for the size of more complex applications. The kernel's currently 5KB long.

[UNIXcoffee928]

Yes - as per the MADS description here:

 

http://mads.atari8.info/mads_eng.html#_relok

 

The loader's already written but needs testing, and this requires a rough and ready ROMdisk handler which I'm working on now. The loader isn't terribly complex, though.

 

Now, the MADS format is all very nice, but has a few limitations, so I'll probably support a second relocatable file format which loads binaries with relocation tables prepared by assembling at different offsets. A simple command line tool in C shouldn't take long to write. This will at least mean that use of MADS for application authoring isn't absolutely mandatory.

 

For a purpose like this, The Digital Mars Compiler should be all that you need. I used to use it with the excellent "ConTEXT" text editor to form a very complete and convenient multi-compiler work environment (Example: Pascal, any compiler, any interpreter, etc).

 

ConTEXT is amazing, once you really tweak the settings, and create your own syntax higlighters (for any language, including MADS). It's super convenient to have a "one editor for everything environment" with ConTEXT.

 

Additionally, because it is a "Notepad.exe" replacement, you can do a virtual "Print" from an Atari emulator, directly into new Tabs in the Context text editor, allowing you to use the Atari as a Text Scripting Tool, for those times when it is more convenient to create the basis of a text file programatically... as a minimum example, set up a loop on the Atari to print a numbering scheme... this goes directly to the text editor in a new tab. Great time saver if you need to make things that look like ASCII tables, etc.

 

Great minimalist setup, and both can easily & quickly be put on a small USB key, so that you can use your standard work environment on any computer with no extra fuss.

 

Try them out. ConTEXT is very powerful, dig into it a bit, and you'll see. Digital Mars is perfect for any ANSI C work.

 

Enjoy!

[pixelmischief]

Great minimalist setup, and both can easily & quickly be put on a small USB key, so that you can use your standard work environment on any computer with no extra fuss. Try them out. ConTEXT is very powerful, dig into it a bit, and you'll see. Digital Mars is perfect for any ANSI C work.

 

That sounds very cool. Is the software portable? Could you zip your configuration up and post it?

[UNIXcoffee928]

 

That sounds very cool. Is the software portable? Could you zip your configuration up and post it?

Perhaps, in the future... I've been running Linux exclusively for quite some time, now, and the Windows system that had all of that on it has to be put back together, one of these days. Sometime within the next four months... I'm kinda busy starving & freezing, at the moment.

 

Really though, just download the above two links, and install them. There is a separate dl link for the version of ConTEXT that doesn't set Registry keys. The Digital Mars compiler can be copied at will, wherever you want it. Set your system environment path variable to allow you to use the compiler from any current directory (otherwise you would have to specify the full path to the compiler), I renamed it to 'cc' for convenience's sake.

 

In ConTEXT, set your background to black, foreground green, and the reverse for highlight, and bring your text point size up so that it's nice & readable, for .txt files. Look in their download section for syntax highlighters, get some. The highlighter files can be directly edited as text files, so make your own, for any purpose, by adding keywords in the appropriate places, for whatever you want to highlight (and set the colors that you want, right from the "Environment Preferences" menu, in ConTEXT.).

 

You can make syntax highlighters for any Atari language, too. On the Atari emulator, just list to printer, and the listing will come up in a new tab in Context. When you give it the appropriate extension, it will automatically highlight the code. In the case of BASIC, use 'ENTER' & 'LIST' for loading & saving, rather than 'LOAD' & 'SAVE', so that you are dealing with a text file. It is nice because you no longer are looking at 40 columns, too. Slightly less interactive, but, whatever.

 

You can then setup your visable windows in the editor, so that you can see console output, and your filesystem. Then setup hot-keys with the Function keys to execute your compiler, sending the current file as it's argument. I think that I had set up macros, as well. ConTEXT is very, very tweakable, so RTFM.

 

It also makes sense to install lua, TCL/TK, Pascal, and anything else that you want to screw around with, and set them up the same way. The editor is very versatile, you can get exceptionally creative with your configurations, once you live in it for a little while.

 

Well, yes the software that you create with Digital Mars is totally portable, since it's ANSI C. TCL/TK is ultra portable, because it will make a pretty gui on Windows, Mac, Linux, Amiga, any system that supports TCL/TK, Free Pascal is also highly portable.

 

ConTEXt & Digital Mars, themselves, are Windows-based, so they are not "Portable". ConTEXT will run fine under Wine on Linux, not sure about dm.

 

Aside from that, a great language to look into is Inform 7. It is meant for creating interactive adventures, but creative usage can give you very accurate simulation & real-world environment modeling. The syntax is nearly English, and is really fun to use. It is exactly the language that Minsky & the other A.I. researchers were hoping for, back in the day.

 

One of the best things about ConTEXT, aside from all that I've mentioned, is that it has a very well implemented Vertical Cut, Copy, Paste capability. You come up with all sorts of uses for it, after you fiddle with it a bit.

 

So, just download them, read the faqs, do the above stuff, and then just start trying lots of things with ConTEXT & dm. If you have any further questions, feel free to ask, and I'll answer them, if memory permits... it's been a while since I was using Windoze.

 

Have fun, lots of cool stuff to mess with listed here!

[flashjazzcat]

Worked until 3am last night getting the MADS relocating loader working, but unfortunately it was a little too late to celebrate when I'd finished. So applications are all stand-alone MADS relocatable binaries now, and it's really starting to feel like a proper operating system. It's unfortunate that all this stuff needs finishing so that I can get the memory stats working in the process monitor, but I figured people would rather see this stuff in action than a lot of place-filling, dummy numbers. Once I get the second graph working, test it, and fix a few other bugs, we'll be good to go.

Finished and WIP stuff:

 

• ROM-based file system working. Part of the cartridge is mapped out as a disk volume, with a FAT root directory storing bank/byte offsets of files (applications, services and resources) in the cluster field. We now have a basic file read-only cart file system with Open, Get Byte, Read Buffer and Close functions.Top-level filename operations (including wildcard directory search) are implemented.
• Processes are now started simply by calling the system and passing the filename and desired task priority.
• Fonts are installed by calling the system and passing the filename.
• The start-up code launches the window server, system, and clock processes, loads the default system fonts and then runs the shell. Since the shell is just an application which owns the desktop, it is replaceable, just like the system fonts.
• Applications now have their program icon embedded in the header, in 12x12 and 16x16 sizes.

Since we have a rudimentary file system, once the demo's out we can tackle making the file browser work, displaying files on the ROM disk in icon/list view and launching applications by double-clicking them. Work can also be started on the terminal, since we now have a directory to list. Buffered keyboard driver needs writing. Beyond that, the biggest job will be writing the SIO and FAT file system drivers, and then the operating system itself will be basically finished. Since I effectively re-wrote the whole thing in November 2013 (when I adopted the rectangle-based windowing system) and didn't start turning it into a micro-kernel, cartridge-based based multitasking OS until May 2014, I feel like this is good progress as we approach 30,000 lines of code.

 

ConTEXT is amazing, once you really tweak the settings, and create your own syntax higlighters (for any language, including MADS). It's super convenient to have a "one editor for everything environment" with ConTEXT.

I've heard about it and will check it out when I have time: thanks. As for MADS, I'm pretty much rooted in Eclipse/WUDSN IDE now (the outline view alone - which lists all the folding LOCAL/PROC ranges - would be impossible to live without). Of course, I'm so used to Eclipse now that I stuck with it when learning Java, but I might not go so far as to use it for C/C++ work.

[flashjazzcat]

Urgh... had to down tools again until further notice because (I think) of a compiler bug:

 

http://atariage.com/forums/topic/179559-mads-knowledge-base/page-11?do=findComment&comment=3151721

 

If this isn't resolved quickly I'll have to replace all the structs with macros... not a small job.

[TheNameOfTheGame]

Urgh... had to down tools again until further notice because (I think) of a compiler bug:

 

http://atariage.com/forums/topic/179559-mads-knowledge-base/page-11?do=findComment&comment=3151721

 

If this isn't resolved quickly I'll have to replace all the structs with macros... not a small job.

 

Crap

[danwinslow]

Jon, fantastic progress. Any chance of us being able to write small apps ourselves under the demo? Just wondering.

[flashjazzcat]

If there was some way to load them, yes: currently they need to be on the ROM disk since there's no SIO file system driver yet.

[flashjazzcat]

 

Crap

 

My sentiments exactly. But I managed to kludge it temporarily by writing macros which generate data for the corresponding struct. Of course this solution (as well as being fiddly, time-consuming and error-prone) completely strips away all the elegance MADS structures provide in the first place. If the struct definition is used as a direct template for instances of data, every time the struct definition changes, the data changes (and throws up an error if the number of arguments is wrong). With the macro workaround, however, one needs to remember to carefully sync changes to the struct with changes to the macro. The whole reason for using structs in the first place was to avoid this kind of thing... SIGH.

[flashjazzcat]

Thanks entirely to Tebe's rapid-response bug fix, we're back in business. Relocating loader now works, and the initialisation routine now loads all the resources from the ROM-disk by filename and everything goes into RAM allocated with MALLOC. In fact all four resident fonts plus the three demo apps all fit in the base 16KB bank at the moment (mainly because the Profiler is the only large-ish application right now). The interesting implication is that the demo will run on a 64KB machine. I can't see that situation lasting for long, though, especially once the shell gets bigger and we need to allocate drive buffers, etc. Anyway... Looking at a weekend download, finally.

[Chilly Willy]

Thanks entirely to Tebe's rapid-response bug fix, we're back in business. Relocating loader now works, and the initialisation routine now loads all the resources from the ROM-disk by filename and everything goes into RAM allocated with MALLOC. In fact all four resident fonts plus the three demo apps all fit in the base 16KB bank at the moment (mainly because the Profiler is the only large-ish application right now). The interesting implication is that the demo will run on a 64KB machine. I can't see that situation lasting for long, though, especially once the shell gets bigger and we need to allocate drive buffers, etc. Anyway... Looking at a weekend download, finally.

As the owner of 5 different 64K Ataris and nothing else, I approve of the memory usage of the current demo.

[Joey Z]

Thanks entirely to Tebe's rapid-response bug fix, we're back in business. Relocating loader now works, and the initialisation routine now loads all the resources from the ROM-disk by filename and everything goes into RAM allocated with MALLOC. In fact all four resident fonts plus the three demo apps all fit in the base 16KB bank at the moment (mainly because the Profiler is the only large-ish application right now). The interesting implication is that the demo will run on a 64KB machine. I can't see that situation lasting for long, though, especially once the shell gets bigger and we need to allocate drive buffers, etc. Anyway... Looking at a weekend download, finally.

*starts working on that 1MB upgrade for the 400*

[flashjazzcat]

I foresee problems with the MADS relocatable format further down the line: although it works very well, there are some obvious limitations. The main one is that it's impossible to allocate undefined memory in the program space, since .DS is not permitted. That means that if you want to define buffer space in your code, you must use (instead of .DS) something like:

 

.REPT 512

.BYTE 0

.ENDR

 

So if your code is 8KB long and you want 8KB of buffers, the binary is also going to be 16KB long. Why not use MALLOC? Well - aside from the fact it's overkill for a bunch of buffers - MALLOC is by no means guaranteed to allocate memory in the same bank as the caller. Since the applications (in the $4000-$7FFF) banking window share the same address space as memory allocated with MALLOC, there's no guarantee that you'll be able to access the allocated RAM directly. We could get around this to some extent by removing the "best fit" bias from the memory allocator, so an 8KB binary would tend to go into the first empty 16KB bank, and subsequent memory requests would tend to return blocks from the same physical bank. But for small buffers this is still overkill when all we want is a .DS .

 

Perhaps binary size isn't such an issue these days, but it will be for applications stored on the ROM-disk, where space is very limited. .DS support in MADS' proprietary format is an unlikely prospect (it's fortunate enough that the format can be re-purposed for use here at all), so it still might be worth looking into the SDX format or perhaps writing some tool which strips empty blocks from binaries and injects some intermediate headers. The loader obviously needs to know the total linear extent of the binary (including skipped gaps), so perhaps something like this would work:

 

.WORD $FFFF

.WORD 0

.WORD LENGTH ; total size

 

<other standard MADS header stuff>

 

.BYTE TYPE_CODE

.WORD length

 

<code>

 

.WORD TYPE_SPACE

.WORD length ; loader just bumps location counter

 

<etc>

 

We could possibly generate this by running completed applications through a little command line tool.

 

.

[flashjazzcat]

A taster of the demo. Short of closing applications, I don't think I'll have time to add much more:

 

 

Dummy clock will be reinstated as well, and full window drag turned off (if not optional).

 

EDIT: Note that used RAM includes the base 48KB usage ($0000-$3FFF and $8000-$FFFF) and 1 page of every 16KB bank for the allocation map, plus the fonts and applications.

Edited January 15, 2015 by flashjazzcat

[gozar]

I know it's somewhere in the last 131 pages of this thread, but will there be an option to turn of full window drag? (Or is it too early to worry about? :-)

 

Looks really amazing, can't wait to see what apps get written.

[flashjazzcat]

You don't have to look further than the post above yours for the answer to that question.