If there are new syscalls used, the solution would be to make a fresh build from the SVN (or wait until the next release). Back-compatibility with OS 1.7 is planned, as far as I know.

Quote from: critor on January 04, 2011, 05:25:20 pm

mViewer is quite stable with Ndless 1.7, on non-CAS calculators, or even with Ndless 2.0 on non-CAS calculators.
I've got problems with the same binaries with Ndless 2.0 on a CAS ClickPad.
After exiting mViewer, the calculator does freeze or reboot very often (which does not happen on the non-CAS).

So may be there is a wrong address for a 2.0 CAS syscall, I'll try to find it. Tell me if you happen to have an idea on which one it could be.

I think freopen might be wrong, syscalls_cas-2.0.1.c has it as 102F6FFC but it should be 102F6FB8.

EDIT: this couldn't be the problem, Ndless 1.7 didn't have freopen

Still no progress, I am afraid. Mostly, I've just been lazy and trying to enjoy the last few days of holidays to their fullest...

You also get crashes on exit:
- if you haven't freed all allocated spaces
- if you haven't closed all open files

Hmm, I do close the wad file, but I am worried about freeing all allocated spaces... I think I've missed a few here and there. I just want to make sure, that refers only to the spaces claimed by malloc() and realloc(), right? Not every single variable and array there is, I hope, since that would be insane.

So may be there is a wrong address for a 2.0 CAS syscall, I'll try to find it. Tell me if you happen to have an idea on which one it could be.

My only idea was the free() call, after which the application always crashes, but you already checked that, so no ideas, sorry.

Are you sure ndless 2.0 progs work on 1.7? I just get a reboot when I run ndoom.

Just a reboot? No error message, no screen full of garbage, just a reboot immediately after running the executable? I've never had that happen with the current releases, there was always at least an error (not counting the crash-on-exit, that is). What OS/keypad/CAS you have?

Mrakoplaz: I understand how you feel about svn... until I lost 3 months worth of code, recovered half of it, then broke it once again, without the possibility to revert 3 days of (bad) work. However I'm not here to force anyone to do anything, so that's fine.

Just to say that I don't either use svn for shared projects, but the dumb way, as a cheap incremental backup with log messages. svn with more than 1 developer is a mess as soon as 2 people change the same file (half joke - but svn branches really sucks), and git seems nice but is too complicated for me. but the backup side of svn is nice. again, just my 2 cents, I totally respect your freedom.

Hey, if something like that happened to me, I'd probably love it too
However, I am ridiculously over-organized, and set up incremental backups on several external/USB drives, all of them labelled and such. I'd guess a SVN would make it a bit easier, but I have batch files and don't need the internet for my method (my connection is a bit... unreliable, let's say).

Since it accepts .wad files, I'll have to try this with Chex Quest

Unfortunately, I don't think it's strictly compatible. It might be, but I think Chex Quest had a few minor executable changes which could make a big difference. Did Ultimate Doom (the source for this port) work with a chex quest wad file?
Also, although the compatibility for any wad file is there theoretically, practically it's only been tested with the Doom 1 demo, so I have no idea if it will actually work at this stage (I'll start testing it with other wad files once the demo is fully playable, though!).

Yes, the clickpad controls are horrible. They would be a lot better if:
1) The left and right keys would rotate the display instead of strafing
2) Use Esc and Home keys for strafing

Ah, thanks for your suggestion! I had no idea where to put the two strafe keys, and didn't even for a second think of using those giant esc/home buttons staring me in the face...
I'll put in the next release, which I'll release when I fix the rendering in level 2. If you're desperate enough, the input code is in i_system.c and quite understandable (even though it's a fairly clumsy hack of fitting asynchronous events into a synchronous system).

Also, cheers everyone, for your great feedback. I know I say this every post, but I do genuinely mean it each and every time!

Mrakoplaz: programs can be built with the GCC option -std=c99 with the latest update of Ndless 2.0, so you could have replaced calls to alloca() in the original source code with variable-length arrays.

Well, sorry everyone for lack and slowness of updates, but not only does school take a long amount of time, but the bugs that are left are increasingly getting more and more obscure (the one I just fixed in this release, everything went wrong due to a single bit being zero instead of one... and this bit wasn't a boolean, it was inside a 4-byte int!) and thus take longer to fix.

Release features:

• Rendering bug in level 2 fixed, this should be the final rendering bug (I hope)
• Added loading screen (useful on real hardware, where the loading actually takes some time)
• Playtested up to level 4 or so
• Lowered default difficulty to easy, because I kept dying (still no menu, though...)
• Manual weapon selection (finally! use A/B/C/H/I/J on Touchpad, or 1-6 on Clickpad)

The crash-on-exit, lack of automap, etc. are still all there, but at least now all the levels are playable and the game can be said to finally work (sort of). Further releases will concentrate on improving the experience (difficulty selection, improved palette, savegame support...).

A peculiar thing: With the introduction of the loading screen, the screen as a whole shifts slightly to the bottom left (~10 pixels in each is my guess). I remember that the particles demo had this bug, and it was resolved by not reading from the screen buffer - however, I am not doing that. All I'm doing is writing (memset and memcpy). I'll attempt to do a test case, but not sure if I'll have the time to do so. Nevermind that, I'm just an idiot.

Again, suggestions for better controls/misc improvements are always welcome. Also reports of crashes.

Wow nice work on the bug fixes!  You are really working hard, and its really paying off!

Its most likely too much memory is being used for the wads, those are like 4mb, right? They are probably overwriting the os memory, thus crashing the os on exit.

Its most likely too much memory is being used for the wads, those are like 4mb, right? They are probably overwriting the os memory, thus crashing the os on exit.

I've run 4MB ROMs in gbc4nspire before (granted, that was on OS 1.1, but still)