Latest commits (Ultibo core 1.3.327)

Releases, updates and announcements from the Ultibo team.
pik33
Posts: 608
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Latest commits (Ultibo core 1.3.327)

Postby pik33 » Mon Jun 05, 2017 6:18 am

About game coding: let's code one. :) I am now cleaning the mess with GUI/player stuff, at the end of this process the player code will be placed in one unit, the windows related code in another and the retromachine graphic primitives in another. The retromachine gives 2-screen drawing engine; it is 8-bit palletted, but it can be easily enhanced to 16- and 24-bit color depth which is planned and not difficult.

We also have a 6502 (the fragments of code can be ported from Atari8/C64 and then executed here) and a SID (all kind of music and sound effects)

The feature request for Ultibo: joystick/gamepad driver :)

Until then, we have kbd and mouse to control the game.

So, I think we can start a new topic about Ultibo game programming :) and start to play.

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

Returning to the topic: I have already tested kbd and mouse in the university environment. They both work - the hub is now disconnected, no more cable mess on the desktop.
Gavinmc42
Posts: 1053
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Latest commits (Ultibo core 1.3.327)

Postby Gavinmc42 » Mon Jun 05, 2017 7:40 am

So, I think we can start a new topic about Ultibo game programming :) and start to play.

At your suggestion
viewtopic.php?f=15&t=631

hmm QEMU version first, er need to figure out keyboard, mine does not seem to work in latest release QEMU.
Text Editor example, no keyboard, time to read up on QEMU.
Multi player online games in QEMU?
User avatar
Ultibo
Site Admin
Posts: 1549
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Latest commits (Ultibo core 1.3.327)

Postby Ultibo » Mon Jun 05, 2017 9:57 am

Gavinmc42 wrote:I have been getting a Zero to work with USB booting just the bootload.bin, start.elf, kernel.bin.
it left me to wonder what is fixup.dat used for?

Be very careful about making (and repeating) assumptions without understanding the full details.

Gavinmc42 wrote:Only needed if you use more than 16MB for GPU?

Nonsense!


The VideoCore IV firmware (start.elf) is an ELF file (Executable and Linkable Format), these have relocation data included in them so they can be loaded at any address and memory and then all memory references adjusted using the fixup data contained in the relocation table.

Because the boot loader (bootcode.bin) has to remain very small to do its task Broadcom and/or Raspberry Pi take a shortcut to avoid having to fully decode the start.elf file and perform all of the relocations by including them in a prebuilt table which is what fixup.dat is for.

If fixup.dat is not included then the GPU will report 256MB of RAM and no more, why, because start.elf is loaded at that point in memory and cannot be relocated without the fixup.dat file.

Ultibo still boots and works normally because it has code to detect this abnormally low amount of RAM and adjust the internal memory allocations to suit because so many people make the incorrect assumption that fixup.dat is not needed.
Ultibo.org | Make something amazing
https://ultibo.org
User avatar
Ultibo
Site Admin
Posts: 1549
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Latest commits (Ultibo core 1.3.327)

Postby Ultibo » Mon Jun 05, 2017 9:59 am

pik33 wrote:I have already tested kbd and mouse in the university environment. They both work

Thank you, that's very good to hear.
Ultibo.org | Make something amazing
https://ultibo.org
Gavinmc42
Posts: 1053
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Latest commits (Ultibo core 1.3.327)

Postby Gavinmc42 » Mon Jun 05, 2017 10:43 am

If fixup.dat is not included then the GPU will report 256MB of RAM and no more,

Ultibo still boots and works normally because it has code to detect this abnormally low amount of RAM


"abnormally low"? well maybe for Windows or Linux, seems to be fine for Ultibo small apps.
Might need more if I ever do 250K lines :lol:
Ok, will add fixup.dat, it is only a tiny file anyway.
I suppose next you will say I need config.txt and cmdline.txt too.

Baremetal, as in minimum that is needed to work.
I do sort of wonder what I can do with the rest of the 512MB/1GB memory.
Gavinmc42
Posts: 1053
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Latest commits (Ultibo core 1.3.327)

Postby Gavinmc42 » Tue Jun 06, 2017 7:31 am

Thanks for quick QEMU keyboard fix, works for me in 1.3.331 ;)
Tab gives one space in keyboardinput example, dig out TextEditor example, ok one space in that too.
Might have to look at how tabs are used. Most IDE editors default to 4 spaces?
Check all other keys? Codepage related?

Need to know now that QEMU is becoming really useful with SDcard stuff ;)
I'm not too worried as I am native English speaker, shift 4 is $ so defaults to USA keyboard?
So much to learn.
Gavinmc42
Posts: 1053
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Latest commits (Ultibo core 1.3.327)

Postby Gavinmc42 » Tue Nov 21, 2017 11:56 am

Found these in the dt-blob.dts file, the three known pins match.
Trying to turn the camera on with a Pi3, as i2c1 can be mapped to 44,45 the CAM_GPIO0/1.
Going to be very confusing as normally i2c0 is mapped to the camera.
To read the camera, it needs to be on, virtual I/O uses i2c0.
Boy is this going to be messy ;)

These are the missing functions of the Pi3 i2c IO expander.

Is there any example code to show how to us these virtual I/O.

Code: Select all

  pin@p128 { function = "output"; termination = "no_pulling"; }; // BT_ON
  pin@p129 { function = "output"; termination = "no_pulling"; }; // WL_ON
  pin@p130 { function = "output"; termination = "no_pulling"; }; // ACT_LED
  pin@p131 { function = "output"; termination = "no_pulling"; startup_state = "active"; }; // LAN_RUN
  pin@p132 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Hotplug
  pin@p133 { function = "output"; termination = "no_pulling"; }; // Camera shutdown
  pin@p134 { function = "output"; termination = "no_pulling"; }; // Camera LED
  pin@p135 { function = "input"; termination = "no_pulling"; polarity = "active_low"; }; // Power low


If Ultibo can read i2c0 then it should see the I/O expander, the camera and the power chip, so no re mapping to i2c1 is needed.
I think I might stay with Zero's a bit longer, much cheaper and less bullets in the revolver.

Return to “Ultibo”

Who is online

Users browsing this forum: No registered users and 1 guest