Tuesday, January 12, 2016

RC 2016/01: My development tools, part 2

In my last post, I talked about some of the tools I would use - specifically cc65 and AppleCommander.  But at the time of that post, I hadn't actually done any development yet.  Now I have, though admittedly I still haven't gotten very much done.  I have refined the build process that I used with other cc65 projects so that it's a bit more logical and flexible, and I've incorporated a library from one of my Retrochallenge "competitors"; more on that below.  Nevertheless, I still have a lot of work to go and it's already 12 days into January.  I knew the first half of the month would be slow going, given everything else I have going on, but I've made even less progress than I'd expected.  I'm hoping I can catch up during the second half of this month.

If you're interested in taking a look, check out the repository on Github: https://github.com/hculpan/kbase.  Note that if you build and run it, it's actually a slightly modified version of the A2 CARDIAC program (see my Prepping for the Challenge post for more information on this).  Obviously this will change, but I just wanted some code to test out my build process.

In this post, I'll talk about my build tool, editor, and emulators that I am using.

Make

For my build tool, I went with the Make utility.  There are almost certainly better tools out there for C development, but honestly I'm reasonably familiar with Make so it's just easy for me to use.  I also like that it makes no assumptions and I'm in complete control of what build targets are available, what commands get executed, etc.  In my professional life as a Java developer, I use Maven, which really does most of the work for you.  I'm happy with that build tool, but it can be a pain when you want it to do something that it doesn't want to do.  But with Make there are no such issues; it does only what I tell it to do and nothing more.  For a larger project, like those I work on in my job, this could be bad and hard to manager, but for a small project like kBase, this is much easier.

Of course, with Linux you almost certainly already have Make installed, and on Mac OS X, it gets installed when you install Apple's command line development tools (see cc65 above).  With Windows, though, it's a bit more of an issue.  My solution is Cygwin, which is one of the first things I install on any Windows machine anyway.  If you don't want to install Cygwin, there is MinGW.  Otherwise, I'm not really sure how to get Make on Windows, but that's just because I don't generally do C/C++ on Windows, and when I do I happily use the Cygwin tools.  There are also other newer cross-platform build tools, but since I'm happy with Make, I haven't really investigated alternatives.

Atom editor

For code editing, I use the relatively new Atom editor.  Overall I like the editor, but honestly it's two best features for me are that it's cross-platform and that it can be launched from the command line.  This last is a rare feature among editors, and for a command line guy like me, a welcome one.  I can type "atom ." at the command line (and I always have a command prompt open), and it will open with all the files in the current directory listed in the left panel, ready for me to select.  It's almost like having a project manager built into the tool without having all the constraints of a full-blown IDE.  Otherwise, I just use it as a text editor.  I haven't installed any plugins to launch builds from my editor or anything else.  It does have C and Makefile syntax highlighting built in, which is nice.

One way I think I'm different than many other developers is that I'm actually pretty neutral about my editor.  I can use anything from Vi to a full IDE without too much complaint, as long as it's not Emacs.  During my last Retrochallenge, I even began to like TECO, the PDP-8 editor, so really I'm pretty flexible when it comes to my editor.  As a side note, it is a little ironic that I hate Emacs but like TECO, since Emacs actually started as a set of macros for TECO.

Emulators

As I've said, I'm doing development on both Mac and Windows, and this is the one category of tools that I really couldn't find a good cross-platform solution.  However, there are good emulators for both platforms, and I chose probably the two most obvious choices, AppleWin for Windows and Virtual II for Mac.  They are both good emulators and both do what I need, at least so far.  But honestly most any emulator would probably do what I need.  The only issues I would be likely to run into would be printer support and extended memory, since I'm pretty certain I won't be implementing dBase III+ in 64k.
Having said all that, I will say that Virtual II may be the best emulator I've used for any platform so far, and it is the only one that I paid for (the others all being open source, not that I've been using them illegally).  Honestly, I haven't used much of its advanced features, but it comes the closest of any emulator to really feeling like a real retro computer.  Overall I love the interface, and I love the sounds it uses to simulate a real disk drive.  So if you're looking for an Apple IIe emulator for Mac OS X, I would recommend you give it a try.



The Real Hardware

The final tools I wanted to mention are the actual hardware that kBase will be running on.  That will be primarily an Apple IIgs with 4 MB of ram, both 5.25" and 3.5" floppy drives, and a Classic IDE for Apple II emulator my hard drives (though I have a CFFA3000 on order).  Obviously I usually run GS/OS, but for this project I'll be using it as a standard Apple II.  I also have an Apple IIc with 512k ram, which is usually packed up but will also be used as another test platform for this project.

TUI Library

Finally, I wanted to mention that Tom Raidna (@TRaidnaComputes on Twitter, blog at https://traidna.wordpress.com/) nicely offered to share his project with me, since we're both working with cc65 and I will need a text interface for kBase.  His project, Retro C IDE, is going to allow you to layout a text-based interface and then generate the C code for that interface from his Windows-based application.  Now since it is Windows-based, that's less useful for me, but as it turns out he's generating code for his TUI Library that he had earlier developed - and this library is definitely of use to me.  So he has shared this library with me, which I hope will simplify my efforts to develop the interface for kBase.  So kudos to Tom!

Next Steps

Hopefully in my next blog post, I'll be able to report some actual progress with kBase.  First, I'll build the basic user interface (the "." prompt) and a simple parser to interpret commands.  After that, I'll hopefully be at a point where I can read a dBase database file.

No comments:

Post a Comment