It that why my machine always locks up when I go below 6-700MB free mem perhaps?!?

Please disable if it cannot calculate correctly, or execute correctly.

@kas1e

Nice!
Is there any changelog, and non-debug build?

Do these version work with the latest MUI now? I forgot the status about this...

@samo79

Yeah, like all of webkit it never frees any memory because it was written for systems with (working) swap. But Odyssey and the player gets unstable around when I have 700MB free ram. I never let Odyssey get below 700MB free (about 700MB allocated), preferable not below 1GB free, because it will surely crash very soon or lock up the system.

But I don't think running out of memory the biggest problem of the player. It trashes memory. If it has been started just once on any small video, the system is unstable and will crash after a while in some unexpected way that never happens when that player has not been run.

It is unfortunate that it should be so buggy. Even if the mediaplayer itself doesn't crash, the whole system gets unstable after it has been used and often results in a crash or freeze somewhere else in Odyssey, Workbench or anywhere.

It's quite clear that it overwrites memory somewhere, maybe stack overflow?

@ChrisH

I would suggest using the MUI pens as they are supposed to be used, i.e. HIGHLIGHTPEN for highlighting, FILLPEN for fill colour etc. Then if it looks like shit on a custom screen (it always does) the user needs to do some configuration to get it right.

Yes, there were some special DMA accelerated CopyMem routine on the Sam. But Sam doesn't have Altivec so it becomes irrelevant in this case...

@zzd10h

Quote:

Maybe you should make external settings (envarc:smTube_dl.prefs) so that no one needs to modify the script, just like the old getVideo.rexx script?

I kind of doubt newlib is, but maybe exec. Anyway, it's still worth experimenting at at some point.

Would be interesting to see how CopyMem and SetMem scores here. Can't use CopyMemQuick since the copy data is always totally misaligned due to RGB triplet. The setmem calls otoh. are pretty much always 16-byte aligned due to the altivec source data from libjpeg-turbo.

Cool!

I just altivec-optimized memcpy and memset from plain byte-loops to altivec-versions created specifically based on statistical analysis and gained between 11-23% speed in decoding ONLY by optimizing memcpy and memset!

@broadblues

It could of course have been soved using either clib och newlib but I got a headache thinking about it. There are only a few simple stdlib functions I needed so it was faster to implement them rather than try to get newlib or clib in there (at the time). Now I realize newlib is a normal library it could have been fairly easy (on AmigaOS).

This was I can also easily profile the usage of memset and memcpy. And also pretend that fwrite can take a BPTR instead of a FILE*. Makes everything MUCH easier

@broadblues

Quote:

Because this is a library and I read somewhere that one had to compile with -nostartfiles -nostdlib. Besides, it wouldn't be MOS compatible I suppose. And it's fun to implement stdlib :)

Quote:

They are not, they are functions. But the examples have bugs; they don't return 0 from the de/compress hooks as the docs say that should unless they want to abort. Seems the docs are wrong and only the progress hook responds to any return value.

@trixie

Quote:

As salass00 said, setjmp/longjmp cannot be implemented in C because they play magic tricks on the C code itself. Need 100% control of register usage and the stack since calling longjmp (from anywhere deep inside other code) causes setjmp, somewhere else in the code, to magically return. longjmp never returns, setjmp returns instead. Pretty cool :)

Error handlers using setjmp tested and working. Jpeg writer also working.

Had to implement setjmp/longjmp from scratch in assembly, with some help from google, since I have no stdlib. All required parts of stdlib are reimplemented from scratch.

Now testing all the different scenarios using the jpeg_library dev examples. Hooks are untested and apparently doesn't quite work...

New jpeg.library implementation based on libjpeg-turbo with Altivec acceleration is nearly complete. I just wasted the last 3 days on an ISI crash/hangs, slowly rebooting the X1000 a hundred times, caused by a brainfuck in memset(). It was overrunning 1 byte destroying an error handling function pointer inside libjpeg.

Anyway, FIXED last night! Now all that remains is to implement setjmp, the last hurdle of stdlib, and we are good for beta-testing :)

The reader already works, just need to test the writer.

@tommysammy

I pushed in the last $50. We are now at 100%

@sinisrus

Cool! I'll have one of these

But why serial and not USB?

I made a similar thing once, but for the parallel port:
http://www.onyxsoft.se/files/parir.readme
http://www.algonet.se/~deniil/prgpages/parir.html
It also carried audio, could learn any remote control and was designed to transfer over ethernet cable for serious remote controlling.

The X1000 doesn't have a parallel port though, and typically no serial port, but I did order the extension cable for mine in case I would need it.

@broadblues

How do I use sashimi on OS4/X1000?

@Thomas

Thanks. I'm not porting 68k code though, and I'm using the SDI macros.

@xenic

That's it! It was after a warm reboot it stopped working.

How do I fix it? Is there an OS4 command to change the output while running? Is there a CFE setting (X1000) I can set to lock it to the buffer?

@broadblues

Thanks. I'm using the SDI stuff so it should take care of this.

@xenic

Yes, but this is a macro, and about _using_ varargs. Anyway, I let SDI take care of the syntax and put the wrapper in the interface stubs.


Now I have a wierd problem that DebugPrintF() won't output anything to the debug buffer log. I get a crash in a code path I know have several DebugPrintF but no output. Worked yesterday....