[announce] c64_tools (DSP loader and IPC)

[notaz]

Ok I'll leave this matter alone, for a while at least. Need to focus more on parallelizing something I'm trying to fit the DSP in..

 

[bsp]

yeah, let's put the damn thing to good use now

(time for me to write a new game..I'm looking forward to what you will come up with, hehe)

 

[Hồng Thất Công]

^ Please lend ptitSeb a hand on DSP with Mupen2

 

[Magic Sam]

Hi,

Houston, I **think** we have a problem...

Am I the only one suffering SD card data corruption while using DSP related stuff (on a Rebirth Pandora) ? That's the second time it happens...

The first time was when you asked us to report sprite limits with ./c64_dsprite. I launched that command many times, but at one moment the icons got all messed up, so I decided to reboot. After the reboot I noticed the SD card was mounted read-only. I ran fsck.vfat and it reported a lot of errors and orphaned files...so I formated the SD card to start from a clean slate.

The second time has just happened: I wanted to show the Mandelbrot thing running only on DSP to my girlfriend, but it didn't work as expected: icons messed up again, SD card disappearing from the desktop...

Is it serious doctor ?

Bye, Magic Sam

 

[bsp]

Which firmware and kernel version did you run before upgrading your OS ?

Chances are you have updated a lot more than just the DSP driver.

Have you ever had SD card issues before ?

According to this thread http://boards.openpandora.org/topic/7789-sd-card-corruption/
and this wiki page http://pandorawiki.org/SD_compatibility_list it seems to be a not-so-uncommon issue that's not related to the DSP at all.

I'd suggest to either run some (non-DSP) stresstests (e.g. SD card I/O under high system load) to see if the card corruption can be reproduced even without any DSP activity, or simply try a different SD card.

p.s.: I use 2x 32g+64g Polaroid SD cards (bought in ED's shop) in my two (GHz) Pandoras and never had any FS corruption problems so far, never seen the 'messed up icons' issue, either.

 

[Hồng Thất Công]

Hi,

Houston, I **think** we have a problem...

Am I the only one suffering SD card data corruption while using DSP related stuff (on a Rebirth Pandora) ? That's the second time it happens...

The first time was when you asked us to report sprite limits with ./c64_dsprite. I launched that command many times, but at one moment the icons got all messed up, so I decided to reboot. After the reboot I noticed the SD card was mounted read-only. I ran fsck.vfat and it reported a lot of errors and orphaned files...so I formated the SD card to start from a clean slate.

The second time has just happened: I wanted to show the Mandelbrot thing running only on DSP to my girlfriend, but it didn't work as expected: icons messed up again, SD card disappearing from the desktop...

Is it serious doctor ?

Bye, Magic Sam

I ran some DSP demos too but no issues here.  All SD cards are still working fine.  So seems like it's "US NASA-only" problem for you there

 

[rohezal]

Ran some dsp tests @ rebirth, no problem here.

 

[WizardStan]

So I'm trying to compile the examples again but it is failing trying to find the ts library. This is following the install of a new OS, I had it before, but now I'm missing something and I don't know what. I've installed CCS, of course, though I don't think it was there; either way, it's still missing. Remind me which package I need to search for again?

 

[Linux-SWAT]

Did you updated the OS ?

 

[WizardStan]

I'm trying to cross compile the demos, I'm not even at the stage of running them

Although I'm sure once I get them compiled I'll have no problem running them: I compiled them before and they ran without a hitch. Also yes, I regularly update my OS.

edit: nevermind, I just removed the "-lts" from the compile line and it worked. I honestly have no idea what libts is (google is trying to tell me I mean tslib) but it doesn't look like it is needed.

 

[bsp]

So I'm trying to compile the examples again but it is failing trying to find the ts library.

edit: nevermind, I just removed the "-lts" from the compile line and it worked. I honestly have no idea what libts is (google is trying to tell me I mean tslib) but it doesn't look like it is needed.

libts (touchscreen utility library) is required by libSDL.


It is provided by "libts-1.0-0_1.0-r24.8.5_armv7a.ipk".


I just updated the tests makefile (locally) since libts was linked to some examples which did not actually require it.


Some examples, however, do, and since you most likely want to use libSDL for Pandora development, it might be a good idea to install that ipk.


In the next release I'll separate the graphics examples from the command line ones to minimize the dependencies.

 

[notaz]

If you don't link statically, there is no need to specify SDL's dependencies. At least on toolchains I use.

 

[WizardStan]

It is provided by "libts-1.0-0_1.0-r24.8.5_armv7a.ipk".

Ahah, so google was right. Since it was required by all the examples I was thinking it was something that should have been included with the DSP libraries, or the cross compiler. I was banging my head trying to find it.

I didn't even try the SDL examples yet, just wanted to get something simple to prove my setup works; compile the base library, build my own module, pass some simple messages, and then work my way back up. I had the examples working before but that was on a completely different system.

 

[bsp]

If you don't link statically, there is no need to specify SDL's dependencies. At least on toolchains I use.

SDL is linked dynamically and depends on libts.so here. I installed the toolchain three months ago, based on information I found on the Pandora wiki and this http://boards.openpandora.org/topic/7147-crosscompiler-toolchain-based-on-openpandoraorg-ipks/ thread. The ipks are hosted on www.openpandora.org so I was under the impression that this was some kind of "official" toolchain. If it isn't, could you please point me to the recommended/official toolchain ? (although I think it's not a bad idea for libSDL to dyna.link its dependencies)

Since it was required by all the examples I was thinking it was something that should have been included with the DSP libraries, or the cross compiler.

It's not required by all examples -- The simple (non-graphical) examples do not try to link libts, so nothing's changed in that regard. Actually, not even all of the gfx examples need libSDL/libts (which is probably the reason why you could simply remove it) but the newer examples do. I am using SDL only for input event handling, btw.

 

[kirkanoss]

wow great job thanks

 

[bsp]

Here's a new release of c64_tools.

It will probably be the last one in some time, unless there are bugs to fix.

Among other things, this update fixes some bugs, improves DSP power management (apps can now suspend the DSP while they don't need it), adds GPP-side L2SRAM memory management (alloc / free), and support for linked 1D / 2D QDMA transfers (useful to stream scattered chunks of memory into / out of DSP SRAM workbuffers).


** Changes

13-Dec-2013
- added 'c64_memview' graphics example
(a realtime memory monitor. quite useless but fun. looks best after a fresh
reboot (unfragmented memory), e.g. load LibreOffice)
- added 'sramtest' DSP component
(various L1/L2 access pattern tests)
- added 'c64_sramtest' example
- optimized 'dsprite' DSP graphics component
Performance @800Mz is now (2000 32x32 ARGB32 sprites):
copy: 249 MPixel/sec
alphatest: 133 MPixel/sec
premul_srcover_saturate: 132 MPixel/sec
srcover: 113 MPixel/sec
- added 'age' DSP graphics component (WIP)
(Amiga "copper" style software display controller that currently emulates
up to 8 bitplanes, and up to 8 scrollregisters, ..work in progress..
currently performs @~90 MPixel/sec (8 bitplanes, ARGB32 target))
- added 'c64_age' graphics example (WIP)
- added qdma_link1d() syscall
- added qdma_link2d() syscall
- fixed sS16 typedef (now signed)
- refactored SRAM malloc code to minim.h/minim.c
- renamed dsp_fshm_*() to dsp_l1sram_*() (old calls are marked deprecated)
- added dsp_physgpp_to_physdsp() API function (L3 to local interconnect addr. translation)
- added C64_IOCTL_L2SRAM_ALLOC to c64_dev.h
- added C64_IOCTL_L2SRAM_FREE to c64_dev.h
- added C64_IOCTL_L2SRAM_DEBUG to c64_dev.h
- added dsp_l2sram_alloc() API function
- added dsp_l2sram_free() API function
- added dsp_l2sram_debug() (private) API function
- added new c64_tc testcase TC_L2SRAM_ALLOCATOR
- added CMD_LINK1D to 'test_qdma' DSP component
- added CMD_LINK2D to 'test_qdma' DSP component
- added new c64_tc testcase TC_QDMA_LINK1D
- added new c64_tc testcase TC_QDMA_LINK2D
- added DSP_MAILBOX_RESET compile time option to dsp_config.h
- added C64_TOOLS_ROOT env.var. export to dsp/setenv.sh (for DSP out of tree builds)
- added setenv.sh (for GPP out of tree builds)
- moved GPP graphics examples from tests/ to gfx_tests/
- moved DSP graphics components from dsp/components/ to gfx_tests/dsp/components/
- moved dsp_component_id_find_by_name() to dsp_priv.h
- fixed multiprocess sync. in dsp_component_load()
- added CORE_FC_CMD_COM_OVERLAY_FIND fastcall to core DSP component
- added some cache writeback calls to fix sporadic DSP side component (un-)registration issue
- added dsp_suspend() API function
- deprecated dsp_power_off() (dsp_priv.h) function (falls back to dsp_suspend())
- moved dsp_resume() to public header file (dsp.h)
- fixed DSP resume which was essentially broken due to some forgotten test/debug code
(registered components were lost during dsp_resume())
- increased RPC timeouts
- added retry loop to dsp_rpc_send() to wait until DSP exits fastcall mode
- increased accuracy of 'c64_nops' utility
(measures DSP clock speed by executing/benchmarking a lot of NOP instructions)
- improved DSP power management: applications can now suspend/resume the DSP at any time
(DSP is powered off when all client apps. have requested the suspend state, and
resumes when first client app. calls dsp_resume())
- added 'c64_pwrtest' testcase
   - added 'pwrlog' c64.ko kernel module option (default is 1 / true)
      (if enabled, trace DSP suspend/resume actions in klog)
   - updated 'go64.sh' to support pwrlog kmod option (C64_PWRLOG env. var. overrides def. pwrlog setting)

Download: http://tkscript.de/c64_tools/c64_tools-13Dec2013_dist.tar.gz

 

[Linux-SWAT]

That's a lot !

 

[rohezal]

This is awesome we need people with lots of free time, to code something cool for it. I would love to see youtube videos in minitube accelerated with the dsp, so you can watch something bigger then 240p (which has worse audio as far as i know).

 

[Hồng Thất Công]

^Or Mupen64, or PPSSPP employing DSP techniques....

 

[rohezal]

^Or Mupen64, or PPSSPP employing DSP techniques....

This is pretty complicated. A decoder is more easy I think (if you could keep sound and pictures in sync).