Apollo85

In the 1st year of my computer science school we had a subject called "hardware and software basics". Practically it was about low-level programming. Therefore we had a computer board from Siemens which had an Intel 8085 processor on it along with a numpad and 8 seven-segment displays. You had to write your program in assembler, change it into machine code by hand and type it in that small computer. Siemens called that board the ECB, an abbrevation for "Experimentier Computer Board" (English: Experimenting computer board).

Here are two sites (only German) which show that board:

• http://wumpus2000.de/Homecomputer%20neu/Computers/Siemens-ECB85/Siemens-ECB85-1.htm
• http://www.hknebel.org/Museum/Tragbare_PCs/Vorlaufer/ECB_85/ecb_85.htm

It was fun, but that computer had some major downsides:

• You couldn't save or load your program. If you turned it off, your program was lost.
• The power supply wasn't very reliable back then and a short circuit erased the whole program.
• You couldn't see into the machine and what it was doing.
• And a more actual downside: It is very hard to get some working examples now. Luckily I own one after having searched for it for several years. I even asked my old school, but got the answered that they have put all of theirs into the trash years ago. I don't want to know what they would have got if they would have put them on eBay because they don't come cheap. The next problem is the lack of documentation. Luckily I have the manual (in English as well as in German) which also contains the source code of the "BIOS" or "firmware" of that board as assembler listing.

The goals of that project are:

• Implementing an emulator which acts exactly like the original hardware. It should show what happens internally if instructions are executed (processor registers, memory, bus system, etc.).
• Implementing an assembler which is coupled with the emulator so you can see which assembler instruction is which machine code in the memory.
• Offering an in-detail documentation.
• Maybe also offering some pseudo extra hardware (e.g. a graphical display). That emulated software could be plugged into that emulated board. It would be maybe even possible to connect to real hardware through, e.g., the serial port of the computer the emulator is running on. There are many possibilities.
• An extended goal would be implementing a C compiler or maybe even a Java compiler (I don't think that it is possible to have a JVM executing byte code because of the limited memory).

Java Dpkg

For a few projects at work I had to build Debian packages by hand in the command line of Linux after copying all the necessary files onto the machines. And for every small change and every new version I had to do it again. That process was very unstable, not documented and not very transparent for others. One solution would have been to use SSH and write some scripts e.g. in Ant. Back then I decided to implement a build system independent solution in Java which could be used as a plug-in in Maven.

Thankfully the department chief of the R&D department agreed that I could do some of the development to finish it at the company. Therefore I big thank you to Mr. Elholm of Aurenz.

You'll find the project here on SourceForge. In the meantime this plug-in - as well as the library - is available as Maven artifact through the public Maven repository.

OpenQuest

I'm a fan of the adventure board game HeroQuest (in Germany also known as "Herr des Schwertes" - master of the sword). And I also know a few people who like it. The problem: If we meet, we only have time for maybe one, two or maximum three levels. So we play the 1st level over and over again. That was the point at which the idea for a digital version of the game was born.

There have been digital versions before. I know that there have been 2 titles for the Amiga500. And there is also a fan made version which is only 2D from above.

The goals of that project are:

• Implementing the game with all of the standard rules of the original board game. That version will be 2D from above and feature a single player mode, a network mode as well as a hot-seat mode. It also will include a safe and load feature. The network mode should be able to support the disconnect and later reconnect of players as levels may take some time - especially if not everyone is sitting in front of the computer all the time.
• Afterwards an isometric view will be implemented.
• An extended goal would be a 3D mode.
• Great would also be to support different devices, not just the PC, so players can play anywhere any time.

This is the project site: http://www.openquest.de/

Java API for NCurses

For the appliances - virtual as well as physical - I've worked so far it was always a requirement that the customer or user should be able to configure the basic settings of the system (e.g. like the IP address) in the Linux console. As customer may not have any clue about Linux - and maybe also shouldn't be able to access the system directly, a program in the text mode of the console was needed. But Java doesn't ship with text mode support (I mean beside System.out, System.err, System.in and the Console class).

I found the Java Curses Library. It is a Java library based on JNI using the ncurses library. As I didn't find any other library which seemed to fit my needs I used that one. As it is very basic I had to overwrite many of their classes and also add new components. But there are even more serious short comings like the last window you close triggers a System.exit(0); within their library. This will end your program instantly. And you can't overwrite that from outside. It also seems that the project is discontinued. The last change they made was when I reported a bug. Before that there haven't been many changes. And since there also seems to be not much activity.

I still think that the general idea of that library is a good one. So I had a look at the ncurses API as well as on JNA (I prefer that over JNI). And I think it is possible to have a Java representation of that library without having any native C code (which can't be overwritten).

In addition I'm thinking to build some visual components which look like the Turbo Vision components, but work more like the Swing components.

Another feature would be to have a client-server architecture available. The client only does the ncurses calls while the user interface itself runs on the server. That way you could have more than one instance of your program (e.g. if more than one user will be able to login into the Linux system and use your program).

Java API for SVGALib

When I developed a setup tool for the Linux console for some application which are shipped to the customers as appliances, one of my colleagues was complaining because other programs come with a graphical user interface (e.g. Sophos SafeGuard).

That moment I remembered that some programs like Doom were ported to Linux by using the SVGALib.

The idea of this project is to create a Java API for the SVGALib using JNA.

In a second step an user interface library should be created based on that API. The look and feel could be similar to Swing, Windows 95, Windows 2000, NeoBook or NeoPaint (if someone still knows these two MS-DOS programs).

This project would also be combinable with the next one, the Java API for RFB protocol.

Java API for RFB protocol

A long time ago I did some research about implementing a Java API for the RFB protocol. Maybe it is not that well known under its name, but if I mention VNC and its siblings - and this is the protocol of that program family - it should be more clear about what I'm talking.

The API should consist of a server as well as a client. SSL support would also be possible.

In a second step an user interface library should be created. And if there would be a common interface implemented by this API and the Java API for SVGALib (maybe through a wrapper / delegation class) it could use the same user interface components.

Java Mail Server

Java already offers (also through some external libraries) Servlets for HTTP (including the needed container). The same goes for FTP: Ftplets are here the solution.

But there seems to be nothing like that for Email also everyone uses it a few times each day (same goes for newsletters, mailing lists, notifications of forums). This project would aim for offering SMTP, POP3 and IMAP functionality.

Later maybe a calendar could be added as many mail clients nowadays ship with a calendar module (e.g. Outlook, IBM Notes, Thunderbird). There are several open APIs (like iCalendar, CalDAV, or Sun Java System Calendar Service (WCAP)).

Atari Portfolio emulator and IDE

Many many years ago I saw and bought an Atari Portfolio, one of the first mobile computers (maybe even the first one). In the meantime I even have a second one (which has a different firmware version) and some peripherals (memory extension, serial interface, parallel interface, modem, etc.).

Also there is still an active community (like the German speaking Portfolio Club Deutschland), there are no (recent) tools for software development.

Like the Apollo85 project offers development tools for the ECB85, this project aims for creating an emulator, an assembler, a C compiler, maybe an IDE and maybe even Java. In this case it would be even possible to implement a real JVM as it's an Intel 80C88 processor with a maximum of 640 KByte of memory.

3D software renderer

Nowadays even smartphones have 3D hardware, so software renderer are normally no longer needed. But to figure out how 3D rendering itself works a software renderer is a nice piece of (educational) software.

Long ago I found a tutorial for rotating a 3D cube. But after typing / copying the source code I realized that the author used a lot of tricks. The 3D cube wasn't really 3D. And it only worked for that one 3D cube in the example. But it made me curious. Back then I had a PDF sample of a book which dealt with that issue (one of authors was John Carmack). Within this book they described how real 3D works and what kind of calculations one had to do. Unfortunately I don't have that PDF sample any longer, but I think it was:

• "Graphics Programming Black Book" by Michael Abrash's
  ISBN: 978-1576101742 (Amazon)

It would be great to be able to continue my research on that topic.

3D engine programming based on Java3D and/or JOGL

I've bought two interesting books who deal with game engine programming in general and 3D engine programming in particular:

• "Killer Game Programming in Java" by Andrew Davison
  ISBN: 978-0596007300 (Amazon)
• "Pro Java 6 3D Game Development: Java 3D, JOGL, JInput and JOAL APIs" also by Andrew Davison
  ISBN: 978-1590598177 (Amazon)

So far I only skipped through both books, but based on what I saw and read I would say that these books are really great. Unfortunately also here my available time is the problem. Otherwise I would try to implement a small 3D engine in Java 3D and / or JOGL.

Java Fax library

I still have two 33.6k modems as well as a D/A converter (I need the converter for the Fax of my MFP as I have ISDN). So I thought it would be fun to have a Fax library for Java, maybe using the Java Communications API or the RXTX API.

Maybe it will be necessary to implement the protocol of some COM port redirectors (means their hardware counterparts, the COM port servers}.

Java BBS library

Like I mentioned in the Java Fax library I still have some modems. And I'm able to connect them to the public telephone network.

When I had my first modem (some kind of 14.4k modem) I tried a few BBSs. And that was a lot fun, also it didn't have any benefit for me back then. So wouldn't it be nice to revive that time and the BBS? So I'm thinking about implementing a library, framework or maybe even server for doing this. That piece of software would offer possibilities to send text user interfaces to the terminal software on the other side. It would also support XMODEM, YMODEM and ZMODEM for file transfers.

For testing I will surely need some terminal programs, so I looked for some:

• Qodem Terminal Emulator
• ZOC Terminal

Let's see if there are a few more. The more the better as it will increase the level of compatibility.