MegaPak template available

[+karri]

The MegaPak vol1 hints at the possibility to continue its line of homebrews by vol2 at some time in the future. To make that part a bit easier for developers I have created a MegaPak Template and s set of MegaPak U3 developer tools.

 

The requirements are an U3 compatible USB memory stick for installing the tools. And a computer running Windows.

 

This template creates a MegaPak cart with a menu launcher, background music, user adjustable settings and eeprom support. It has just one game on it called Mygame that does about nothing.

 

So if you are interested in creating good submissions for the vol2 then download the tools and start working.

 

There are tools for C and asm based work available in the U3 toolkit.

 

--

Regards,

 

Karri

[luke.trevorrow]

Okay, so I have downloaded the tools and am raring to go. I notice in other posts that you mention a developer cart that you designed: Do you have the schematics anywhere? Is it easy to make a cartridge to load a game onto which others can use?

 

Thanks for any help.

[gallenza]

Hello,

 

This is my first post.

I'm a french lover of the Lynx and free software.

So Karri, I would like to compile the MegaPak Template, but it needs the binary sprpck in a Linux version, that you don't give in your MegaPak U3 developer tools contrary to lyxass.

And I have problem to compil it from the sources of Bastian.

How do you do that ?

Aren't you programming under Linux ?

[+karri]

Hello,

 

This is my first post.

I'm a french lover of the Lynx and free software.

So Karri, I would like to compile the MegaPak Template, but it needs the binary sprpck in a Linux version, that you don't give in your MegaPak U3 developer tools contrary to lyxass.

And I have problem to compil it from the sources of Bastian.

How do you do that ?

Aren't you programming under Linux ?

 

I program mostly in Linux today. The sprpck sources are part of the BLL kit. I include it here.

 

--

Regards,

 

Karri

SPRPCK.zip

Edited December 16, 2008 by karri

[+karri]

The previous sprpck had only the file itself. Here is also tha Makefiles and a compiled executable on Linux.

sprpck.zip

 

--

Karri

[gallenza]

Thanks Karri for your speed answer, but your file seems to be a 1.0 version and the one I try to compile is the latest Bastian version 1.97 which is on its website.

http://www.geocities.com/SiliconValley/Byt.../download/lynx/

 

Do you really use the version 1.0 ? That's ok ?

[gallenza]

ok so the problem of the version 1.97 is 4 lines of code with depreciated syntax in io.c :

 

w3 = *((USHORT *)pByte2)++;

w2 = *((USHORT *)pByte2)++;

w1 = *((USHORT *)pByte2)++;

w0 = *((USHORT *)pByte2)++;

 

gcc4 says :

 

io.c:535: error: invalid lvalue in increment

io.c:536: error: invalid lvalue in increment

io.c:537: error: invalid lvalue in increment

io.c:538: error: invalid lvalue in increment

make: *** [io.o] Error 1

 

but gcc3.4 is ok with warning :

 

io.c:535: warning: use of cast expressions as lvalues is deprecated

io.c:536: warning: use of cast expressions as lvalues is deprecated

io.c:537: warning: use of cast expressions as lvalues is deprecated

io.c:538: warning: use of cast expressions as lvalues is deprecated

 

So my solution is to compile with gcc3.4 ^...I'm too much afraid to break a code I don't understand,

[+karri]

ok so the problem of the version 1.97 is 4 lines of code with depreciated syntax in io.c :

 

w3 = *((USHORT *)pByte2)++;

w2 = *((USHORT *)pByte2)++;

w1 = *((USHORT *)pByte2)++;

w0 = *((USHORT *)pByte2)++;

 

Interesting piece of code .

 

I understand perfectly well why it does not compile. Modern compilers cannot accept the implicite type conversion in that code. Rewriting it like

 

w3 = *((USHORT *)pByte2);

pByte2 += 2;

w2 = *((USHORT *)pByte2));

pByte2 += 2;

...

 

tells the computer what it is all about.

 

--

Karri

[gallenza]

hello Karri,

 

I hadn't view your second post !

I'm jalous : you have a version 1.98 ! Where do you take it ?

 

However the little compilation problem is still here.

 

If somebody fix it, where can he submit or commit the patch?

[gallenza]

ok so the problem of the version 1.97 is 4 lines of code with depreciated syntax in io.c :

 

w3 = *((USHORT *)pByte2)++;

w2 = *((USHORT *)pByte2)++;

w1 = *((USHORT *)pByte2)++;

w0 = *((USHORT *)pByte2)++;

 

Interesting piece of code .

 

I understand perfectly well why it does not compile. Modern compilers cannot accept the implicite type conversion in that code. Rewriting it like

 

w3 = *((USHORT *)pByte2);

pByte2 += 2;

w2 = *((USHORT *)pByte2));

pByte2 += 2;

...

 

tells the computer what it is all about.

 

--

Karri

 

Thanks a lot.

[+karri]

hello Karri,

 

I hadn't view your second post !

I'm jalous : you have a version 1.98 ! Where do you take it ?

 

However the little compilation problem is still here.

 

If somebody fix it, where can he submit or commit the patch?

 

No idea. Exceed used this version of sprpck in MegaPak so it just came to me that way. Perhaps 42Bastian keeps the version numbers up-to-date?

 

Actually I would like to have a "free" version of it that could be included in the cc65 libraries for the Lynx target. Then the sprpck would automatically be included with the compiler tools.

 

--

Karri

[gallenza]

This is the license in te readme.1st of the BLL kit :

 

"""

Title: BLL-ReadMe

Version: 1.0

Date: 1996/12/22

Maintainer: Bastian Schick (42bastian@epost.de)

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

1.) Copyright

I have the copyright on every part of this Development Kit (Dev.Kit) for

the Atari Lynx (1).

 

This Dev.Kit maybe copied but only the complete archive without any

modification !

 

It is not permitted :

- to put it on a BBS.

- to sell it on public domain/shareware compiliation or something

similar.

- to put it on a Web-Page.

- to put it on a ftp-server.

 

If you want it to, you'll need my permission (letter).

 

Any software written with the help of this Dev.Kit should name either

the kit:

'Dev.Kit....BLL'

or

'Dev.Kit by Lars Baumstark (hardware) and Bastian Schick (Software).'

or something similar.

"""

 

It's clearly non RMS-free

 

I would package all this stuff for Debian, because I think easier the toolchain will be to setup, biggest the number of devs could be.

The actual license is a dead-end... but Karri it seems to me you have integrated BLL code to cc65 and have shared it. Have you a special agreement from Bastian ? If yes, is it possible for him to release all under a free licence (GPL is the best for me, but a MIT/BSD could be fine to !!) ?

[+karri]

The actual license is a dead-end... but Karri it seems to me you have integrated BLL code to cc65 and have shared it. Have you a special agreement from Bastian ? If yes, is it possible for him to release all under a free licence (GPL is the best for me, but a MIT/BSD could be fine to !!) ?

 

I have permissions for a few things. Harry Dodgson wrote me a free encrypted loader and Sage has made a free modified loader for other block sizes. I also got 42Bastians blessings for the initialisation code in the cc65 library and I wrote some missing parts together with a few other developers (Shawn Jefferson, Carl Forhan etc...).

 

I also got permission to use parts of the newcc65 compiler like eeprom support code. But fortunately most of the needed stuff was already in the cc65 compiler and I wrote the rest like joystick, conio, graphics from scratch. Later people like Harry Dodgson gave me better algorithms so there is a very large community who has contributed to this.

 

But the BLL kit is not part of the cc65 tools. And because of these limitations the sprpck binary, the lyxass and bll is missing from the standard cc65 distribution.

 

Useful extensions to "free" lynx tools would be a free sprpck, a free ComLynx suite, a free cart access library and a free music and sound effects player. Any takers?

 

42Bastian has also written a BLL macro interface that could be run on top of the ra65 assembler. This allows me to compiler lyxass and bll code using the cc65 tools. So I really don't see a point in using bll at all. Sprpck is another story, we need a "free" version of that.

--

Karri

[gallenza]

I have permissions for a few things.

[...]

I also got 42Bastians blessings for the initialisation code in the cc65 library

[...]

I also got permission to use parts of the newcc65 compiler like eeprom support code.

Why 42Bastian couldn't bless you for sprpck ?

42Bastian has also written a BLL macro interface that could be run on top of the ra65 assembler. This allows me to compiler lyxass and bll code using the cc65 tools.

That's fine !

[+karri]

I have permissions for a few things.

[...]

I also got 42Bastians blessings for the initialisation code in the cc65 library

[...]

I also got permission to use parts of the newcc65 compiler like eeprom support code.

Why 42Bastian couldn't bless you for sprpck ?

42Bastian has also written a BLL macro interface that could be run on top of the ra65 assembler. This allows me to compiler lyxass and bll code using the cc65 tools.

That's fine !

 

I have never asked 42Bastian about the rights to sprpck

 

So far 42Bastian has said "yes" to everything I have asked from him.

 

--

Karri

[gallenza]

I know I'm really new to the community to want change things ^^, but if Bastian is open minded about changing license, we should ask him to do it.

[+karri]

I know I'm really new to the community to want change things ^^, but if Bastian is open minded about changing license, we should ask him to do it.

 

There is actually another problem too.

 

Usually you want some kind of quality on the code you want to make open source. Sprpck is more like a quick hack. It is not really up to the coding standards. So it needs to be tidied up a lot before you can submit it to the cc65 guys. As it is today I doubt that it would be accepted.

 

--

Karri

[gallenza]

Karri, I heard it so many times and I strongly disagree. In my company, "cleaning the code" is the perfect way to never open source. If you open source, maybe the code will be clean a day, and you are sure it's useful to somebody.

 

You are finnish ^^, so Linux was a hack, maybe a ugly hack, BUT it was free, you know what it is now !

 

Sprpck is not a hack, it's the only one version, for ever.

With no change since 10 years, it is used for doing a job it's the only one to do, and it do it well.

 

In more, Sprpck IS open source, we all have the code, but it is not free, so we can't really use it.

It's really damage.

 

So, you know Bastian and have a good relationship with him, you are one of the 3 best active programmer for Lynx, if you could tell him something like "There's a crazy french on AtariAge who would like a release of Sprpck under a free license, and I think it could be useful", you'll make me so happy, and maybe a lot of people more free.

[gallenza]

Hello Karri,

 

I understand ASM and Python, but not C :-(

Tell me if I'm wrong :

pByte2 is counting the number of bytes, wd are USHORT so 16 bits so 2 bytes.

But how do you know in w3 = *((USHORT *)pByte2)++; which one is done in first between affection and iteration?

In fact I'have compiled sprpck with your modifications and it works fine, but what can I do ? Where can I submit this correction to help people to compile under Linux ? Have you news from Bastian ?

 

Your MegaPakTemplate is really a wonderful piece of work. But I haven't found any reference to a license, so I don't know if I can use it.

I think a lot of homebrew will be done if more people could know how easy it is to integrate its work to a real cartridge.

[semicolo]

no, pByte2 is a byte pointer. this code reads the 4 words starting at the address stored in pByte2.

iteration is done after affectation because the ++ is at the end, in c you can do ++i (pre-increment) or i++ (post-increment)

[gallenza]

no, pByte2 is a byte pointer. this code reads the 4 words starting at the address stored in pByte2.

iteration is done after affectation because the ++ is at the end, in c you can do ++i (pre-increment) or i++ (post-increment)

Thanks a lot...so I really don't understand C