That's easy enough to add, I guess I can have a separate upload form below the normal sourceCoder upload form? What does everyone else think of that, would it be worth my effort?

Certainly so!

And what do you think it should offer? I was thinking for color or grayscale images, it can just take the average of the red, green, and blue values, and round to black or white. I guess I'll accept bmp, png, and gif; should I bother with jpg? I don't know if a lossy format would be the best to accept.

3 and 4 level grayscale images would be cool. As for jpg, I'm not certain. It may be hard to support a lossy format indeed. Also maybe an option to convert to z80 instead of 8xi. Either a 96x64 z80 image, or split by 8x8 sprite data.

I was just thinking the same thing. Those are all pretty easy to do; the hardest part will be, for the grayscale ones, letting the user choose the thresholds. I'll have to look into what Javascript provides in the way of sliders, or figure out a less flexible way to do it. I'll definitely offer the .db the image, since the current SourceCoder iteration can already generate .db statements for ASM from .8xi files. I think it would be nice to offer 8x8 and 16x16 sprites, probably.

How about monochrome bmp to 8xi? That would be fairly easy.

BMPtoC conversion. It takes a bitmap, and turns it into code like:
0xF0,0x0F,0x0C,0xAF, <etc>. And it makes the rows even, so if the picture is 5 rows tall, there will be 5 rows of code. Oh, and at the beggining of the line it will start with "[<data size for the bytes]={" and end with "}". Not sure if that's too much work though...

That sounds doable. Are these monochrome? What are the pixel dimensions, fixed or variable?

16 level greyscale, each pixel gets its own hex character. Variable width (I assume you can figure out the width and heigth of the bmp by looking in the header) and variable heigth, with it being the size of the bmp

Ah, so it's nibble-packed grayscale, that makes sense. This should be no big deal at all. Can someone confirm if the following things are what I need to add?

1) Reading .bmp, .png, and .gif images
2) Offering output of .8xi files, .db statements, and nibble-packed hex
3) .8xi files will be monochrome, .db statements will contain 2-level, 3-level, and 4-level sections, and nibble-packed hex will be for 16 gray levels.

Did I miss anything?

*bump* Everything implemented except the actual .8xi exporting. I'll be posting a new topic about the upgrades shortly.

Can the SourceCoder program run programs on the computer?

I don't think it can right now, if it can, I can't find it.

No. You'll need an emulator to run programs on the computer. All SourceCoder (SC) does is open the program and display the tokens (Output(, For(, etc) inside.

No, for that you want what's called an emulator. I recommend WabbitEmu. All you need to do to combine SourceCoder and WabbitEmu is export a .8xp from SourceCoder, then drag it onto the screen of the virtual calculator in WabbitEmu.

Does this site have an emulator?

All emulators run computer-side; there are no online emulators for a variety of technical and legal reasons, not the least of which would be remote storage or sharing of copyrighted ROMs.

Unfortunately. No. An emulator requires a ROM Image, something that SourceCoder lacks and will continue to lack.

Aye, the only solution would be something Flash-ish that would have the user point to a local ROM on their own computer, but even that is iffy. I'd rather not touch the issue at all for now.

I'm not sure if this was suggested, but have you thought about adding support for the alternate Axe token names? Example, when a program got an Axe header, SinReg becomes Freq(, DeltaList( becomes Data( and Conj( becomes Copy(. I assume this might be hard to change between Axe and BASIC tokens in real time when editing, though (changing them when adding/removing the Axe header would require some AJAX, right?)

It would indeed require some AJAX, but because those three, for example, are not duplicates of existing token names, I could just add them as new tokens with numerical values identical to existing tokens. Unfortunately, though, I wouldn't have no way of using them in .8xp->source, since other than parsing out the header of the program, something I haven't done yet for any BASIC header type for the sake of universality, only for source->.8xp. It's an interesting idea though; is this something other users would be interested in? (@ Said other users?)