cadcdev-kallistios — KallistiOS related mailing list

[KOS] Problems compiling SDL 2 samples

[Luke B. <ka...@gm...>]

Hi there!

I've managed to get the SDL 2 port to a state where it compiles, but is
untested. My SD card adapter just arrived so I figured I'd try to compile
one of the SDL 2 sample applications to test the port.

I added the following target to the KOSMakefile.mk file:


defaultall: replacefiles $(OBJS) subdirs linklib buildsamples

TESTDRAW2_SRCS = $(CURDIR)/test/testdraw2.c
TESTDRAW2_OBJS = $(CURDIR)/test/testdraw2.o
TESTDRAW2_TARGET = testdraw2.elf

buildsamples:
    $(KOS_CC) $(CFLAGS) -Iinclude -c $(TESTDRAW2_SRCS) -o $(TESTDRAW2_OBJS)
    $(KOS_CC) $(KOS_CFLAGS) $(KOS_LDFLAGS) -L$(CURDIR) -Iinclude -o
$(TESTDRAW2_TARGET) $(KOS_START) $(TESTDRAW2_OBJS) $(KOS_LIBS) -lSDL2

No matter what incantation I use to build the source file, I still end up
with undefined references to the SDL 2 functions. e.g.

/home/lukeb/Dreamcast/kos-ports/SDL2/build/SDL2-2.0.4/test/testdraw2.o: In
function `_DrawPoints':
testdraw2.c:(.text+0x1a0): undefined reference to `_SDL_RenderGetViewport'
testdraw2.c:(.text+0x1b8): undefined reference to `_SDL_SetRenderDrawColor'
testdraw2.c:(.text+0x1c4): undefined reference to `_SDL_RenderDrawPoint'


Am I missing something obvious? Grepping for those functions does find them
in libSDL2.a which I'm linking to. I've tried changing the order of the GCC
args, and also tried just compiling the source file directly rather than to
an object file first.

I'd appreciate any suggestions you might have!

Thanks,

Luke.

Re: [KOS] semaphore.h?

[Luke B. <ka...@gm...>]

Done! You can keep an eye on my progress here:
https://gitlab.com/Kazade/kos-ports/commits/master

On 27 January 2016 at 15:22, Luke Benstead <ka...@gm...> wrote:

> OK yeah I was hoping I could just piggy back on the pthread stuff, but
> you're right I'll code a proper backend.
>
> Thanks!
>
> On 27 January 2016 at 14:49, Lawrence Sebald <
> ljs...@us...> wrote:
>
>> POSIX semaphores are a bit different than KOS semaphores for a couple of
>> reasons. Chief amongst them is that POSIX semaphores can be used for
>> cross-process synchronization, which is obviously inapplicable in KOS as we
>> have no concept of processes. Also POSIX semaphores are often (but not
>> required to be) implemented as files in the filesystem, which is pretty
>> helpful in implementing their cross-process support.
>>
>> I’d recommend just porting the threading stuff over to KOS threads
>> wholesale if you’re porting SDL2 rather than trying to use the pthreads
>> stuff. It shouldn’t be hard to port it properly, plus then you have less
>> overhead to deal with (since the pthreads stuff just calls down to the KOS
>> stuff anyway). Also, I haven’t really been paying any attention to the
>> pthreads stuff for a while…
>>
>> - Lawrence
>>
>> > On Jan 27, 2016, at 5:14 AM, Luke Benstead <ka...@gm...> wrote:
>> >
>> > Hi,
>> >
>> > I've tentatively started porting SDL 2 to KOS - I have it successfully
>> compiling, I've just started swapping out all the generic/dummy
>> implementations of the subsystems with KOS specific ones. I've done the
>> timer backend and now I'm working on the thread backend.
>> >
>> > I noticed that the existing pthreads backend in SDL 2 would probably
>> work on KOS, but SDL looks for "semaphore.h" which apparently doesn't exist
>> in KOS, but does exist in newlib. There also seems to be a very similar
>> semaphore implementation in "kos/sem.h".
>> >
>> > Before I implement a wrapper around kos/sem.h to make the SDL 2
>> pthreads stuff compile, I just wondered if there was a reason why
>> semaphore.h isn't available in KOS by default, and would it be better if I
>> perhaps altered the semaphore.h from newlib (in a similar way to pthread.h)
>> and sent a patch to KOS?
>> >
>> > Thanks,
>> >
>> > Luke.
>> >
>> ------------------------------------------------------------------------------
>> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> > Monitor end-to-end web transactions and take corrective actions now
>> > Troubleshoot faster and improve end-user experience. Signup Now!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
>> > cadcdev-kallistios mailing list
>> > cad...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>>
>
>

Re: [KOS] semaphore.h?

[Luke B. <ka...@gm...>]

OK yeah I was hoping I could just piggy back on the pthread stuff, but
you're right I'll code a proper backend.

Thanks!

On 27 January 2016 at 14:49, Lawrence Sebald <ljs...@us...
> wrote:

> POSIX semaphores are a bit different than KOS semaphores for a couple of
> reasons. Chief amongst them is that POSIX semaphores can be used for
> cross-process synchronization, which is obviously inapplicable in KOS as we
> have no concept of processes. Also POSIX semaphores are often (but not
> required to be) implemented as files in the filesystem, which is pretty
> helpful in implementing their cross-process support.
>
> I’d recommend just porting the threading stuff over to KOS threads
> wholesale if you’re porting SDL2 rather than trying to use the pthreads
> stuff. It shouldn’t be hard to port it properly, plus then you have less
> overhead to deal with (since the pthreads stuff just calls down to the KOS
> stuff anyway). Also, I haven’t really been paying any attention to the
> pthreads stuff for a while…
>
> - Lawrence
>
> > On Jan 27, 2016, at 5:14 AM, Luke Benstead <ka...@gm...> wrote:
> >
> > Hi,
> >
> > I've tentatively started porting SDL 2 to KOS - I have it successfully
> compiling, I've just started swapping out all the generic/dummy
> implementations of the subsystems with KOS specific ones. I've done the
> timer backend and now I'm working on the thread backend.
> >
> > I noticed that the existing pthreads backend in SDL 2 would probably
> work on KOS, but SDL looks for "semaphore.h" which apparently doesn't exist
> in KOS, but does exist in newlib. There also seems to be a very similar
> semaphore implementation in "kos/sem.h".
> >
> > Before I implement a wrapper around kos/sem.h to make the SDL 2 pthreads
> stuff compile, I just wondered if there was a reason why semaphore.h isn't
> available in KOS by default, and would it be better if I perhaps altered
> the semaphore.h from newlib (in a similar way to pthread.h) and sent a
> patch to KOS?
> >
> > Thanks,
> >
> > Luke.
> >
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> > cadcdev-kallistios mailing list
> > cad...@li...
> > https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>

Re: [KOS] semaphore.h?

[Lawrence S. <ljs...@us...>]

POSIX semaphores are a bit different than KOS semaphores for a couple of reasons. Chief amongst them is that POSIX semaphores can be used for cross-process synchronization, which is obviously inapplicable in KOS as we have no concept of processes. Also POSIX semaphores are often (but not required to be) implemented as files in the filesystem, which is pretty helpful in implementing their cross-process support.

I’d recommend just porting the threading stuff over to KOS threads wholesale if you’re porting SDL2 rather than trying to use the pthreads stuff. It shouldn’t be hard to port it properly, plus then you have less overhead to deal with (since the pthreads stuff just calls down to the KOS stuff anyway). Also, I haven’t really been paying any attention to the pthreads stuff for a while…

- Lawrence

> On Jan 27, 2016, at 5:14 AM, Luke Benstead <ka...@gm...> wrote:
> 
> Hi,
> 
> I've tentatively started porting SDL 2 to KOS - I have it successfully compiling, I've just started swapping out all the generic/dummy implementations of the subsystems with KOS specific ones. I've done the timer backend and now I'm working on the thread backend.
> 
> I noticed that the existing pthreads backend in SDL 2 would probably work on KOS, but SDL looks for "semaphore.h" which apparently doesn't exist in KOS, but does exist in newlib. There also seems to be a very similar semaphore implementation in "kos/sem.h".
> 
> Before I implement a wrapper around kos/sem.h to make the SDL 2 pthreads stuff compile, I just wondered if there was a reason why semaphore.h isn't available in KOS by default, and would it be better if I perhaps altered the semaphore.h from newlib (in a similar way to pthread.h) and sent a patch to KOS?
> 
> Thanks,
> 
> Luke.
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

[KOS] semaphore.h?

[Luke B. <ka...@gm...>]

Hi,

I've tentatively started porting SDL 2 to KOS - I have it successfully
compiling, I've just started swapping out all the generic/dummy
implementations of the subsystems with KOS specific ones. I've done the
timer backend and now I'm working on the thread backend.

I noticed that the existing pthreads backend in SDL 2 would probably work
on KOS, but SDL looks for "semaphore.h" which apparently doesn't exist in
KOS, but does exist in newlib. There also seems to be a very similar
semaphore implementation in "kos/sem.h".

Before I implement a wrapper around kos/sem.h to make the SDL 2 pthreads
stuff compile, I just wondered if there was a reason why semaphore.h isn't
available in KOS by default, and would it be better if I perhaps altered
the semaphore.h from newlib (in a similar way to pthread.h) and sent a
patch to KOS?

Thanks,

Luke.

Re: [KOS] Patch needed to build with GCC 5.1.1

[Lawrence S. <ljs...@us...>]

Applied. Thanks for the patch. :)

- Lawrence

> On Jan 13, 2016, at 10:16 AM, Luke Benstead <ka...@gm...> wrote:
> 
> Hi, I've attached a patch to fix this as I've just hit it again on another machine. Thanks!
> 
> On 2 August 2015 at 16:24, Luke Benstead <ka...@gm... <mailto:ka...@gm...>> wrote:
> Yeah sorry, just the cast and the inline thing :)
> 
> You should give GitHub or GitLab a play, it makes it far easier for people to contribute if they've already got changes in their tree. Issue tracking and reviewing is much easier too than on SF.
> 
> Anyway, thanks for applying the patches, I'll upload anymore I come up with to the patch tracker. Looking at porting SDL 2 as I need it for my game engine :)
> 
> 
> On Sun, 2 Aug 2015 15:38 Lawrence Sebald <ljs...@us... <mailto:ljs...@us...>> wrote:
> With regard to the GCC related issue… In that thread you linked to from OpenWRT, is anything needed to make it compile other than the last patch (the one that has the int cast and the __gnu_inline__ stuff)? The rest of that looks extraneous to the situation at hand (at least as reported by the DragonflyBSD issue that that part of the patch was derived from). I’m just checking, since I don’t actually have any machines handy that have GCC 5.x on them (and I don’t even have GCC period on my normal dev machine — I only have Clang installed here).
> 
> As for libpng, I’ve gone ahead and applied your patch and pushed it up to the repository.
> 
> Also, with regard to GitHub  while we do have a mirror of the repository on GitHub (https://github.com/ljsebald/KallistiOS <https://github.com/ljsebald/KallistiOS> and https://github.com/ljsebald/kos-ports <https://github.com/ljsebald/kos-ports>specifically), the primary/canonical repository is on SourceForge and will stay there for the foreseeable future. The preferred way of dealing with patches is to format them exactly as you have for the libpng one and either submit them on the patches tracker on SourceForge. Generally I’ll notice them if they’re posted to the mailing list too, but the patches tracker would be the “correct” way to dispense with them. Truth be told, I’ve never dealt with pull requests on GitHub. ;-)
> 
> - Lawrence
> 
> 
>> On Aug 2, 2015, at 4:15 AM, Luke Benstead <ka...@gm... <mailto:ka...@gm...>> wrote:
>> 
> 
>> Also it appears libpng-1.6.17 has been replaced here: ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/ <ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/>
>> 
>> Now it only hosts 1.6.18, so either we need to bump the version in kos-ports, or find 1.6.17 hosted elsewhere. I've attached a patch which updates to *.18.
>> 
>> On 2 August 2015 at 08:57, Luke Benstead <ka...@gm... <mailto:ka...@gm...>> wrote:
>> Hi there!
>> 
>> I wasn't sure where bug reports for Kos are supposed to go, so I figured just emailing here might be the best thing to do.
>> 
>> I had some trouble compiling Kos on Fedora 22 which ships with GCC 5.1.1. Turns out that the openwrt project had exactly the same compilation issue and this is the patch to GCC that fixes it: https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8 <https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8>
>> 
>> After applying that to my local tree, Kos compiled successfully.
>> 
>> Luke.
>> 
>> P.S. Just as a side note, any chance of moving over to GitHub? Normally I'd just be able to send a pull request for this kind of thing, but sourceforge doesn't seem to have something similar.
>> 
> 
>> <0001-Bump-the-libpng-version-to-1.6.18.patch>------------------------------------------------------------------------------
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li... <mailto:cad...@li...>
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios <https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li... <mailto:cad...@li...>
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios <https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios>
> 
> <0001-Add-a-patch-to-allow-compiling-GCC-4.7.3-with-GCC-5.patch>------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________>
> cadcdev-kallistios mailing list
> cad...@li... <mailto:cad...@li...>
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios <https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios>

Re: [KOS] Patch needed to build with GCC 5.1.1

[Luke B. <ka...@gm...>]

Hi, I've attached a patch to fix this as I've just hit it again on another
machine. Thanks!

On 2 August 2015 at 16:24, Luke Benstead <ka...@gm...> wrote:

> Yeah sorry, just the cast and the inline thing :)
>
> You should give GitHub or GitLab a play, it makes it far easier for people
> to contribute if they've already got changes in their tree. Issue tracking
> and reviewing is much easier too than on SF.
>
> Anyway, thanks for applying the patches, I'll upload anymore I come up
> with to the patch tracker. Looking at porting SDL 2 as I need it for my
> game engine :)
>
> On Sun, 2 Aug 2015 15:38 Lawrence Sebald <ljs...@us...>
> wrote:
>
>> With regard to the GCC related issue… In that thread you linked to from
>> OpenWRT, is anything needed to make it compile other than the last patch
>> (the one that has the int cast and the __gnu_inline__ stuff)? The rest of
>> that looks extraneous to the situation at hand (at least as reported by the
>> DragonflyBSD issue that that part of the patch was derived from). I’m just
>> checking, since I don’t actually have any machines handy that have GCC 5.x
>> on them (and I don’t even have GCC period on my normal dev machine — I only
>> have Clang installed here).
>>
>> As for libpng, I’ve gone ahead and applied your patch and pushed it up to
>> the repository.
>>
>> Also, with regard to GitHub  while we do have a mirror of the repository
>> on GitHub (https://github.com/ljsebald/KallistiOS and
>> https://github.com/ljsebald/kos-ports specifically), the
>> primary/canonical repository is on SourceForge and will stay there for the
>> foreseeable future. The preferred way of dealing with patches is to format
>> them exactly as you have for the libpng one and either submit them on the
>> patches tracker on SourceForge. Generally I’ll notice them if they’re
>> posted to the mailing list too, but the patches tracker would be the
>> “correct” way to dispense with them. Truth be told, I’ve never dealt with
>> pull requests on GitHub. ;-)
>>
>> - Lawrence
>>
>> On Aug 2, 2015, at 4:15 AM, Luke Benstead <ka...@gm...> wrote:
>>
>> Also it appears libpng-1.6.17 has been replaced here:
>> ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/
>>
>> Now it only hosts 1.6.18, so either we need to bump the version in
>> kos-ports, or find 1.6.17 hosted elsewhere. I've attached a patch which
>> updates to *.18.
>>
>> On 2 August 2015 at 08:57, Luke Benstead <ka...@gm...> wrote:
>>
>>> Hi there!
>>>
>>> I wasn't sure where bug reports for Kos are supposed to go, so I figured
>>> just emailing here might be the best thing to do.
>>>
>>> I had some trouble compiling Kos on Fedora 22 which ships with GCC
>>> 5.1.1. Turns out that the openwrt project had exactly the same compilation
>>> issue and this is the patch to GCC that fixes it:
>>> https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8
>>>
>>> After applying that to my local tree, Kos compiled successfully.
>>>
>>> Luke.
>>>
>>> P.S. Just as a side note, any chance of moving over to GitHub? Normally
>>> I'd just be able to send a pull request for this kind of thing, but
>>> sourceforge doesn't seem to have something similar.
>>>
>>
>> <0001-Bump-the-libpng-version-to-1.6.18.patch>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>>
>

[KOS] Fw: important message

[<to...@fr...>]

Hello!

 

New message, please read <http://imsomemphis.us/my.php?u4>

 

to...@fr...

[KOS] BootDreams' current indefinite future

[Cyle T. <cyl...@gm...>]

Hey,

Well I'm back from 2 years of absence and some clearing mind done and I
want to get back on the project I started a few years ago writing C sources
for BootDreams... click <https://github.com/emptythought/bootdreams>.
However I only have a issue compiling anything I save to the trunk, so,
does anyone want commit access to share getting this programmed? I need
people as compilers for this at the moment, and now that I mention it
Windows, Linux and Mac would be all I want.

All I need is errors? I must get a personal computer soon maybe I'll buy a
netbook they're the apparent choice even though they're not touch screen!

I'm gonna write some stuff to get a readmbf, just another name for BIN
Checker, released but any string system to search binaries is gonna be
difficult. I'll expand more later.

>From there I'm thinking of simply diving into cdrecord and making
libpacburn however, there isn't any projects for that library yet only
archive instances of it in BootDreams... I wasn't ready. With 2 years + (in
reality 5 since the © is 2010).

- Cyle

Re: [KOS] Patch needed to build with GCC 5.1.1

[Luke B. <ka...@gm...>]

Yeah sorry, just the cast and the inline thing :)

You should give GitHub or GitLab a play, it makes it far easier for people
to contribute if they've already got changes in their tree. Issue tracking
and reviewing is much easier too than on SF.

Anyway, thanks for applying the patches, I'll upload anymore I come up with
to the patch tracker. Looking at porting SDL 2 as I need it for my game
engine :)

On Sun, 2 Aug 2015 15:38 Lawrence Sebald <ljs...@us...>
wrote:

> With regard to the GCC related issue… In that thread you linked to from
> OpenWRT, is anything needed to make it compile other than the last patch
> (the one that has the int cast and the __gnu_inline__ stuff)? The rest of
> that looks extraneous to the situation at hand (at least as reported by the
> DragonflyBSD issue that that part of the patch was derived from). I’m just
> checking, since I don’t actually have any machines handy that have GCC 5.x
> on them (and I don’t even have GCC period on my normal dev machine — I only
> have Clang installed here).
>
> As for libpng, I’ve gone ahead and applied your patch and pushed it up to
> the repository.
>
> Also, with regard to GitHub  while we do have a mirror of the repository
> on GitHub (https://github.com/ljsebald/KallistiOS and
> https://github.com/ljsebald/kos-ports specifically), the
> primary/canonical repository is on SourceForge and will stay there for the
> foreseeable future. The preferred way of dealing with patches is to format
> them exactly as you have for the libpng one and either submit them on the
> patches tracker on SourceForge. Generally I’ll notice them if they’re
> posted to the mailing list too, but the patches tracker would be the
> “correct” way to dispense with them. Truth be told, I’ve never dealt with
> pull requests on GitHub. ;-)
>
> - Lawrence
>
> On Aug 2, 2015, at 4:15 AM, Luke Benstead <ka...@gm...> wrote:
>
> Also it appears libpng-1.6.17 has been replaced here:
> ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/
>
> Now it only hosts 1.6.18, so either we need to bump the version in
> kos-ports, or find 1.6.17 hosted elsewhere. I've attached a patch which
> updates to *.18.
>
> On 2 August 2015 at 08:57, Luke Benstead <ka...@gm...> wrote:
>
>> Hi there!
>>
>> I wasn't sure where bug reports for Kos are supposed to go, so I figured
>> just emailing here might be the best thing to do.
>>
>> I had some trouble compiling Kos on Fedora 22 which ships with GCC 5.1.1.
>> Turns out that the openwrt project had exactly the same compilation issue
>> and this is the patch to GCC that fixes it:
>> https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8
>>
>> After applying that to my local tree, Kos compiled successfully.
>>
>> Luke.
>>
>> P.S. Just as a side note, any chance of moving over to GitHub? Normally
>> I'd just be able to send a pull request for this kind of thing, but
>> sourceforge doesn't seem to have something similar.
>>
>
> <0001-Bump-the-libpng-version-to-1.6.18.patch>
> ------------------------------------------------------------------------------
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>

Re: [KOS] Patch needed to build with GCC 5.1.1

[Lawrence S. <ljs...@us...>]

With regard to the GCC related issue… In that thread you linked to from OpenWRT, is anything needed to make it compile other than the last patch (the one that has the int cast and the __gnu_inline__ stuff)? The rest of that looks extraneous to the situation at hand (at least as reported by the DragonflyBSD issue that that part of the patch was derived from). I’m just checking, since I don’t actually have any machines handy that have GCC 5.x on them (and I don’t even have GCC period on my normal dev machine — I only have Clang installed here).

As for libpng, I’ve gone ahead and applied your patch and pushed it up to the repository.

Also, with regard to GitHub  while we do have a mirror of the repository on GitHub (https://github.com/ljsebald/KallistiOS and https://github.com/ljsebald/kos-ports specifically), the primary/canonical repository is on SourceForge and will stay there for the foreseeable future. The preferred way of dealing with patches is to format them exactly as you have for the libpng one and either submit them on the patches tracker on SourceForge. Generally I’ll notice them if they’re posted to the mailing list too, but the patches tracker would be the “correct” way to dispense with them. Truth be told, I’ve never dealt with pull requests on GitHub. ;-)

- Lawrence

> On Aug 2, 2015, at 4:15 AM, Luke Benstead <ka...@gm...> wrote:
> 
> Also it appears libpng-1.6.17 has been replaced here: ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/ <ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/>
> 
> Now it only hosts 1.6.18, so either we need to bump the version in kos-ports, or find 1.6.17 hosted elsewhere. I've attached a patch which updates to *.18.
> 
> On 2 August 2015 at 08:57, Luke Benstead <ka...@gm... <mailto:ka...@gm...>> wrote:
> Hi there!
> 
> I wasn't sure where bug reports for Kos are supposed to go, so I figured just emailing here might be the best thing to do.
> 
> I had some trouble compiling Kos on Fedora 22 which ships with GCC 5.1.1. Turns out that the openwrt project had exactly the same compilation issue and this is the patch to GCC that fixes it: https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8 <https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8>
> 
> After applying that to my local tree, Kos compiled successfully.
> 
> Luke.
> 
> P.S. Just as a side note, any chance of moving over to GitHub? Normally I'd just be able to send a pull request for this kind of thing, but sourceforge doesn't seem to have something similar.
> 
> <0001-Bump-the-libpng-version-to-1.6.18.patch>------------------------------------------------------------------------------
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

Re: [KOS] Patch needed to build with GCC 5.1.1

[Luke B. <ka...@gm...>]

Also it appears libpng-1.6.17 has been replaced here:
ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/

Now it only hosts 1.6.18, so either we need to bump the version in
kos-ports, or find 1.6.17 hosted elsewhere. I've attached a patch which
updates to *.18.

On 2 August 2015 at 08:57, Luke Benstead <ka...@gm...> wrote:

> Hi there!
>
> I wasn't sure where bug reports for Kos are supposed to go, so I figured
> just emailing here might be the best thing to do.
>
> I had some trouble compiling Kos on Fedora 22 which ships with GCC 5.1.1.
> Turns out that the openwrt project had exactly the same compilation issue
> and this is the patch to GCC that fixes it:
> https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8
>
> After applying that to my local tree, Kos compiled successfully.
>
> Luke.
>
> P.S. Just as a side note, any chance of moving over to GitHub? Normally
> I'd just be able to send a pull request for this kind of thing, but
> sourceforge doesn't seem to have something similar.
>

[KOS] Patch needed to build with GCC 5.1.1

[Luke B. <ka...@gm...>]

Hi there!

I wasn't sure where bug reports for Kos are supposed to go, so I figured
just emailing here might be the best thing to do.

I had some trouble compiling Kos on Fedora 22 which ships with GCC 5.1.1.
Turns out that the openwrt project had exactly the same compilation issue
and this is the patch to GCC that fixes it:
https://github.com/981213/openwrt/commit/f1a46cdab03240df27d7632a2adac509d58118e8

After applying that to my local tree, Kos compiled successfully.

Luke.

P.S. Just as a side note, any chance of moving over to GitHub? Normally I'd
just be able to send a pull request for this kind of thing, but sourceforge
doesn't seem to have something similar.

[KOS] OCRAM

[Christian G. <ko...@ya...>]

Hi,

is anybody using it? For testing I've added INIT_OCRAM to KOS_INIT_FLAGS 
in the Atari800 DC port
and put the palette values there. I didn't see a noticeable speed 
difference in the screen update.

If you are using it, can you give some first hand experience about 
better (or worse) performance when
using it?


To ease the use of the OCRAM, I've changed the linker script in Atari800 
like this:


@@ -1,3 +1,5 @@
+/* This is the same as KOS's utils/ldscripts/shlelf.xc, except that
+   it adds an "ocram" section.  */
  /* Script for -z combreloc: combine and sort reloc sections */
  OUTPUT_FORMAT("elf32-shl", "elf32-shl",
               "elf32-shl")
@@ -186,6 +188,13 @@
    . = ALIGN(32 / 8);
    . = ALIGN(32 / 8);
    _end = .; PROVIDE (end = .);
+  .ocram 0x7c001000 (NOLOAD) :
+  {
+    *(.ocram)
+    /* We have 8kb of operand cache RAM. The next line lets ld throw
+       an error if we exceed that size.  */
+    . = . > 0x2000 ? 0x2000 : .;
+  }
    /* Stabs debugging sections.  */
    .stab          0 : { *(.stab) }
    .stabstr       0 : { *(.stabstr) }


This way one can define an uninitialized variable to be in the OCRAM 
like this

int var __attribute__((section (".ocram")));

It doesn't work for initialized data as is, that would need changes in 
the startup code.

Anyone interested in this, should I commit this change?

regards,
chris

Re: [KOS] Ports tree

[Lawrence S. <ljs...@us...>]

Well, I’ll take the silence on the list to mean that everyone’s tested it and nobody’s found any problems that haven’t already been fixed. ;-)

I replaced the old kos-ports repo with the new one this evening (so now it’s mirrored on sourceforge as well as on github, but the sourceforge one should be considered the canonical repo as of now). I pushed the updates to the ghettoplay-vorbis and hello-ogg examples so that they’ll work with the new vorbis library in the kos-ports tree. The Lua example still needs to be updated. Hopefully I’ll find the time to do that in the next few days or so.

The old kos-ports repo is still available, but at a different URL now (replace kos-ports with kos-ports-old). I don’t intend to update the old repo any further, so keep that in mind if you use it for some reason.

- Lawrence

> On May 4, 2015, at 11:50 AM, Lawrence Sebald <ljs...@us...> wrote:
> 
> At least the ghettoplay-vorbis example does use liboggvorbisplay, as does the hello-ogg example (at least optionally). But, that’s beside the point, since I went ahead and updated it anyway (and split it into three separate ports in the process — libogg, libvorbis, and liboggvorbisplay). ;-)
> 
> 
> And with that, I’ve pushed out the first version of the new ports tree to a github repository, which can be found here: https://github.com/ljsebald/kos-ports <https://github.com/ljsebald/kos-ports> . I’d appreciate it if others could try it out and make sure it works on other systems than my own. You’ll need to have the KOS_PORTS environment variable pointing to the root of wherever you put the kos-ports tree in order to use it, by the way (and that should be all the setup you’ll need). This was added to the normal kos environ script the other day, by the way.
> 
> In doing this, I’ve updated a few of the ports to use the current upstream versions of their code. Specifically, zlib, libpng, libjpeg, libogg, libvorbis, SDL, Lua, and libtremor have all been updated. Testing those specifically would probably be a good idea (especially SDL, since I haven’t checked that one at all).
> 
> A few example programs will need a few updates. The ones that use liboggvorbisplay will need to be updated to link against all three of libogg, libvorbis, and liboggvorbisplay, for instance. The Lua example doesn’t compile at all now due to API differences between Lua 5.0.0 and 5.3.0.
> 
> - Lawrence
> 
>> On May 2, 2015, at 2:14 AM, Quzar <qu...@ya... <mailto:qu...@ya...>> wrote:
>> 
>> I don't recall seeing anything use liboggvorbisplay before (and I certainly haven't).
>> 
>> Glad to hear this is finally moving forward.
>> 
>> -Donald Haase
>> --------------------------------------------
>> On Fri, 5/1/15, Lawrence Sebald <ljs...@us... <mailto:ljs...@us...>> wrote:
>> 
>> Subject: [KOS] Ports tree
>> To: cad...@li... <mailto:cad...@li...>
>> Date: Friday, May 1, 2015, 10:15 PM
>> 
>> *cough* *cough* Is this thing on? Now
>> that I have your attention…
>> 
>> As some of you might know (if you’ve looked at the roadmap
>> page on the website), I’ve had this idea of having some
>> sort of package manager for the kos-ports tree for a long
>> while. Well, I’m happy to say that I’ve finally started
>> working on just such a thing.
>> 
>> Now, I’m not going for a package manager in the
>> traditional sense of apt or yum on Linux, but rather
>> something much more akin to the FreeBSD ports collection.
>> The goal of this is to make it exceptionally easy to
>> “port” new libraries to the system and have them fit
>> right in to the existing collection. Another goal here is to
>> defer to the upstream packages wherever possible, rather
>> than maintaining old crusty versions of the ports’ code in
>> our git repositories (of course, many of the things in
>> kos-ports don’t have an upstream as they were made
>> directly for KOS, but that’s beside the point).
>> 
>> At the moment, it’s nowhere near perfect (it can’t
>> handle package dependencies at the moment, and there are a
>> few hiccups with some of the ports as they stand), but I did
>> want to put it out there that I’m working on it (not that
>> I think anyone else was doing such a thing).
>> 
>> With that out of the way, I wanted to bring up the subject
>> of a few of the ports that currently exist in the kos-ports
>> tree. Specifically, there’s two that I’m pretty sure
>> I’m going to get rid of and one that I’m considering
>> doing away with.
>> 
>> In the first category there, I’d like to get rid of libs3m
>> and lwIP entirely from the kos-ports tree. libs3m doesn’t
>> look like it’s worked in a long while (the code that
>> actually gets turned into libs3m looks like it’s just a
>> broken/old version of the snd_sfx_* code), so I don’t
>> really think there’s going to be any objection there.
>> lwIP, I’d like to get rid of because it has been
>> completely superseded by the internal network stack. I know
>> there are still a few performance related issues in the
>> internal stack, but keeping lwIP around doesn’t really
>> change that. So, if there aren’t any objections, I’m
>> going to just do away with those two ports as I continue
>> working on the new port manager. They’ll both continue to
>> exist in the Git repositories they already have set up on
>> the sourceforge page, I’m just planning on essentially
>> acting like they don’t exist from now on. ;-)
>> 
>> In the second category, I was wondering if anyone uses
>> liboggvorbisplay over libtremor these days? libtremor has
>> kinda been the “suggested” Vorbis library in KOS for a
>> while, so I’m just wondering if it’s even worthwhile to
>> keep liboggvorbisplay around. Any comments from anyone on
>> that subject?
>> 
>> I’ve rambled enough at this point, so I’ll cut this off
>> here for now. Hopefully, I’ll have more good news on the
>> new port management stuff very soon. :)
>> 
>> - Lawrence
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across
>> Physical-Virtual-Cloud 
>> Widest out-of-the-box monitoring support with 50+
>> applications
>> Performance metrics, stats and reports that give you
>> Actionable Insights
>> Deep dive visibility with transaction tracing using APM
>> Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y>
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li... <mailto:cad...@li...>
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios <https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios>
>> 
>> 
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud 
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y>
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
> 

Re: [KOS] Ports tree

[Lawrence S. <ljs...@us...>]

At least the ghettoplay-vorbis example does use liboggvorbisplay, as does the hello-ogg example (at least optionally). But, that’s beside the point, since I went ahead and updated it anyway (and split it into three separate ports in the process — libogg, libvorbis, and liboggvorbisplay). ;-)


And with that, I’ve pushed out the first version of the new ports tree to a github repository, which can be found here: https://github.com/ljsebald/kos-ports <https://github.com/ljsebald/kos-ports> . I’d appreciate it if others could try it out and make sure it works on other systems than my own. You’ll need to have the KOS_PORTS environment variable pointing to the root of wherever you put the kos-ports tree in order to use it, by the way (and that should be all the setup you’ll need). This was added to the normal kos environ script the other day, by the way.

In doing this, I’ve updated a few of the ports to use the current upstream versions of their code. Specifically, zlib, libpng, libjpeg, libogg, libvorbis, SDL, Lua, and libtremor have all been updated. Testing those specifically would probably be a good idea (especially SDL, since I haven’t checked that one at all).

A few example programs will need a few updates. The ones that use liboggvorbisplay will need to be updated to link against all three of libogg, libvorbis, and liboggvorbisplay, for instance. The Lua example doesn’t compile at all now due to API differences between Lua 5.0.0 and 5.3.0.

- Lawrence

> On May 2, 2015, at 2:14 AM, Quzar <qu...@ya...> wrote:
> 
> I don't recall seeing anything use liboggvorbisplay before (and I certainly haven't).
> 
> Glad to hear this is finally moving forward.
> 
> -Donald Haase
> --------------------------------------------
> On Fri, 5/1/15, Lawrence Sebald <ljs...@us...> wrote:
> 
> Subject: [KOS] Ports tree
> To: cad...@li...
> Date: Friday, May 1, 2015, 10:15 PM
> 
> *cough* *cough* Is this thing on? Now
> that I have your attention…
> 
> As some of you might know (if you’ve looked at the roadmap
> page on the website), I’ve had this idea of having some
> sort of package manager for the kos-ports tree for a long
> while. Well, I’m happy to say that I’ve finally started
> working on just such a thing.
> 
> Now, I’m not going for a package manager in the
> traditional sense of apt or yum on Linux, but rather
> something much more akin to the FreeBSD ports collection.
> The goal of this is to make it exceptionally easy to
> “port” new libraries to the system and have them fit
> right in to the existing collection. Another goal here is to
> defer to the upstream packages wherever possible, rather
> than maintaining old crusty versions of the ports’ code in
> our git repositories (of course, many of the things in
> kos-ports don’t have an upstream as they were made
> directly for KOS, but that’s beside the point).
> 
> At the moment, it’s nowhere near perfect (it can’t
> handle package dependencies at the moment, and there are a
> few hiccups with some of the ports as they stand), but I did
> want to put it out there that I’m working on it (not that
> I think anyone else was doing such a thing).
> 
> With that out of the way, I wanted to bring up the subject
> of a few of the ports that currently exist in the kos-ports
> tree. Specifically, there’s two that I’m pretty sure
> I’m going to get rid of and one that I’m considering
> doing away with.
> 
> In the first category there, I’d like to get rid of libs3m
> and lwIP entirely from the kos-ports tree. libs3m doesn’t
> look like it’s worked in a long while (the code that
> actually gets turned into libs3m looks like it’s just a
> broken/old version of the snd_sfx_* code), so I don’t
> really think there’s going to be any objection there.
> lwIP, I’d like to get rid of because it has been
> completely superseded by the internal network stack. I know
> there are still a few performance related issues in the
> internal stack, but keeping lwIP around doesn’t really
> change that. So, if there aren’t any objections, I’m
> going to just do away with those two ports as I continue
> working on the new port manager. They’ll both continue to
> exist in the Git repositories they already have set up on
> the sourceforge page, I’m just planning on essentially
> acting like they don’t exist from now on. ;-)
> 
> In the second category, I was wondering if anyone uses
> liboggvorbisplay over libtremor these days? libtremor has
> kinda been the “suggested” Vorbis library in KOS for a
> while, so I’m just wondering if it’s even worthwhile to
> keep liboggvorbisplay around. Any comments from anyone on
> that subject?
> 
> I’ve rambled enough at this point, so I’ll cut this off
> here for now. Hopefully, I’ll have more good news on the
> new port management stuff very soon. :)
> 
> - Lawrence
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across
> Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+
> applications
> Performance metrics, stats and reports that give you
> Actionable Insights
> Deep dive visibility with transaction tracing using APM
> Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

Re: [KOS] Ports tree

[Quzar <qu...@ya...>]

I don't recall seeing anything use liboggvorbisplay before (and I certainly haven't).

Glad to hear this is finally moving forward.

-Donald Haase
--------------------------------------------
On Fri, 5/1/15, Lawrence Sebald <ljs...@us...> wrote:

 Subject: [KOS] Ports tree
 To: cad...@li...
 Date: Friday, May 1, 2015, 10:15 PM
 
 *cough* *cough* Is this thing on? Now
 that I have your attention…
 
 As some of you might know (if you’ve looked at the roadmap
 page on the website), I’ve had this idea of having some
 sort of package manager for the kos-ports tree for a long
 while. Well, I’m happy to say that I’ve finally started
 working on just such a thing.
 
 Now, I’m not going for a package manager in the
 traditional sense of apt or yum on Linux, but rather
 something much more akin to the FreeBSD ports collection.
 The goal of this is to make it exceptionally easy to
 “port” new libraries to the system and have them fit
 right in to the existing collection. Another goal here is to
 defer to the upstream packages wherever possible, rather
 than maintaining old crusty versions of the ports’ code in
 our git repositories (of course, many of the things in
 kos-ports don’t have an upstream as they were made
 directly for KOS, but that’s beside the point).
 
 At the moment, it’s nowhere near perfect (it can’t
 handle package dependencies at the moment, and there are a
 few hiccups with some of the ports as they stand), but I did
 want to put it out there that I’m working on it (not that
 I think anyone else was doing such a thing).
 
 With that out of the way, I wanted to bring up the subject
 of a few of the ports that currently exist in the kos-ports
 tree. Specifically, there’s two that I’m pretty sure
 I’m going to get rid of and one that I’m considering
 doing away with.
 
 In the first category there, I’d like to get rid of libs3m
 and lwIP entirely from the kos-ports tree. libs3m doesn’t
 look like it’s worked in a long while (the code that
 actually gets turned into libs3m looks like it’s just a
 broken/old version of the snd_sfx_* code), so I don’t
 really think there’s going to be any objection there.
 lwIP, I’d like to get rid of because it has been
 completely superseded by the internal network stack. I know
 there are still a few performance related issues in the
 internal stack, but keeping lwIP around doesn’t really
 change that. So, if there aren’t any objections, I’m
 going to just do away with those two ports as I continue
 working on the new port manager. They’ll both continue to
 exist in the Git repositories they already have set up on
 the sourceforge page, I’m just planning on essentially
 acting like they don’t exist from now on. ;-)
 
 In the second category, I was wondering if anyone uses
 liboggvorbisplay over libtremor these days? libtremor has
 kinda been the “suggested” Vorbis library in KOS for a
 while, so I’m just wondering if it’s even worthwhile to
 keep liboggvorbisplay around. Any comments from anyone on
 that subject?
 
 I’ve rambled enough at this point, so I’ll cut this off
 here for now. Hopefully, I’ll have more good news on the
 new port management stuff very soon. :)
 
 - Lawrence
 ------------------------------------------------------------------------------
 One dashboard for servers and applications across
 Physical-Virtual-Cloud 
 Widest out-of-the-box monitoring support with 50+
 applications
 Performance metrics, stats and reports that give you
 Actionable Insights
 Deep dive visibility with transaction tracing using APM
 Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 _______________________________________________
 cadcdev-kallistios mailing list
 cad...@li...
 https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
 

[KOS] Ports tree

[Lawrence S. <ljs...@us...>]

*cough* *cough* Is this thing on? Now that I have your attention…

As some of you might know (if you’ve looked at the roadmap page on the website), I’ve had this idea of having some sort of package manager for the kos-ports tree for a long while. Well, I’m happy to say that I’ve finally started working on just such a thing.

Now, I’m not going for a package manager in the traditional sense of apt or yum on Linux, but rather something much more akin to the FreeBSD ports collection. The goal of this is to make it exceptionally easy to “port” new libraries to the system and have them fit right in to the existing collection. Another goal here is to defer to the upstream packages wherever possible, rather than maintaining old crusty versions of the ports’ code in our git repositories (of course, many of the things in kos-ports don’t have an upstream as they were made directly for KOS, but that’s beside the point).

At the moment, it’s nowhere near perfect (it can’t handle package dependencies at the moment, and there are a few hiccups with some of the ports as they stand), but I did want to put it out there that I’m working on it (not that I think anyone else was doing such a thing).

With that out of the way, I wanted to bring up the subject of a few of the ports that currently exist in the kos-ports tree. Specifically, there’s two that I’m pretty sure I’m going to get rid of and one that I’m considering doing away with.

In the first category there, I’d like to get rid of libs3m and lwIP entirely from the kos-ports tree. libs3m doesn’t look like it’s worked in a long while (the code that actually gets turned into libs3m looks like it’s just a broken/old version of the snd_sfx_* code), so I don’t really think there’s going to be any objection there. lwIP, I’d like to get rid of because it has been completely superseded by the internal network stack. I know there are still a few performance related issues in the internal stack, but keeping lwIP around doesn’t really change that. So, if there aren’t any objections, I’m going to just do away with those two ports as I continue working on the new port manager. They’ll both continue to exist in the Git repositories they already have set up on the sourceforge page, I’m just planning on essentially acting like they don’t exist from now on. ;-)

In the second category, I was wondering if anyone uses liboggvorbisplay over libtremor these days? libtremor has kinda been the “suggested” Vorbis library in KOS for a while, so I’m just wondering if it’s even worthwhile to keep liboggvorbisplay around. Any comments from anyone on that subject?

I’ve rambled enough at this point, so I’ll cut this off here for now. Hopefully, I’ll have more good news on the new port management stuff very soon. :)

- Lawrence

Re: [KOS] keyboard

[Lawrence S. <ljs...@us...>]

I don’t see why restoring the old behavior would be a bad idea, so that all sounds good to me. Feel free to fix it up as you see fit. :)

- Lawrence

> On Apr 12, 2015, at 5:54 PM, Christian Groessler <ko...@ya...> wrote:
> 
> Hi,
> 
> when I connected a German keybaord it gave me just scancodes in the high 
> byte.
> 
> Looking at kernel/arch/dreamcast/hardware/maple/keyboard.c I see that 
> only Japanese and
> US keyboards are supported. All other keyboards just return scancodes.
> 
> I propose the following change for unsupported keyboards to let them at 
> least appear as
> an US keyboard. I think that's better than returning scancodes for keys 
> which were previously
> (in older KOS versions) returned as ASCII.
> 
> 
> --------------------
> --- a/kernel/arch/dreamcast/hardware/maple/keyboard.c
> +++ b/kernel/arch/dreamcast/hardware/maple/keyboard.c
> @@ -354,6 +354,10 @@ static int kbd_attach(maple_driver_t *drv, 
> maple_device_t *dev) {
>      else
>          state->region = dev->info.function_data[d] & 0xFF;
> 
> +    if (state->region > KBD_NUM_KEYMAPS)
> +        /* Punt #2. */
> +        state->region = KBD_REGION_US;
> +
>      /* Make sure all the queue variables are set up properly... */
>      state->queue_tail = state->queue_head = state->queue_len = 0;
> 
> --------------------
> 
> 
> And, I want to support German keyboards. They identify as region #4.
> The 'keymaps' array in kernel/arch/dreamcast/hardware/maple/keyboard.c 
> just has entries
> for (regions) #1 and #2. I don't know what region #3 is. I'd add it as 
> just zeroes, and add
> a check in above patch to map it to an US keyboard,
> 
> What do you think?
> 
> regards,
> chris
> 
> 
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

[KOS] keyboard

[Christian G. <ko...@ya...>]

Hi,

when I connected a German keybaord it gave me just scancodes in the high 
byte.

Looking at kernel/arch/dreamcast/hardware/maple/keyboard.c I see that 
only Japanese and
US keyboards are supported. All other keyboards just return scancodes.

I propose the following change for unsupported keyboards to let them at 
least appear as
an US keyboard. I think that's better than returning scancodes for keys 
which were previously
(in older KOS versions) returned as ASCII.


--------------------
--- a/kernel/arch/dreamcast/hardware/maple/keyboard.c
+++ b/kernel/arch/dreamcast/hardware/maple/keyboard.c
@@ -354,6 +354,10 @@ static int kbd_attach(maple_driver_t *drv, 
maple_device_t *dev) {
      else
          state->region = dev->info.function_data[d] & 0xFF;

+    if (state->region > KBD_NUM_KEYMAPS)
+        /* Punt #2. */
+        state->region = KBD_REGION_US;
+
      /* Make sure all the queue variables are set up properly... */
      state->queue_tail = state->queue_head = state->queue_len = 0;

--------------------


And, I want to support German keyboards. They identify as region #4.
The 'keymaps' array in kernel/arch/dreamcast/hardware/maple/keyboard.c 
just has entries
for (regions) #1 and #2. I don't know what region #3 is. I'd add it as 
just zeroes, and add
a check in above patch to map it to an US keyboard,

What do you think?

regards,
chris

Re: [KOS] just waving

[Potter <ba...@al...>]

Oh cool... I'd love to look at some of this new stuff. It's too bad it's such a pain to go dig up one of my Dreamcasts and hook it up somewhere. ^^; I think I know where they are, but the only thing I have left to hook them up to is a projector that's currently without audio. My dcload CDs are somewhere else, and there's no ethernet out there. I know, I've fallen far... :S

I'd be tempted to play with KOS again, but I've got some other projects (and life things) holding my attention right now. Among other things, I'm working on moving to Canada (looking for jobs now). I don't suppose anyone knows an employer in Vancouver or Toronto looking for people? Eheh :)


On 2014 Jun 28, at 7:23 PM, Lawrence Sebald wrote:

> Actually… Speaking of burritro, Indiket over at DCEmulation recently up-ported it to a more current version of KOS: http://dcemulation.org/phpBB/viewtopic.php?p=1043598#p1043598 .
> 
> Kinda neat to see people working to preserve older pieces of code like that (and even add somewhat useful things to them, like a 50/60hz selector menu for PAL consoles — which looks like it was borrowed from one of my projects ;-)).
> 
> On Jun 27, 2014, at 2:44 PM, Potter <ba...@al...> wrote:
> 
>> Nice! I always wished there were more demos on the Dreamcast. That was part of my pre-Dreamcast background (thus Reverie) so it always makes me smile. :) Seeing the ADK banner on there makes me think of the Burritro, too, which sadly doesn't seem to have much of a presence online.
>> 
>> On 2014 Jun 26, at 7:50 AM, Julian Brown wrote:
>> 
>>> Hi!
>>> 
>>> Re: lurking & DC development and so forth, I put a little thing together
>>> last weekend for a demo party in the UK...
>>> 
>>> http://www.pouet.net/prod.php?which=63617
>>> 
>>> The actual "Dreamcast" part was only about a weekend's worth of
>>> hacking, so it's nothing to get too excited about :-). Anyway, it
>>> was nice to find that all the tools still work and are even under
>>> active(-ish?) development!
>>> 
>>> Jules
>>> 
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> cadcdev-kallistios mailing list
>>> cad...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
>> 
>> 
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

Re: [KOS] just waving

[Lawrence S. <ljs...@us...>]

Actually… Speaking of burritro, Indiket over at DCEmulation recently up-ported it to a more current version of KOS: http://dcemulation.org/phpBB/viewtopic.php?p=1043598#p1043598 .

Kinda neat to see people working to preserve older pieces of code like that (and even add somewhat useful things to them, like a 50/60hz selector menu for PAL consoles — which looks like it was borrowed from one of my projects ;-)).

On Jun 27, 2014, at 2:44 PM, Potter <ba...@al...> wrote:

> Nice! I always wished there were more demos on the Dreamcast. That was part of my pre-Dreamcast background (thus Reverie) so it always makes me smile. :) Seeing the ADK banner on there makes me think of the Burritro, too, which sadly doesn't seem to have much of a presence online.
> 
> On 2014 Jun 26, at 7:50 AM, Julian Brown wrote:
> 
>> Hi!
>> 
>> Re: lurking & DC development and so forth, I put a little thing together
>> last weekend for a demo party in the UK...
>> 
>> http://www.pouet.net/prod.php?which=63617
>> 
>> The actual "Dreamcast" part was only about a weekend's worth of
>> hacking, so it's nothing to get too excited about :-). Anyway, it
>> was nice to find that all the tools still work and are even under
>> active(-ish?) development!
>> 
>> Jules
>> 
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> cadcdev-kallistios mailing list
>> cad...@li...
>> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

Re: [KOS] just waving

[Potter <ba...@al...>]

Nice! I always wished there were more demos on the Dreamcast. That was part of my pre-Dreamcast background (thus Reverie) so it always makes me smile. :) Seeing the ADK banner on there makes me think of the Burritro, too, which sadly doesn't seem to have much of a presence online.

On 2014 Jun 26, at 7:50 AM, Julian Brown wrote:

> Hi!
> 
> Re: lurking & DC development and so forth, I put a little thing together
> last weekend for a demo party in the UK...
> 
> http://www.pouet.net/prod.php?which=63617
> 
> The actual "Dreamcast" part was only about a weekend's worth of
> hacking, so it's nothing to get too excited about :-). Anyway, it
> was nice to find that all the tools still work and are even under
> active(-ish?) development!
> 
> Jules
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> cadcdev-kallistios mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-kallistios

Re: [KOS] just waving

[Julian B. <ju...@pa...>]

Hi!

Re: lurking & DC development and so forth, I put a little thing together
last weekend for a demo party in the UK...

http://www.pouet.net/prod.php?which=63617

The actual "Dreamcast" part was only about a weekend's worth of
hacking, so it's nothing to get too excited about :-). Anyway, it
was nice to find that all the tools still work and are even under
active(-ish?) development!

Jules

Re: [KOS] Just waving

[Oleg E. <ole...@t-...>]

On Sat, 2014-06-21 at 14:27 -0700, Potter wrote:
> Good to hear from you all. :)
> 
> Is there anywhere left out there? :D Or are we the last bastion of
> Dreamcast civilization? It seems like all the other sites I've checked
> have either been abandoned or turned to other topics. (Even the CA
> games forum... shame, that.) Even RedSpot seems to have moved on to Wii
> and Xbox downloadable games.

A while ago I had some spare time and ideas and wanted to do something.
I realized that GCC would generate "not so good" code for SH.  I've
ended up working on GCC's SH backend.  Some improvements have been made
in GCC 4.8 and 4.9, but there are still open issues which are
unfortunately not so easy to solve.  One day hopefully it will output
'42'.

Cheers,
Oleg