Help with porting Arduboy core?

[uXe]

I sort of cover this in the README.md on the GitHub releases folder:

The .HEX files as produced by the Arduino IDE have been modified for use with the core, an empty block of 512 bytes is added to the start and used for non-volatile EEPROM storage, and an end-of-file marker (0x1A) is added to the end.

(Note: this is not a 1:1 FPGA based emulation of the ATmega32U4 microcontroller used in the Arduboy - at this stage it is more a 'simulation' of an Arduboy, using a RISC-V 'soft' microcontroller and a modified version of the Arduboy libraries to re-compile games for this platform... so, existing pre-compiled Arduboy .HEX files are not going to run on this right now! But the majority of Arduboy games are open-source anyway, so it is not a big deal to make any necessary adjustments to the code and then re-compile a compatible .HEX file.)

Long story short - I was already familiar with the Arduboy libraries, so for me the most rewarding path was to take the FPGArduino RISC-V core, port it to MiSTer, and adapt the Arduboy C++ code to fit it... which means games need to be recompiled using the modified libraries - a different path would be to take something like this AVR core for example as a starting point:

https://github.com/freecores/avr_core

and adapt it, and build upon it, and have it emulate every possible register and instruction of the ATmega32U4 until you have shaped it to fit around already pre-compiled Arduboy HEX files without having to modify them at all...

Also - Sorgelig, maybe adding this core to the official MiSTer repo (so it downloads automatically during updates) would help alleviate a lot of the issues / pain users seem to be having right now because of the need to download the files manually off GitHub?

PS. ...VIDEO!

[trashuncle]

Thanks for the explanation. I believe this wouldn't be added to the main updater /repository until it is more complete? Will you need to recompile the entire arduboy library or do you think a better process will come about?

[uXe]

Have just uploaded Super-Crate-Buino.ino.HEX (still unfinished - need to work on sound) and a new Arduboy.rbf file - instructions for the game are here:

http://legacy.gamebuino.com/forum/viewt ... =17&t=3151

PS. Hold UP and press DOWN for a weapons cheat!

Added in the sounds now - new Super-Crate-Buino.ino.HEX and Arduboy.rbf files uploaded to GitHub!

(PS. scores are saved, and scores unlock the higher levels - resetting the core gets you back to the title screen to try higher levels once they are unlocked...)

[uXe]

Good news - have found a brilliant collaborator, Iulian Gheorghiu - author of XMEGA-CORE:

https://opencores.org/projects/attiny_atmega_xmega_core

...and we are slowly, surely, experimentally working our way towards eventually having full compatibility with the pre-compiled Arduboy .HEX files! [smilie=greencolorz4_pdt_01.gif]

[NML32]

Good news - have found a brilliant collaborator, Iulian Gheorghiu - author of XMEGA-CORE:

https://opencores.org/projects/attiny_atmega_xmega_core

...and we are slowly, surely, experimentally working our way towards eventually having full compatibility with the pre-compiled Arduboy .HEX files! [smilie=greencolorz4_pdt_01.gif]

Thank you, this is great news.

[trashuncle]

Awesome!!! Can't wait for the updates

[uXe]

Would it be easy to convert arduventure?

...continuing to work on the XMEGA branch of the repo (using MorgothCreator's ATmega core), we can now run Arduventure with sound! https://github.com/uXeBoy/Arduboy_MiSTe ... f?raw=true (still need to re-implement loading hex files from SD, and saving EEPROM to SD, so for right now EEPROM will be lost when the core is closed and it is limited to the one pre-injected game...)

[uXe]

OK, the new ATmega32U4 compatible release is now available!

Hopefully now the core can be made 'MiSTer official' and get some more visibility / improvements from others?

https://github.com/uXeBoy/Arduboy_MiSTe ... f?raw=true

A collection of .bin files converted and tested so far can be found here (you can hit the green 'Clone or download' button as pictured, and then 'Download ZIP' to get them all at once if you like):

https://github.com/uXeBoy/ArduboyCollection

Download.png

MorgothCreator also has donate links on his page for the atmega core for those who are so inclined:

https://github.com/MorgothCreator/atmeg ... -soft-core

...if you experience any glitches then a warm reset from the OSD, or a cold reset of MiSTer should sort it!

[NML32]

Great job!!
Thank you to everyone involved in bringing this core to MiSTer.

[Sorgelig]

wow!
Finally someone made open source AVR core!

Hopefully now the core can be made 'MiSTer official' and get some more visibility / improvements from others?

i've sent invitation to MiSTer-devel. After accepting you can create the repository there.

[kublai]

Thanks very much your hard work on adding another new core to Mister.

[uXe]

...you're welcome

OK, repo is up!

https://github.com/MiSTer-devel/Arduboy_MiSTer

...the 'sys' folder probably needs an update - I'm not certain where to find the latest version? (the one there now I had just borrowed from the PET2001 repo back at the beginning of this thread as was suggested)

[Sorgelig]

You can take latest sys in recently released (by me) cores. Currently it's SNES, NES.

[BitsNStuff]

@uXe Out of interest, do you know if you'll be attempting to incorprorate the Arcade versions of the Arduboy at some point? I'm not actually sure how different thehardware is, well, apart from the fact that they obviously include a colour screen.

[Sorgelig]

I think, the next step is to support HEX files loading directly. You can add either another atmega core for conversion on the fly, or other cores like Z80, ZPU, etc for this task.

[Sorgelig]

@uXe Out of interest, do you know if you'll be attempting to incorprorate the Arcade versions of the Arduboy at some point? I'm not actually sure how different thehardware is, well, apart from the fact that they obviously include a colour screen.

Micro Arcade looks fishy.. unlike generic Arduboy HW these Micro-Arcades are per-game offers. Hardcoded games without ability to change. Otherwise why they have to offer different "versions" even as a packs of 3-4 while being universal it should allow to load any game.

[BitsNStuff]

@uXe Out of interest, do you know if you'll be attempting to incorprorate the Arcade versions of the Arduboy at some point? I'm not actually sure how different thehardware is, well, apart from the fact that they obviously include a colour screen.

Micro Arcade looks fishy.. unlike generic Arduboy HW these Micro-Arcades are per-game offers. Hardcoded games without ability to change. Otherwise why they have to offer different "versions" even as a packs of 3-4 while being universal it should allow to load any game.

Yeah, that's what I was expecting to be honest. Obviously the standard version is open source but the licensed versions are unlikely to be due to whatever licensing restrictions have been put in place by the owners. It's a nice little core without the licensed games and without the colur anyway,

[uXe]

I think, the next step is to support HEX files loading directly. You can add either another atmega core for conversion on the fly, or other cores like Z80, ZPU, etc for this task.

Easiest way to support HEX would be to have the HPS do the conversion from HEX to BIN on-the-fly and send the data over the ioctl signals as normal? Otherwise you are double-handling the data, sending it once from HPS to FPGA, and then again processing and sending the same data a second time between two virtual CPUs?

First issue on the to do list that needs resolving though is around the Timers / sound... as noted on MorgothCreator's repo:

https://github.com/MorgothCreator/atmeg ... -soft-core

Observed some issues with TIM3 on 'arduboy-rtl-emulator' project, so is needed to
"Fix situations where on random times at core reset the TIM3 prescaller is setup at
wrong value ( at /64 instead of /8 core clock )" need to check in what situation
this issue is manifesting.

We haven't been able to puzzle this out yet, but sometimes (not everytime!) the pitch of the sound comes out much lower / slower than it should... a reset usually quickly resolves this, but it is weird / annoying that this bug can not be consistently recreated

[Sorgelig]

Easiest way to support HEX would be to have the HPS do the conversion from HEX to BIN on-the-fly and send the data over the ioctl signals as normal? Otherwise you are double-handling the data, sending it once from HPS to FPGA, and then again processing and sending the same data a second time between two virtual CPUs?

Special support on HPS side is only for special cases when doing it in FPGA is impossible or hard. Otherwise core-specific handling should be done in FPGA. Arduboy core is quite small and doesn't consume much resources. There are still many resources available on FPGA to add converter there and make the core self-containing.

[uXe]

Fair enough

Speaking of those available resources - I was thinking that using the rotate screen Arcade functionality might be a handy addition? There are some games that would benefit from being able to rotate the view - 1943 and the '3in1' games are a good example!

[Newsdee]

Would this core have code that can help with Gameduino?

I don't know how good are the games for it, though. Arduboy was a neat little physical device (I have one) so that makes it more fun to code for.

[PikWik]

anyone else getting some screen tearing with arduboy core?
ive run latest update script, and when i go to play arduboy, there is screen tearing which is distracting.

is there something im missing to get this core running without any screen tearing?
maybe a video mode or custom vsync needed for the core??

***EDIT*** - http://www.atari-forum.com/viewtopic.php?f=117&t=35169 "Custom Video Modes"

it looks like a custom video mode will be needed to make the arduboy 2:1 (128x64) aspect ratio behave properly with my modern HDTV. custom video modes are kind of over my head at the moment, so i will have to do more research on this, and hopefully get back to this thread with a video mode fix for this screen tearing

(adding something like this to the bottom of the mister.ini will set a custom video mode, for only the arduboy core)

[arduboy]
video_mode=???, ??, ??, ??, ??, ??, ??, ??, ???

[Sorgelig]

it looks like a custom video mode will be needed to make the arduboy 2:1 (124x68) aspect ratio behave properly with my modern HDTV.

MiSTer treats all HDMI resolutions as resolutions with square pixels. So it's absolutely doesn't matter which resolution you will use. Arduboy will always have 2:1 aspect ratio with either vertical or horizontal bars depending on HDMI resolution.

OLED screen has no refresh rate. Well, at least there is no way from AVR point of view to know the vsync AFAIK.
So basically there is no way to simulate this screen on TV fully. TV uses refresh, OLED - no. Software can change the pixels at any time and it will be visible on OLED while TV needs sync to refresh to avoid the tearing.

[Sorgelig]

Fair enough

Speaking of those available resources - I was thinking that using the rotate screen Arcade functionality might be a handy addition? There are some games that would benefit from being able to rotate the view - 1943 and the '3in1' games are a good example!

I was thinking about screen rotation, but as far as i know Arduboy uses only horizontal mode - otherwise it's hard to hold it in hands and play. 1943 for Arduboy is horizontal shooter unlike on arcade/console.

[PikWik]

MiSTer treats all HDMI resolutions as resolutions with square pixels. So it's absolutely doesn't matter which resolution you will use. Arduboy will always have 2:1 aspect ratio with either vertical or horizontal bars depending on HDMI resolution.

OLED screen has no refresh rate. Well, at least there is no way from AVR point of view to know the vsync AFAIK.
So basically there is no way to simulate this screen on TV fully. TV uses refresh, OLED - no. Software can change the pixels at any time and it will be visible on OLED while TV needs sync to refresh to avoid the tearing.

ahh, i see.
so the custom video mode would only be needed for displaying any of the cores to my HDTV, and would not matter for the arduboy core. the arduboy core would not make use of a TV's vsync setting, as it does not use a refresh rate on the actual hardware to display an image.

well, thank you for the explanation and help, i do appreciate your reply!