USB. There's not much information because we don't have much information. When you enter the world of USB, regular asm is gone forever. You now enter the world of randomness without reason. There is no debugging, there is no 100% information, you start to involve hardware failures, and stuff can just not work for no reason at all.

+1 for dramatic and completely justified statement.

Also, I think DrDnar spent some time with USB, but I could be wrong.

Can't wait to see this! One suggestion I have is that the syntax be something like Mediawiki's or HTML syntax.

You are awesome and I want to have your children.

Here is a list of rules and suggestions that I believe those who develop for the Prizm should keep in mind for their apps. Many of these apply to all platforms whether it be other calculators or computers but a few are more targeted at the Prizm.

• Treat the user's calculator with respect. Don't use any code that will put THEIR calculator at risk! Test your programs extensively and remove any holes that could potentially cause a major error. Even if you're not liable for damage, these types of incidents can tear apart communities.

...

• Value user friendliness over extreme optimization. I'm not condemning optimization—in fact, every program should be extensively optimized—but what I'm warning against is overdoing it. You should always program in extensive exception handlers to prevent the user from breaking your apps. Graphical appearance should also be focused upon. Most users would prefer a sharp UI over an additional frame per second.

The first one is especially important in the case of custom flash routines. Don't use them. They have the potential to seriously damage calcs.

Also, the second may not be true for programming utilities like interpreters and emulators. In such reasonably uncommon situations, extreme optimization is often entirely warranted (and lamented if not present).

2. Scrolling is a bit harder, any way you do it it's going to be messy. I have two approaches, the oversized buffer method, and the clipping method.

• Oversized buffer: For this, you'll want to allocate a big buffer, 150x150 pixels should be fine. Then, you'll have to make your own drawing methods to draw to this buffer. You really only have to copy over a line drawer and a vPutS, which isn't really that tough. After that, you simply draw you whole molecule to the buffer and only display the 96x64 region that is currently showing.
• Clipping method: This method might be harder, but it uses fewer resources. You will probably be able to use the system vPutS for this but you'll need a special line routine that automatically clips itself to the edges of the screen. (badja made one). From here, you also need to define how far the screen has scrolled from the top left corner of the true screen. The final step is just to take the coordinates of something on the screen, subtract from it how much the screen has shifted, and draw the atom to the resulting position on the screen. You'll just have to watch out to make sure that you don't accidentally try to vPutS something off the screen.
  

I would highly recommend not going with the virtual buffer method. As you mentioned, it's messy. It's also rather inefficient for long carbon/Silicon chains where you have large 2d plots, but relatively few molecules. I'd instead recommend a more "vector"-ish approach where the coordinates of the nuclear centers are represented in a virtual 3d space as a table of coordinates and bond relations. When you need to display them, you define a 2d buffer that will be directly translated to the screen and just project the points from that 3d space into the buffer along with the bonds. A bit more complex, perhaps, but it allows "infinite resolution" of arbitrarily large molecules (within reason of course) and uses a less memory for molecules with low nuclear density since all you're storing is an extra coordinate over the 2d buffer method.

As for generating the structures themselves from the formulas, I'll be blunt. It's basically impossible to do at any significant level of accuracy, since the structure of a molecule depends on a lot more than just an enumeration of the atoms in it. For example, it often depends on the prior history of its constituent atoms. A good demonstration of this is Barrelene, a molecule with the formula C8H8. This molecular formula is also shared by Cubane and Styrene, among a few others. These isomers are all [somewhat] stable in their radically different configurations and determining which one the user means is nigh impossible. A structural formula like SMILES is much less ambiguous, pretty widely available for most molecules, and essentially eliminates the near impossible problem of predicting molecular structure.

Did you know that the vast majority of RAM already relies on higher-base storage concepts? Yet, it is part of a binary computer system.

That's because the fundamental unit of information is the bit, which coincidentally, is the same unit used in binary Notice that the bit contains more information than a unary digit. As Builderboy said (and you implied with the statement that "it has to read them all until it reaches a zero"), with *ONLY* 0's, you can't build a computer using unary instead of binary. There just isn't enough information in unary digits by themselves to determine multiple opcodes. Additional information in the form of formatting is inherently necessary.

actually, it involves counting the numbers of 0s.

think tally marks, minus the 5 groupings. That's unary. Binary allows having ones separating the zeros, but unary doesn't, so (I'm representing the bits as one for clarity) 111111 = 1+1+1+1+1+1 = 6 , or command #6.

As such, it's easy to make a binary processor pretend to be unary, just as a quaternary one can easily pretend to be binary.

@epic7 zeros and spaces would be two symbols, and therefore binary.

An 8 bit CPU would have 9 possible states: {},{1},{11},{111},{1111},{11111},{111111},{1111111},{11111111}

and each wire would be powered after the previous, so it's easy to convert from an analog voltage by using compariters.

Binary is much better, of course. quaternary is better than binary in the same way.

That wouldn't work. Memory has to be initialized to some set of states, so unary is impossible. Let's take a look:

Let's say we have a turing machine where all the cells on the tape can hold a unary 1 and that's it (it's unary, remember). Now, the machine looks at the first step and sees a 1. So, does it read that as {1} or {11} or {111} or any of the other possible combinations? Let's say it decides based on some magic oracle that it's not {1}, so it looks at the next cell and sees another 1. That narrows the choice down to {11}, {111} and so on. There is no way on the basis of the information provided in the memory tape to distinguish between the opcodes. The machine can have at most one instruction and since memory cannot be modified (unary memory sucks), it can't possibly be Turing complete. Basically, an Unary computer can execute any one instruction repetitively so long as that instruction is trivial (e.g. a NOP or outputting a constant value on a line).

Betcha can't guess where my name came from

Also, where the heck did Dvorak.37 go?