Help with porting Arduboy core?

[NML32]

I am using a samsung 128GB card that has been working for everything else. I do not have the IO board and only the 32 MB of sdram, does that have anything to do with it?

I only have the bare DE10-Nano, so IO board / SDRAM won't be it...

Hrm... jca / NML32 - what size cards are you using? Maybe Sorgelig will have some insight, or be able to refactor / tighten up what I've done?

Thanks for trying!

I'm loading my games from my NAS and my MiSTer has a 128 meg RAM chip.

[uXe]

Ok so I tried all 4 of the test games, loaded the hex, reset, waited 40-60 seconds, still just flashing colors.

...not sure it would make any difference, but have you run the MiSTer update script recently?

[trashuncle]

Ok so I tried all 4 of the test games, loaded the hex, reset, waited 40-60 seconds, still just flashing colors.

...not sure it would make any difference, but have you run the MiSTer update script recently?

I am up to date, ran the updater yesterday. (I run it a few times a week, if there have been updates)

[Sorgelig]

sd_* signals aren't directly connected to SD card. It's just interface to transfer data between HPS and FPGA. Data transfer within block (512bytes) is always the same regardless SD card speed. Pause between blocks may depend on SD card speed.

[uXe]

Pause between blocks may depend on SD card speed.

This is likely where the problem is then - my code only worked after a lot of trial and error, so it must be flawed for SD cards outside of a certain tolerance for timing between blocks? (Disclaimer: I'm not an engineer - just a nerd who taught myself some Verilog! )

I did try adding some extra code including a condition to wait through sd_ack when crossing the 512 byte boundary between blocks, but this made it stop working for me... it is all there on the GitHub repo, maybe some fresh eyes on the problem can help stabilise this part of the core??

[trashuncle]

(I'm not an engineer - just a nerd who taught myself some Verilog! )

From the videos that were posted and the reports of it working for others, I would say you are doing just fine!

I don't have any other SD cards at the moment to test, but I might have access to a 64GB one here soon that I can do a test mister setup on with just the latest mister and your core.

Thanks for all your work!

[jca]

I am using a samsung 128GB card that has been working for everything else. I do not have the IO board and only the 32 MB of sdram, does that have anything to do with it?

I only have the bare DE10-Nano, so IO board / SDRAM won't be it...

Hrm... jca / NML32 - what size cards are you using? Maybe Sorgelig will have some insight, or be able to refactor / tighten up what I've done?

Thanks for trying!

The SD card I am using is a 64GB Sandisk Extreme.
I also tried to put the Boot.vhd in the Arduboy directory. Now when I start the core and after the flashing colors I get some white squares and rectangles on screen and that's it. Never the less I can still load files and run them.
What is the use of this boot.vhd?

[jca]

I forgot: I also made a screenshot of the screen after boot.vhd started. Here it is.

[uXe]

What is the use of this boot.vhd?

boot.vhd is just the default demo sketch - renamed to boot.vhd so it will be automatically mounted at startup, if you Reset the core at startup before attaching any HEX files you'll see it!

[NML32]

Aren't saves stored in the VHD?

[uXe]

I've added an empty block of 512 bytes to the start of each .HEX for the non-volatile EEPROM storage (also added an end-of-file marker (0x1A) to the end of the .HEX files). So when you select Mount *.HEX, you are basically mounting a separate VHD (virtual hard disk) for each game, with 'saves' stored at < 512 bytes and the compiled program stored at > 512 bytes... not a perfect system admittedly - you could for example end up with saves associated with the wrong .HEX if you mounted a different one while playing a game and then saved to it?

[uXe]

Ok so I tried all 4 of the test games, loaded the hex, reset, waited 40-60 seconds, still just flashing colors.

...might be worth another try now with the latest release files? I've tweaked / improved the code a little, and also padded out the HEX files a little (seems like the first couple of 512 byte blocks can sometimes be slower to load at first when mounting a new HEX file, or when first starting the core - so added an extra empty block there to let it catch up...)

[trashuncle]

I updated to all the new files from your gihub page. I also have the most recent MiSTer updates. Now all I get when I boot up the core is an unsupported video mode (over HDMI, tried using match display frequency and low latency.)

[uXe]

Well that's weird.

Will try some different screens and see if I can recreate the same result...

[trashuncle]

Well that's weird.

Will try some different screens and see if I can recreate the same result...

I can try with a different monitor later, just haven't had a chance.

[NML32]

Nice progress!!
I like the bootup screen.

https://youtu.be/ZAkwKNkJhAE

Thank you for the updates.

[jca]

No luck with the new version (previous one worked perfectly). On startup the core crashes MISTer and I have to power cycle the board, I don't even get the flashing colors any longer. I even renamed boot.vhd to demo.hex to be sure that the core was not trying to load anything.
I do not think the problem is with the core but more likely to the fact that I have a 32M Windbond chip: on some jotego arcades I get messed up sprites and with the Popeye core I get the same crash as with the Arduboy.
Which memory board are you using? Can anyone with the 32M Winbond chip test it?

[uXe]

Weirdness... I am not using SDRAM at all, so am not sure why that would cause a crash. Sorgelig - any reason you can think of that having an SDRAM board plugged in might cause issues reading from SD card? ...are the signals related in any way??

I have uploaded a new Arduboy.rbf file that may help, added in an extra condition to also wait for RESET in addition to status[0] before accessing the SD card - I am just kind of guessing at this point though!

[jca]

Sorry for my misleading assumption, now I think it is totally unrelated to the SDRAM.
You shouldn't rush to make a new core:
The previous version was working as it should.
The version which crashes on me does not seem to crash for other testers.
There does not look like many users are testing this core so my problem is not very significant.

Recently I saw on the forum some posts regarding some strange problems and one recommendation was to re-FTP the core (or whatever) to MISTer and it seems to fix these problems.
I use FTP set to binary transfer so it is not a problem of binary vs text but I will reinstall the core by removing the SD card and make a direct copy.
I also want to re-download the core in case of bad download. Is it in the _Arduboy folder?
I will test it this evening and post the results.

[jca]

I made some progress but now I am really confused.
This morning I was short in time and saw the 2 folders Arduboy and _Arduboy but did not have time to look into them. At lunch time I had enough time to do it and one contains the HEX files, the other the rbf.
I am not sure if the rbf is the one I had problems with or the modified one. I downloaded it and now everything is working.
BUT !!! On the download page the core seemed much bigger than the one I had. The problem core was 66KB, the downloaded one 2.6MB.
It looks like the download was bad. I doubled checked the troublesome Popeye core which I downloaded around the same time and same thing happened the core was smaller.
I cannot understand why I got 2 bad downloads as it never happened before and I did not get any error when downloading.
I suppose the problem core was good but now I have no way to test it.
You should append the date to your core and leave the previous ones in the release folder.
Lesson learned: if a core crashes on you but no one is complaining you should double check that the download is good.

[DrOG]

Download is sometimes problematic on GitHub if you use the 'Download' button. Try 'View Raw' instead, it's more reliable. This issue was discussed earlier in another topic:
http://www.atari-forum.com/viewtopic.ph ... 35#p388735

[Sorgelig]

@uXe:
i don't know if you will be interested, but there is another arduino-based awesome project called Gameduino. I'm talking about first version with sprite engine when it was based on FPGA. It has very advanced graphics engine - better than NES, probably even better than Genesis. I was thinking to port it some time ago, but was busy by other projects.
Probably gameduino can be coupled with your Risc-V core. Since you already have some integration with Ardiono IDE, it could be an addition to what you have.

[uXe]

Gameduino could be awesome, yeah - will definitely look into it!

Funny that you should mention it, because I am in the middle of porting a game from the very similarly named (but much less powerful) Gamebuino handheld...

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!

[uXe]

You should append the date to your core and leave the previous ones in the release folder.
Lesson learned: if a core crashes on you but no one is complaining you should double check that the download is good.

Will try and remember to date the releases from now on - thanks again for helping out! [smilie=greencolorz4_pdt_12.gif]

[trashuncle]

I believe this core is working for me now. I need to switch over to HDMI instead of VGA, but I think I had the wrong files downloaded. Sometimes github likes to save the html instead of the raw file (could be chrome or my own stupidity)

EDIT: IT IS! I am finally greeted to a game screen (just tested Super Crate Buino!)

I do have some questions about your hex files as opposed to the standard Arudboy hex files. I noticed yours have null data and different formatting. Why the need for this? If this was explained earlier in the thread, I apologize.

There is quite a decent size library of games and demos to try out, but I suspect they are incompatible without conversion. What would I need to do to convert other games into this format?