my god...

take castlevania and emulate it, and show me a pic

only then will I slap myself even harder

Here you go

gcc will sometimes emit calls to memset or memcpy functions if you initialize or assign large structures. Having them as macros won't help. I think we need to have real memset and memcpy functions in the library (even if all they do is call the OS functions).

Thanks bwang. I've been meaning to criticize some of the Nspire C code that's going around, having it all in one place makes that easier

console.c
Has no protection against writing past the end of buf. Also, I think scrbuf is unnecessary; drawing directly to A4000100 should be fine. It shouldn't flicker; flicker comes from drawing to the same part of the screen in multiple passes. For example, if you first draw a background and then draw a sprite on top of that, there's a brief period of time when the sprite isn't there. Since putChar works in a single pass, it's just fine to use it directly on the screen.

dirlist.c
This is a bad function even in concept - the caller has no way to know how big an array to allocate for result unless it has already enumerated the directory itself.

screen.c
Looks ok.

string.c
itoa, strlen, strcpy, strcmp: Looks ok.
atoi: Doesn't conform to the C standard. Should allow initial whitespace characters (i.e. space, tab, line feed, vertical tab, form feed, and carriage return), and should stop at the first non-digit. A standards-conforming implementation of atoi exists in the TI OS at address 1018DC44 (non-CAS) or 1018D94C (CAS).

syscalls.c
What the heck is this?

utils.c
rect_intersect, refresh, clearScreen, clearBuf, setPixel, setPixelBuf, getPixel, getPixelBuf, rand, showSimpleDialogBox: Looks ok.
fade: The loop is one byte too short. Should start with i = 0.
scrollScreen: Works, but there is no reason why such a function should require a temporary buffer. Just use memmove (address 1018606C in the non-CAS OS, 10185D74 in the CAS OS):
memmove(scrbuf, scrbuf + bytesOffset, cpysize);
memset(scrbuf + cpysize, 0xFF, bytesOffset);
scrollScreenDown: Doesn't work, probably will crash. This should be done as:
memmove(scrbuf + bytesOffset, scrbuf, cpysize);
memset(scrbuf, 0xFF, bytesOffset);
scrollScreenUp: Function is identical to scrollScreen. No reason both should exist.
filesize, getch: Looks ok.

Easy ASCII input:

struct event {
unsigned int timestamp;
unsigned short type;
unsigned short ascii;
unsigned int key;
unsigned int unknown[3];
unsigned int control;
};

#ifdef CAS
#define get_event (_oscall(int, 0x100CBF78, struct event *))
#else
#define get_event (_oscall(int, 0x100CBF44, struct event *))
#endif

int getch() {
struct event event;
do {
get_event(&event);
} while (event.type != 8 || event.ascii == 0);
return event.ascii;
}


The main RAM is 32MB (there are a few secondary RAMs, but their size is probably insignificant by comparison). The NAND flash, which I assume is what you mean by Archive, is also 32 MB (well, it's actually 33 MB, since each 512 byte page has 16 extra bytes alongside it for checksums and bookkeeping stuff). The OS takes up about half of both.

Maybe you can do something different with the register accesses on the couple of instructions afterward - basically on the load from memory you could do "interlockcount = cyclecount + 2" and upon register accesses, "if reg == loadedreg and interlockcount > cyclecount: cyclecount = interlockcount"

If I made the translator actually emit code to do that I think it would slow emulation way down, with several real instructions added per emulated instruction. It needs to precompute cycle counts as much as possible.

Edit: Would more accurate cycle counting slow down the emulation significantly? (Aside from the fact that instructions would take longer)

That depends on what version of ARM the Nspire uses. The newer versions have longer pipelines, and the longer a CPU's pipeline is the more complicated it gets to predict how long something will take. Let's just hope it's not an ARM11 model.