Emulating hex files containing ASF = Breach of ASF license?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ASF license says that all redistributions/modifications may only be used in Atmel's processors. Does this mean that if I emulate on an Android device or on my PC a video game that has the ASF code breach the ASF license? If yes, that means that for this project I may not use ASF. I would like to have an exception in the license because I'm working on a game console (again) and I wouldn't want to get discouraged (again) by all this legal stuff. The exception should allow all my games containing ASF code to be used on other platforms by using emulators.

 

P.S. Hello, everybody. I've decided to come back and dive into the microcontroller battle like I used to one year ago. My friend Albert Gajšak made a game console MAKERbuino which is based on Gamebuino, went to conventions, hosted education classes, won a Kickstarter campaign and gave me some inspiration to try something with that XMEGA that I've left in the dust after thinking that I'll never find the proper hardware for a decent game's framerate. I thought to myself what if I made XMEGA great again by doing something similar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:

The ASF license says that all redistributions/modifications may only be used in Atmel's processors. Does this mean that if I emulate on an Android device or on my PC a video game that has the ASF code breach the ASF license? If yes, that means that for this project I may not use ASF. I would like to have an exception in the license because I'm working on a game console (again) and I wouldn't want to get discouraged (again) by all this legal stuff. The exception should allow all my games containing ASF code to be used on other platforms by using emulators.

Emulation (especially on PCs/Android) would be a separate distinct case, and I'd say is fine.

If you 'zoom-out' to understand why the clause is there, by saying  "may only be used in Atmel's processors" they mean "may not be used on Brand XYZ microcontrollers", which also translates to if some other MCU company is seeing your significant dollars  and not Atmel, that's enough to unleash the lawyers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about emulation on a microcontroller? I'm not sure if Raspberry Pi's SoC counts as a Brand XYZ microcontroller. There's an emulator for Raspberry Pi that emulates all kinds of consoles and I wouldn't want mine to be excluded.

 

And if I would like to let people be able to port their games to other microcontrollers, should I make a wrapper class that wraps around the ASF code so that it's easier to isolate my engine from the ASF code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:

What about emulation on a microcontroller? I'm not sure if Raspberry Pi's SoC counts as a Brand XYZ microcontroller. There's an emulator for Raspberry Pi that emulates all kinds of consoles and I wouldn't want mine to be excluded.

That's a MPU & is running under Linux, so is probably still ok, but if it starts to appear to middle managers that Atmel is losing MCU sales, that's when I'd become more careful.

Anything that advances the Atmel/AVR brand, (without running on an alternative microcontroller) is likely to help their sales.

 

Foxcat385 wrote:

And if I would like to let people be able to port their games to other microcontrollers, should I make a wrapper class that wraps around the ASF code so that it's easier to isolate my engine from the ASF code?

 

Seems worthwhile to be able to replace it, if needed later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's no use asking legal questions here - you need to take that up with Atmel.

My take is the sale of atmel silicon finances the ASF work, thus if no atmel silicon is involved then it is not kosher. Simple solution - don't use ASF.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Opinions, here, carry no weight. Nobody here is a licensing attorney, and, if there were, they would charge you big dollars for an opinion. But, even after such an opinion, the only thing that really counts is the Atmel/Microchip legal department, and, after that, the courts.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright, I won't use ASF. Does anyone of you know an alternative to ASF's SD card interface, USART ring buffer, USB HID drivers and bootloader stuff? It should be for XMEGA.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ring buffers should be pretty much processor independent. Dean Camera (search: Four Walled Cubicle) has a USB access library called LUFA (which I think became the foundation for USB in ASF) which I think is available to use. Dean also did, I think, a ring buffer. For SD card access, try Elm Chan FatFS library. I think that the latter takes a few tweaks for XMega, but there have been postings about that, in this forum.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:
ASF's SD card interface
FatFs (best possible solution anyway!)

Foxcat385 wrote:
USART ring buffer
Dean Camera's "Lightweight Ring Buffer"

Foxcat385 wrote:
USB HID drivers and bootloader stuff? It should be for XMEGA
LUFA is an alternative to ASF but note that Dean says Xmega and UC3 support in LUFA is "experimental" - so it may not be as solid as LUFA support for AT90USB.

 

EDIT: OK so it seems Jim and I are pretty much in agreement in all that!

Last Edited: Thu. Apr 6, 2017 - 03:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do not miss to inspect and evaluate the license terms for each of these suggestions. E.g LUFA requires "attribution" (or a fee to get out of that) for commercial projects.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:

The ASF license says that all redistributions/modifications may only be used in Atmel's processors.

 

I think the question is already answered, but this is my take...

 

The purpose of Atmel* is to sell Atmel chips. The purpose of the ASF restriction is to make life hard for people who want to clone Atmel chips. A clone could be made by copying the die, or by emulating with a different CPU (not very practical but possible). Maybe there is a $0.50 Cortex-A8 that could emulate an XMEGA, I could sell that instead of buying real Atmel chips.

 

If your emulator is purely for development/debug, or your emulator runs on a chip bought from Atmel, then I think Atmel would not mind, but if the end-product supplied to the user is not bought from Atmel, that is exactly the case Atmel wish to prevent.

 

* For Atmel, substitute Microchip, same thing applies.

 

I've tried asking legal questions through our distributor when they were still Atmel , but I didn't get a useful response. Perhaps Microchip are more responsive. If you are intending to ever put something into production, it is simply best to avoid the whole issue from the start. Handling a lawsuit or being forced into a rewrite later down the line would be a real hassle. Of course, companies tend not to bother suing if you have no money. But as soon as you get a chunk of money from sales or investment, then that is when you get hit.

 

You can build a commercial product with Open Source components, but you still need to read the license carefully. A lot depends on whether you intended to publish all your source code or want to keep it private. To be certain to avoid legal issues, either write from scratch or seek formal legal agreements with those concerned. As a programmer and not a lawyer, I prefer the former approach.  :)

Bob.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forget the legal questions. What can ASF possibly have that you can't do better with your own implementation?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Forget the legal questions. What can ASF possibly have that you can't do better with your own implementation?

  1. 32-bit pointers allowing to access all data spaces (Data, Flash, EEPROM, Device Signature, etc.). Maybe I could make a template pointer for that in C++.
  2. Use my game console as an ISP/PDI programmator, USB keyboard, USB joystick, share the SD card access with the game's engine while it's open in Windows Explorer. All that stuff is done by ASF.
  3. Malloc/new/free/delete with heap that's across 64kB of SRAM and uses 32-bit pointers.

IAR probably has all of this.

 

The only luck I have here is this XMEGA A1U Xplained Pro with an Embedded Debugger chip so that I don't have to rely on the buggy Simulator and I can directly debug the whole XMEGA. I guess I could do the 32-bit pointer thing I've been ranting about few years ago.

I won't be able to make these USB things because I'm not sure how USB works. I don't know how HID devices work either.

But I could write my own malloc/new/free/delete if I somehow found a way to change the C++ runtime. But wherever I went to find code for how to do that, I'd end up looking at copyleft code. I need something copycenter that I can use with no strings attached. If malloc.h is written in the C book from 1978, it should be free (not as in speech, but as in no strings attached).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) __memx pointers cater for 23 bits in RAM and flash. That is an 8MB range in each. Do you really need pointers to cater for outside that range on an Xmega?
.
2) but you were talking about "emulating" this AVR code on (presumably) non-AVR hardware? You aren't going to emulate USB or SPI to SD/MMC surely? For those you are presumably talking about running AVR code on AVR silicon? As that represents a silicon sale for Microchip why do you think their license agreement might preclude such use?
.
3) again you could easily implement a mallocator using __memx that would cater for 8MB. Do you really need a heap larger than that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) I had compiler errors with __memx and __flashx. Are those fixed? It's been a while since I've last programmed my XMEGA. These errors are the reason why I moved to BASCOM-AVR to finish my final high school project as Atmel Studio and its avr-gcc couldn't help me.

 

2) I'd let people without the console emulate their games on any device at any time completely legally which includes any microcontroller owned by any company. I might emulate USB and SD probably. Gamebuino fans would really like to have SD card emulation possible on their emulators. But the main thing is running the games' hex files on the one and only ATXMEGA128A1U because it's my favorite 8-bit microcontroller of all!yes. The problem with licensing is when someone'll try to run the games with ASF code on another microcontroller. I want to say that emulation of my console's games is by itself defaultly legal and that for a specific game it depends on the license chosen by the emulated game's developer (freeware/shareware). How will it be legal if ASF prevents emulation on other devices? What about simulating in the Atmel Studio Simulator?

 

3) My heap should be completely in the external RAM and in the range reserved by the SRAM. According to what I've heard of so far, it's possible to have a 22-bit address bus if you use ports H,J,K,F as ports 0,1,2,3 and then an unknown pin on port E as said in this post: https://www.avrfreaks.net/comment.... If I use a display, it might be possible to have max 1MB for RAM and 1MB of address space for the following: I'll have an 8-bit parallel display on the EBI bus so that I can DMA framebuffers and scanline buffers and bitmaps and etc. to the screen and also stream videos from the SD card such as game cutscenes or have a queue with commands and pixels for the display so that during the VBlank the whole queue is activated and popped and the image blitted to the screen's buffer while the screen is not refreshing. Because of this, I'd need a FIFO, but that's its own topic.