It has recently come to light that a significant number of the community's most accomplished z80 Assembly programmers, including thepenguin77(Brian Coventry), FloppusMaximus (Benjamin Moody), calc84maniac (Brendan Fletcher), Ben Ryves, and Brandon Wilson all have first names beginning with the letter "B." This statistically significant event is obviously full of mystical meaning, so what is your hypothesis as to why this is?

After a discussion about x86 emulation and WINE on #omnimaga, I became curious about the possibility of an emulation layer to provide additional functionality to Prizm programs by replacing missing hardware like the FPU and potentially other higher level functions.

Here's the basic conceptual framework I came up with:

• All Assembly/C programs would go through a low level interpreter. This interpreter would be interrupt based and would copy a section of code into a buffer.
  
• The buffer would be terminated with a Sleep instruction so that if the code finished executing the buffer, the processor would halt until the next interrupt fired in a few milliseconds.
• When the interpreter detected something like an FPU instruction code, it would handle the instruction by replacing it with a call to a library routine.

This raises some obvious points, like the slowdown inherent in interpreted programs, but I don't think that's a serious problem, since most applications aren't speed critical enough for that to be a problem. Such an interpreter would also operate very low in the system, so it could probably be accomplished in only a few hundred cycles. You could also replace the interrupt/Sleep idea with a call to the interpreter so that it automatically calls the interpreter upon finishing. That would leave the interrupts open for modification by the program, as long as it doesn't modify itself to overflow the buffer.

Anyway, just a thought.

Since DJ has officially announced his resignation from omnimaga.org and the larger TI/Casio community, Omnimaga now faces the uncertain question of future funding after the hosting bill of $334.89 USD is due in October. While the remaining administrators will attempt to cover as much of the costs as they are reasonably able, the funds are likely to be insufficient. Therefore, on behalf of the staff and moderators, I have posted this poll for public discussion of solutions to the problem of future Omnimaga funding.

Note: Any form of donations will be accompanied by periodic and transparent publications of Omnimaga's financial records in order to assure donors that their money is going towards what they intended it for rather than into the pockets of those responsible for handling the money.

Thank you

If you're going to produce commercial software, here are a few rules that absolutely everyone should follow:

1) Design without a purpose. Everyone knows that commercial software designed for an actual market doesn't sell. Design for a market with few people. Better yet, make sure the market doesn't even exist. A good example of this is the DJvu converter hosted at http://www.convertdjvutopdf.com/. Although few people have even heard of the format, let alone use it, a proprietary converter to the more widely used PDF format exists. Don't let the "freeware" signs fool you. To get any actual use out of it, you have to pay for it. That's exactly how I think software should be.

2) Don't bother bug testing. There's nothing like using some software only to have it bug out halfway through a large, time consuming project. It's even better if you allow the user to cause fatal errors and data corruption in the program simply by having the program running while they have text or other common things in their Copy/paste clipboard as Logicworks allows you to do.

3) Make it useless. Don't let utility slow you down. The off-line IP country finder by Fairdell software accomplishes this in an amazing 1 MB of space.

4) There may be half a dozen competitors in the market already offering software of equal quality for little to no cost, but don't let that stop you from making another Text editor or unit converter.

5) Use up all the memory you can. Just remember that your users are practically begging you to get rid of their extra memory space. Don't worry that your label maker uses up 200 MB. If anything, you should expect thank you letters in the mail from your users.

Keep these in mind, along with a thoughtful disregard for common sense and you'll be on your way to making millions from your next proprietary quadratic solver.

I'd like to announce the new channel for the Casio Prizm on EFnet, #prizm. This wasn't really a formal thing, but given how many bots have gone through, I suppose it's stable enough for announcement.

Anyway, add it to your /join lists and enjoy 

I've put together some tools and materials that are very useful in developing for the Prizm. It's very rough right now, but I think it covers all of the major bases and gets the information across.

Download: http://www.megaupload.com/?d=HRXZXH5N

I'd like to present the spiritual predecessor to the Casio Prizm, the HP Xpander.



The HP Xpander was an experimental calculator by HP that sadly never made it to market. It used an SH3 CPU running Windows CE and would have had 8MB program RAM and 16 MB ROM with an additional expansion slot. As you can see in the picture, it had a massive B/W screen with 240×320 pixels. The screen also allowed a stylus to be used instead of the butttons, making it effectively an early touchscreen calculator, back when it was announced in 2000.

Unfortunately, HP canceled the project only months before its release and few projects were ever developed for it. One can only imagine what the calculator world would look like today had this revolutionary product been released.