Rockbox mail archiveSubject: Re: sony cd changer emulation almost finished
Re: sony cd changer emulation almost finished
From: sophana <jobarjo78_at_yahoo.fr>
Date: Tue, 01 Jun 2004 18:27:45 +0200
>>I had a look at the plugin mechanism.
>>The big struct containing all the pointers is touchy to make backward
>>Is there not another way of making system calls through a trap or
>>something like that? (like most modern OS)
>The struct is versioned forward and backwards, it's kind of mandatory for a
>plugin to check that first.
>A trap would have at least the same kind of compatibility problem, what if
>you change the IDs?
the ID space is huge. If you decide to deprecate one ID, you just don't
implement the id, and make a hole in the id space.
The implementation I am thinking of is a simple table containing the ID
to function pointer translation.
I don't know how parameters are passed in sh1, but if it is stack like,
the trap handler would just pop out the id, retrieve the function ptr
then jump to it. the stack contains the parameters directly for the
The principle is a bit like the event IDs in the event queues. Note that
the plugin should communicate through queues. this would be much easier...
The table could be generated using a macro processing, simplifying the
evolution of new plugin routines.
>Plus, the simple function pointer struct works equally well in the
>>I saw a flash in my player jukebox. I have read somewhere in the list
>>that you had a failed attempt in flashing the player. Are you sure there
>>is no way for recovering a badly flashed player? (jtag or something like
>There is, this is what I call the UART boot mod. I did that, reflashed it
>back to original, verified that, but it still doesn't work. The flash
>content is not the problem here, I must have broken something while doing
what is the principle of the UART boot mod?
>>I would be glad to help for player flashing because I could not find how
>>to connect to the 'ON' button.
>Maybe one day...
Received on 2004-06-01