C and Assembly project suggestion needed for class on low level software

Question

I have a class on low-level programming which requires a final project (syllabus at the end). It is basically a piece of software that puts to use all you learned.

I had a few ideas, like designing my own Roguelike (should be kind of like NetHack, only single-player), but I'd like some suggestions on alternatives. It needn't be a game; it can be anything. The time frame is a month and a half, and I have other projects, etc. so it shouldn't be too time-consuming to implement.

Requirements:

• Use, at least, four I/O devices, one of which should be the mouse or serial port
• Some of those devices should use interrupts, others should use polling
• Languages: C and Assembly (mandatorily, else there is a penalization)
• Implement state machines

The peripherals we were lectured on were:

• Graphics card - Graphical mode
• Graphics card - Text mode
• Mouse
• Keyboard
• Real Time Counter
• On-board Speaker (via timers 0 and 2)
• Serial port

This is the abridged syllabus:

Input/Output peripherals and their operation Direct mapping in a process address space Access to peripherals in polled mode and by interrupt Processor interrupts in the IA-32 architecture and the interrupt controller. Writing interrupt service routines in Assembly and in C Study of some typical personal computer peripherals, such as keyboard, mouse, graphics card, real time clock, timer, loudspeaker and serial port.

Programming in the C programming language: main differences with respect to C++ language; structured programming in C. Memory layout of a process. Function calls: mechanisms, parameter passing, storage of local variables and return values. Combined programming in C and the IA-32 processor family assembly. Creation and use of libraries. Static linking of object code.

Use of software development tools: gcc, make, gdb, ar, prof, diff, patch and SVN

Answer 1

One simple option is to go for games. They can always use several devices, such as mouse, keyboard, timers, graphics card and (depending what you do) the RTC.

Another option is to go for a "music composer" application. For instance, you could write (using the keyboard and mouse) a song (note frequency, duration) and then let the computer speaker play it.

You could also go for a "clock/calendar application". It could draw a clock in the screen (which might be harder than it might look if you draw an analog one on the screen), and then let the user adjust the time of the day(saving the changes in the RTC). The clock could also include alarm and some ticking sound.

As for the calendar, you could also allow the user to create "events" in the calendar, which could work a bit like alarms.

You could also try to write your own "notepad"-like application. This would require having a working GUI(write area, menus, etc.). This could either be in text or graphics mode. You could detect the keyboard being pressed to add character, handle CAPS LOCK (giving you the opportunity to mess up with the keyboard LEDs). You could use mouse position/clicks to change position in text editor or trigger menus. Then timers to have the blinking caret in the text editor. Clicking a disabled menu option could cause a short speaker sound to indicate an invalid action.

I'd recommend writing most of the code in C, except for little bits in Assembly. ISRs are a good opportunity for Assembly code.

Regarding state machines:

1. Games can have many states ("Main Menu", "Playing Game", "Pause Menu", "High scores") with well defined transitions between states.
2. A music composer could have some states too("Stop", "Pause", "Playing")
3. A clock application could have states such as "Show Clock", "Show Calendar", "Alarm Message Box", "Event Message Box", "Event Message Box With Pending Alarm.
4. The notepad application could have states such as "Editing Text", "In Menu" or "In Message Box")

Most of the devices you mentioned can be accessed with interrupts. Unfortunately, I can not think of good opportunities for polling...

Answer 2

Music synthesizer/tracker like program? Use a keyboard to "play" it, save/record songs, handle the audio and I/O portions. Maybe use the mouse as a pitch controller, or link two computers with the serial port for cooperative play?

Answer 3

If you can connect two computers to each other via the serial port and implement the same code on each computer then theoretically you could split the coding time between yourself and the owner of the other computer - thus minimizing some effort! (Well perhaps maximizing arguments over design!)

One project that comes to mind is to implement a simple point to point text networking app between two computers. You type in text to an on-screen buffer, use the mouse to click a target, which triggers sending the message via the serial port to the other computer - which displays it on its own screen and beeps the speaker to say that a message has been received. Also the sending computer could beep its speaker with a different tone for successful transmission, transmission errors or retries. That covers all the hardware that you have been introduced to.

For added bonus design the messaging protocol to be fault tolerant or detect reception errors.

Sounds like a great project what ever you do! However be careful about going overboard with the project. There is enough meat in your requirements to take up all your time without designing an entire game as well. Use the Kiss priciple

Answer 4

Break it into two programs.

Program One is a GUI-like thing that shows some clickable graphics for a set of tests that can be performed. Once clicked, some sort of text box pops up, and you can type START to start the test. The command goes out the serial port, to a remote machine where program Two is running. Program 2 does the test, and returns some sort of status back to program 1. The status is displayed , and another graphic can be clicked.

Program two listens on the serial port, and receives a command from program 1, performs it and sends back the status.

When program 1 get a click on the QUIT icon, it tells program two to shut down as well.

Add bells and whistles as needed.