Sounds like a good plan to me as long as code blocks is optional.
Why? Space reasons? Code::Blocks is actually very small. If I go back to having separate binary and source releases, the combined binary release would not be much bigger than Catalina is now.
If one needs a specialized build environment, and I currently am setting one of those up for a Internet startup venture, lean products tend to fit into those rather easily. No worries, all upside. (Jazzed, I think we are going to use Mercurial --it's excellent, and IMHO superior to older file based systems)
"The Propeller Tool Experience" is a good thing. That is thicker than just a simple command line environment. But, I think that has a nice pay off too, because there are a lot of people who won't get on a command line. I like both actually. Depends on things. At times a GUI rocks. I like the Prop Tool GUI a lot, because it's lean. I don't have to know much, and I can make the Prop do things, while keeping track of a very small number of additional things.
To explain "lean" (and I'm basically in the mood, with a bit of downtime sufficient to write it, but not so much that I could jump into something else, so...)
1. Fewest number of dependencies
2. Ability to operate "plain vanilla", like load the OS, load the tool, go. Might not be optimal, but that should work, period. This tends to keep the number of unique assumptions to a optimal size for the source tech as well. Knowing extra things has to pay off, or why know them?
3. Smallest number of machine resources. Again, maybe not optimal, but it should work, period.
4. Least impact on options. eg: Too complex of a manipulation means few people will exercise the choice, or a set of poor, or conflicting choices marginalizes the value of making them. That's the kind of thing I'm getting at.
From there, options are good, but I think each one should pay off. The Code::Blocks move would pay off, because there are a fair number of prospective users who would be inclined to just load it and go, and the choice to not use it would not be a complex manipulation.
I don't think introducing the dependency of specialized "wish it were really UNIX" tools on Windows would pay off, and I think we've arrived at why that is. Just use a UNIX; otherwise, use Windows as Windows. It's lean that way.
Got that influence from a few core drivers in my life.
1. Grew up somewhat poor. One appreicates lean on a lot of levels when money is a issue. Not bitching, and in fact, happy it worked that way for me, simply because I ended up with a nice set of "coping" skills that leave me empowered in most scenarios at most times. Can't buy that easily, if at all.
2. Manufacturing. Now I don't do manufacturing anymore for a lot of reasons, the primary one being how devalued it is in the US right now. That's politics, so I'll stop there and just say I chose to move horizontally, leveraging that experience. In manufacturing, dependencies introduce cost and they introduce variance, which ends up being cost when you boil it all down, because it's a quality issue. Waste introduces cost, just because materials cost, and waste isn't productive. Don't like waste, and will regularly invest people time, thinking time to avoid, or marginalize, or re-purpose waste. Excessive handling, and or redundant processes, means, methods, paths. Human energy costs money, machines cost money, and throughput matters in manufacturing.
Once I reconfigured a shop after doing about a weeks worth of planning. That week paid nearly 6 figures over the course of the next year. Do not underestimate lean in this respect. And that's a nod toward the build environments. That is exactly why people build them for software. It's the same exact problem, just a different space.
Finally, automation. Automation itself can get thick because it introduces dependencies. It's important to make sure things pay off, so that the holistic product of the effort is optimal in terms of the cost of the operation as well as the human energy required / saved and the impact of that on overall variance. Toward that end, where processes are lean to begin with, the equation for automation is simplified, often removing a factor or two, making it viable at a fairly low barrier to entry, as well as making it deliver a return quickly.
During my time in manufacturing, I broke every quality record and production record ever set in front of me by a significant margin, walking out on the chumps that were penny wise, pound foolish, because it just wasn't lean, and that consumed me for no return, and well? I've better things to do, and really haven't changed much.
3. Software. I've written some software. Not too many big pieces of software, though I want to, but lots of little bits of software for many different things. Some of it was manufacturing automation. Lean was big here, because barrier to entry for one off things is HUGE. It impacts the entire equation. Giving that serious consideration really pays off. I used what was lean, that would endure, portable, etc... and most of the stuff ran for well beyond it's expected life, and was ported easily. In fact, one bit of code, written for a CAD system in 92 is still working, on the modern version, because lean kept that code to the core of the API, which didn't suffer the kind of change the thicker and sexier elements of it did. Result? The users of my product got huge value for their dollars, with me in shock to find it's still in use today, just down the street. Pirate copy too! I grinned, and told them seeing it running after so long was totally worth it, and wrote them a license on the spot.
(yeah, softie)
4. UNIX. Unix changed my computing life. Having come up on 8 bit computers, hacking on all matter of arcane NC controls, serial this to bizzare old box that, hope to god USENET has somebody somewhere who knows what this widget does, serial to the end stuff, I moved up and out to do systems work. Went from ugly contraptions, DOS, assembly, etc... to multi-cpu 6 figure devices that would serve 30 users at a time, doing high end stuff, UNIX is the pinnacle of lean, when it's well realized. A good systems engineer enjoys their Slashdot and MP3 time, and that ain't gonna happen, without lean. Lots to say about UNIX and X, and I'll just rest on it's simply the bar for computing lean as far as I am concerned, and that one can make as big of a mess on UNIX as they feel inclined to do. That costs though, and it's all self-selecting in a hurry, with the ones who didn't get the memo running around haggard, while the ones that did are listening to their MP3 files, planning their next move to significantly improve on that listening time.
Then we come to Windows... So, I hated it for a long time, simply because it was not lean in a way that paid off. Well, paid off for the producers of it, but not for most people using it. Very interesting dynamic to watch over the years, and I'll stop there, leaving that as a case in point how simple lack of features and planning isn't lean. Lessons learned there too, with XP and 7 being perfectly fine OSes. Not as lean as they could be, mostly because they are still built on some very broken ideas that introduce dependencies not required, nor advantageous.
That said, people vary, so lean varies!!
For somebody who has not experienced the things I have, lean might mean "just works on windows with the command line", or it might mean they want the GUI, or maybe it means, "works like the other cool stuff I really know how to use" too.
From the developer standpoint, or more simply, source of technology to be adopted, that potential set of "lean" means characterizing the potential sets of users, their potential for "lean", and making investments that will pay off for both the source, and adopter of the technology in question. I do not believe I've ever seen that balance play out differently. That is simply lean, and where it's done right, there is a "thick" return for everybody, and a best case long technology use cycle, which in and of itself is lean.
(sorry Ross, if I've made a mess of the thread Edit: I wanted to put some perspective out there, highlighting how people do vary, and how sets of choices can impact technology adoption in general. People default to lean, unless they've got some very compelling reason to do otherwise.)
If you only want to package catalina + code blocks that's fine. I tried code blocks and i don't like it. It has nothing to do with how big it is. I have some hardware that I'd like to see supported by catalina though so I guess I have no choice but to use it.
IMHO, this should be a simple choice. Is it possible to stage things? Pluck out a package that's just command line "works on windows", then finish, and produce Code::Blocks?
Other vendors have solved this problem by including, "Catalina Command Prompt" in their program groups on Windows. Click the app icon and get the GUI. Click the command prompt, and get dropped into a ready to cook, vanilla environment. From there, people either go for one or the other as they see fit, or they start with one, come to understand the other is necessary and it's there, ready.
One nice thing about that is there is a reference environment in the command prompt. This is kind of great for checking when things don't work. First move, use the "official" one, compare / contrast to whatever environment is in use otherwise, and deal accordingly. Most people won't get there, but for the ones that do, it's lean.
(sorry Ross, if I've made a mess of the thread Edit: I wanted to put some perspective out there, highlighting how people do vary, and how sets of choices can impact technology adoption in general. People default to lean, unless they've got some very compelling reason to do otherwise.)
No worries - what kind of tool maker would not be happy to listen to others experiences with similar tools?
If you only want to package catalina + code blocks that's fine. I tried code blocks and i don't like it. It has nothing to do with how big it is. I have some hardware that I'd like to see supported by catalina though so I guess I have no choice but to use it.
While I may end up packaging them together, that doesn't mean you can't simply ignore Code::Blocks and use the Catalina on the command line instead. It just means that I would stop offering any other build tool support (i.e. makefiles, batch files, bash scripts etc, etc).
If you don't want to use Code::Blocks as your build tool, but you do have some facility with make and only need to support one environment (i.e. Windows or Linux) then you can easily do this yourself - the difficult part is supporting multiple environments - Code::Blocks does, and MinGW does (mostly) - but make by itself doesn't.
Quick tale to point to where I am coming from...
I was in computers before the micro chip was invented. I bought the first Motorola 6800 D1 and then D2 kits. I wrote my own cross-compiler on my own mini (yes, and it was the length of my garage... because it was in my air-conditioned garage). So I do know all about command line compilers, etc.
But, I had been away from electronics for a few years, building my boat and sailing.
I came back to electronics and accidentally discovered the prop while waiting for my pic kits to arrive. Lucky for me hey! Ordered my Prop ProtoBoards immediately ( I had a FT2232 board so I didn't need a propplug).
Literally, from installing PropTool and powering up my ProtoBoard (with a superbright LED spread between two pins to use the onboard 10K resistor in the mouse circuit) in less than 10 minutes the LED was flashing. No worries about make files, bash scripts (let alone what the hell they are), etc. Just a simple compile and voila - its downloaded and working
I didn't even have to work out what to set all the registers to to get the prop configured to run (or find a file that did this for me). Nothing like the old micros that required this knowledge up front. And looking at all the pic chips, avr chips, etc, they all suffer from an exhaustive set of registers that have to be initialised pretty much in order to get anything to work.
I had such a fantastic experience on the prop, I just want to keep it that way!
I don't wish to learn *nix because I am no longer interested in the command-line. That was aeons ago!! And I don't mean I am a windoze fan - I am definately not - it has so much baggage and I cannot control when it goes off and does its own thing. However, it has made life simple, and that is what I want, or should I say demand!
So, if Catalina is simple to use, then hey I will bother to learn C better than I know now (yes, I did write some C code a long time ago).
Hope this helps put into perspective where I am coming from. Don't know if it is relevant to anyone elses perspective or not.
Hope this helps put into perspective where I am coming from. Don't know if it is relevant to anyone elses perspective or not.
Yes, it all helps. Catalina doesn't get as much use as I'd like, and one reason (as Dr_A highlighted) is the complex process of getting up and running (or at least it seems complex if you are unfamiliar with the underlying tools you will need to use). Let's face it - these days many users (my own children included) have never even seen a command line interface, and are completely unaware that Windows even has one!
This means Cataliina is not a happy experience for some potential users. A proper installer would help - but Windows installers are notoriously difficult to write and/or expensive to maintain - sometimes more complex or more expensive than the software they install (I have direct experience with instances of this). This is why "open source" software often doesn't bother with them. That, and the fact that the target market for a lot of "open source" software is an experienced user base that has no problem with command line tools and a manual installation process.
Obviously, this means Catalina currently has a mismatch with both the existing Propeller user base (at least the hobbyists and enthusiast user base) and also the commercial user base (pretty much non-existent as yet, but perhaps one day ...).
So learning these lessons is vital - not only will it help Catalina, but also anyone else who wants to offer Propeller tools or products.
GNU Make isn't a particularly complex or difficult tool. Sure there are some corner-case advanced features in there, but the basic working of Make is very easy. Two concepts:
1) Dependencies. That's just writing them as file1: file2 when file1 depends on file 2.
2) Rules: What to do when a dependency tells Make that something must be done. You write them below the dependency. That can be as simple as the command-line equivalent of the action. But many rules are built-in already, so you don't have to write anything. This includes compiling C, for example.
So I have my 'hello.c' program. I can write 'cc -o hello hello.c' every time I wish to compile it, but I can also write a Makefile. Looks like this:
hello: hello.c
That's all. Now I just write 'Make':
$ Make
cc hello.c -o hello
$ ./hello
Hello, World
Now if I write 'Make' again:
$ Make
make: `hello' is up to date.
Not complex. I could have added the rule myself:
# My Makefile
hello: hello.c
cc -O2 -o hello hello.c
# Just added a bit of optimization there
and it'll work too. And there are shortcuts so that I don't have to spell out the name of the files, e.g. 'cc -O2 -o $@ $^', but that's just to save typing when there's lot of simillar stuff (will make your copy&paste easier). But there's no need to dive deeper than you wish.
My point is only that saying GNU Make is complex is a red herring. It's false. (Now, there's something called 'Automake'.. must not be mixed with Make. Automake sure is complex, and difficult, and huge. But it's still the best tool if you need a build system to work anywhere and everywhere. But in practice only a few specialists write those kind of things.)
My point is only that saying GNU Make is complex is a red herring.
Not really. I wasn't intending to single out GNU make in particular, but there is no doubt that make is a complex tool. I agree that the fundamentals are easy, but the devil is always in the detail - and handwritten makefiles often embody so much detail that they become unmaintainable. This is particularly true when trying to write a makefile for use in multiple environments. GNU automake is a good attempt to eliminate some of the complexity implicit in make (by remove the need to write makefiles by hand) but it does add some complexity of its own.
Of course, exactly how complex you find these tools to be depends on your level of expertise, but as an indication, the GNU make manual is about 110 pages, and the automake manual is about 170 pages. And all this complexity is just to achieve the same thing that most IDE users these days (including users of both Code::Blocks and the Parallax Propeller Tool) expect to achieve just by pressing a single key.
It is also worth noting (again) that while most Unix programmers will have at least been exposed to such build tools, many Windows programmers will never have seen one. And since the vast majority (currently around 80%) of propeller programmers are windows programmers - and I see no reason to think this will change in future - it seems reasonable to assume that most propeller programmers (now and in the future) will be unfamiliar with such tools.
So my current feeling is that those who want to use such tools can do so, but that I should not force all users to do so - at least not just to build the demos and utilities included with Catalina (building Catalina itself is a separate issue).
Yes, but each makefile would typically only support a single environment. While this is ok for a user who is capable of generating their own makefiles for their own purposes (since most users only work on one environment), it means I would have to maintain two different sets of makefiles (since I support two different environments). So there is no benefit for me over the current method of batch files & bash scripts.
That was why I originally suggested MinGW. With a bit of work, it is possible to write makefiles that will work under both MinGW and Linux - but it is harder to do so if you just have make (i.e. without MinGW).
Please keep it simple! Could it be ALL done in a complete install package?
Yes, this is my current thinking. Of course, since I do this for nothing, it will depend on whether it is both cheap enough (in tools required) and simple enough (in time required) for me to do it. There are also licensing issues I will need to look into.
I suppose I could offer the "one touch" installer as a purchasable option (as I currently do with the Catalina Optimizer) but distribute the source code for nothing to those who want to install it themselves.
Just brainstorming a bit here, but in an ideal world, you would download a zip file, click on "setup.exe" and it would run a setup program, possibly ask some questions along the way ("directory xxx does not exist, would you like to create it?), and then "would you like to create a desktop icon?" and "would you like to run the program?".
This would then run code::blocks with the catalina custom settings, and the newbie user would then think "what do I do next, I know, try File/Open" and in there might be "demo.c" and so open that, then ideally there is a "run" button that is fairly obvious, so you click that and it says "propeller not found", so you connect the propeller and power it up, and then try "run" again, and a led flashes on the board.
That might be the ideal. Certainly if one writes a vb.net program, the creation of the "setup.exe" program is a very simple process with just a few clicks. For the end user, installing that program if one has .net is probably as simple as above. I'm not sure what happens if .net is not installed - probably the program goes away and downloads .net automatically.
But Catalina and code::blocks are two separate programs. Still, this is not insurmountable. Often for instance, installing one program chains the install of another program, eg many programs I've downloaded go on to install things like acrobat, or java.
I'm not sure how one might go about building a "setup" for the command line part of catalina. Ideally it is a one step process, though behind the scenes you might have batch files chaining other batch files. So long each chains the next correctly, there would be nothing inherently wrong with questions appearing in dos command shell boxes rather than in windows input dialog boxes.
I imagine there might be a few questions to ask. The first one would be to ask if it is ok to create c:\program files\catalina. And the second really important one might be to note that the program has found a previous instance of c:\program files\catalina, and would you like to copy this somewhere else, or overwrite but only with newer files etc. (I have an awful lot of programs in c:\program files\catalina\demos, and I wouldn't want those overwritten with a new install).
Batch files can ask questions, can't they? And batch files can chain other programs, right, eg chaining the install of code::blocks?
If not, I could think of a fairly simple vb.net 'setup' program that goes through a few of these questions and then creates directories, archives old files, chains the customised install of code::blocks. It would be a tiny program, well under 100 lines, and from a new install point of view, the whole thing would start by running setup.exe. The downside though is that this method would install all of .net in order to run a tiny 100 line program.
So there are probably better answers, eg some of the simpler versions of C. TinyC could probably handle this.
I'm thinking though about what *can't* be done with batch files, as I'm fairly sure batch files can ask questions, create directories, copy files, and chain other install programs/batchfiles. If I unzipped a bunch of files and found 'setup.bat' that is the program I would try running.
Ramble away! Some good suggestions there, which I will follow up if I decide to offer a new installer for free - but if I decide to instead go with the option of charging for an installer, then both Windows users and Linux users have certain expectations of how such an installer should look, and what it should do (and not do!).
That's why there are tools sold to simplify building such installers. There are of course many free ones as well - but I don't know which ones are good and which ones aren't.
Ross if. you would charge for an "installer" version I would be OK with that as would most users I think. I always seam to have problems when I have to either build or make the demos , utilities etc. I guess its the bane of a windows environment. I have never had a formal programing class other then on a "old" 6 bit machine with hand coded machine language. I am all for the KISS method!!
I like "Ultimate Installer". Haven't done any authoring with it, but I have had great experiences with some software that used it.
Personally, I would pay for and enjoy a installer that did the following:
1. Load command line Catalina, nicely configured. Offer "Catalina command prompt", and a environment script, both set to operate in a working directory, with environment set properly, etc... User picks their Catalina install directory, and their desired working directory, everything else done.
2. Same as 1, with samples and such populated in the working directory, ready to go. (so user can do "clean" install, if desired)
3. Load GUI catalina, nicely configured, working directory, environment, etc....
4. Same as 3 with samples
5. Both
6. Load optimizer as option to any of the above, so user can load that, or the free environment, depending on what they've licensed and or whether or not they want it for whatever reason.
Have installer output a nice text log of what was done, dropped into the working directory, for the users reference.
Edit: I suppose there should also be a "Use existing Code::Blocks" installation option too.
As I think (most Win users) have minimal knowledge on building Make-files/Auto-run. As You can even see on forum much of Beginners have Not so big knowledge in electronics.
With Make-files that even more complicate them STARTING with programing/use Propeller First time!
The Linux testing of release 3.1 has gone surprisingly well. I've managed to sort out a few issues. Installing, building and running on Linux should now be cleaner and simpler.
After getting Linux sorted, my original plan was to do a complete documentation update - but after the recent comments here, I think improving the user installation experience is more important. So now my plan is to just do a minor "refresh" of the documents (to bring them up to date) and then issue Catalina release 3.1. (Based on a lot of the questions I get asked, it appears that most people don't read any of the documentation anyway!)
After release 3.1 is out, I will then concentrate on a new installer. The objective will be to have a "one click" installer for Windows, which (license issues permitting) will install both Catalina and Code::Blocks. It will also set up a Catalina command line environment, but building and installing all the Catalina demos and utilities will be able to be done entirely from Code::Blocks (i.e. you never need to use the command line at all if you don't want to).
Linux users will probably have to wait awhile to get the same functionality. But Linux users are generally fine with command line tools, and anyway the Linux installation process is already much simpler and cleaner than the Windows one - it's partly the complexities of Windows (especially Windows 7) that complicates the process. You know, it's almost as if Microsoft actively conspires to make it difficult to use anything other than Windows tools to do software development under Windows ... Naaah! Surely not!
After release 3.1 is out, I will then concentrate on a new installer. The objective will be to have a "one click" installer for Windows, which (license issues permitting) will install both Catalina and Code::Blocks. It will also set up a Catalina command line environment, but building and installing all the Catalina demos and utilities will be able to be done entirely from Code::Blocks (i.e. you never need to use the command line at all if you don't want to).
Sounds brilliant!
I'm working at the moment on some new board designs that should speed up XMM. Essentially, 23 prop pins driving a ram chip, one for Rd, one for Wr, 8 for data so that leaves 13 pins for address. This gives datablocks of 8k so updates to the latch will be very infrequent. Should be able to get almost as quick as Cluso's design that connected all the prop pins to the ram chip.
I'm hoping to get a Gadget Gangster memory kit down to about $10 so that adding memory is cheap enough for everyman.
You know, it's almost as if Microsoft actively conspires to make it difficult to use anything other than Windows tools to do software development under Windows ... Naaah! Surely not!
Remember the saying "The job ain't done till Lotus won't run".
Anyway, I for one will love the Windows install where command lines are not required - Thanks Ross
GNU automake is a good attempt to eliminate some of the complexity implicit in make (by remove the need to write makefiles by hand) but it does add some complexity of its own.
Automake isn't about eliminating complexity implicit in make, it has a totally different purpose: It is about (and only about) trying to create a build system that will work on a large number of different platforms. As part of that it will create Makefiles, if you asked it to, but that's a tiny part of what it does. And its complexity is on a totally different level to just writing Makefiles. There are very few Automake experts out there, while just writing Makefiles is quite simple - on the level of writing build scripts, if not easier.
Anyway, I'm not arguing for or against using Make with Catalina, I'm only trying to point out miscomprehensions about what Make is about. (Although I'm slightly suprised that it's claimed that it's difficult for Windows users to write Makefiles, even though the same people are expected to actually write C code..)
It's a meta-task, as opposed to the real task; namely, code. Documentation, build environment, system environment, etc... all meta, and as such more critically evaluated than the primary work product is, particularly when introduced initially, or is first associated with a primary task.
The same artifact happens with meta-data, as opposed to data. Generating data can be easy or hard, just like code can be easy or hard. Both are necessary things. People are motivated to complete primary tasks, and far less motivated to meta-or secondary tasks.
I've seen that critical perception of difficulty or usefulness applied in a variety of scenarios. Take something like a smart part number schema. Now, I normally don't advocate those for a lot of reasons, all associated with systems integration and data portability reasons, but when they are in use, it's common to see a engineer declare part numbering schemes as "hard" compared with the "easy" task of designing some fairly involved mechanical or electrical thing.
The analogy to a build tool, or environment should be obvious.
I don't fully understand why that is, only that it is. Interestingly, once a person has acclimated to the meta tasks and data, stripping that away suddenly becomes "hard" as well, even though they said adding it to the primary task was hard initially! Funny how our perception of things happens.
So, the typical new user / author of these things needs to "punch through" acclimating themselves to the meta-environments / tasks, and all will be well. The problem is getting them to punch through when there are no strict requirements to do so.
However, the demo one is probably not so important as I mainly use that as a test to see if a program compiles, without downloading it. The DRACBLADE version is the more important one to change, and this one is producing an error in the compilation (first time this has been tested with TV so not surprising)
...
Any suggestions would be most appreciated.
Ok - for that one, you need to edit the file Catalina_HMI.inc. Here is an edited copy that enables all HMI options for the DRACBLADE:
{{
'-------------------------------------------------------------------------------
'
' HMI.inc - This file is included by all target files to perform the logic
' required to select the correct HMI option, based on the defined
' platform (and CPU), as well as the following HMI related symbols:
'
' GRAPHICS - load graphics driver instead of screen driver
'
' NO_HMI - do not load any HMI plugin (except GRAPHICS)
'
' NO_MOUSE - do not load/start mouse driver
' NO_KEYBOARD - do not load/start keyboard driver
' NO_SCREEN - do not load/start screen driver
'
' HIRES_VGA - load a HiRes VGA driver
' LORES_VGA - load a LoRes VGA driver
' VGA - " " " " "
'
' HIRES_TV - load a HiRes TV driver
' LORES_TV - load a LoRes TV driver
' TV - " " " " "
'
' NO_INTERLACE - use non-interlace mode (TV drivers only)
' NTSC - use NTSC mode (TV drivers only)
'
' PC - use a PC HMI plugin (screen/kbd only)
' PROPTERMINAL - use a PropTerminal HMI plugin
'
' PROXY_KEYBOARD - use a proxy for the keyboard driver
' PROXY_MOUSE - use a proxy for the mouse driver
' PROXY_SCREEN - use a proxy for the screen driver
'
'
' This file is included by the following target files:
'
' lmm_default.spin
' emm_default.spin
' smm_default.spin
' xmm_default.spin
' lmm_blackcat.spin
' emm_blackcat.spin
' smm_blackcat.spin
' xmm_blackcat.spin
' Catalina_LMM_Debug.spin
' Catalina_Proxy_Server.spin
' Catalyst_HMI.spin
'
' Version 2.8 - initial version by Ross Higson
' Version 2.9 - Disable mouse by default on C3
'
}}
'===============================================================================
' Disable MOUSE if both keyboard and mouse are not supported (C3, DRACBLADE)
'===============================================================================
#ifdef C3
#ifndef NO_MOUSE
#ifndef NO_KEYBOARD
#define NO_MOUSE
#endif
#endif
#elseifdef DRACBLADE
#ifndef NO_MOUSE
#define NO_MOUSE
#endif
#endif
'===============================================================================
' Check CPU is correctly specified (multi-CPU platforms only)
'===============================================================================
#ifdef MORPHEUS
#ifdef CPU_1
#define SUPPORT_MORPHEUS_CPU_1
#elseifdef CPU_2
#define SUPPORT_MORPHEUS_CPU_2
#else
ERROR : CPU NOT SPECIFIED (SPECIFY CPU_1 OR CPU_2)
#endif
#endif
'
#ifdef TRIBLADEPROP
#ifdef CPU_1
#define SUPPORT_TRIBLADEPROP_CPU_1
#elseifdef CPU_2
#define SUPPORT_TRIBLADEPROP_CPU_2
#elseifdef CPU_3
#define SUPPORT_TRIBLADEPROP_CPU_3
#else
ERROR : CPU NOT SPECIFIED (SPECIFY CPU_1, CPU_2 OR CPU_3)
#endif
#endif
'===============================================================================
' Check GRAPHICS option is supported on current platform
'===============================================================================
#ifdef GRAPHICS
#ifdef PROXY_SCREEN
ERROR : GRAPHICS OPTION NOT SUPPORTED WHEN USING PROXY DRIVERS
#elseifdef DRACBLADE
ERROR : GRAPHICS OPTION NOT SUPPORTED ON THE SPECIFIED PLATFORM
#else
#define SUPPORT_GRAPHICS_TV
#define START_GRAPHICS
#define NO_SCREEN
#endif
#endif
'===============================================================================
' Check HMI option specified is supported HMI (or NO_HMI specified)
'===============================================================================
#ifdef NO_HMI
'===============================================================================
' The NO_HMI option is supported on all platforms
'===============================================================================
#else
'===============================================================================
' Encode multiple HMI options into one combined symbol for simplicity
' (provided the combination is supported)
'===============================================================================
#ifdef SUPPORT_MORPHEUS_CPU_1
'===============================================================================
' MORPHEUS CPU_1 (no VGA or TV HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#define NOT_SUPPORTED
#elseifdef LORES_VGA
#define NOT_SUPPORTED
#elseifdef VGA
#define NOT_SUPPORTED
#elseifdef HIRES_TV
#define NOT_SUPPORTED
#elseifdef LORES_TV
#define NOT_SUPPORTED
#elseifdef TV
#define NOT_SUPPORTED
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
'
'instead of "SUPPORT_PC" as the default, we define a local keyboard and mouse
' driver so that we can use proxy drivers - but we disable the screen
'
#ifndef NO_SCREEN
#define NO_SCREEN
#endif
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
'
#endif
#elseifdef SUPPORT_MORPHEUS_CPU_2
'===============================================================================
' MORPHEUS CPU_2 (not TV HMI options, use Morpheus-specific VGA HMI supported)
'===============================================================================
#ifdef HIRES_TV
#define NOT_SUPPORTED
#elseifdef LORES_TV
#define NOT_SUPPORTED
#elseifdef TV
#define NOT_SUPPORTED
#elseifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_MORPHEUS_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_MORPHEUS_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_MORPHEUS_HIRES_VGA
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_MORPHEUS_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_MORPHEUS_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_MORPHEUS_HIRES_VGA
#endif
#endif
#elseifdef SUPPORT_TRIBLADEPROP_CPU_1
'===============================================================================
' TRIBLADEPROP CPU_1 (all HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_VGA
#endif
#elseifdef LORES_VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#elseifdef SUPPORT_TRIBLADEPROP_CPU_2
'===============================================================================
' TRIBLADEPROP CPU_2 (no VGA or TV HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#define NOT_SUPPORTED
#elseifdef LORES_VGA
#define NOT_SUPPORTED
#elseifdef VGA
#define NOT_SUPPORTED
#elseifdef HIRES_TV
#define NOT_SUPPORTED
#elseifdef LORES_TV
#define NOT_SUPPORTED
#elseifdef TV
#define NOT_SUPPORTED
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
'
'instead of "SUPPORT_PC" as the default, we define a local keyboard and mouse
' driver so that we can use proxy drivers - but we disable the screen
'
#ifndef NO_SCREEN
#define NO_SCREEN
#endif
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
'
#endif
#elseifdef SUPPORT_TRIBLADEPROP_CPU_3
' TRIBLADEPROP CPU_3 (no VGA or TV HMI options):
#ifdef HIRES_VGA
#define NOT_SUPPORTED
#elseifdef LORES_VGA
#define NOT_SUPPORTED
#elseifdef VGA
#define NOT_SUPPORTED
#elseifdef HIRES_TV
#define NOT_SUPPORTED
#elseifdef LORES_TV
#define NOT_SUPPORTED
#elseifdef TV
#define NOT_SUPPORTED
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#define SUPPORT_PC
#endif
#elseifdef RAMBLADE
'RAMBLADE (no VGA or TV HMI options):
#ifdef HIRES_VGA
#define NOT_SUPPORTED
#elseifdef LORES_VGA
#define NOT_SUPPORTED
#elseifdef VGA
#define NOT_SUPPORTED
#elseifdef HIRES_TV
#define NOT_SUPPORTED
#elseifdef LORES_TV
#define NOT_SUPPORTED
#elseifdef TV
#define NOT_SUPPORTED
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#define SUPPORT_PC
#endif
#elseifdef DRACBLADE
'DRACBLADE (all HMI options supported)
#ifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_VGA
#endif
#elseifdef LORES_VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#elseifdef DEMO
'===============================================================================
'DEMO (all HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_VGA
#endif
#elseifdef LORES_VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#elseifdef CUSTOM
'===============================================================================
'CUSTOM (all HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_VGA
#endif
#elseifdef LORES_VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#elseifdef HYBRID
'===============================================================================
'HYBRID (no VGA HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#define NOT_SUPPORTED
#elseifdef LORES_VGA
#define NOT_SUPPORTED
#elseifdef VGA
#define NOT_SUPPORTED
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#elseifdef HYDRA
'===============================================================================
'HYDRA (all HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_VGA
#endif
#elseifdef LORES_VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#else
'===============================================================================
'DEFAULT (currently default is a copy of HYDRA - i.e. all HMI options supported)
'===============================================================================
#ifdef HIRES_VGA
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_VGA_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_VGA
#endif
#elseifdef LORES_VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef VGA
#ifdef NO_MOUSE
#define SUPPORT_LORES_VGA_NO_MOUSE
#else
#define SUPPORT_LORES_VGA
#endif
#elseifdef HIRES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#elseifdef LORES_TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef TV
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_LORES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_LORES_TV
#endif
#elseifdef PROPTERMINAL
#define SUPPORT_PROPTERMINAL
#elseifdef PC
#define SUPPORT_PC
#else
' default
#ifdef NO_MOUSE
#ifdef NO_KEYBOARD
#define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
#else
#define SUPPORT_HIRES_TV_NO_MOUSE
#endif
#else
#define SUPPORT_HIRES_TV
#endif
#endif
#endif
#endif
'===============================================================================
' now choose a CGI plugin based on the combined symbol:
'===============================================================================
#ifdef SUPPORT_GRAPHICS_TV
CGI : "Catalina_CGI_Plugin_TV"
#endif
'===============================================================================
' now choose a HMI plugin based on the combined symbol:
'===============================================================================
#ifdef NO_HMI
#elseifdef SUPPORT_MORPHEUS_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
HMI : "Catalina_HMI_Plugin_Morpheus_Vga_No_Mouse_No_Keyboard"
#elseifdef SUPPORT_MORPHEUS_HIRES_VGA_NO_MOUSE
HMI : "Catalina_HMI_Plugin_Morpheus_Vga_No_Mouse"
#elseifdef SUPPORT_MORPHEUS_HIRES_VGA
HMI : "Catalina_HMI_Plugin_Morpheus_Vga"
#elseifdef SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE
HMI : "Catalina_HMI_Plugin_HiRes_Vga_No_Mouse"
#elseifdef SUPPORT_HIRES_VGA_NO_MOUSE
HMI : "Catalina_HMI_Plugin_HiRes_Vga_No_Mouse"
#elseifdef SUPPORT_HIRES_VGA
HMI : "Catalina_HMI_Plugin_HiRes_Vga"
#elseifdef SUPPORT_LORES_VGA_NO_MOUSE
HMI : "Catalina_HMI_Plugin_LoRes_Vga_No_Mouse"
#elseifdef SUPPORT_LORES_VGA
HMI : "Catalina_HMI_Plugin_LoRes_Vga"
#elseifdef SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE
HMI : "Catalina_HMI_Plugin_HiRes_Tv_No_Mouse_No_Keyboard"
#elseifdef SUPPORT_HIRES_TV_NO_MOUSE
HMI : "Catalina_HMI_Plugin_HiRes_Tv_No_Mouse"
#elseifdef SUPPORT_HIRES_TV
HMI : "Catalina_HMI_Plugin_HiRes_Tv"
#elseifdef SUPPORT_LORES_TV_NO_MOUSE
HMI : "Catalina_HMI_Plugin_Tv_No_Mouse"
#elseifdef SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE
HMI : "Catalina_HMI_Plugin_Tv_No_Mouse_No_Keyboard"
#elseifdef SUPPORT_LORES_TV
HMI : "Catalina_HMI_Plugin_Tv"
#elseifdef SUPPORT_PROPTERMINAL
HMI : "Catalina_HMI_Plugin_PropTerminal"
#elseifdef SUPPORT_PC
HMI : "Catalina_HMI_Plugin_PC"
#else
ERROR : HMI OPTION NOT SUPPORTED ON THE SPECIFIED PLATFORM
#endif
'
'===============================================================================
'
' (end of section of code common to all target files)
'
'===============================================================================
Just copy this whole file over the existing HMI.inc.
Sorry I think I have broken the hmi.inc file. Overwrote the old one and didn't make a backup ('tis after midnight, but that is no excuse for a vampire...)
===================
SETTING UP CATALINA
===================
CATALINA_DEFINE = [default]
CATALINA_INCLUDE = [default]
CATALINA_LIBRARY = [default]
CATALINA_TARGET = [default]
CATALINA_LCCOPT = [default]
CATALINA_TEMPDIR = [default]
LCCDIR = [default]
catalina -lcx -D PLUGIN -x5 -M 256k -D DRACBLADE -D SHARED_XMM -D LORES_TV NEW.C
Catalina Compiler 3.0
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\xmm_default.spin
parsing C:\Program Files\Catalina\target\Catalina_Common.spin
parsing C:\Program Files\Catalina\target\Catalina_HUB_XMM_Loader.spin
parsing C:\Program Files\Catalina\target\Catalina_XMM.spin
Error: HMI.inc (56, 2): Unexpected #
#ifdef C3
^
Payload XMM NEW
Using Propeller (version 1) on port COM1 for first upload
Using port COM1 for subsequent uploads
Press any key to continue . . .
I note some comments in these HMI files about the dracblade not having a mouse and keyboard. The older versions didn't but the more recent ones do. I'll need to get all that working.
I must say, it is pretty nifty to have a portable C platform with these little TV screens!
Sorry I think I have broken the hmi.inc file. Overwrote the old one and didn't make a backup ('tis after midnight, but that is no excuse for a vampire...)
===================
SETTING UP CATALINA
===================
CATALINA_DEFINE = [default]
CATALINA_INCLUDE = [default]
CATALINA_LIBRARY = [default]
CATALINA_TARGET = [default]
CATALINA_LCCOPT = [default]
CATALINA_TEMPDIR = [default]
LCCDIR = [default]
catalina -lcx -D PLUGIN -x5 -M 256k -D DRACBLADE -D SHARED_XMM -D LORES_TV NEW.C
Catalina Compiler 3.0
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\xmm_default.spin
parsing C:\Program Files\Catalina\target\Catalina_Common.spin
parsing C:\Program Files\Catalina\target\Catalina_HUB_XMM_Loader.spin
parsing C:\Program Files\Catalina\target\Catalina_XMM.spin
Error: HMI.inc (56, 2): Unexpected #
#ifdef C3
^
Payload XMM NEW
Using Propeller (version 1) on port COM1 for first upload
Using port COM1 for subsequent uploads
Press any key to continue . . .
I note some comments in these HMI files about the dracblade not having a mouse and keyboard. The older versions didn't but the more recent ones do. I'll need to get all that working.
I must say, it is pretty nifty to have a portable C platform with these little TV screens!
Yes, in the code I posted, the forum has preceeded each line with a space - I should probably have attatched the file insted - I've now attached a working version of HMI.inc, that allows all HMI options on the DracBlade. Use -D NO_KEYBOARD or -D NO_MOUSE to disable those drivers.
Comments
Why? Space reasons? Code::Blocks is actually very small. If I go back to having separate binary and source releases, the combined binary release would not be much bigger than Catalina is now.
Ross.
If one needs a specialized build environment, and I currently am setting one of those up for a Internet startup venture, lean products tend to fit into those rather easily. No worries, all upside. (Jazzed, I think we are going to use Mercurial --it's excellent, and IMHO superior to older file based systems)
"The Propeller Tool Experience" is a good thing. That is thicker than just a simple command line environment. But, I think that has a nice pay off too, because there are a lot of people who won't get on a command line. I like both actually. Depends on things. At times a GUI rocks. I like the Prop Tool GUI a lot, because it's lean. I don't have to know much, and I can make the Prop do things, while keeping track of a very small number of additional things.
To explain "lean" (and I'm basically in the mood, with a bit of downtime sufficient to write it, but not so much that I could jump into something else, so...)
1. Fewest number of dependencies
2. Ability to operate "plain vanilla", like load the OS, load the tool, go. Might not be optimal, but that should work, period. This tends to keep the number of unique assumptions to a optimal size for the source tech as well. Knowing extra things has to pay off, or why know them?
3. Smallest number of machine resources. Again, maybe not optimal, but it should work, period.
4. Least impact on options. eg: Too complex of a manipulation means few people will exercise the choice, or a set of poor, or conflicting choices marginalizes the value of making them. That's the kind of thing I'm getting at.
From there, options are good, but I think each one should pay off. The Code::Blocks move would pay off, because there are a fair number of prospective users who would be inclined to just load it and go, and the choice to not use it would not be a complex manipulation.
I don't think introducing the dependency of specialized "wish it were really UNIX" tools on Windows would pay off, and I think we've arrived at why that is. Just use a UNIX; otherwise, use Windows as Windows. It's lean that way.
Got that influence from a few core drivers in my life.
1. Grew up somewhat poor. One appreicates lean on a lot of levels when money is a issue. Not bitching, and in fact, happy it worked that way for me, simply because I ended up with a nice set of "coping" skills that leave me empowered in most scenarios at most times. Can't buy that easily, if at all.
2. Manufacturing. Now I don't do manufacturing anymore for a lot of reasons, the primary one being how devalued it is in the US right now. That's politics, so I'll stop there and just say I chose to move horizontally, leveraging that experience. In manufacturing, dependencies introduce cost and they introduce variance, which ends up being cost when you boil it all down, because it's a quality issue. Waste introduces cost, just because materials cost, and waste isn't productive. Don't like waste, and will regularly invest people time, thinking time to avoid, or marginalize, or re-purpose waste. Excessive handling, and or redundant processes, means, methods, paths. Human energy costs money, machines cost money, and throughput matters in manufacturing.
Once I reconfigured a shop after doing about a weeks worth of planning. That week paid nearly 6 figures over the course of the next year. Do not underestimate lean in this respect. And that's a nod toward the build environments. That is exactly why people build them for software. It's the same exact problem, just a different space.
Finally, automation. Automation itself can get thick because it introduces dependencies. It's important to make sure things pay off, so that the holistic product of the effort is optimal in terms of the cost of the operation as well as the human energy required / saved and the impact of that on overall variance. Toward that end, where processes are lean to begin with, the equation for automation is simplified, often removing a factor or two, making it viable at a fairly low barrier to entry, as well as making it deliver a return quickly.
During my time in manufacturing, I broke every quality record and production record ever set in front of me by a significant margin, walking out on the chumps that were penny wise, pound foolish, because it just wasn't lean, and that consumed me for no return, and well? I've better things to do, and really haven't changed much.
3. Software. I've written some software. Not too many big pieces of software, though I want to, but lots of little bits of software for many different things. Some of it was manufacturing automation. Lean was big here, because barrier to entry for one off things is HUGE. It impacts the entire equation. Giving that serious consideration really pays off. I used what was lean, that would endure, portable, etc... and most of the stuff ran for well beyond it's expected life, and was ported easily. In fact, one bit of code, written for a CAD system in 92 is still working, on the modern version, because lean kept that code to the core of the API, which didn't suffer the kind of change the thicker and sexier elements of it did. Result? The users of my product got huge value for their dollars, with me in shock to find it's still in use today, just down the street. Pirate copy too! I grinned, and told them seeing it running after so long was totally worth it, and wrote them a license on the spot.
(yeah, softie)
4. UNIX. Unix changed my computing life. Having come up on 8 bit computers, hacking on all matter of arcane NC controls, serial this to bizzare old box that, hope to god USENET has somebody somewhere who knows what this widget does, serial to the end stuff, I moved up and out to do systems work. Went from ugly contraptions, DOS, assembly, etc... to multi-cpu 6 figure devices that would serve 30 users at a time, doing high end stuff, UNIX is the pinnacle of lean, when it's well realized. A good systems engineer enjoys their Slashdot and MP3 time, and that ain't gonna happen, without lean. Lots to say about UNIX and X, and I'll just rest on it's simply the bar for computing lean as far as I am concerned, and that one can make as big of a mess on UNIX as they feel inclined to do. That costs though, and it's all self-selecting in a hurry, with the ones who didn't get the memo running around haggard, while the ones that did are listening to their MP3 files, planning their next move to significantly improve on that listening time.
Then we come to Windows... So, I hated it for a long time, simply because it was not lean in a way that paid off. Well, paid off for the producers of it, but not for most people using it. Very interesting dynamic to watch over the years, and I'll stop there, leaving that as a case in point how simple lack of features and planning isn't lean. Lessons learned there too, with XP and 7 being perfectly fine OSes. Not as lean as they could be, mostly because they are still built on some very broken ideas that introduce dependencies not required, nor advantageous.
That said, people vary, so lean varies!!
For somebody who has not experienced the things I have, lean might mean "just works on windows with the command line", or it might mean they want the GUI, or maybe it means, "works like the other cool stuff I really know how to use" too.
From the developer standpoint, or more simply, source of technology to be adopted, that potential set of "lean" means characterizing the potential sets of users, their potential for "lean", and making investments that will pay off for both the source, and adopter of the technology in question. I do not believe I've ever seen that balance play out differently. That is simply lean, and where it's done right, there is a "thick" return for everybody, and a best case long technology use cycle, which in and of itself is lean.
(sorry Ross, if I've made a mess of the thread Edit: I wanted to put some perspective out there, highlighting how people do vary, and how sets of choices can impact technology adoption in general. People default to lean, unless they've got some very compelling reason to do otherwise.)
Other vendors have solved this problem by including, "Catalina Command Prompt" in their program groups on Windows. Click the app icon and get the GUI. Click the command prompt, and get dropped into a ready to cook, vanilla environment. From there, people either go for one or the other as they see fit, or they start with one, come to understand the other is necessary and it's there, ready.
One nice thing about that is there is a reference environment in the command prompt. This is kind of great for checking when things don't work. First move, use the "official" one, compare / contrast to whatever environment is in use otherwise, and deal accordingly. Most people won't get there, but for the ones that do, it's lean.
No worries - what kind of tool maker would not be happy to listen to others experiences with similar tools?
Ross.
While I may end up packaging them together, that doesn't mean you can't simply ignore Code::Blocks and use the Catalina on the command line instead. It just means that I would stop offering any other build tool support (i.e. makefiles, batch files, bash scripts etc, etc).
If you don't want to use Code::Blocks as your build tool, but you do have some facility with make and only need to support one environment (i.e. Windows or Linux) then you can easily do this yourself - the difficult part is supporting multiple environments - Code::Blocks does, and MinGW does (mostly) - but make by itself doesn't.
Ross.
I was in computers before the micro chip was invented. I bought the first Motorola 6800 D1 and then D2 kits. I wrote my own cross-compiler on my own mini (yes, and it was the length of my garage... because it was in my air-conditioned garage). So I do know all about command line compilers, etc.
But, I had been away from electronics for a few years, building my boat and sailing.
I came back to electronics and accidentally discovered the prop while waiting for my pic kits to arrive. Lucky for me hey! Ordered my Prop ProtoBoards immediately ( I had a FT2232 board so I didn't need a propplug).
Literally, from installing PropTool and powering up my ProtoBoard (with a superbright LED spread between two pins to use the onboard 10K resistor in the mouse circuit) in less than 10 minutes the LED was flashing. No worries about make files, bash scripts (let alone what the hell they are), etc. Just a simple compile and voila - its downloaded and working
I didn't even have to work out what to set all the registers to to get the prop configured to run (or find a file that did this for me). Nothing like the old micros that required this knowledge up front. And looking at all the pic chips, avr chips, etc, they all suffer from an exhaustive set of registers that have to be initialised pretty much in order to get anything to work.
I had such a fantastic experience on the prop, I just want to keep it that way!
I don't wish to learn *nix because I am no longer interested in the command-line. That was aeons ago!! And I don't mean I am a windoze fan - I am definately not - it has so much baggage and I cannot control when it goes off and does its own thing. However, it has made life simple, and that is what I want, or should I say demand!
So, if Catalina is simple to use, then hey I will bother to learn C better than I know now (yes, I did write some C code a long time ago).
Hope this helps put into perspective where I am coming from. Don't know if it is relevant to anyone elses perspective or not.
Yes, it all helps. Catalina doesn't get as much use as I'd like, and one reason (as Dr_A highlighted) is the complex process of getting up and running (or at least it seems complex if you are unfamiliar with the underlying tools you will need to use). Let's face it - these days many users (my own children included) have never even seen a command line interface, and are completely unaware that Windows even has one!
This means Cataliina is not a happy experience for some potential users. A proper installer would help - but Windows installers are notoriously difficult to write and/or expensive to maintain - sometimes more complex or more expensive than the software they install (I have direct experience with instances of this). This is why "open source" software often doesn't bother with them. That, and the fact that the target market for a lot of "open source" software is an experienced user base that has no problem with command line tools and a manual installation process.
Obviously, this means Catalina currently has a mismatch with both the existing Propeller user base (at least the hobbyists and enthusiast user base) and also the commercial user base (pretty much non-existent as yet, but perhaps one day ...).
So learning these lessons is vital - not only will it help Catalina, but also anyone else who wants to offer Propeller tools or products.
Ross.
1) Dependencies. That's just writing them as file1: file2 when file1 depends on file 2.
2) Rules: What to do when a dependency tells Make that something must be done. You write them below the dependency. That can be as simple as the command-line equivalent of the action. But many rules are built-in already, so you don't have to write anything. This includes compiling C, for example.
So I have my 'hello.c' program. I can write 'cc -o hello hello.c' every time I wish to compile it, but I can also write a Makefile. Looks like this: That's all. Now I just write 'Make': Now if I write 'Make' again: Not complex. I could have added the rule myself:
# My Makefile hello: hello.c cc -O2 -o hello hello.c # Just added a bit of optimization thereand it'll work too. And there are shortcuts so that I don't have to spell out the name of the files, e.g. 'cc -O2 -o $@ $^', but that's just to save typing when there's lot of simillar stuff (will make your copy&paste easier). But there's no need to dive deeper than you wish.My point is only that saying GNU Make is complex is a red herring. It's false. (Now, there's something called 'Automake'.. must not be mixed with Make. Automake sure is complex, and difficult, and huge. But it's still the best tool if you need a build system to work anywhere and everywhere. But in practice only a few specialists write those kind of things.)
-Tor
Maybe including only the make command from http://unxutils.sourceforge.net would be enough to support build scripts?
Please keep it simple! Could it be ALL done in a complete install package?
Not really. I wasn't intending to single out GNU make in particular, but there is no doubt that make is a complex tool. I agree that the fundamentals are easy, but the devil is always in the detail - and handwritten makefiles often embody so much detail that they become unmaintainable. This is particularly true when trying to write a makefile for use in multiple environments. GNU automake is a good attempt to eliminate some of the complexity implicit in make (by remove the need to write makefiles by hand) but it does add some complexity of its own.
Of course, exactly how complex you find these tools to be depends on your level of expertise, but as an indication, the GNU make manual is about 110 pages, and the automake manual is about 170 pages. And all this complexity is just to achieve the same thing that most IDE users these days (including users of both Code::Blocks and the Parallax Propeller Tool) expect to achieve just by pressing a single key.
It is also worth noting (again) that while most Unix programmers will have at least been exposed to such build tools, many Windows programmers will never have seen one. And since the vast majority (currently around 80%) of propeller programmers are windows programmers - and I see no reason to think this will change in future - it seems reasonable to assume that most propeller programmers (now and in the future) will be unfamiliar with such tools.
So my current feeling is that those who want to use such tools can do so, but that I should not force all users to do so - at least not just to build the demos and utilities included with Catalina (building Catalina itself is a separate issue).
Ross.
Yes, but each makefile would typically only support a single environment. While this is ok for a user who is capable of generating their own makefiles for their own purposes (since most users only work on one environment), it means I would have to maintain two different sets of makefiles (since I support two different environments). So there is no benefit for me over the current method of batch files & bash scripts.
That was why I originally suggested MinGW. With a bit of work, it is possible to write makefiles that will work under both MinGW and Linux - but it is harder to do so if you just have make (i.e. without MinGW).
Ross.
Yes, this is my current thinking. Of course, since I do this for nothing, it will depend on whether it is both cheap enough (in tools required) and simple enough (in time required) for me to do it. There are also licensing issues I will need to look into.
I suppose I could offer the "one touch" installer as a purchasable option (as I currently do with the Catalina Optimizer) but distribute the source code for nothing to those who want to install it themselves.
Ross.
This would then run code::blocks with the catalina custom settings, and the newbie user would then think "what do I do next, I know, try File/Open" and in there might be "demo.c" and so open that, then ideally there is a "run" button that is fairly obvious, so you click that and it says "propeller not found", so you connect the propeller and power it up, and then try "run" again, and a led flashes on the board.
That might be the ideal. Certainly if one writes a vb.net program, the creation of the "setup.exe" program is a very simple process with just a few clicks. For the end user, installing that program if one has .net is probably as simple as above. I'm not sure what happens if .net is not installed - probably the program goes away and downloads .net automatically.
But Catalina and code::blocks are two separate programs. Still, this is not insurmountable. Often for instance, installing one program chains the install of another program, eg many programs I've downloaded go on to install things like acrobat, or java.
I'm not sure how one might go about building a "setup" for the command line part of catalina. Ideally it is a one step process, though behind the scenes you might have batch files chaining other batch files. So long each chains the next correctly, there would be nothing inherently wrong with questions appearing in dos command shell boxes rather than in windows input dialog boxes.
I imagine there might be a few questions to ask. The first one would be to ask if it is ok to create c:\program files\catalina. And the second really important one might be to note that the program has found a previous instance of c:\program files\catalina, and would you like to copy this somewhere else, or overwrite but only with newer files etc. (I have an awful lot of programs in c:\program files\catalina\demos, and I wouldn't want those overwritten with a new install).
Batch files can ask questions, can't they? And batch files can chain other programs, right, eg chaining the install of code::blocks?
If not, I could think of a fairly simple vb.net 'setup' program that goes through a few of these questions and then creates directories, archives old files, chains the customised install of code::blocks. It would be a tiny program, well under 100 lines, and from a new install point of view, the whole thing would start by running setup.exe. The downside though is that this method would install all of .net in order to run a tiny 100 line program.
So there are probably better answers, eg some of the simpler versions of C. TinyC could probably handle this.
I'm thinking though about what *can't* be done with batch files, as I'm fairly sure batch files can ask questions, create directories, copy files, and chain other install programs/batchfiles. If I unzipped a bunch of files and found 'setup.bat' that is the program I would try running.
Please don't mind me if I am rambling....
Ramble away! Some good suggestions there, which I will follow up if I decide to offer a new installer for free - but if I decide to instead go with the option of charging for an installer, then both Windows users and Linux users have certain expectations of how such an installer should look, and what it should do (and not do!).
That's why there are tools sold to simplify building such installers. There are of course many free ones as well - but I don't know which ones are good and which ones aren't.
Ross.
Personally, I would pay for and enjoy a installer that did the following:
1. Load command line Catalina, nicely configured. Offer "Catalina command prompt", and a environment script, both set to operate in a working directory, with environment set properly, etc... User picks their Catalina install directory, and their desired working directory, everything else done.
2. Same as 1, with samples and such populated in the working directory, ready to go. (so user can do "clean" install, if desired)
3. Load GUI catalina, nicely configured, working directory, environment, etc....
4. Same as 3 with samples
5. Both
6. Load optimizer as option to any of the above, so user can load that, or the free environment, depending on what they've licensed and or whether or not they want it for whatever reason.
Have installer output a nice text log of what was done, dropped into the working directory, for the users reference.
Edit: I suppose there should also be a "Use existing Code::Blocks" installation option too.
Installer type are most interesting.
As I think (most Win users) have minimal knowledge on building Make-files/Auto-run. As You can even see on forum much of Beginners have Not so big knowledge in electronics.
With Make-files that even more complicate them STARTING with programing/use Propeller First time!
The Linux testing of release 3.1 has gone surprisingly well. I've managed to sort out a few issues. Installing, building and running on Linux should now be cleaner and simpler.
After getting Linux sorted, my original plan was to do a complete documentation update - but after the recent comments here, I think improving the user installation experience is more important. So now my plan is to just do a minor "refresh" of the documents (to bring them up to date) and then issue Catalina release 3.1. (Based on a lot of the questions I get asked, it appears that most people don't read any of the documentation anyway!)
After release 3.1 is out, I will then concentrate on a new installer. The objective will be to have a "one click" installer for Windows, which (license issues permitting) will install both Catalina and Code::Blocks. It will also set up a Catalina command line environment, but building and installing all the Catalina demos and utilities will be able to be done entirely from Code::Blocks (i.e. you never need to use the command line at all if you don't want to).
Linux users will probably have to wait awhile to get the same functionality. But Linux users are generally fine with command line tools, and anyway the Linux installation process is already much simpler and cleaner than the Windows one - it's partly the complexities of Windows (especially Windows 7) that complicates the process. You know, it's almost as if Microsoft actively conspires to make it difficult to use anything other than Windows tools to do software development under Windows ... Naaah! Surely not!
Ross.
Sounds brilliant!
I'm working at the moment on some new board designs that should speed up XMM. Essentially, 23 prop pins driving a ram chip, one for Rd, one for Wr, 8 for data so that leaves 13 pins for address. This gives datablocks of 8k so updates to the latch will be very infrequent. Should be able to get almost as quick as Cluso's design that connected all the prop pins to the ram chip.
I'm hoping to get a Gadget Gangster memory kit down to about $10 so that adding memory is cheap enough for everyman.
Remember the saying "The job ain't done till Lotus won't run".
Anyway, I for one will love the Windows install where command lines are not required - Thanks Ross
Anyway, I'm not arguing for or against using Make with Catalina, I'm only trying to point out miscomprehensions about what Make is about. (Although I'm slightly suprised that it's claimed that it's difficult for Windows users to write Makefiles, even though the same people are expected to actually write C code..)
-Tor
The same artifact happens with meta-data, as opposed to data. Generating data can be easy or hard, just like code can be easy or hard. Both are necessary things. People are motivated to complete primary tasks, and far less motivated to meta-or secondary tasks.
I've seen that critical perception of difficulty or usefulness applied in a variety of scenarios. Take something like a smart part number schema. Now, I normally don't advocate those for a lot of reasons, all associated with systems integration and data portability reasons, but when they are in use, it's common to see a engineer declare part numbering schemes as "hard" compared with the "easy" task of designing some fairly involved mechanical or electrical thing.
The analogy to a build tool, or environment should be obvious.
I don't fully understand why that is, only that it is. Interestingly, once a person has acclimated to the meta tasks and data, stripping that away suddenly becomes "hard" as well, even though they said adding it to the primary task was hard initially! Funny how our perception of things happens.
So, the typical new user / author of these things needs to "punch through" acclimating themselves to the meta-environments / tasks, and all will be well. The problem is getting them to punch through when there are no strict requirements to do so.
Catalina 3.1 has now been released. See here for details.
Please feel free to continue to use this thread to discuss any issues specific to Catalina 3.0.
Ross.
Ok - for that one, you need to edit the file Catalina_HMI.inc. Here is an edited copy that enables all HMI options for the DRACBLADE:
{{ '------------------------------------------------------------------------------- ' ' HMI.inc - This file is included by all target files to perform the logic ' required to select the correct HMI option, based on the defined ' platform (and CPU), as well as the following HMI related symbols: ' ' GRAPHICS - load graphics driver instead of screen driver ' ' NO_HMI - do not load any HMI plugin (except GRAPHICS) ' ' NO_MOUSE - do not load/start mouse driver ' NO_KEYBOARD - do not load/start keyboard driver ' NO_SCREEN - do not load/start screen driver ' ' HIRES_VGA - load a HiRes VGA driver ' LORES_VGA - load a LoRes VGA driver ' VGA - " " " " " ' ' HIRES_TV - load a HiRes TV driver ' LORES_TV - load a LoRes TV driver ' TV - " " " " " ' ' NO_INTERLACE - use non-interlace mode (TV drivers only) ' NTSC - use NTSC mode (TV drivers only) ' ' PC - use a PC HMI plugin (screen/kbd only) ' PROPTERMINAL - use a PropTerminal HMI plugin ' ' PROXY_KEYBOARD - use a proxy for the keyboard driver ' PROXY_MOUSE - use a proxy for the mouse driver ' PROXY_SCREEN - use a proxy for the screen driver ' ' ' This file is included by the following target files: ' ' lmm_default.spin ' emm_default.spin ' smm_default.spin ' xmm_default.spin ' lmm_blackcat.spin ' emm_blackcat.spin ' smm_blackcat.spin ' xmm_blackcat.spin ' Catalina_LMM_Debug.spin ' Catalina_Proxy_Server.spin ' Catalyst_HMI.spin ' ' Version 2.8 - initial version by Ross Higson ' Version 2.9 - Disable mouse by default on C3 ' }} '=============================================================================== ' Disable MOUSE if both keyboard and mouse are not supported (C3, DRACBLADE) '=============================================================================== #ifdef C3 #ifndef NO_MOUSE #ifndef NO_KEYBOARD #define NO_MOUSE #endif #endif #elseifdef DRACBLADE #ifndef NO_MOUSE #define NO_MOUSE #endif #endif '=============================================================================== ' Check CPU is correctly specified (multi-CPU platforms only) '=============================================================================== #ifdef MORPHEUS #ifdef CPU_1 #define SUPPORT_MORPHEUS_CPU_1 #elseifdef CPU_2 #define SUPPORT_MORPHEUS_CPU_2 #else ERROR : CPU NOT SPECIFIED (SPECIFY CPU_1 OR CPU_2) #endif #endif ' #ifdef TRIBLADEPROP #ifdef CPU_1 #define SUPPORT_TRIBLADEPROP_CPU_1 #elseifdef CPU_2 #define SUPPORT_TRIBLADEPROP_CPU_2 #elseifdef CPU_3 #define SUPPORT_TRIBLADEPROP_CPU_3 #else ERROR : CPU NOT SPECIFIED (SPECIFY CPU_1, CPU_2 OR CPU_3) #endif #endif '=============================================================================== ' Check GRAPHICS option is supported on current platform '=============================================================================== #ifdef GRAPHICS #ifdef PROXY_SCREEN ERROR : GRAPHICS OPTION NOT SUPPORTED WHEN USING PROXY DRIVERS #elseifdef DRACBLADE ERROR : GRAPHICS OPTION NOT SUPPORTED ON THE SPECIFIED PLATFORM #else #define SUPPORT_GRAPHICS_TV #define START_GRAPHICS #define NO_SCREEN #endif #endif '=============================================================================== ' Check HMI option specified is supported HMI (or NO_HMI specified) '=============================================================================== #ifdef NO_HMI '=============================================================================== ' The NO_HMI option is supported on all platforms '=============================================================================== #else '=============================================================================== ' Encode multiple HMI options into one combined symbol for simplicity ' (provided the combination is supported) '=============================================================================== #ifdef SUPPORT_MORPHEUS_CPU_1 '=============================================================================== ' MORPHEUS CPU_1 (no VGA or TV HMI options supported) '=============================================================================== #ifdef HIRES_VGA #define NOT_SUPPORTED #elseifdef LORES_VGA #define NOT_SUPPORTED #elseifdef VGA #define NOT_SUPPORTED #elseifdef HIRES_TV #define NOT_SUPPORTED #elseifdef LORES_TV #define NOT_SUPPORTED #elseifdef TV #define NOT_SUPPORTED #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' 'instead of "SUPPORT_PC" as the default, we define a local keyboard and mouse ' driver so that we can use proxy drivers - but we disable the screen ' #ifndef NO_SCREEN #define NO_SCREEN #endif #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif ' #endif #elseifdef SUPPORT_MORPHEUS_CPU_2 '=============================================================================== ' MORPHEUS CPU_2 (not TV HMI options, use Morpheus-specific VGA HMI supported) '=============================================================================== #ifdef HIRES_TV #define NOT_SUPPORTED #elseifdef LORES_TV #define NOT_SUPPORTED #elseifdef TV #define NOT_SUPPORTED #elseifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_MORPHEUS_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_MORPHEUS_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_MORPHEUS_HIRES_VGA #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_MORPHEUS_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_MORPHEUS_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_MORPHEUS_HIRES_VGA #endif #endif #elseifdef SUPPORT_TRIBLADEPROP_CPU_1 '=============================================================================== ' TRIBLADEPROP CPU_1 (all HMI options supported) '=============================================================================== #ifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_HIRES_VGA #endif #elseifdef LORES_VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #elseifdef SUPPORT_TRIBLADEPROP_CPU_2 '=============================================================================== ' TRIBLADEPROP CPU_2 (no VGA or TV HMI options supported) '=============================================================================== #ifdef HIRES_VGA #define NOT_SUPPORTED #elseifdef LORES_VGA #define NOT_SUPPORTED #elseifdef VGA #define NOT_SUPPORTED #elseifdef HIRES_TV #define NOT_SUPPORTED #elseifdef LORES_TV #define NOT_SUPPORTED #elseifdef TV #define NOT_SUPPORTED #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default ' 'instead of "SUPPORT_PC" as the default, we define a local keyboard and mouse ' driver so that we can use proxy drivers - but we disable the screen ' #ifndef NO_SCREEN #define NO_SCREEN #endif #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif ' #endif #elseifdef SUPPORT_TRIBLADEPROP_CPU_3 ' TRIBLADEPROP CPU_3 (no VGA or TV HMI options): #ifdef HIRES_VGA #define NOT_SUPPORTED #elseifdef LORES_VGA #define NOT_SUPPORTED #elseifdef VGA #define NOT_SUPPORTED #elseifdef HIRES_TV #define NOT_SUPPORTED #elseifdef LORES_TV #define NOT_SUPPORTED #elseifdef TV #define NOT_SUPPORTED #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #define SUPPORT_PC #endif #elseifdef RAMBLADE 'RAMBLADE (no VGA or TV HMI options): #ifdef HIRES_VGA #define NOT_SUPPORTED #elseifdef LORES_VGA #define NOT_SUPPORTED #elseifdef VGA #define NOT_SUPPORTED #elseifdef HIRES_TV #define NOT_SUPPORTED #elseifdef LORES_TV #define NOT_SUPPORTED #elseifdef TV #define NOT_SUPPORTED #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #define SUPPORT_PC #endif #elseifdef DRACBLADE 'DRACBLADE (all HMI options supported) #ifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_HIRES_VGA #endif #elseifdef LORES_VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #elseifdef DEMO '=============================================================================== 'DEMO (all HMI options supported) '=============================================================================== #ifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_HIRES_VGA #endif #elseifdef LORES_VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #elseifdef CUSTOM '=============================================================================== 'CUSTOM (all HMI options supported) '=============================================================================== #ifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_HIRES_VGA #endif #elseifdef LORES_VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #elseifdef HYBRID '=============================================================================== 'HYBRID (no VGA HMI options supported) '=============================================================================== #ifdef HIRES_VGA #define NOT_SUPPORTED #elseifdef LORES_VGA #define NOT_SUPPORTED #elseifdef VGA #define NOT_SUPPORTED #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #elseifdef HYDRA '=============================================================================== 'HYDRA (all HMI options supported) '=============================================================================== #ifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_HIRES_VGA #endif #elseifdef LORES_VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #else '=============================================================================== 'DEFAULT (currently default is a copy of HYDRA - i.e. all HMI options supported) '=============================================================================== #ifdef HIRES_VGA #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_VGA_NO_MOUSE #endif #else #define SUPPORT_HIRES_VGA #endif #elseifdef LORES_VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef VGA #ifdef NO_MOUSE #define SUPPORT_LORES_VGA_NO_MOUSE #else #define SUPPORT_LORES_VGA #endif #elseifdef HIRES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #elseifdef LORES_TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef TV #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_LORES_TV_NO_MOUSE #endif #else #define SUPPORT_LORES_TV #endif #elseifdef PROPTERMINAL #define SUPPORT_PROPTERMINAL #elseifdef PC #define SUPPORT_PC #else ' default #ifdef NO_MOUSE #ifdef NO_KEYBOARD #define SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE #else #define SUPPORT_HIRES_TV_NO_MOUSE #endif #else #define SUPPORT_HIRES_TV #endif #endif #endif #endif '=============================================================================== ' now choose a CGI plugin based on the combined symbol: '=============================================================================== #ifdef SUPPORT_GRAPHICS_TV CGI : "Catalina_CGI_Plugin_TV" #endif '=============================================================================== ' now choose a HMI plugin based on the combined symbol: '=============================================================================== #ifdef NO_HMI #elseifdef SUPPORT_MORPHEUS_HIRES_VGA_NO_KEYBOARD_NO_MOUSE HMI : "Catalina_HMI_Plugin_Morpheus_Vga_No_Mouse_No_Keyboard" #elseifdef SUPPORT_MORPHEUS_HIRES_VGA_NO_MOUSE HMI : "Catalina_HMI_Plugin_Morpheus_Vga_No_Mouse" #elseifdef SUPPORT_MORPHEUS_HIRES_VGA HMI : "Catalina_HMI_Plugin_Morpheus_Vga" #elseifdef SUPPORT_HIRES_VGA_NO_KEYBOARD_NO_MOUSE HMI : "Catalina_HMI_Plugin_HiRes_Vga_No_Mouse" #elseifdef SUPPORT_HIRES_VGA_NO_MOUSE HMI : "Catalina_HMI_Plugin_HiRes_Vga_No_Mouse" #elseifdef SUPPORT_HIRES_VGA HMI : "Catalina_HMI_Plugin_HiRes_Vga" #elseifdef SUPPORT_LORES_VGA_NO_MOUSE HMI : "Catalina_HMI_Plugin_LoRes_Vga_No_Mouse" #elseifdef SUPPORT_LORES_VGA HMI : "Catalina_HMI_Plugin_LoRes_Vga" #elseifdef SUPPORT_HIRES_TV_NO_KEYBOARD_NO_MOUSE HMI : "Catalina_HMI_Plugin_HiRes_Tv_No_Mouse_No_Keyboard" #elseifdef SUPPORT_HIRES_TV_NO_MOUSE HMI : "Catalina_HMI_Plugin_HiRes_Tv_No_Mouse" #elseifdef SUPPORT_HIRES_TV HMI : "Catalina_HMI_Plugin_HiRes_Tv" #elseifdef SUPPORT_LORES_TV_NO_MOUSE HMI : "Catalina_HMI_Plugin_Tv_No_Mouse" #elseifdef SUPPORT_LORES_TV_NO_KEYBOARD_NO_MOUSE HMI : "Catalina_HMI_Plugin_Tv_No_Mouse_No_Keyboard" #elseifdef SUPPORT_LORES_TV HMI : "Catalina_HMI_Plugin_Tv" #elseifdef SUPPORT_PROPTERMINAL HMI : "Catalina_HMI_Plugin_PropTerminal" #elseifdef SUPPORT_PC HMI : "Catalina_HMI_Plugin_PC" #else ERROR : HMI OPTION NOT SUPPORTED ON THE SPECIFIED PLATFORM #endif ' '=============================================================================== ' ' (end of section of code common to all target files) ' '===============================================================================Just copy this whole file over the existing HMI.inc.Ross.
I note some comments in these HMI files about the dracblade not having a mouse and keyboard. The older versions didn't but the more recent ones do. I'll need to get all that working.
I must say, it is pretty nifty to have a portable C platform with these little TV screens!
Yes, in the code I posted, the forum has preceeded each line with a space - I should probably have attatched the file insted - I've now attached a working version of HMI.inc, that allows all HMI options on the DracBlade. Use -D NO_KEYBOARD or -D NO_MOUSE to disable those drivers.
Ross.