Join us on Discord!
You can help CodeWalrus stay online by donating here.

microcat - The ultimative ARM based handheld game console

Started by DarkestEx, August 09, 2015, 09:50:08 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DarkestEx

Quote from: c4ooo on August 14, 2015, 10:29:32 PM
There is little security on windows, and yet people get along fine. You should know what you are installing. But that's just my personal, honest opinion :P
You are right but Windows people have antiviruses - we don't.
This thing will still have access to its own online app store right on the device. For apps downloaded from the store things will be easier to manage so we only show the warning before downloading, but for untrusted apps we show that warning every time you run it. Of course will you be able to disable that warning in the settings. But this thing has full access to your local network and the internet, so you must really be safe or apps could infiltrate your home network very easily.
  • Calculators owned: TI-84+, Casio 101-S, RPN-Calc, Hewlett-Packard 100LX, Hewlett-Packard 95LX
  • Consoles, mobile devices and vintage computers owned: Original Commodore 64C, C64 DTV, Nintendo GameBoy Color, Nintendo GameCube, Xbox 360, PlayStation 2

Snektron

If every game is going to be made in CLAW, why not just limit CLAW to not be able to collect user data?
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


DarkestEx

#32
Quote from: Cumred_Snektron on August 14, 2015, 10:35:10 PM
If every game is going to be made in CLAW, why not just limit CLAW to not be able to collect user data?
Its not the on device data but the other PCs in the same network.
Everything is made in CLAW including the full app store and the settings and the main menu.
So we need special rights for those apps / games (however you want to call the assemblies).
Also we still want apps to be able to have multi player capabilities (even over the net) we need rights and permissions.
Its nothing to discuss about as nothing negative comes from this type of protection. Not even a speed decrease.
  • Calculators owned: TI-84+, Casio 101-S, RPN-Calc, Hewlett-Packard 100LX, Hewlett-Packard 95LX
  • Consoles, mobile devices and vintage computers owned: Original Commodore 64C, C64 DTV, Nintendo GameBoy Color, Nintendo GameCube, Xbox 360, PlayStation 2

gbl08ma

So let me check if I understood correctly, you are part of a two-person team that wants to build a hardware board with two CPUs (an ARM core + the ESP8266 CPU), OLED screen, SD card interface, USB capabilities, rechargeable battery, all good. I take it that you have experience with the design and fabrication process for this sort of thing, hardware-wise?

SPI, I2C and I2S are not the first thing that comes to my mind when I think of "plug and play", but I think I see what you mean.

I'm more worried about the software side, you plan on building your own bytecode and associated virtual machine, plus a BASIC interpreter... and I see that the "OS" part of the project is also quite complex, as I see you talking about settings, an app store and multi player capabilities (I hope turn-based only, as with such slow processors - and the ESP8266 network stack is nothing but high-speed, real-time multiplayer is going to be impossible). And do all that with some form of permissions system.

So... I don't want to demotivate anyone, as I like dreaming big as well. And I'm not saying any of this is impossible, especially with adjustments to the hardware platform to allow for things to be a bit more powerful. But I have a honest question, how many years do you plan it will take to finish this?
  • Calculators owned: Prizm CG-20

Dream of Omnimaga

Quote from: DarkestEx on August 14, 2015, 10:22:22 PM
Quote from: DJ Omnimaga on August 14, 2015, 05:23:40 PM
Quote from: DarkestEx on August 13, 2015, 11:42:41 PM
Quote from: DJ Omnimaga on August 13, 2015, 11:35:10 PM
By the way I hope you can manage to get this console produced for as cheap as possible so that you can charge a small enough price while still making a profit. Imagine if you had to buy each part at different retailers and paid different shipping fees >.<. That could easily rack up the production costs to $100-200 per unit. Over here if you buy a processor on Ebay from USA some people charges $40 in shipping.
We buy basically everything except three parts from Farnell Electronics.
In the case that we don't form a company, we might not be able to order directly from them, so mass discount is less significant in such a case.
We hope to get it below 90 eur in this case.
But if nothing goes wrong it should be available for about 59 EUR + shipping
60-70 would definitively be fine if we got enough freedom with that device. Everything is more expensive in Europe than in North America (except mobile plans) so it's harder for Europeans to sell something cheap enough to North Americans, but if it was like 100 euros, then we can get an used Xbox 360 or PS3 for cheaper.
Well, how much freedom would you all like?
We try to make it as free as possible, but we still want to make it secure - no game should be able to hack local computers or collect data. We will certainly have quite a few security functions, but they will all be similar to Android. So when installing Apps you will be prompted with all the permissions an app does request and you can't run it without accepting them.
Also about the price, we will have different models, so you can choose between only the populated pcb or a full console with case or a starter kit with a usb cable and a microsd with the system already preinstalled.
The 59 EUR are for a console with starter kit (as calculations are right now). We don't know if we will really form a company to get greater mass discount (if not it will get more expensive). Discount is also possible - if we sell 100 units, one unit would be a lot cheaper.

As long as the console is as open as the TI-84 Plus CE or at least its language runs as fast as HP PPL, then I'm good. It should not be as locked down as the TI-Nspire CX.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

DarkestEx

Quote from: gbl08ma on August 14, 2015, 11:11:43 PM
So let me check if I understood correctly, you are part of a two-person team that wants to build a hardware board with two CPUs (an ARM core + the ESP8266 CPU), OLED screen, SD card interface, USB capabilities, rechargeable battery, all good. I take it that you have experience with the design and fabrication process for this sort of thing, hardware-wise?

SPI, I2C and I2S are not the first thing that comes to my mind when I think of "plug and play", but I think I see what you mean.

I'm more worried about the software side, you plan on building your own bytecode and associated virtual machine, plus a BASIC interpreter... and I see that the "OS" part of the project is also quite complex, as I see you talking about settings, an app store and multi player capabilities (I hope turn-based only, as with such slow processors - and the ESP8266 network stack is nothing but high-speed, real-time multiplayer is going to be impossible). And do all that with some form of permissions system.

So... I don't want to demotivate anyone, as I like dreaming big as well. And I'm not saying any of this is impossible, especially with adjustments to the hardware platform to allow for things to be a bit more powerful. But I have a honest question, how many years do you plan it will take to finish this?
Second take writing this on my stupid tablet. First time the processor froze with only one chrome tab open and half ram free and reset the tablet when i was half way done.

So first thanks for beeing honorest. Yea its a huge project and it will take atleast half a year to the kickstarter campaign.
We both spent big parts of our savings to buy proper tools and prototyping parts.
I bought OLED modules, ARMs, Sound amplifiers, adapter boards, a hot air SMD reflow station, a proper JTAG interface, SMD tweezers, esd workmat, and tons of other tools and parts.

We spent weeks searching for the best and cheapest parts that we can interface and made huge detailled spreadsheets about all possible aspects.
Now we have all parts here in testing quantities, most in DIP form so that we can build our first hardware prototypes.

About your other points:

The plug and play interface will use drivers written in either CLAW or ones written in C++ that are builtin to the os kernel to deal with different types of devices. Yes we use plug and play for i2c, spi and i2s. How do we do that?
Its simple: every expansion module will have an spi eeprom on it that is also connected to the arm by a seperate cs line.
If you plug any spi or i2c device in the arm detects the eeprom and checks if a driver exists (all spi devices you can write a driver for are supported - even shift registers and other dumb parts, as the eeprom does all the magic by identifying the device and telling its id).

About the software, yes we will make our own bytecode vm and a compiler for it. No basic one though. Only a single lua like and a mnemorics to bytecode one. We can still change parts of the hardware when something does just not work, like you said. The esp is actually very fast with its 150 MHz core speed and its RISC architecture, only speed issue is the serial connection to the arm, that we make as fast as possible.
You are right that only slow games or turn based ones will work. As the esp has a hotspot function we might be able to make a packet based tron clone or so in multiplayer mode but nothing too exciting probably. Well atleast we have ssl and json decode and encode capabilities in the esp.

I really want to make this happen :)
  • Calculators owned: TI-84+, Casio 101-S, RPN-Calc, Hewlett-Packard 100LX, Hewlett-Packard 95LX
  • Consoles, mobile devices and vintage computers owned: Original Commodore 64C, C64 DTV, Nintendo GameBoy Color, Nintendo GameCube, Xbox 360, PlayStation 2

Dream of Omnimaga

On a side note, if the other guy is interested in forums, you should remind him that the site suffered a data loss so his account was lost and he will need to register again. Just in case he wonders why he can't login (assuming he tries after the red notice at the top of the page is gone)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Unicorn

Hopefully you can get this going. Maybe post on a few different websites like kickstarter to?
  • Calculators owned: I own all of them: PICKACHUP TI 84+ CSE TI 83+ SE TI something something ??? ??? ??? ??? ???
  • Consoles, mobile devices and vintage computers owned: PICKACHUP ??? ??? ??? ??? ???



??? ??? ??? ??? ???

gbl08ma

Quote from: DarkestEx on August 14, 2015, 11:47:05 PMevery expansion module will have an spi eeprom on it that is also connected to the arm by a seperate cs line.

This is the approach used by the Raspberry Pi foundation for Raspberry Pi HATs, I think it worked well for them and I don't see why they wouldn't work well for you. That is, as long as the drivers work well. The only downside of this approach I can think of, is that each expansion module becomes a bit more expensive to produce due to the extra EEPROM, but this can possibly be mitigated by using clever trickery to make the components on the module emulate this SPI memory during the enumeration phase.

The ESP8266, in the highest CPU speed, is indeed very fast. I have not done any benchmarks but I suspect it is more powerful than the ARM core you plan to use, even though it uses a weird Xtensa architecture that is not ARM. The problem is that the ESP is very limited in terms of interfaces, so for USB and etc. you'd always need a separate processor.

I suggest that you make the ESP8266 the main processor, and try building things so that the ARM is its slave. This would make implementing debugging over Wi-Fi easier, I think. You would then load a basic OS into the ESP8266 and make it responsible for starting the ARM core, and the OS from the SD card, if there is one, or otherwise just wait for instructions over the network. I'm just not sure this is possible, for this (controlling the ARM core) you'd ideally use its JTAG, but the ESP has no JTAG interface (I think?). Bit-banging using some of the ESP GPIOs may be feasible, I don't know.

Note that since you only plan to support that Claw bytecode VM thing, you would actually not need JTAG to allow for the ESP to control game execution: you'd just make the VM listen to commands over the serial and take the appropriate actions (pause, jump to, get/set value, resume execution...). Now I get why you say supporting native code would be technically impossible.

This would result in a system that is basically unbrickable (because the firmware in the ESP would not be modified by anyone but advanced users). Shall you want to update that firmware, you can, either using the OTA update capability of the ESP, or by making the ARM core control the ESP bootloader. It would also allow for it to be useful without a SD card (by network-loading the software to run, but you need somewhere to store it temporarily, so this may not be possible). And it would hopefully ease some of your worries about security/permissions.

The ESP8266 serial can communicate with baud rates over 900000 baud, which gives an effective speed close to 1 Mbit/s. Do not expect being able to communicate wirelessly at this speed, though. You must also check the ARM part supports such speeds. I think at 900000 baud you can get a real-time view over the Claw VM without making the bytecode program run too slow.
  • Calculators owned: Prizm CG-20

CKH4

Quote from: DarkestEx on August 14, 2015, 10:22:22 PM
Well, how much freedom would you all like?
We try to make it as free as possible, but we still want to make it secure - no game should be able to hack local computers or collect data. We will certainly have quite a few security functions, but they will all be similar to Android. So when installing Apps you will be prompted with all the permissions an app does request and you can't run it without accepting them.
Would it be possible to accept certain permissions and deny others so that when a permission is needed you will be prompted that the part of the app will not function unless you allow the permission.
  • Calculators owned: TI-83+, TI-84+


DarkestEx

Quote from: CKH4 on August 16, 2015, 12:41:24 PM
Quote from: DarkestEx on August 14, 2015, 10:22:22 PM
Well, how much freedom would you all like?
We try to make it as free as possible, but we still want to make it secure - no game should be able to hack local computers or collect data. We will certainly have quite a few security functions, but they will all be similar to Android. So when installing Apps you will be prompted with all the permissions an app does request and you can't run it without accepting them.
Would it be possible to accept certain permissions and deny others so that when a permission is needed you will be prompted that the part of the app will not function unless you allow the permission.
Oft course in theory its possible, but more management is needed as all apps would need to be registered with their permissions in the save flash area.
  • Calculators owned: TI-84+, Casio 101-S, RPN-Calc, Hewlett-Packard 100LX, Hewlett-Packard 95LX
  • Consoles, mobile devices and vintage computers owned: Original Commodore 64C, C64 DTV, Nintendo GameBoy Color, Nintendo GameCube, Xbox 360, PlayStation 2

adekto

hi guys im the other guy who is making this thing, just a litle update on the hardware prototypes we are doing, we got almoust all parts together apart from the main m0+ part
we could not get out hands on any devboard for it so we tryed (and failed) doing our own breakout ones, curently we are going with the alternative wich is a socket.

atm im unsure about the licencing for the software/hardware
best option is to get pickt up by a company to be frank, since that will alow cheaper devices
ofcource that sound very unlikely so most probebly we do some crowd funding to get a batch made

i read on here someone asking about why not get a bigger better chip? wel we can sure fo for the m3 or m4 but then again u can go biger and biger until your at that the flagship smartphones
also we are still very new to this and starting with a gen 1 ish device, need to start somewhere and the m0+ seems a nice upgrade from the old avr arduino stuff

DarkestEx

Quote from: gbl08ma on August 15, 2015, 06:23:45 PM
Quote from: DarkestEx on August 14, 2015, 11:47:05 PMevery expansion module will have an spi eeprom on it that is also connected to the arm by a seperate cs line.

This is the approach used by the Raspberry Pi foundation for Raspberry Pi HATs, I think it worked well for them and I don't see why they wouldn't work well for you. That is, as long as the drivers work well. The only downside of this approach I can think of, is that each expansion module becomes a bit more expensive to produce due to the extra EEPROM, but this can possibly be mitigated by using clever trickery to make the components on the module emulate this SPI memory during the enumeration phase.

The ESP8266, in the highest CPU speed, is indeed very fast. I have not done any benchmarks but I suspect it is more powerful than the ARM core you plan to use, even though it uses a weird Xtensa architecture that is not ARM. The problem is that the ESP is very limited in terms of interfaces, so for USB and etc. you'd always need a separate processor.

I suggest that you make the ESP8266 the main processor, and try building things so that the ARM is its slave. This would make implementing debugging over Wi-Fi easier, I think. You would then load a basic OS into the ESP8266 and make it responsible for starting the ARM core, and the OS from the SD card, if there is one, or otherwise just wait for instructions over the network. I'm just not sure this is possible, for this (controlling the ARM core) you'd ideally use its JTAG, but the ESP has no JTAG interface (I think?). Bit-banging using some of the ESP GPIOs may be feasible, I don't know.

Note that since you only plan to support that Claw bytecode VM thing, you would actually not need JTAG to allow for the ESP to control game execution: you'd just make the VM listen to commands over the serial and take the appropriate actions (pause, jump to, get/set value, resume execution...). Now I get why you say supporting native code would be technically impossible.

This would result in a system that is basically unbrickable (because the firmware in the ESP would not be modified by anyone but advanced users). Shall you want to update that firmware, you can, either using the OTA update capability of the ESP, or by making the ARM core control the ESP bootloader. It would also allow for it to be useful without a SD card (by network-loading the software to run, but you need somewhere to store it temporarily, so this may not be possible). And it would hopefully ease some of your worries about security/permissions.

The ESP8266 serial can communicate with baud rates over 900000 baud, which gives an effective speed close to 1 Mbit/s. Do not expect being able to communicate wirelessly at this speed, though. You must also check the ARM part supports such speeds. I think at 900000 baud you can get a real-time view over the Claw VM without making the bytecode program run too slow.
Well, the expansion module doesn't become much more expensive. We calculated about 30 cents of cost increase when ordering 10 EEPROMs.

After rethinking the debug interface a bit, a good idea came to my mind which uses the ESP for debugging and allows it to send bytecode to the ARM which it then does execute.
The ESP has a HOLD line going to the ARM, which is normally pulled HIGH. When the ESP pulls that line low, the VM is halted and reacts to serial commands like setting breakpoints, reading the stack, manipulating the stack, program pointer and seeing other debug information.
One BREAK line will also go from the ARM to the ESP which will indicate that the ARM has reached a breakpoint and waits for instructions. Breakpoints will be done either with a break instruction or by serial command (I am not sure yet).

The ARM will be slave to the ESP and the ESP's WiFi is slave to the ARM.

Thanks for your tipps :)
  • Calculators owned: TI-84+, Casio 101-S, RPN-Calc, Hewlett-Packard 100LX, Hewlett-Packard 95LX
  • Consoles, mobile devices and vintage computers owned: Original Commodore 64C, C64 DTV, Nintendo GameBoy Color, Nintendo GameCube, Xbox 360, PlayStation 2

Snektron

Quote from: adekto on August 18, 2015, 10:12:57 AM
hi guys im the other guy who is making this thing, just a litle update on the hardware prototypes we are doing, we got almoust all parts together apart from the main m0+ part
we could not get out hands on any devboard for it so we tryed (and failed) doing our own breakout ones, curently we are going with the alternative wich is a socket.

atm im unsure about the licencing for the software/hardware
best option is to get pickt up by a company to be frank, since that will alow cheaper devices
ofcource that sound very unlikely so most probebly we do some crowd funding to get a batch made

i read on here someone asking about why not get a bigger better chip? wel we can sure fo for the m3 or m4 but then again u can go biger and biger until your at that the flagship smartphones
also we are still very new to this and starting with a gen 1 ish device, need to start somewhere and the m0+ seems a nice upgrade from the old avr arduino stuff

Welcome to the forums, adekto :). If you'd like, you can introduce yourself here: https://codewalr.us/index.php?topic=32
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


Dream of Omnimaga

Welcome aboard adekto. My suggestion for crowdfunding would be to wait until you got a prototype with a design/case done, so that way people are easier to convince. That's of course if you need crowdfunding at all. Also good luck on this project, I'm glad that you are both slowly getting your parts together. :)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Powered by EzPortal