microcat - The ultimative ARM based handheld game console

[DarkestEx]

We decided to put the C API on hold. We will start with a Lua firmware first and build the C one later.
People will be able to upgrade to the C based firmware or downgrade back to the Lua one.
We want to go for Lua first, as its easier for many potential buyers and it will be compilable right on the device. The resources and functions will be compatible to the ones of the planned C API.
I hope this attracts more users. Also we have trouble getting C working at first so we want to start with an easier and hopefully working solution.

[Dream of Omnimaga]

Interesting. I hope that having 2 firmware or API to update won't put strain on your project, though. But if it makes it easier to allow people to program in Lua on your device, then go for it. That language, while some people dislikes it, is very popular and it's used by PICO-8 and the Nspire. Even the Casio PRIZM has some form of Lua.


Good luck!

[DarkestEx]

Interesting. I hope that having 2 firmware or API to update won't put strain on your project, though. But if it makes it easier to allow people to program in Lua on your device, then go for it. That language, while some people dislikes it, is very popular and it's used by PICO-8 and the Nspire. Even the Casio PRIZM has some form of Lua.


Good luck!

Yes. Also it is way easier for us to initially port Lua and look into the way more complex C powered firmware later. Having two different firmwares also has features and allows people to switch based on their skill.
We don't know if the C firmware will be complete when we release the microcat, but the Lua one will certainly be complete on release. L

People will be able to change and upgrade firmware easily.
They can update over the SD card, the PC or over the AIR using WiFi.
SD and AIR are basically the same, as I plan writing a bootloader that can flash image files from SD. The WiFi method would just download the image from the web to the SD and jump to the standard SD bootloader.
The PC bootloader is already built by atmel and is in a non changeable ROM segment, making debricking very easy.
We allow custom firmware.

[Dream of Omnimaga]

Well, at least if one firmware is complete, as well as the console, then that's what counts for the release.

ALso, make sure that there are many failsafes for firmware upgrade, formating or reinstalling. For example, on the TI-Nspire, reseting your Nspire at specific moments during rebooting can permanently brick your calculator. I'm glad that you already have plans in place to prevent that, especially over unstable wi-fi connections or low battery, but of course re-installing a firmware should be made easy for the user, unlike on the Nspire where they placed the maintenance button combo in a way that requires 30 cm long hands. Also, with SD card update, do you mean someone could remove his SD card then insert another with a different firmware?

[DarkestEx]

Well, at least if one firmware is complete, as well as the console, then that's what counts for the release.

ALso, make sure that there are many failsafes for firmware upgrade, formating or reinstalling. For example, on the TI-Nspire, reseting your Nspire at specific moments during rebooting can permanently brick your calculator. I'm glad that you already have plans in place to prevent that, especially over unstable wi-fi connections or low battery, but of course re-installing a firmware should be made easy for the user, unlike on the Nspire where they placed the maintenance button combo in a way that requires 30 cm long hands. Also, with SD card update, do you mean someone could remove his SD card then insert another with a different firmware?

Yes sure I will make it easy.
My idea is to have a bootloader that reads the flash image off an SD card.
You just place a single file e.g. called "kernel.img" on the root folder of the SD card and after a reboot it will begin flashing that image into the consoles Flash memory. If rebooted again the console should run an updated OS.

That said I think I forgot thinking about the fact that we do need an reset button.

[Dream of Omnimaga]

Oh right, the reset button would be handy, so we don't need to remove the battery  all the time during testing.

[DarkestEx]

Oh right, the reset button would be handy, so we don't need to remove the battery  all the time during testing.

Well removing that one is not going to be that easy. We will make it user replaceable and use a header instead of directly soldering it on, but you still would need to open up the case.
Reset button will definitely be added.

EDIT: It looks like we are going to make a Lua emulator first. This means you can run and develop games even before the actual console comes out

[Dream of Omnimaga]

Just make sure to not use a deprecated battery nor a battery that costs as much as the console.

And nice about the emulator

[DarkestEx]

Just make sure to not use a deprecated battery nor a battery that costs as much as the console. [emoji14]

And nice about the emulator

Well the battery is pretty cheap, but it can be replaced with pretty much any LiPo battery that fits into the case.

The simulator is making progress too.

[Dream of Omnimaga]

Ah that's good. I was worried about the possibility of supporting just 1 battery, but then when it dies we get at the shop, only to find out our battery was discontinued. On the other hand, if it supports any LiPo battery, then make sure it's safe, though, as in no risk of overloading the battery, and that it has good checks for if it's charged or almost depleted, to avoid battery explosion and stuff >.<

Glad to see simulator progress, by the way

[DarkestEx]

Ah that's good. I was worried about the possibility of supporting just 1 battery, but then when it dies we get at the shop, only to find out our battery was discontinued. On the other hand, if it supports any LiPo battery, then make sure it's safe, though, as in no risk of overloading the battery, and that it has good checks for if it's charged or almost depleted, to avoid battery explosion and stuff >.<

Glad to see simulator progress, by the way

Of course will it be safe. But don't poke holes into the battery as it won't like that anyways.

I will restart everything in plain C. C# was not exactly the best language for this task and it might be better to be able to reuse all the simulator code in the actual device.

[Dream of Omnimaga]

Wait, does it mean you are scrapping the Lua firmware or simulator for now and switching back to C? Or is the Lua-compatible  firmware or simulator coded in C?

[DarkestEx]

Wait, does it mean you are scrapping the Lua firmware or simulator for now and switching back to C? Or is the Lua-compatible  firmware or simulator coded in C?

Well I want to make my life easier and on the same time make everything faster, so I will be using C to program the microcat simulator. It is still Lua and nothing has changed, except that I will use big chunks of the simulator code in the actual firmware for the microcat now. The simulation will be faster, better and way more accurate.

[Dream of Omnimaga]

Oh I see, I thought you had changed your mind on doing the Lua firmware first. Thanks for clarifying and yes it's better IMHO to make your life easier, especially considering how big this project is.

[Araidia]

I'd like to present you the new console @adekto, @Cumred_Snektron, @gbl08ma, @Streetwalrus and I are working on!
Special thanks to all of them, they are awesome

The microcat

Preliminary specifications:
- ARMv7 Core @ 120 MHz
- ESP8266 WiFi @ 150 MHz
- 128 KB builtin RAM
- High speed SDIO interface for SD cards for program and media storage (resulting in almost unlimited program and ressource sizes)
- 128x128px 16 bit OLED (about 1.5 inches in diagonal)
- 4 direction buttons, 4 action buttons, a soft power switch and a home button
- big expansion header
- Digital 16 bit audio and headphone socket
- LiPo battery with builtin charge circuit
- USB 2.0 full speed, host and slave

I bit of the typo on the specs(where I bolded it)
I also love to host and slave lol