Well, before you start worrying about that stuff, I would think you need to get a solid format going for how you represent your molecules in memory. I would say that your data structures for each of your atoms should look like this.

[Atomic number][lone pairs][charge][flags xx112234][bonded id 1][bonded id 2][bonded id 3][bonded id 4][bonded id 5][bonded id 6][display x][display y]

Where:
 - atomic number = atomic number
 - lone pairs = number of lone pairs
 - charge = formal charge
 - flags = bond type 0 = single bond, 1 = double bond, 2 = triple bond, 3 = ionic
 - bonded id # = the array position of the other atom it is bonded to
 - display x/y = where it is displayed on the full buffer

So with this system, you have the 10 byte atom structures lined up in memory. Each one would have an ID based on where it is in memory as well as the atoms it is bonded to. The goal would then be to parse what the user typed and turn it into one of these structures. If you start to get triple bonds, you may have to switch some of the bond id's around as you add them, but that is fine.

Using this system, you should be able to represent any kind of atom I can think of, even complex organic molecules.


Then, onto your questions:
1. This one is easy, assuming you don't start getting really space filling molecules (2,2 - dimethylpropane), the angle calculation is as simple as taking 360 divided by the number of atoms and lone pairs bonded to the atom. So, if it is bonded to 2 atoms and has one lone pair, 360/3 = 120. Then you'll just have to make a sine and cosine LUT to figure out how to draw your lines. (The LUT only needs 360, 180, 120, 90, 72, and 60)

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.

That looks good to me. I don't even need to 4088h routine. But, the more the merrier I guess.

If xeda will give me an entry point, I'd be glad to do it.

However, in the grand scheme of things, I'd like to see Grammer get a little bigger before I add support for it. Like I said, I'm pretty low on space and adding in options like this takes a minimum of 100 bytes.


One option that I do like would be to somehow use the "Run on zStart" option to add in a hook to make it work. I don't see that being very difficult.

Visual Studio's been working great for me for over 2 years now. Granted I've never tried anything else, but setting up your environment is as simple as installing the program.

One of the things I love about it is that it red underlines stuff that it knows is going to cause a compiler error, that definitely improves your C++ skills

I'm very glad to hear that, because I never actually tested it

I don't have the means to make an axe program large enough to test it so I just figured that since it put the ports in the right states, it should work. And I guess it does.

That is by far the greatest thing I have learned all week. I didn't realize that you could edit webpages on the fly. I'll have fun with this

(Yes, I realize it's only on my computer)

I know one easy way to do it, though I'm not sure how good it would look. I really have no way to describe it other than in steps:


1. First, you need a counter, I will make it 8-bit and call it _C, the counter starts at 00.
2. Clear your buffer

OuterLoop:
3. Set a pointer to the beginning of the picture buffer

InnerLoop:
4. Take a random 8-bit number, AND it with _C, then OR it with the current data in the picture buffer and store it
5. Rotate _C by one bit (left or right doesn't matter, just keep it consistent)
6. Increase to the next byte in the picture buffer
7. Goto InnerLoop until you are at the end of the buffer

8. Increase _C by 1 (the real _C, not whatever kind of rotated crap you ended up with after the inner loop)
9. Goto OuterLoop as long as _C is not equal to 256 (0)

10. Goto OuterLoop a few more times with _C = 255 just to make sure any stragglers get filled in


That aught to do it. The only thing that will break it is if your random routine isn't truely random. You might also get interesting results if you randomly rotated _C rather than just rotating it by 1.

Edit:
    The second AND is an OR

Most Recent Version Here

For those who haven't figured out where the name came from, I knew I had to use the word full, as in "full Ram", but I had to make it cool. So then I decided on Fullrene, those cool carbon creations, only to find out that it's spelled Fullerene.

I believe that this axiom is ready to go. It appears to work on every emulator I've tested it on, so it should be good.

A few notes on usage:

• Syntax: Fcdf() or Fcdf()^r (preferably at the start of the program)
  
• The version without ^r will work on all calculators and is 163 bytes, period.
  
• The version with the ^r won't work on the 83+BE, but is only 78 bytes.
  
• This axiom sets up a wrapper around your entire program so that it can disable this feature when you quit. This means that you should either try to end your program by using Return or running off the end of the program. (Return^r still works, but it's bad practice to leave the calculator in this unlocked state.)
  
• This routine disables interrupts

You should already know how Axioms work, but if you don't, send this appvar to your calculator and put it in flash. To include the axiom in your Axe program, add the line:
:AsmComp(FULLRENE)
   or
:#Axiom(FULLRENE)      (Axe hooks)

Then, include this line preferably at the top of your program.
:Fcdf()        (all calculators)
   or
:Fcdf()r        (non-83+BE calculators)

If you can't find Fcdf(, it's in [2nd] [Vars] [9 or 0]

Also, if today is your lucky day, here is the code to optimize: (I'd be happy with even a single byte)