Help with porting Arduboy core?

[Sorgelig]

I've pushed the video changes.

[uXe]

Excellent - have posted a new release, thanks again for all that you do!

[BitsNStuff]

That's good to see, it's working brilliantly in Horizontal mode now for the dozen or so games that I've just tried.

[PikWik]

@uXe

thank you so much for the work youve done putting this together, i keep finding fun little timekillers to play and the arduboy definitely has a certain "charm" to it


loading hex files makes things so much easier as well, and it would be great to have a full repo of all the games available that gets updated automatically (but im fine with manually adding too)

is there a possibility to correct the vsync issues over HDMI, or is that something that is just not possible?
is the only route to get tear-free arduboy gaming playing over VGA??

[uXe]

I am using only HDMI and have not had any issues - not sure what is going on there? maybe specific to the screen you are using??

[PikWik]

it could be my HDTV, but i can say that this is the only core that i notice the screen tearing with.
i have used the SNES, NES, Neo Geo, and Genesis core, and none of them have screen tearing.

as a note, i did try different vsync modes (low lag, match core frequency, match TV frequency) and got the same kind of screen tearing, running in 1920x1080 60hz NTSC.
its particular games that exhibit it the most (the default game 'arduventure' is a good example of a game that has the tearing - walking around the houses and outside, there is a horizontal line/screen tearing).
but if the game is stationary/one screen (box stacker) there is no screen tearing.

i will do more testing and report back if i find a fix for what's going on

[Sorgelig]

Did people forgot how to read? Why need to come back with tearing when it was already answered in couple pages before??

[PikWik]

Did people forgot how to read? Why need to come back with tearing when it was already answered in couple pages before??

ahh, my question was acknowledging what you had said about the arduboy core and how it disregards vsync, yes.
my question was more of a followup and a question to the developer to see if something could be done/coded to fix the tearing.
he mentioned that it may be my TV, and that is a possibility. however, this is the only core ive tried that has screen tearing (comparing to SNES, NES, Genesis, & Neo Geo)

and also, i would see people saying its "working perfectly" and assume they also meant tear-free.
so my question now would be "who else is experiencing screen tearing on the arduboy with the game arduventure, over HDMI?"

[Sorgelig]

small OLED and LCD displays have no refresh rates. Pixels are directly accessible at any time. Software doesn't wait for sync as nothing to wait for. So there is no way to make it tear free.
Only if Arduboy will introduce the HW with vsync and games will start to wait for vsync, then it can be implemented in the core and it will be tear-free then.

[Sorgelig]

Seeing the latest tweaks in display commands i've decided to look in datasheet of display and discovered many commands not implemented in the core.

[uXe]

Correct, but most games never use the OLED commands (outside of the startup initialisation command sequence to make the screen work, which is not necessary in our case), the few commands already implemented are the rare exceptions.

However, it would be fantastic to have all of the OLED commands properly implemented, and would make that code very useful outside of the core as an OLED emulator (it is not something I can make time to do to myself at the moment though). But you are going to have a hard time finding any games that would make any use of them, unless you write a game to do it yourself...

[Sorgelig]

I'm not going to implement it anyway
I see OLED has scroll commands which potentially could be useful for games, but it seems they are useless as there is no way to know the scroll status.

[reflex]

I'm not going to implement it anyway
I see OLED has scroll commands which potentially could be useful for games, but it seems they are useless as there is no way to know the scroll status.

Just curious if screen tearing would occur if you happen to have an OLED tv or not. I do have one, but I have no idea if there is a layer that makes it conform to expectations of HDMI connections for VSYNC and so on. I'm guessing yes, but haven't tried it (and personally don't have much interest in this core but just a sense of curiosity).

[Sorgelig]

Just curious if screen tearing would occur if you happen to have an OLED tv or not. I do have one, but I have no idea if there is a layer that makes it conform to expectations of HDMI connections for VSYNC and so on. I'm guessing yes, but haven't tried it (and personally don't have much interest in this core but just a sense of curiosity).

Normal OLED panels follow TV/Monitor standards, so they have hsync/vsync and other traditional signals. So it doesn't matter what kind of TV you use.

[reflex]

Just curious if screen tearing would occur if you happen to have an OLED tv or not. I do have one, but I have no idea if there is a layer that makes it conform to expectations of HDMI connections for VSYNC and so on. I'm guessing yes, but haven't tried it (and personally don't have much interest in this core but just a sense of curiosity).

Normal OLED panels follow TV/Monitor standards, so they have hsync/vsync and other traditional signals. So it doesn't matter what kind of TV you use.

That makes sense. This discussion made me curious because stuttering of 24p content (especially panning shots) ceased when I went OLED, my assumption is it's not so much gone as OLED pixels just switch much more quickly so it's less detectable.

[senkun]

I've pushed the video changes.

Excellent - have posted a new release, thanks again for all that you do!

Fantastic. Thank you both!

[uXe]

Lots of updates to the Arduboy core recently - MorgothCreator has done a lot of re-factoring of his AVR core, and these changes have meant a lot more playable games added to the collection that previously didn't work! I've also recently added in paddle support ('cause who doesn't love paddles?! ) the option to enable it is under 'ADC' in the F12 menu, just toggle it over to 'AnalogStick' and you can get a proportional analog input to the core mapped from the analog joystick X-axis... a couple of good sketches to try out the paddle implementation are:

https://github.com/uXeBoy/ArduboyCollec ... n?raw=true
https://github.com/uXeBoy/ArduboyCollec ... n?raw=true

(PS. by default the ADC is just getting random values - which is useful because a lot of games use the ADC input as a random seed)

[Sorgelig]

I think in updated AVR core something is misused. Arduboy again is compiling very long time. It should be something with clocks use.

[uXe]

That would be this little piece of code in the RAM implementation. I was trying to have the memory-mapped AVR registers automatically cleared on every reset, to squash some bugs. But should be fine to just edit those lines out and cut back down on the compilation time (that part of RAM doesn't actually get written to anyway with ram_sel and the way it is implemented right now).

[Sorgelig]

for (clear_cnt = 0; clear_cnt < 256; clear_cnt = clear_cnt + 1)

oops.. that's gross!
Verilog is not a C this "for" block with 256 cycles will be cloned to 256 copies. "for" is not really verilog instruction, it's pre-processor instruction.
More over, the part of RAM implementing these 256 cells will be converted to registers - large amount of LEs, not BRAM.

If you need to clear the part of memory, then you have to make a state machine in always block which will cycle through all 256 addresses one by one. Probably some signal have to pause the core till clear is finished.

[Sorgelig]

I've pushed the fix.

Also i think using XILINX flag is too exaggerated. Checking this flag should imply some REALLY specific to Xilinx features absent in other FPGAs. Currently i see in mega_ram.v it checks for XILINX to generate *generic* inferred RAM. This is not right way to code, from my opinion. It make code more obfuscated without a reason. For example in mega_ram.v it's better to remove PLATFORM = "XILINX" parameter completely. Inferred RAM should work fine in all FPGAs.
For a better portability without much complexity i suggest to split AVR code to 2 sets of modules: first set will be architecture independent, and second one will be architecture depended. For example ram implementation and that strange pll handling modules can be placed to second set. Then porting to other FPGA will need simply to change (not always) the modules in second set.
As for specific Intel vs Xilinx implementation for AVR, i don't see anything which should be different. AVR can be written fully without checking Xilinx or Intel.

I even would write the way when required clocks/ram/rom signals would be a port of top level. Then specific project will provide the clocks and memory according to specific FPGA implementation, so AVR core will be fully independent from specific implementations.

[Sorgelig]

Btw, Arduboy3D doesn't work anymore. The last release where this game works is 0313.

[uXe]

Btw, Arduboy3D doesn't work anymore. The last release where this game works is 0313.

Yes, some of the changes in MorgothCreator's core that made a lot more games start working seem to have also made a few other games stop working! He has been developing a debug module to try and investigate closer... in the meantime I recompiled Arduboy3D using a slightly different sound implementation, and that modified version does work:

https://github.com/uXeBoy/ArduboyCollec ... n?raw=true

Have made a new release with your improvements, thanks!

Looking here though, does having reg [15:0] reset_cnt = 0; inside the always block not mean it will be reset to zero on every clock? I'm just not used to seeing initialisations inside the 'always', but then again I mostly only know what I've learned through trial-and-error!

Code: Select all

// make reset at least 65K cycles long.
reg reset = 1;
always @(posedge clk_avr) begin
    reg [15:0] reset_cnt = 0;

    reset <= 0;
    if(~&reset_cnt) begin
        reset_cnt <= reset_cnt + 1'd1;
        reset <= 1;
    end

    if(status[0] | buttons[1] | RESET | ioctl_download) reset_cnt <= 0;
end

[uXe]

Almost forgot - yes, all of those PLATFORM definitions are a hangover from the original AVR core, the only place I see it actually being used now is in mega-reg.v, so have deleted all of the others...

[Sorgelig]

Looking here though, does having reg [15:0] reset_cnt = 0; inside the always block not mean it will be reset to zero on every clock? I'm just not used to seeing initialisations inside the 'always', but then again I mostly only know what I've learned through trial-and-error!

Unlike traditional languages for sequential execution, the HDL has no such things as local variables (pre-processor or function variables aren't counted), so all variables(registers) are global. Thus it doesn't matter if reg [15:0] reset_cnt = 0; is written outside always or inside.
The difference is only visibility. Variable declared inside always is visible only for this always block. I often use this way to control the visibility. Also same name can be used inside other always block and they won't be collided.