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 microcatPreliminary specifications:- ARMv7 Core @ 120 MHz
- ESP8266 WiFi @ 80 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-, a home- and a reset 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
Estimated price is about 45 EUR for the base unit
About 59 for a full starter kit.
The console will be very tiny. Just about smaller than a credit card.
We are still in prototyping phase, but I want to log progress here, and we really hope that you like it :)
Have fun!
Looks pretty sweet :D Im interested in how developement with this wil go.
How will games be made?
Quote from: Cumred_Snektron on August 09, 2015, 10:31:45 PM
Looks pretty sweet :D Im interested in how developement with this wil go.
How will games be made?
Games can be made in a Lua like language or in our custom, easy assembly language.
They can be made on a PC or even right on the device.
Debugging and uploading can be done over WiFi.
It seems interesting. I hope it comes to fruition like the Gamebuino did. The specs also seem pretty nice for retro gaming :)
Oo, sounds very cool!This seems ambitous, but good luck! :)
Quote from: DJ Omnimaga on August 09, 2015, 11:50:30 PM
It seems interesting. I hope it comes to fruition like the Gamebuino did. The specs also seem pretty nice for retro gaming :)
I really hope so too and yes, we want to do primarily retro gaming as we really like it. Basically we want to start where the Gamebuino's limits are and allow color retro games with modern SD, WiFi and USB capabilities to become reality again.
Quote from: Unicorn on August 10, 2015, 04:25:08 AM
Oo, sounds very cool!This seems ambitous, but good luck! :)
Thanks. I will keep you all updated on our progress.
Very cool, maybe this will become very popular as it sounds great.
What OS will it run, if any? Will it be able to run code in any language that can compile to ARM assembly?
Quote from: Strontium on August 13, 2015, 12:13:42 AM
What OS will it run, if any? Will it be able to run code in any language that can compile to ARM assembly?
It will run our custom OS we're working on.
About languages, we don't support running ARM assemblies, as this is not possible on our architecture.
Basically it's like Java - you have a virtual processor running on the microcat that executes our own improved assembly code that you can write directly or use one of our compilers that we're working on to generate assemblies for you.
Benefits are smaller code sizes, easy game writing, library support, code is loaded directly from sd card, so it won't be loaded into ram.
This allows for games without any size limitations.It will support games written in C and linked to a shared API in Flash.
Sweet :) Can libraries have native code though? or do you implement everything (like a graphics library and such) in the asm language itself?
Quote from: Cumred_Snektron on August 13, 2015, 10:19:01 AM
Sweet :) Can libraries have native code though? or do you implement everything (like a graphics library and such) in the asm language itself?
Libraries can bridge core and OS low level functions directly to any assembly or just provide easy to use functions.
Basically we will provide a subset of base functions that the libraries can build on top of.
We can always update the main firmware to implement new features.
Libraries will have linker files that contain the entry points to the referenced functions to interface with programs, so we will basically have shared libraries.
The whole assembly executing system will be secured by permissions.
Libraries and assemblies can only use functions that they have permissions for or the program execution will end and the console will return to the menu.
So the library has to use the same permissions as the main program or game requests.
Maybe libraries can have small static ARM assembly blocks, but we don't know yet how to do it. Probably they won't have them to prevent security incidents.
Are you sure security is somehting you want to focus on with such low-end hardware ?
Quote from: Streetwalrus on August 13, 2015, 02:25:04 PM
Are you sure security is somehting you want to focus on with such low-end hardware ?
Well, yes. No complex security, but basic things like permissions (just flags in the VM) and SSL which is already builtin to the WiFi chipset.
Maybe certification, but we probably ditch that idea.
Looks interesting so far, although I wonder why a seperate µC for power control?
Most ARM µCs have a lot of power control built-in.
Quote- ARM Cortex M0+ Core @ 48 MHz
- 128 KB builtin RAM (expandable)
Let me guess, a STM32F0? I like those chips a lot, I have the F407 and F429 discovery and they're really useful.
Why not a slightly more powerful core like a Cortex M4F, though? Faster floating point processing could be nice to have.
Quote from: DarkestEx on August 13, 2015, 08:51:47 AM
Quote from: Strontium on August 13, 2015, 12:13:42 AM
What OS will it run, if any? Will it be able to run code in any language that can compile to ARM assembly?
It will run our custom OS we're working on.
About languages, we don't support running ARM assemblies, as this is not possible on our architecture.
Basically it's like Java - you have a virtual processor running on the microcat that executes our own improved assembly code that you can write directly or use one of our compilers that we're working on to generate assemblies for you.
Benefits are smaller code sizes, easy game writing, library support, code is loaded directly from sd card, so it won't be loaded into ram.
This allows for games without any size limitations.
Sounds suspiciously familiar... <_<
As long as it's not locked down like the TI-Nspire CX and that the supported languages don't have the severe slowdowns that Nspire Lua had at times, then I think it's fine.
There should at least be a possibility to make native apps.
Only allowing bytecode to run is an unnecessary restriction.
Loading binaries from SD would be nice.
Quote from: Vogtinator on August 13, 2015, 04:53:55 PM
Looks interesting so far, although I wonder why a seperate µC for power control?
Most ARM µCs have a lot of power control built-in.
Quote- ARM Cortex M0+ Core @ 48 MHz
- 128 KB builtin RAM (expandable)
Let me guess, a STM32F0? I like those chips a lot, I have the F407 and F429 discovery and they're really useful.
Why not a slightly more powerful core like a Cortex M4F, though? Faster floating point processing could be nice to have.
This
iswas our
current chipset:
| Description | Manufacturer | Part |
| ARM CPU | Atmel | ATSAMD21G18A-AU |
| WiFi | Espressiv | EXP8266-07 |
| SRAM | Microchip | 23LCV1024 |
| Power control MCU | Atmel | ATTINY13A |
| Audio amplifier with volume control | Texas Instruments | LM4811 |
| Address decoder | NXP | 74HC139 |
Of course other features are nice, but we really have quite a tight budget already.
Also it must be a TQFP or QFP with 48 pins
Quote from: Vogtinator on August 13, 2015, 05:05:20 PM
There should at least be a possibility to make native apps.
Only allowing bytecode to run is an unnecessary restriction.
Loading binaries from SD would be nice.
Sorry native apps are impossible.
Its not an unnecessary restriction but its just impossible for us to get any external native code to run with its variables inside of 32KB internal RAM.
Bytecode is always ran directly from SD; its never loaded to RAM.Quote from: DJ Omnimaga on August 13, 2015, 05:01:59 PM
As long as it's not locked down like the TI-Nspire CX and that the supported languages don't have the severe slowdowns that Nspire Lua had at times, then I think it's fine.
Well we will of course try to make it as fast as possible. ;)
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.
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
Quote from: DarkestEx on August 13, 2015, 08:51:47 AM
Quote from: Strontium on August 13, 2015, 12:13:42 AM
What OS will it run, if any? Will it be able to run code in any language that can compile to ARM assembly?
It will run our custom OS we're working on.
About languages, we don't support running ARM assemblies, as this is not possible on our architecture.
Basically it's like Java - you have a virtual processor running on the microcat that executes our own improved assembly code that you can write directly or use one of our compilers that we're working on to generate assemblies for you.
Benefits are smaller code sizes, easy game writing, library support, code is loaded directly from sd card, so it won't be loaded into ram.
This allows for games without any size limitations.
So, you can't use any programming language? Also, could you please elaborate on how there can be no native code? How is that even possible?
Quote from: Strontium on August 14, 2015, 12:36:00 AM
Quote from: DarkestEx on August 13, 2015, 08:51:47 AM
Quote from: Strontium on August 13, 2015, 12:13:42 AM
What OS will it run, if any? Will it be able to run code in any language that can compile to ARM assembly?
It will run our custom OS we're working on.
About languages, we don't support running ARM assemblies, as this is not possible on our architecture.
Basically it's like Java - you have a virtual processor running on the microcat that executes our own improved assembly code that you can write directly or use one of our compilers that we're working on to generate assemblies for you.
Benefits are smaller code sizes, easy game writing, library support, code is loaded directly from sd card, so it won't be loaded into ram.
This allows for games without any size limitations.
So, you can't use any programming language?
Well in theory you can use any programming language possible, but you have to write something first that compiles a language to claw bytecode.
The other good thing about bytecode is that it basically runs on other devices too without much modification (even a PC for testing and debugging).
We hope to be able to make claw debuggable over wifi, but until that it will take some time.
So I could port my TI-BASIC games over if there was a compliler? :P
Quote from: Unicorn on August 14, 2015, 02:14:46 AM
So I could port my TI-BASIC games over if there was a compliler? :P
Yes it is possible if somebody either makes an interpreter or a compiler. One more reason why this is possible is that the monochrome TI-Calcs have the same resolution then the microcat.
Even grayscale is natively possible as the microcat has a full color screen.
Watch out you don't get sued by TI if you make a ti basic interperter/compiler though :P
Quote from: Cumred_Snektron on August 14, 2015, 11:43:08 AM
Watch out you don't get sued by TI if you make a ti basic interperter/compiler though :P
Why should we get sued :P
It's just Basic.
But I don't plan making such an interpreter / compiler (yet?), as there is a whole lot of things to do already.
Did TI copyright/patent (I don't know which word to use) TI BASIC or something like that?
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.
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.
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
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.
If every game is going to be made in CLAW, why not just limit CLAW to not be able to collect user data?
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.
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?
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.
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 :)
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)
Hopefully you can get this going. Maybe post on a few different websites like kickstarter to?
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.
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.
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.
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
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 :)
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
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. :)
Quote from: DJ Omnimaga on August 18, 2015, 09:05:22 PM
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. :)
Oh we will need crowdfunding in any case.
thank you guys for your intrest aswel
we have spend about 400 euro's on prototyping parts at the moment
Darn, that's a lot of money. That is partly why I always hope that people who work on such project are experienced enough to achieve their goals and have enough free time to work on it. It sucks if all money spent into a project goes to waste.
Also, one suggestion I have for this project would be to ensure that it can be worked on as a solo project. That way, if, for example, you or DarkestEx became unable to work on any project for three years due to school and had to drop out from Microcat development, then you could at least continue alone. In the past, I saw many projects (physical or software-based) die because one of the team member disappeared with important parts of code)
il keep that in mind.
i was wondering if any of you people know any european pick and place fabs. im just mainly looking to get some price's since atm we plan to do it by hand (for 50 ish units that be fine but more it becoms like a big problem to do by hand)
Depending on how open the microcat's hardware is planned to be, you could manage 'trusted' 'solder slaves' through a kind of microcat shop - private people selling microcats they assembled following some quality guidelines. But that might be hard to achieve both in a organisational and a juridical uncritical way.
yea i see where your coming from but then again it probebly more trust weurthy to get a profesional company on bourd for that
dealing with multiple indipendants and probebly sending to the costumer derectly cant guarantee that the product works and is made to spec, and we will only get the blame from that
the idea of making a kits and supplieng resellers like that might be a way to go, but for the current version we arent making it opensource hardware (mainly for copycat reasons)
Well about openness, we will be releasing the schematics, but we won't release the PCB files to prevent cheaper copies. Also eagle costs a freakkin 140EUR with student discount O.O
If I was you guys I would avoid getting this product assembled by multiple companies. This will cause too much issues I think and if something doesn't work then they'll blame each others for damaging each others' work or stuff like that.
And yeah if I was you I would wait before releasing the schematics, in case your work gets stolen or something for money. Of course if you ever became too busy to work on it then you could release what you have, though.
Quote from: DJ Omnimaga on August 22, 2015, 04:57:35 AM
If I was you guys I would avoid getting this product assembled by multiple companies. This will cause too much issues I think and if something doesn't work then they'll blame each others for damaging each others' work or stuff like that.
And yeah if I was you I would wait before releasing the schematics, in case your work gets stolen or something for money. Of course if you ever became too busy to work on it then you could release what you have, though.
Well I don't see any issue in releasing the schematics. Making them takes time, but is nowhere as costly and time expensive as ruling out a 4 layer PCB.
So we will never release the PCB files. But releasing the schematics is fine and allows people to understand the console more and develop expansion modules for it and maybe even hack it.
Other news is that we now have two great people that joined our team and help us developing the software:
@Cumred_Snektron and @gbl08ma They're awesome :thumbsup:
Awesome to hear. Will they also participate to the discussion and share updates here? :walrii:
I may, at least for the bytecode virtual machine part. And I already participated in the discussion. :) But at this point there's still so much to be done and we're still experimenting a lot, so it's hard to come up with concrete updates. For the VM part, it's probably easier for people to follow the activity on https://github.com/microcat-dev/claw-vm for the time being.
I'll try to do some updates too, but i don't really have big projects for it yet. I made a Setup utility and a claw bytecode syntax for notepad++ though.
Awesome! I expect a great thing from you guys.... :P
Quote from: gbl08ma on August 22, 2015, 08:41:06 PM
I may, at least for the bytecode virtual machine part. And I already participated in the discussion. :) But at this point there's still so much to be done and we're still experimenting a lot, so it's hard to come up with concrete updates. For the VM part, it's probably easier for people to follow the activity on https://github.com/microcat-dev/claw-vm for the time being.
Cool to hear. I was more wondering since certain developers like the Ndless team and other Nspire developers posts all progress on Github/Bitbucket/etc exclusively and this happens with other platforms as well (although it's more common with the Nspire). Although Ndless team has to hide that info from TI at all cost, so I think they have a case there. But otherwise developers tend to not get as much community feedback that way. On the other hand it's generally better to avoid hype, to avoid giving false hopes to people in case the project takes longer than expected or never comes to fruition. Anyway good luck to everyone :)
So we made some progress and changed the hardware specs quite a bit.
Basically the console now has 16 bit instead of 8 bit graphics, 680mAh battery, RTC, full speed USB 2.0 host and slave, high speed SDIO interface, real binary code loading instead of vm (either directly from SD or through RAM), 512 KB Flash (instead of 256), 128KB RAM (instead of 32), 120 MHz (instead of 48)
And here comes the best: the price stays!
Also it will be fully hackable and reprogrammable. You can use it for almost anything else!
Wow that sounds great. That is a massive specs boost.
Yes indeed, although the ram is pretty small and is likely to be a limiting factor. We'll see what it can do. :)
Quote from: Streetwalrus on September 10, 2015, 08:55:04 AM
Yes indeed, although the ram is pretty small and is likely to be a limiting factor. We'll see what it can do. :)
Well for the small size and display, the RAM should be okay I think.
Games should be linked to the builtin API in flash - I have sadly no clue how so any help is greatly apprechiated (see below).
The person who helps me getting an executable that I copy from the SD to RAM to execute while using the shared API in flash gets a console for free (only when we get the thing kickstarted though).
Gotta look at the datasheet, but it should be feasible. Which compiler are you using ? I assume GCC ?
Quote from: Streetwalrus on September 10, 2015, 10:18:35 AM
Gotta look at the datasheet, but it should be feasible. Which compiler are you using ? I assume GCC ?
Well we will be using gcc for ARMv7.
Basically we want one application at once (so no multitasking and multithreading).
OS sometimes gets called by ARM events or interrupts or though the OS API.
It normally does nothing though.
C should probably be enough though C++ would be really awesome.
Also the API (graphics, OS, file system, network, etc.) will be in the flash.
We will make a .h API. The games need to be shared linked to this. The positions in flash do only change on firmware updates - there is no filesystem in flash, just bound into address space. We have a FAT32 filesystem on the SD card (interfaced though the HSMCI interface).
When the console boots, it should run the OS from flash (like normally) and allows the user to select an executable from the SD card (I am doing that part).
Then the executable needs to be copied into RAM and jumped to it. Because of the small amount of RAM we have, we don't want a static API in that executable, but the API should be entirely in flash and shared linked to that.
It should also be (relatively) easy for a user to make games. So any makefile or so would be good then (remember some of the targeted people don't know too much about linking and such things).
I hope that is feasable. Thanks to everybody who can help.
The first solution that I like will be the winner and he or she gets a free console when the kickstarter is over and the project funded. (One of the first consoles)
How about having a jump table in flash to keep api functions at the same location ? that would vastly simplify things. You can then use the syscall interrupt to call the api from flash, just have a tiny handler statically linked into the executables and it should be fine. That should remove the linking problem entirely.
Have a look at this : http://wiki.osdev.org/ARM_System_Calls
Quote from: Streetwalrus on September 10, 2015, 10:42:59 AM
How about having a jump table in flash to keep api functions at the same location ? that would vastly simplify things. You can then use the syscall interrupt to call the api from flash, just have a tiny handler statically linked into the executables and it should be fine. That should remove the linking problem entirely.
Have a look at this : http://wiki.osdev.org/ARM_System_Calls
How do you mean that?
Also how do i then use e.g. int32_t do_something(uint_8t x, uint32_t) from a .h file?
How do I link that with gcc?
Jumptable makes sense, but how do I link that to the .h files?
And how do I place that inside of the flash api always at the same position in flash?
You need to write custom linking scripts (they should ship as part of your toolchain).
For every api call you need to write an assembly stub that will pass control to the api code in flash. Shouldn't take more than a couple instructions per function.
Quote from: Streetwalrus on September 10, 2015, 11:04:39 AM
You need to write custom linking scripts (they should ship as part of your toolchain).
For every api call you need to write an assembly stub that will pass control to the api code in flash. Shouldn't take more than a couple instructions per function.
I will do that. Thanks for helping. But you might understand that I can only choose you as the winner when it works. And it might be more fair to just give you 50% discount for there suggestions. But we will see ;)
Glad I could help, I've done a lot of low level stuff on arm, including bare metal on the raspberry pi and all my experimentations with ndless. Knowledge is meant to be shared, not kept secret. ;)
So I decided to start with the OS.
After some thinking I decided to not make it closed source. It will be licenced under the New BSD 3 clause licence.
You can track progress here: https://github.com/ninjabyte/ClawOS
I unfortunately cannot help nor provide much feedback on the hardware side of this project, simply because I am completely illiterate about that stuff, so all I can do is suggest technical specs, which looks like I won't need to do, from the first post.
However, I support this project and while I was skeptical at first, it seems you have gotten your stuff together quite well despite the fact that most of those projects end up being vaporware. This is why at first I suggested to not launch a Kickstarter campaing or something too early, if you ever need one.
Glad that you are making the OS open-source. It's your decision in the end, but TI community members tend to prefer open-source platforms and ones that aren't overly locked-down like the TI-82A or TI-Nspire CX. Also make sure that if you don't support ASM nor C that you include support for languages that are fast enough for this platform (eg not Visual Basic :P)
Anyway good luck and make sure to continue planning stuff ahead. :)
Quote from: Streetwalrus on September 10, 2015, 11:14:23 AM
Knowledge is meant to be shared
Don't you also mean "Sharing is meant to be known"? :P
Quote from: DJ Omnimaga on September 11, 2015, 06:19:40 AM
Glad that you are making the OS open-source. It's your decision in the end, but TI community members tend to prefer open-source platforms and ones that aren't overly locked-down like the TI-82A or TI-Nspire CX. Also make sure that if you don't support ASM nor C that you include support for languages that are fast enough for this platform (eg not Visual Basic :P)
Anyway good luck and make sure to continue planning stuff ahead. :)
Thanks!
Well we are not doing the VM anymore as I said a few posts above. The hardware is finally good enough for having games in C or Assembly :)
Cool to hear. I thought it still didn't support ASM/C.
Huge feature upgrade:
The console's screen is now way bigger.
It was 96x64 pixels @ 16 bpp before.
Now its 128x128 pixels @ 8 bpp!
But it allows for direct 16 bit drawing.
This does probably slightly affect the price of the console.
It will be about 2 EUR more than it used to be. But it is now way more usable.
Ooh that's a nice upgrade actually. While it's not calc size it's closer to Gameboy size (it was 160x144) and if someone wants to port an old calc game directly he can simply use a black frame around the screen. 16 bit color draw seems cool as well, although 8 bits might be better since it's easier to create 8 bit files on the computer. Anyway I don't mind the price increase if it's not too much anyway.
On a side note, do you have a prototype in the works or will you have to restart from scratch due to the screen change?
Quote from: DJ Omnimaga on September 13, 2015, 05:45:01 PM
Ooh that's a nice upgrade actually. While it's not calc size it's closer to Gameboy size (it was 160x144) and if someone wants to port an old calc game directly he can simply use a black frame around the screen. 16 bit color draw seems cool as well, although 8 bits might be better since it's easier to create 8 bit files on the computer. Anyway I don't mind the price increase if it's not too much anyway.
On a side note, do you have a prototype in the works or will you have to restart from scratch due to the screen change?
Well first, I managed it to get rid of the price increase and I got rid of the directional stick. It is now 4 buttons.
Second, we have a new way how images are drawn. We have color palettes now. For the console we are using the full websafe color palette.
Following colors are in the palette:
(http://puu.sh/k9R9F/903abf21cd.png)
Additionally to that the user can define 39 own 16 bit colors to that. The color 0xFF is transparent in sprites and black when used on the drawing buffer.
And for whom that is not enough can directly draw 8 or 16 bit RGB to the display. We will support 1 bpp and 8 bpp (palette) sprites, loaded from SD into RAM.
As said before, the price stays at 49,99 EUR (without shipping and taxes) and might even drop below that (maybe).
We are still doing this for non-profit, so we will make the price as fair as possible.
The backside of the unit is either 3D printed or laser cut. We will probably make two versions to choose from, where the 3D printed one is of course cheaper and always included.
Great palette. Glad you included some shades of gray, too ^.^
Can you 3D-print for cheap?
Quote from: DJ Omnimaga on September 13, 2015, 07:29:58 PM
Great palette. Glad you included some shades of gray, too ^.^
Can you 3D-print for cheap?
Great that you like it.
For the test unit, I ordered a new OLED for testing for 53 EUR from Mouser (half of it was just shipping).
We can print the case for 1-2 EUR.
@adekto owns a 3D printer and gets the filliament for a good price.
i hope people dont mind the 3D prints, the plastic i use is PLA and probebly only limited colors
Quote from: adekto on September 13, 2015, 07:49:27 PM
i hope people dont mind the 3D prints, the plastic i use is PLA and probebly only limited colors
Well in case somebody doesn't like a 3D printed back, will be probably provide a laser cut back for a small extra fee.
Is there any kind of paint for plastic that won't peel off and still look professional? That could be a compromise for 3D-printed cases, but otherwise I don't mind unless my device is fluorescent pink :P
ALso I still hope that shipping fees won't eat too much of your money when ordering parts. Good luck.
Quote from: DJ Omnimaga on September 17, 2015, 03:16:08 AM
Is there any kind of paint for plastic that won't peel off and still look professional? That could be a compromise for 3D-printed cases, but otherwise I don't mind unless my device is fluorescent pink :P
ALso I still hope that shipping fees won't eat too much of your money when ordering parts. Good luck.
Well we thought about dark orange plastic on the back and the pcb visible on the front. The PCB will be black with white labels on the top. Also there will be no components on the top side of the PCB except for the buttons, the usb connector, the expanson port and the oled.
Also we made huge progress with the conversion tools. Any wave file can now be converted to Claw Audio and most of the image formats are working too.
We plan to offer following image formats:
- 1 bit per pixel (8 pixel per byte) micro palette / monochrome (foreground color selectable from big palette)
- 2 bit per pixel (4 pixel per byte) tiny palette (3 colors selectable from big palette)
- 4 bit per pixel (2 pixel per byte) palette (15 colors selectable from big palette)
- 8 bit per pixel big palette (217 predefined colors and 39 user selectable ones)
For audio, there is the claw audio format, which is essentially a riff wave based one.
It allows for mono audio, standard sample rates, 16 bit per sample, autor + comment + title metadata.
Quote from: adekto on September 13, 2015, 07:49:27 PM
i hope people dont mind the 3D prints, the plastic i use is PLA and probebly only limited colors
Hmmm is it possible to use ABS instead ? PLA isn't the best for casing, especially if you're going to use screws to hold it together because it's too brittle.
Quote from: DarkestEx on September 23, 2015, 07:41:16 PM
Quote from: DJ Omnimaga on September 17, 2015, 03:16:08 AM
Is there any kind of paint for plastic that won't peel off and still look professional? That could be a compromise for 3D-printed cases, but otherwise I don't mind unless my device is fluorescent pink :P
ALso I still hope that shipping fees won't eat too much of your money when ordering parts. Good luck.
Well we thought about dark orange plastic on the back and the pcb visible on the front. The PCB will be black with white labels on the top. Also there will be no components on the top side of the PCB except for the buttons, the usb connector, the expanson port and the oled.
Also we made huge progress with the conversion tools. Any wave file can now be converted to Claw Audio and most of the image formats are working too.
We plan to offer following image formats:
- 1 bit per pixel (8 pixel per byte) monochrome (back and forecolor selectable when drawing; probably its more like a 2 color paletted image
- 4 bit per pixel (2 pixel per byte) tiny palette (15 colors user selectable)
- 8 bit per pixel palette (217 predefined colors and 39 user selectable ones)
- 16 bit per pixel RGB (RGB565 encoded)
For audio, there is the claw audio format, which is essentially a riff wave based one.
It allows for mono audio, standard sample rates, 16 bit per sample, autor + comment + title metadata.
This is our main chipset. We are still searching for good boost and buck converters therefore the ?.
| Description | Manufacturer | Part |
| ARM CPU | Atmel | ATSAM4S8BA-AU |
| WiFi SoC | Espressiv | EXP8266-07 |
| Audio amplifier with digital volume | Texas Instruments | LM4811 |
| Step up regulator 100mA 5v | ? | ? |
| Step down regulator 500mA 3.3v | ? | ? |
Seems promising. I actually like the freedom those specs seems to offer, especially the image color depth. I am curious about how close to assembling a prototype that actually boots (even if Hello world) you guys are, by the way? Is it still a long way off?
Quote from: Streetwalrus on September 23, 2015, 11:52:23 PM
Quote from: adekto on September 13, 2015, 07:49:27 PM
i hope people dont mind the 3D prints, the plastic i use is PLA and probebly only limited colors
Hmmm is it possible to use ABS instead ? PLA isn't the best for casing, especially if you're going to use screws to hold it together because it's too brittle.
I agree unless you can get PLA at a really reduced cost.
Quote from: alexgt on September 24, 2015, 02:51:37 AM
Quote from: Streetwalrus on September 23, 2015, 11:52:23 PM
Quote from: adekto on September 13, 2015, 07:49:27 PM
i hope people dont mind the 3D prints, the plastic i use is PLA and probebly only limited colors
Hmmm is it possible to use ABS instead ? PLA isn't the best for casing, especially if you're going to use screws to hold it together because it's too brittle.
I agree unless you can get PLA at a really reduced cost.
PLA is the cheapest we can do.
The case is only going to cost us about 1 euro.
We sadly have no 3D printer that can print ABS.
Maybe at school but i guess its not allowed.
Is PLA really too fragile to be used for cases? I guess you could start with that and if the console gets very popular you could invest a little into ABS. Or maybe the latter could be a premium feature?
Also I heard that those two plastics get malleable when heated. Do you think the console will generate some heat when in use for a while? It might be wise to include some ventilation in such case, in case when the console gets warm it results into the plastic bending and stuff.
Quote from: DJ Omnimaga on September 24, 2015, 06:02:35 AM
Is PLA really too fragile to be used for cases? I guess you could start with that and if the console gets very popular you could invest a little into ABS. Or maybe the latter could be a premium feature?
Also I heard that those two plastics get malleable when heated. Do you think the console will generate some heat when in use for a while? It might be wise to include some ventilation in such case, in case when the console gets warm it results into the plastic bending and stuff.
Well we need to experiment with the plastic to see if it is really that fragile.
For the abs, we would need a whole new 3D printer to use abs, which is beyond any financial resources we have.
About heat i don't know. We need to test. It will probably generate some.
PLA is more sensitive to heat than ABS by the way.
Quote from: Streetwalrus on September 24, 2015, 10:29:18 AM
PLA is more sensitive to heat than ABS by the way.
Well we only have two options, Laser cut something or print PLA.
ABS is probably not an option and laser cut is not planned (the company did not reply back so I need to find another).
Some companies tend to take several weeks to reply to anything, for some reasons. I got this experience when contacting Casio support for a PRIZM bug report.
A screen size of 128x128 with a depth of 8-16...
Is this me or the specs are very similar to the Pico-8 ?
Deliberate or simply a coincidence ?
Hmmm...
Quote from: gameblabla on September 27, 2015, 11:25:50 AM
A screen size of 128x128 with a depth of 8-16...
Is this me or the specs are very similar to the Pico-8 ?
Deliberate or simply a coincidence ?
Hmmm...
Well it was simply a coincidence. Thereoretically it is absolutely possible to run Lua on it, just to note that.
If somebody is interested porting the Pico-8 API, these games would run on actual hardware :)
Quote from: DJ Omnimaga on September 26, 2015, 03:36:54 AM
Some companies tend to take several weeks to reply to anything, for some reasons. I got this experience when contacting Casio support for a PRIZM bug report.
Ok, I will give them some more time, but they didn't answered for over 1 month now.
128x128 reminds me a bit of the Game Boy. In any case, would the buttons be placed on each side of the screen? Because that could allow the console to be rather compact.
And if anyone is really concerned about the 1:1 aspect ratio, then he can always simulate a dual-screen console and have 1 half of the screen for gameplay area and the 2nd half for the menu and HUD or mission briefings.
Quote from: DJ Omnimaga on September 28, 2015, 03:53:11 AM
128x128 reminds me a bit of the Game Boy. In any case, would the buttons be placed on each side of the screen? Because that could allow the console to be rather compact.
And if anyone is really concerned about the 1:1 aspect ratio, then he can always simulate a dual-screen console and have 1 half of the screen for gameplay area and the 2nd half for the menu and HUD or mission briefings.
Yes buttons will be placed right and left from the screen. The console will be rectangular.
Also yes one can use these areas of the screen differently.
Apart from that the new screen size is really an improve over the old one.
I don't know if I asked this before, but among the parts that you have gotten so far, how much do they cost in total? Can you get them in large numbers for cheaper per pieces? (eg 1 for $3, 5 for $10, 80 for $100, 1200 for $1000)?
Quote from: DJ Omnimaga on September 28, 2015, 05:38:19 AM
I don't know if I asked this before, but among the parts that you have gotten so far, how much do they cost in total? Can you get them in large numbers for cheaper per pieces? (eg 1 for $3, 5 for $10, 80 for $100, 1200 for $1000)?
Following total part costs are per unit and come right out of my spreadsheet. They might change in the future.
38,43 € at 50 units sold total
34,49 € at 100 units sold total
30,32 € at 500 units sold total
Every part as in every single thing that the console will contain once finished, or just every part as in the ones you have bought so far? I forgot if you had bought every single part already (at least for the current planned product revision).
Quote from: DJ Omnimaga on September 28, 2015, 05:47:17 AM
Every part as in every single thing that the console will contain once finished, or just every part as in the ones you have bought so far? I forgot if you had bought every single part already (at least for the current planned product revision).
Well these prices relate to the total price of all parts that we planned in so far, when we buy them after we hopefully got funded.
Oh ok, thanks for clarifying. Good luck with the funding (although that shouldn't be now since people will probably wait until there's a working prototype on Youtube. One step at a time) :)
Also regardless of if you decide to make this console non-profit or not, you should probably not make that a permanent agreement nor really make the console non-profit. You should at least try to make the bare minimum just in case you ever hit a roadblock such as part price increases or building issues. That would be better so that you don't actually lose money either.
Quote from: DJ Omnimaga on September 28, 2015, 05:52:13 AM
Oh ok, thanks for clarifying. Good luck with the funding (although that shouldn't be now since people will probably wait until there's a working prototype on Youtube. One step at a time) :)
Also regardless of if you decide to make this console non-profit or not, you should probably not make that a permanent agreement nor really make the console non-profit. You should at least try to make the bare minimum just in case you ever hit a roadblock such as part price increases or building issues. That would be better so that you don't actually lose money either.
Well we absolutely plan making this non-profit, or atleast with very little profit (we have a small money buffer in case it anything costs more than expected). In the unlikely case that everything goes alright without any extra costs, we get a very small amount of profit (under 100 euro currently).
Also, I am working on the serial protocol between the WiFi processor and the main core ARM. They will be using async serial at up to 128KB/s.
This (http://docs.ninjabyte.eu/microcat/ClawWire.pdf) is the preliminary protocol I came up with. What do you think?
EDIT: You can always find the latest version of the protocol here: http://docs.ninjabyte.eu/microcat/ClawWire.php
Yeah a money buffer is what I meant. I see so many non-profit organizations around here dying because they can no longer afford to operate.
And by serial do you mean like on the TI-Nspire or old serial ports that computers used to have? Or is it a different protocol? I am confused since you mention WiFi.
Quote from: DJ Omnimaga on October 07, 2015, 03:24:45 AM
Yeah a money buffer is what I meant. I see so many non-profit organizations around here dying because they can no longer afford to operate.
And by serial do you mean like on the TI-Nspire or old serial ports that computers used to have? Or is it a different protocol? I am confused since you mention WiFi.
With serial I mean like Arduino like serial so calles UART serial.
It is the interface between the WiFi chip and the main processor. It is used for firmware upgrading the WiFi chip and for any internet activity.
Oh I see now. Thanks for the info. Can't wait for more prigress. :)
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.
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!
Quote from: DJ Omnimaga on October 08, 2015, 06:34:56 AM
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.
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?
Quote from: DJ Omnimaga on October 08, 2015, 05:35:11 PM
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.
Oh right, the reset button would be handy, so we don't need to remove the battery all the time during testing. :P
Quote from: DJ Omnimaga on October 08, 2015, 08:29:45 PM
Oh right, the reset button would be handy, so we don't need to remove the battery all the time during testing. :P
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 :)
Just make sure to not use a deprecated battery nor a battery that costs as much as the console. :P
And nice about the emulator :D
Quote from: DJ Omnimaga on October 09, 2015, 08:20:25 PM
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 :D
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.
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 :)
Quote from: DJ Omnimaga on October 11, 2015, 06:36:22 PM
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.
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?
Quote from: DJ Omnimaga on October 11, 2015, 07:20:54 PM
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.
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. :)
Quote from: DarkestEx on August 09, 2015, 09:50:08 PM
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
Quote from: Araidia on October 15, 2015, 01:05:10 AM
Quote from: DarkestEx on August 09, 2015, 09:50:08 PM
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
Sorry, I don't get the typo. What should I change?
Also I have sad news about the WiFi. It looks like that we can't do it as we can't order the ESP8266 from a reputable seller in big amounts and second, the ESP8266 isn't a good WiFi SoC.
We either change WiFi chips (If you have a suggestion) or we go for Bluetooth and internet using your phone or maybe the ESP will get more stable over time (maybe it isn't crashing that often anymore at some point with some firmware.
Quote from: DarkestEx on October 15, 2015, 05:07:04 PM
Quote from: Araidia on October 15, 2015, 01:05:10 AM
Quote from: DarkestEx on August 09, 2015, 09:50:08 PM
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
Sorry, I don't get the typo. What should I change?
Also I have sad news about the WiFi. It looks like that we can't do it as we can't order the ESP8266 from a reputable seller in big amounts and second, the ESP8266 isn't a good WiFi SoC.
We either change WiFi chips (If you have a suggestion) or we go for Bluetooth and internet using your phone or maybe the ESP will get more stable over time (maybe it isn't crashing that often anymore at some point with some firmware.
Finding a better one may be more expensive, but people are willing to spend the extra money for that. Having WiFi or not may be a game-changer for some.
Make WiFi optional. Ship the console without it but design the hardware to allow people to open it up and plug in their own esp8266 module. And of course this way you'll have to use USB for code upload and debugging (painless effort anyway).
Please though, for the love of everything good, do NOT use bluetooth. It's pretty common in laptops, phones and tablets but extremely rare in desktops (I don't have it even though I have wifi in my desktop). Also the whole thing just sucks in general.
Quote from: Streetwalrus on October 15, 2015, 05:28:34 PM
Make WiFi optional. Ship the console without it but design the hardware to allow people to open it up and plug in their own esp8266 module.
Well the problem is that first, the ESP8266 is horribly unstable and crashes all the time. I don't know if we can even make our own firmware for it, which would be required to do anything with WiFi at all (no, we won't use Frankenstein, NodeMCU or the crappy AT firmware as they all suck).
If the WiFi would be more stable (or maybe accessible over SPI) that all wouldn't be a problem.
Quote from: Araidia on October 15, 2015, 05:25:45 PM
Finding a better one may be more expensive, but people are willing to spend the extra money for that. Having WiFi or not may be a game-changer for some.
Yes, WiFi is important. I don't know if bluetooth could replace it. Well we could use internet supplied over a mobile phone which would certainly work, but in the end I don't know what would be better.
That's why I'm suggesting making it optional, this way if someone really wants it despite the issues they can have it. Wifi is pretty useless on such a device anyway. Also I edited my post above.
Quote from: Streetwalrus on October 15, 2015, 05:33:02 PM
That's why I'm suggesting making it optional, this way if someone really wants it despite the issues they can have it. Wifi is pretty useless on such a device anyway. Also I edited my post above.
Hmm yea Bluetooth couldn't really replace it. Also we can't make it optional. Not really. The reason is, that the form factor doesn't allow for the thick ESP8266 module but only for the canned SMD ones which we would be using. I mean, the WiFi is about 3 EUR in parts and we might find somebody who can sell us a few hundered of these I am sure. But the problem is the ESP8266 being unstable. Of course if people don't mind the WiFi crashing at times and having the ARM core to reset the ESP every here and then and the WiFi being slow, there is no problem. We can certainly come up with the firmware we planned and we can make a lot of error detection into it. The only real issue is the instability.
"Slow" is a little exaggerated lol, this kind of machine really doesn't need much bandwidth.
Quote from: Streetwalrus on October 15, 2015, 05:42:28 PM
"Slow" is a little exaggerated lol, this kind of machine really doesn't need much bandwidth.
But it what it needs is 64 Gigabytes of ram and a terabyte of storage
:P
Quote from: DarkestEx on October 15, 2015, 05:07:04 PM
Quote from: Araidia on October 15, 2015, 01:05:10 AM
Quote from: DarkestEx on August 09, 2015, 09:50:08 PM
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
Sorry, I don't get the typo. What should I change?
The last preliminary spec says: "USB 2.0 full speed, host and slave"
It should be "save" instead of "slave"
Quote from: Araidia on October 15, 2015, 05:52:12 PM
The last preliminary spec says: "USB 2.0 full speed, host and slave"
It should be "save" instead of "slave"
Nope, slave is the correct word there. It means that the device can be plugged into a computer, or things like mice and keyboards can plug into it, like it was a computer. "Host" means stuff can plug into it, and "slave" means it can plug into stuff.
Quote from: Ivoah on October 15, 2015, 06:12:31 PM
Quote from: Araidia on October 15, 2015, 05:52:12 PM
The last preliminary spec says: "USB 2.0 full speed, host and slave"
It should be "save" instead of "slave"
Nope, slave is the correct word there. It means that the device can be plugged into a computer, or things like mice and keyboards can plug into it, like it was a computer. "Host" means stuff can plug into it, and "slave" means it can plug into stuff.
Well, I'm dumb. At least I learned something today.
Sorry for the inconveniences
Quote from: Araidia on October 15, 2015, 06:14:10 PM
Quote from: Ivoah on October 15, 2015, 06:12:31 PM
Quote from: Araidia on October 15, 2015, 05:52:12 PM
The last preliminary spec says: "USB 2.0 full speed, host and slave"
It should be "save" instead of "slave"
Nope, slave is the correct word there. It means that the device can be plugged into a computer, or things like mice and keyboards can plug into it, like it was a computer. "Host" means stuff can plug into it, and "slave" means it can plug into stuff.
Well, I'm dumb. At least I learned something today.
Sorry for the inconveniences
No problem, glad you learned something :)
The proper word is device if you wanna be picky (that's the official terminology for USB).
Quote from: Streetwalrus on October 15, 2015, 06:18:33 PM
The proper word is device if you wanna be picky (that's the official terminology for USB).
Really? I always thought the correct term was "slave" I guess I learned something new today too.
Yeah, while most buses use the words master and slave, USB uses host and device.
Quote from: Ivoah on October 15, 2015, 06:19:50 PM
Quote from: Streetwalrus on October 15, 2015, 06:18:33 PM
The proper word is device if you wanna be picky (that's the official terminology for USB).
Really? I always thought the correct term was "slave" I guess I learned something new today too.
I guess I learned something too. Well I will change it.
Quote from: Araidia on October 15, 2015, 05:52:12 PM
Quote from: Streetwalrus on October 15, 2015, 05:42:28 PM
"Slow" is a little exaggerated lol, this kind of machine really doesn't need much bandwidth.
But it what it needs is 64 Gigabytes of ram and a terabyte of storage
:P
Well 64 GB of RAM is obviously not possible. But the 1 TB of storage actually is. We have full SDIO support and we implement FAT32 which supports up to 2 TB of storage. But in reality we will only support SD cards up to 32 GB. If we want to save some more RAM we could go for 4 GB as maximum SD card size too.
Quote from: Streetwalrus on October 15, 2015, 05:42:28 PM
"Slow" is a little exaggerated lol, this kind of machine really doesn't need much bandwidth.
Well slow isn't that big of a deal. We might get up to maybe 100KB/s of maximum speed (theoretical) using maximum serial speed.
The bigger problem really is the stability of the ESP8266. It's very unstable and tends to crash very often.
Wi-Fi could be handy for multiplayer games, but for such old school hardware, maybe linked play could be a better option, via USB or something. Given the community nature of this console, I doubt there would be many multiplayer games on it anyway.
I'm still gonna buy it even if it lacks wifi.
I say keep the wifi. It won't be able to do too much, due to the limited ram in the cpu, but it will allow for some fun like pong online or something. And since most people using the microcat(at least for now), are calc users, it will provide a sense of unity.
Quote from: semiprocoder on October 17, 2015, 03:35:47 AM
I say keep the wifi. It won't be able to do too much, due to the limited ram in the cpu, but it will allow for some fun like pong online or something. And since most people using the microcat(at least for now), are calc users, it will provide a sense of unity.
Quote from: DJ Omnimaga on October 17, 2015, 02:56:25 AM
Wi-Fi could be handy for multiplayer games, but for such old school hardware, maybe linked play could be a better option, via USB or something. Given the community nature of this console, I doubt there would be many multiplayer games on it anyway.
I'm still gonna buy it even if it lacks wifi.
Well after all I am pretty sure that I will keep the WiFi as its a nice feature in my opinion. It is only about 2-3 euros and even though it tends to be unstable, I am sure that we get it to a usable state. Actually I am not sure whether the chip or just the two firmwares that I tried were unstable (Frankenstein worked just fine and was stable; nodeMCU and the original AT firmware are very unstable).
About WiFi games, I am sure real time games are possible, but they are hard. Turn based ones will work in any case.
Estimated speed of the internet is about 50 - 100KB/s. So it is possible to use some easy binary format to do real time multiplayer in some games.
About RAM, internet won't use any ram at all. It will all be done in the ESP 8266s processor. I will program it to make internet things way easier, and it will contain the network stack. The ESP will be user reprogrammable. The arm can program the esp at any time.
I already want to say thanks in advance to anyone who's interested in buying or supporting it :D
50 units need to be sold so that we can get the project running. With the base model we do make a calculated loss. At 50 units the single unit (45 euro) would make us loose 30%. That's why the starter kit (59 euro) is a little more expensive than it needs to be.
The starter kit really is for people who want to support us additionally or who are beginners. The base kit will require preparing and an own SD card (I will make a program to do so). The starter kit includes a SD card already prepared, a pouch (probably), an mini USB cable and a USB host cable (to hook up keyboard and mouse).
Another thing that we were thinking is having an x2 mode, that allows allows drawing inside the first 64*64 pixels and everything will be scaled up while drawn. That mode could be toggled on and off. The reason why this mode could be done is, that the display has such a high resolution, that we could afford this mode for readability and visibility of things.
We made some progress :)
Below are some pictures of the display working. Iwert wrote some code to test the display on the Arduino Due with the exact same palette and colors that the microcat will have. These images give a good preview of what the microcat's screen will behave and look like.
The diagonal lines are caused by the camera, they are not visible to the human eye.
[spoiler=Images]
(http://i.imgur.com/ema3bBG.jpg)
(http://i.imgur.com/DmSnXua.jpg)
(http://i.imgur.com/sB3YRxv.jpg)
[/spoiler]
I definitively think that you should try breaking even from the start. Losing money on 50 consoles would definitively add up fast to the money you already invested so far. Unless this includes what you have invested so far?
Also I like the progress so far. I'm glad to see that the hardware is progressing. How much completion percentage would you give to the prototype's internal hardware without the case so far?
Also a 64x64 mode would be cool for people would want to go even more old school or have more speed. :)
Quote from: DJ Omnimaga on October 17, 2015, 10:40:50 PM
I definitively think that you should try breaking even from the start. Losing money on 50 consoles would definitively add up fast to the money you already invested so far. Unless this includes what you have invested so far?
Also I like the progress so far. I'm glad to see that the hardware is progressing. How much completion percentage would you give to the prototype's internal hardware without the case so far?
Also a 64x64 mode would be cool for people would want to go even more old school or have more speed. :)
No, this is actual loss. We have about 130 euros that we have to cover using the overshoot in the starter kits price.
But at 100 consoles its all covered. As we can't change the price during the campaign, we want to stay as cheap as possible with the 50 units.
Well we have basically like 10% progress in the prototype. The actual processor is not yet fully working and I haven't hooked up some components yet.
But the basic plan is done, but I haven't copied it into KiCad so far.
I think you should just make it so that anyone can pay anything they want for the microcat to support it, starting at 45 euros. It will be like the donations you can give to processing to support the project. Also maybe make the starting price 50 euros, just in case. Moreover, why does this use usb mini, not micro or usb c? Is it more expensive?
Quote from: DarkestEx on October 17, 2015, 11:13:50 PM
Quote from: DJ Omnimaga on October 17, 2015, 10:40:50 PM
I definitively think that you should try breaking even from the start. Losing money on 50 consoles would definitively add up fast to the money you already invested so far. Unless this includes what you have invested so far?
Also I like the progress so far. I'm glad to see that the hardware is progressing. How much completion percentage would you give to the prototype's internal hardware without the case so far?
Also a 64x64 mode would be cool for people would want to go even more old school or have more speed. :)
No, this is actual loss. We have about 130 euros that we have to cover using the overshoot in the starter kits price.
But at 100 consoles its all covered. As we can't change the price during the campaign, we want to stay as cheap as possible with the 50 units.
Well we have basically like 10% progress in the prototype. The actual processor is not yet fully working and I haven't hooked up some components yet.
But the basic plan is done, but I haven't copied it into KiCad so far.
I see. I'm definitively hoping for the completion of this project and that it gets attention over big sites once it reaches a state where it can play actual games and have some firmware allowing to launch them. The losses would then be turned into profit (or at least enough money to cover the initial development costs/losses).
Also will the console have some protection against bricking if someone plays a game then pulls the SD card during gameplay? People normally would use common sense about that, but kids might not necessarily know.
Quote from: semiprocoder on October 18, 2015, 12:01:41 AM
I think you should just make it so that anyone can pay anything they want for the microcat to support it, starting at 45 euros. It will be like the donations you can give to processing to support the project. Also maybe make the starting price 50 euros, just in case. Moreover, why does this use usb mini, not micro or usb c? Is it more expensive?
Well we would really like to do it this way, but kickstarter or similar sites sadly don't support it. We could though make some special badges to support us.
About the 45 euro, we could still go up to 50 in case something goes wrong, but if we sell more than 100, we would have a drastic decrease in total cost while keeping the old retail price.
We choose mini USB over micro USB, because mini USB is a lot more durable than the fragile micro USB. We don't want the connector to shear off under any circumstances.
Quote from: DJ Omnimaga on October 18, 2015, 02:44:11 AM
Quote from: DarkestEx on October 17, 2015, 11:13:50 PM
Quote from: DJ Omnimaga on October 17, 2015, 10:40:50 PM
I definitively think that you should try breaking even from the start. Losing money on 50 consoles would definitively add up fast to the money you already invested so far. Unless this includes what you have invested so far?
Also I like the progress so far. I'm glad to see that the hardware is progressing. How much completion percentage would you give to the prototype's internal hardware without the case so far?
Also a 64x64 mode would be cool for people would want to go even more old school or have more speed. :)
No, this is actual loss. We have about 130 euros that we have to cover using the overshoot in the starter kits price.
But at 100 consoles its all covered. As we can't change the price during the campaign, we want to stay as cheap as possible with the 50 units.
Well we have basically like 10% progress in the prototype. The actual processor is not yet fully working and I haven't hooked up some components yet.
But the basic plan is done, but I haven't copied it into KiCad so far.
I see. I'm definitively hoping for the completion of this project and that it gets attention over big sites once it reaches a state where it can play actual games and have some firmware allowing to launch them. The losses would then be turned into profit (or at least enough money to cover the initial development costs/losses).
Also will the console have some protection against bricking if someone plays a game then pulls the SD card during gameplay? People normally would use common sense about that, but kids might not necessarily know.
About the 64x64, they don't give any speed increase at all. Only a slight speed decrease. But they significantly lower the ram usage by up to 50%.
I do really hope for this project to succeed. We will finish it under any circumstances. The only real problem is selling it, as we don't know about laws. And of course do we hope to get the development costs back, but even if we don't, we still learned a lot.
The console won't brick, if the SD card is removed while the console is turned on. But the SD card might corrupt. The console itself is never turned of completely; it's always in a low power standby mode with all peripherals disabled. People could even wake it up at a specific time if they want to. The low power standby only draws about 5uA which is even lower than the natural discharge rate of a LiPo so it won't be noticeable.
Even if the console gets powered off during firmware flashing, we want to provide an option to unbrick it by placing the firmware file on the SD card and rebooting. Also we want to use Atmels USB or Serial bootloader that is burned into the internal ROM to be able to recover it.
Quote from: DarkestEx on October 18, 2015, 09:55:40 AM
We choose mini USB over micro USB, because mini USB is a lot more durable than the fragile micro USB. We don't want the connector to shear off under any circumstances.
This is a good decision. Micro USB is hardly thinner than mini and it's extremely fragile, mini feels very solid on comparison. Type C is a good thing but it's not popular enough yet to be used for this. Also pretty much everyone should have a mini USB cable at home.
I thought that micro usb has more insertion cycles than mini usb. Something about micro usb having twice the lifetime of mino usb for plugging in and out.
It's supposed to be the case but in practice breaking a micro USB connector is very easy. I broke countless cables and even though I haven't broken any female connectors a lot of people have. Never heard of that for mini USB.
But maybe their are less reports about broken mini because micro is more spread today. Anyway, I don't care about which type of USB it is, but I also never broke a usb female/male adapter.
Mini USB is still very widespread and was used for over a decade before micro got popularized (even though mini is deprecated since 2007). I haven't had a single case of a cable breaking. But we're getting way off topic here. :P
We could always switch to micro USB but mini USB is just stronger and they both support USB OTG.
I don't care about which USB port is being used, as long as it's not deprecated (or if it is then the console should come with a cable in case people can no longer find any for sale anywhere). Nowadays, both mini and micro are common, but we never know how it will be when Microcat comes out.
Quote from: DJ Omnimaga
I don't care about which USB port is being used, as long as it's not deprecated (or if it is then the console should come with a cable in case people can no longer find any for sale anywhere). Nowadays, both mini and micro are common, but we never know how it will be when Microcat comes out.
Well I don't think USB mini cables won't be available in a few years anymore. The bare console won't come with any accessories (no SD, no cables) but the starter kit will. It contains the console, a mini USB cable (to charge it and connect it to a PC), a mini USB OTG cable (to connect USB devices to the microcat) and a micro SD card with the OS preinstalled.
hi guys just want to mention im doing the alpha branch on arduino, its more for proof of concept for the display buffer and all that
curently looking into realtime interpreters (been playing around with basic, but havent been able to display and run it at the same time)
any ideas for this are welcome
heres the working display buffer with a sprite and a background that sets random pixels in random colors
https://www.youtube.com/watch?v=wuG4EgBKaSo (https://www.youtube.com/watch?v=wuG4EgBKaSo)
After some more research and after talking to my uncle I think that I might go back and use serial for communication between the display and the processor, as serial communication is more stable and allows faster speeds than parallel does.
In a parallel bus, factors like trace inductance and length massively affect the maximum speed of the bus, as not all signals arrive at the same time, so the master has to wait until all signals arrive at the device. So I will switch back to serial (SPI) based communication with the OLED.
Quote from: adekto on October 19, 2015, 09:07:57 AM
hi guys just want to mention im doing the alpha branch on arduino, its more for proof of concept for the display buffer and all that
curently looking into realtime interpreters (been playing around with basic, but havent been able to display and run it at the same time)
any ideas for this are welcome
heres the working display buffer with a sprite and a background that sets random pixels in random colors
https://www.youtube.com/watch?v=wuG4EgBKaSo (https://www.youtube.com/watch?v=wuG4EgBKaSo)
Wouldn't this be better as a separate thread?
Probably get better feedback than here.
It's the microcat OLED, but not powered by the actual hardware of the actual microcat (yet), so this is the right topic I guess.
Quote from: p4nix on October 19, 2015, 02:39:11 PM
It's the microcat OLED, but not powered by the actual hardware of the actual microcat (yet), so this is the right topic I guess.
Yes its alright. I am just porting his code to the actual hardware that finally works since today :D
All the images are made with the microcat color palette then, i guess.
Quote from: p4nix on October 19, 2015, 03:19:43 PM
All the images are made with the microcat color palette then, i guess.
Yes, but now the prototype has a working display and working processor, so we will switch to it now.
We did it! The processor works finally after more than 6 weeks and the display does work now too ;D
It works stable up to its maximum frequency of 120MHz, which we reach using the PLL.
(http://i.imgur.com/kJdMBRh.jpg)
(http://i.imgur.com/E3vKPpi.jpg)
Quote from: DarkestEx on October 19, 2015, 10:10:43 AM
After some more research and after talking to my uncle I think that I might go back and use serial for communication between the display and the processor, as serial communication is more stable and allows faster speeds than parallel does.
In a parallel bus, factors like trace inductance and length massively affect the maximum speed of the bus, as not all signals arrive at the same time, so the master has to wait until all signals arrive at the device. So I will switch back to serial (SPI) based communication with the OLED.
Regarding that, after running the OLED as maximum SPI speed, SPI is barely fast enough. We will switch to parallel on the final unit if it works.
I think you shouldn't worry too much about that, you're not running at extreme clocks so it should be ok.
Also congrats on getting it to work.
Congrats DarkestEx and Adekto. I'm glad that this project is getting more and more into hardware format.
Quote from: DJ Omnimaga on October 27, 2015, 05:17:57 PM
Congrats DarkestEx and Adekto. I'm glad that this project is getting more and more into hardware format.
Thanks :)
Here is a picture of the now competed BIOSes tiny text buffer in action:
(http://i.imgur.com/8ApV00G.jpg)
Good job. Are there risks of bricking the device if it loses power during booting or shutdown? Or does the bricking protection protects Microcat against that?
Quote from: DJ Omnimaga on October 28, 2015, 04:11:21 AM
Good job. Are there risks of bricking the device if it loses power during booting or shutdown? Or does the bricking protection protects Microcat against that?
There are no moving parts or anything that could brick it. But resetting it without a proper shutdown shell only be done on a freeze crash that is not handled by the chip itself. It might corrupt the data on the SD card.
Ok phew, will the SD card still be formatable afterwards ir useless for any use?
Also I forgot: What is the max SD card size allowed? And what about SDHC?
Quote from: DJ Omnimaga on October 28, 2015, 06:06:16 AM
Ok phew, will the SD card still be formatable afterwards ir useless for any use?
Also I forgot: What is the max SD card size allowed? And what about SDHC?
Maximum supported SD card size will be 32 GB. SDHC will absolutely be supported.
The SD card is normally always reformattable but you can destroy files on it.
Ah ok good, I was worried because it seemed like SDHC was slowly replacing SD so it would have sucked if the console only supported a format that could be discontinued in a few years. And if it only supported SD or micro-SD cards up to 1 GB like some phones then it would be problematic for large games with audio.
Quote from: DJ Omnimaga on October 28, 2015, 05:29:51 PM
Ah ok good, I was worried because it seemed like SDHC was slowly replacing SD so it would have sucked if the console only supported a format that could be discontinued in a few years. And if it only supported SD or micro-SD cards up to 1 GB like some phones then it would be problematic for large games with audio.
Well sure we want to keep it compatible and support SDHC but I really doubt that a normal user will fill even 250 MB of their SD card with actual games or their data.
I was more wondering if some games had particularly elaborate audio. I know that music will be compressed and stuff but if for example 20 games have 30 minutes of OST each and 250 KB of code, wouldn't that add up fast? I would be fine with just 1 GB, though.
Quote from: DJ Omnimaga on October 28, 2015, 05:53:55 PM
I was more wondering if some games had particularly elaborate audio. I know that music will be compressed and stuff but if for example 20 games have 30 minutes of OST each and 250 KB of code, wouldn't that add up fast? I would be fine with just 1 GB, though.
Sure it could add up, but first, I was thinking about going to simple chiptune audio even though the processor does support outputting CD quality audio (16 bit) which would reduce the size drastically.
Also IMO 1GB is more than enough.
Awesome news!
Hardware recognition finally works in the BIOS!
We can now determine RAM size and configuration at run time.
(http://i.imgur.com/ZlhZFAD.jpg)
Quote from: DarkestEx on October 28, 2015, 06:39:23 PM
Awesome news!
Hardware recognition finally works in the BIOS!
We can now determine RAM size and configuration at run time.
Looks awesome! Did you ever decide what size to make the stack?
Quote from: Max Leiter on October 28, 2015, 06:40:27 PM
Quote from: DarkestEx on October 28, 2015, 06:39:23 PM
Awesome news!
Hardware recognition finally works in the BIOS!
We can now determine RAM size and configuration at run time.
Looks awesome! Did you ever decide what size to make the stack?
Thanks :)
Well as I will have two stacks (one tiny for the BIOS and a larger one for the OS), the BIOS stack is 750 bytes right now. I might increase it if necessary in the future.
Whoa that looks awesome :D Nice job!
its really shaping up :)
Good job DarkestEx :)
Thanks :)
Here is the image of my setup and the new bootloader layout:
(http://i.imgur.com/EtnlDlA.jpg)
Looks very good, I can't wait to see it with the game pad and command input in action :)
Controls are not too hard and should be done soon.
First I will get the BIOS done, which is quite a bit of work.
Here is a new high resolution gallery of the latest setup and BIOS layout:
[spoiler]
(http://i.imgur.com/Q2RdPkK.jpg)
(http://i.imgur.com/st8qMx7.jpg)
(http://i.imgur.com/evy4ie8.jpg)
[/spoiler]
THanks for the pics :) Also good to hear. I hope the screen was not damaged too much by the sparking you mentioned earlier on IRC. Could you clarify about what might have caused the sparking? I was unsure if I understood on IRC.
Quote from: DJ Omnimaga on October 28, 2015, 10:18:21 PM
THanks for the pics :) Also good to hear. I hope the screen was not damaged too much by the sparking you mentioned earlier on IRC. Could you clarify about what might have caused the sparking? I was unsure if I understood on IRC.
Well I have a wool carpet in my room and I had socks on. When I came back getting some parts, the action of walking over the carpet had generated an electrostatic charge inside me. When I grabbed the oled to move it out of the way, the charge arced over to the oled's frame.
A few minutes later the oled went black and I was not able to turn it back on. While I was searching for a new oled, about half an hour after it went black, the oled suddenly started to live again.
Attached are the new icons that we added to the BIOS. They can be all used inside the BIOS or in applications that make use of the BIOSes routines.
Also this are the icons in action:
(http://i.imgur.com/e1RDcAC.jpg)
Edit: Some fixes and a layout change:
(http://i.imgur.com/rKPiJBe.jpg)
The 6502 emulator is finally booting ;D
Here is a video of my setup for all who want to see it:
https://www.youtube.com/watch?v=ANFyX-wqNck
Nice job. :D
Wooo awesome :D
Wait, does it mean Microcat will be able to run scaled-down (TI-Boy SE style) NES and Atari 2600 games?
Either way, good job. I'm happy to see stuff running on this :)
EDIT: If it really runs BASIC, does it mean that we could actually make BASIC games (the old school language)? O.O
Well, judging by the video, it doesn't run very fast :P
But a text rpg or something could be done i guess, but there'd have to be a basic interpreter in the os.
you guys like to have basic?
wel there some wierd things in that video like the amount of ram is wierd
i still dont know why we are using 6502 version of basic
Quote from: Cumred_Snektron on October 31, 2015, 10:36:17 AM
Well, judging by the video, it doesn't run very fast [emoji14]
But a text rpg or something could be done i guess, but there'd have to be a basic interpreter in the os.
Well its not the BASIC but the screen redraw. I redraw the entire screen on every character send by the 6502 emulator. I will definitively optimize that.
When using the emulator without the display and using the serial console, its really fast.
Quote from: DJ Omnimaga on October 31, 2015, 05:28:44 AM
Wait, does it mean Microcat will be able to run scaled-down (TI-Boy SE style) NES and Atari 2600 games?
Either way, good job. I'm happy to see stuff running on this :)
EDIT: If it really runs BASIC, does it mean that we could actually make BASIC games (the old school language)? O.O
If people want we will indeed make a basic interpreter too. Its not too much work if most people here like to program in a token basic such as on the TI calculators :)
It doesn't seem too fast anyway. Is it the emulator being so slow or the redraw (last one would be fatal)?
Quote from: p4nix on October 31, 2015, 02:26:52 PM
It doesn't seem too fast anyway. Is it the emulator being so slow or the redraw (last one would be fatal)?
As I just said ;)
The emulator is really fast but the redaw is very slow. This is the fastest CPU and communication frequency over SPI.
We will be switching to parallel data communication later on, which should increase the speed by about 8 times.
How fast is displaying the same char on the whole screen without anything like emulators and stuff slowing down?
Quote from: p4nix on October 31, 2015, 02:31:45 PM
How fast is displaying the same char on the whole screen without anything like emulators and stuff slowing down?
I don't know and I can't measure it right now, but from earlier tests I know that the redraw rate is very poor.
I used some delays in the pixel drawing code as the CPU was too fast and overran the OLED. So in have a 5 CPU cycle delay per pixel.
The CPU frequency is roughly 120MHz. But its probably very imprecise as I use the internal oscillator and PLL that up times 10. But for breadboarding that works.
Quote from: p4nix on October 31, 2015, 02:31:45 PM
How fast is displaying the same char on the whole screen without anything like emulators and stuff slowing down?
we have some prototype code on a buffer that ran realy smooth, i dint have any way to calculated it perfectly but i say it was around 12 fps at least over spi on lesser hardware
Though we will probably be using parallel in the final console as it can give up to an IIRC 8 times speed increase.
Quote from: adekto on October 31, 2015, 12:30:07 PM
you guys like to have basic?
wel there some wierd things in that video like the amount of ram is wierd
i still dont know why we are using 6502 version of basic
I would be ok if the firmware excludes BASIC and has it as third-party application, but adding it would definitively be nice to allow more calculator programmers to get into Microcat development easily. I would probably not use BASIC as much as Lua, though, but having it would be nice for porting games like First Fantasy: Mana Force.
Quote from: DJ Omnimaga on November 01, 2015, 06:33:45 AM
Quote from: adekto on October 31, 2015, 12:30:07 PM
you guys like to have basic?
wel there some wierd things in that video like the amount of ram is wierd
i still dont know why we are using 6502 version of basic
I would be ok if the firmware excludes BASIC and has it as third-party application, but adding it would definitively be nice to allow more calculator programmers to get into Microcat development easily. I would probably not use BASIC as much as Lua, though, but having it would be nice for porting games like First Fantasy: Mana Force.
Well as you might know, porting a proper BASIC engine is almost as much work as Lua. If you would like to develop in Lua then others can learn it too. If so, the BASIC interpreter would be optional and might come later.
I don't know what many people want who are interested in the project. If anybody wants some features, please go and request them. I really appreciate any feedback, especially regarding the programming language. The worst that can happen is that it might not fit into the remaining space (for BIOS and Lua firmware releated wishes) or that I ask you to program it yourself.
Well, I think the current setup is very good hardware-side, except some problems with multiple voltage converters and stuff. In my opinion it should be programmable in every imaginable way - and should be as open as required to ensure people being able to hack some things. Also, people should be able to post their programs at one single point - preferable also a kind of 'App Store' on the device itself, since this would make the device also suitable for non-tech-related guys. It would be cool if it also comes with a kind of game-maker (maybe just Lua though) so that anyone can make great stuff. The firmware should definitely include a tilepainter and stuff - maybe it should even have access to an online sprite-database and sound-database. But for myself I'm fine with C :P
Quote from: p4nix on November 01, 2015, 02:05:07 PM
Well, I think the current setup is very good hardware-side, except some problems with multiple voltage converters and stuff. In my opinion it should be programmable in every imaginable way - and should be as open as required to ensure people being able to hack some things. Also, people should be able to post their programs at one single point - preferable also a kind of 'App Store' on the device itself, since this would make the device also suitable for non-tech-related guys. It would be cool if it also comes with a kind of game-maker (maybe just Lua though) so that anyone can make great stuff. The firmware should definitely include a tilepainter and stuff - maybe it should even have access to an online sprite-database and sound-database. But for myself I'm fine with C [emoji14]
The new BIOS will make it highly hackable. It will allow many new cool features and will drastically ease the development of custom ROMs.
The BIOS will abstract the C code away from the hardware while still maintaining powerful and hardware near development.
Using the BIOS people can load new firmware to the WiFi SOC and the processor. And they can dump firmware that allows to be dumped (will provide flags or certificates).
We also want to provide a powerful framework to develop custom ROMs.
And yes, we are planning some sort of app and graphics and music download service.
And of course will people be able to make games right on the device.
@c4ooo even though that it is not yet done, here is the current block diagram (https://drive.google.com/file/d/0B3L1-KGtJOR1Vnhwa2xGanNDNVk/view?usp=sharing), as I have holidays now and will be away for the next two days.
Quote from: DarkestEx on November 01, 2015, 11:08:03 AM
I don't know what many people want who are interested in the project. If anybody wants some features, please go and request them. I really appreciate any feedback, especially regarding the programming language. The worst that can happen is that it might not fit into the remaining space (for BIOS and Lua firmware releated wishes) or that I ask you to program it yourself.
Dual-booting or easy switching between firmwares. Or perhaps a Lua<>C mode that lets you reboot quickly into the other firmware back and forth? That way we can run both C and Lua games without having to reinstall another firmware over and over.
Perhaps there could be some libraries or routines for people who wants to quickly write games? But that would probably be only if there is enough space and if it doesn't make games less portable.
I would be ok with hosting games, as long as they aren't too large (eg with the audio and stuff, since CW only has 30 GB of disk space). You could otherwise add a download page on your site and stuff and it could be linked to via an extra sub-forum here and the games could also be included in CW downloads section (linking to original download).
im not sure abotu dual booting, if you want both c an lua and basic fermware on it its going to have to be its own special single version that can do all of these
i think we need to focus on one version of the fermwere for now, branching out now woul lead to incompatibilaty and instabilaty
Yeah, my worry is that DarkestEx said that the Lua firmware would only run Lua games and the C one would only run C games at first, and I feared it would be permanent. That would have caused issues because then we would need to make our games in both languages and the Microcat user reviews would probably suffer as a result of having two separate firmwares.
But yeah focus should be on one firmware IMHO for the time being. I'm glad that it's slowly coming along.
Quote from: DJ Omnimaga on November 02, 2015, 04:35:01 AM
Quote from: DarkestEx on November 01, 2015, 11:08:03 AM
I don't know what many people want who are interested in the project. If anybody wants some features, please go and request them. I really appreciate any feedback, especially regarding the programming language. The worst that can happen is that it might not fit into the remaining space (for BIOS and Lua firmware releated wishes) or that I ask you to program it yourself.
Dual-booting or easy switching between firmwares. Or perhaps a Lua<>C mode that lets you reboot quickly into the other firmware back and forth? That way we can run both C and Lua games without having to reinstall another firmware over and over.
Perhaps there could be some libraries or routines for people who wants to quickly write games? But that would probably be only if there is enough space and if it doesn't make games less portable.
I would be ok with hosting games, as long as they aren't too large (eg with the audio and stuff, since CW only has 30 GB of disk space). You could otherwise add a download page on your site and stuff and it could be linked to via an extra sub-forum here and the games could also be included in CW downloads section (linking to original download).
Well the BIOS will indeed support that. Lua is its own firmware (and the default one) and C games are just Games wrapped as firmware updates replacing the Lua / Basic firmware while you are playing them. They can make use of the many BIOS support functions to get started quickly.
Also thank you for offering to host them here. I'd really like that. Games can't be that big and the new audio format is really tiny compared to what we started with.
Quote from: DJ Omnimaga on November 02, 2015, 06:27:18 AM
Yeah, my worry is that DarkestEx said that the Lua firmware would only run Lua games and the C one would only run C games at first, and I feared it would be permanent. That would have caused issues because then we would need to make our games in both languages and the Microcat user reviews would probably suffer as a result of having two separate firmwares.
But yeah focus should be on one firmware IMHO for the time being. I'm glad that it's slowly coming along.
And kinda yes. The Lua firmware will only run Lua and potentially BASIC games. There is no real c firmware as I said as c games are really just temporary firmware updates.
Oh wait, that could be an idea as well for C games. As for audio I was worried since you once said it used real music, but compressed. If you take one of my 4 minutes long song, how large would it be if converted to your format and what would be the quality like?
Quote from: DJ Omnimaga on November 02, 2015, 07:46:35 AM
Oh wait, that could be an idea as well for C games. As for audio I was worried since you once said it used real music, but compressed. If you take one of my 4 minutes long song, how large would it be if converted to your format and what would be the quality like?
It really depends on the sample rate. How many tunes per second is your song approximately?
Do you mean BPM? Because it depends of the song. One Axe to Save us All is around 195 BPM I think. If you mean bitrate/sampling rate then it's 44.1 Khz uncompressed.
Quote from: DJ Omnimaga on November 02, 2015, 10:50:45 PM
Do you mean BPM? Because it depends of the song. One Axe to Save us All is around 195 BPM I think. If you mean bitrate/sampling rate then it's 44.1 Khz uncompressed.
What format is the song in? Wav, mp3 or some custom format?
The bandcamp versions were uploaded in WAV format. You can download them (if you pay $0.00 in the Buy field) in any format including FLAC and 320 kbps MP3, though.
Otherwise, most of my old songs were originally in 128 kbps MP3.
Quote from: DarkestEx on August 09, 2015, 09:50:08 PM
Preliminary specifications:
- ARMv7 Core @ 120 MHz
- 128 KB builtin RAM
Ok, why the extreme dirge of RAM? How much of a problem can 128 MB be? What do you expect to do with 128 KB? Why did you even consider a VM on that?
Quote from: bb010g on November 09, 2015, 05:55:41 AM
Quote from: DarkestEx on August 09, 2015, 09:50:08 PM
Preliminary specifications:
- ARMv7 Core @ 120 MHz
- 128 KB builtin RAM
Ok, why the extreme dirge of RAM? How much of a problem can 128 MB be? What do you expect to do with 128 KB? Why did you even consider a VM on that?
We can't have more RAM as we already went for one specific processor. 128 MB RAM is absolutely impossible. The 100 pin version of the chip does support external RAM of up to 32 MB though SRAM is quite pricy and it wouldn't be worth it.
Also this is not intended to be another Linux running console that can do everything. A little limitation tends to make more creative ;)
I expect great and awesome games from you all. You managed it to do awesome things with the bug riddled TI-OS and TI Basic and just 80KB of total RAM so 128KB can't be that much of a limitation. Though I have to say, as the display is color the sprites are larger in size, but that's why we support 4 different types of sprites that have a different amount of supported colors but can be mixed freely and still give a lot of room for creativity.
Implementing a VM is not consuming much RAM at all. I assume that the consumption of the VM is just a few hundred bytes of RAM and it does barely change with the number of variables created. Our custom programming language that can be compiled on the device is very tiny and consumes almost no RAM at all. We will also provide a C SDK so that games can be developed using that one too, but as C games itself need to be loaded into RAM, you can't make them unlimited in size opposed to the VM language which has unlimited program sizes as it streams from SD through a pipeline or similar technique.
I made First Fantasy in less than 128 KB of RAM on the CSE. Granted, this excludes the routines, but I am fairly sure that a lot can be done with such low amount of RAM, considering what old calcs can do.
Plus you can exchange maps/tiles/sound.
Quote from: DJ Omnimaga on November 09, 2015, 06:16:13 AM
I made First Fantasy in less than 128 KB of RAM on the CSE. Granted, this excludes the routines, but I am fairly sure that a lot can be done with such low amount of RAM, considering what old calcs can do.
I'm sure you can do it. In case you port First fantasy, would you rather use our new language or C?
Quote from: p4nix on November 09, 2015, 12:44:12 PM
Plus you can exchange maps/tiles/sound.
Indeed you can. Also the new language, which is called Claw BTW (yes I know that this is attempt 2 now as the first language sucked as it was too brainf***ing to write it - so this is Claw from now on) won't have garbage collection (yes this still exists today :() but use a block based approach (like C) to get rid of old variables and save a ton of processing and memory this way.
Since I'm new here I just discovered this project, it seems promising!
Keep up the good work people!
Also, not having Garbage Collection in your language is a good choice.
Quote from: add on November 09, 2015, 06:34:48 PM
Since I'm new here I just discovered this project, it seems promising!
Keep up the good work people!
Also, not having Garbage Collection in your language is a good choice.
Thanks, great that you like it :)
Quote from: DarkestEx on November 09, 2015, 04:32:58 PM
Quote from: DJ Omnimaga on November 09, 2015, 06:16:13 AM
I made First Fantasy in less than 128 KB of RAM on the CSE. Granted, this excludes the routines, but I am fairly sure that a lot can be done with such low amount of RAM, considering what old calcs can do.
I'm sure you can do it. In case you port First fantasy, would you rather use our new language or C?
Quote from: p4nix on November 09, 2015, 12:44:12 PM
Plus you can exchange maps/tiles/sound.
Indeed you can. Also the new language, which is called Claw BTW (yes I know that this is attempt 2 now as the first language sucked as it was too brainf***ing to write it - so this is Claw from now on) won't have garbage collection (yes this still exists today :() but use a block based approach (like C) to get rid of old variables and save a ton of processing and memory this way.
I would prefer to use the new language, assuming the syntax is very similar to TI-83 Plus BASIC or the graphical Axe commands.
As for lack of garbage collection, my only worry is having to reboot the console after every Claw game execution if the games are particularly RAM-hungry. This is a major issue on the HP Prime because when you run programs, the RAM is still used by them (or at least partly) so the next program you run has chances to not run properly.
Quote from: DJ Omnimaga on November 10, 2015, 06:47:52 AM
As for lack of garbage collection, my only worry is having to reboot the console after every Claw game execution if the games are particularly RAM-hungry. This is a major issue on the HP Prime because when you run programs, the RAM is still used by them (or at least partly) so the next program you run has chances to not run properly.
When there is no garbage collection there should be manual memory management. I'm sure he won't forget to include functions to release the memory used by a program, and the OS should automatically release leaked memory on program exit.
Quote from: DJ Omnimaga on November 10, 2015, 06:47:52 AM
Quote from: DarkestEx on November 09, 2015, 04:32:58 PM
Quote from: DJ Omnimaga on November 09, 2015, 06:16:13 AM
I made First Fantasy in less than 128 KB of RAM on the CSE. Granted, this excludes the routines, but I am fairly sure that a lot can be done with such low amount of RAM, considering what old calcs can do.
I'm sure you can do it. In case you port First fantasy, would you rather use our new language or C?
Quote from: p4nix on November 09, 2015, 12:44:12 PM
Plus you can exchange maps/tiles/sound.
Indeed you can. Also the new language, which is called Claw BTW (yes I know that this is attempt 2 now as the first language sucked as it was too brainf***ing to write it - so this is Claw from now on) won't have garbage collection (yes this still exists today :() but use a block based approach (like C) to get rid of old variables and save a ton of processing and memory this way.
I would prefer to use the new language, assuming the syntax is very similar to TI-83 Plus BASIC or the graphical Axe commands.
As for lack of garbage collection, my only worry is having to reboot the console after every Claw game execution if the games are particularly RAM-hungry. This is a major issue on the HP Prime because when you run programs, the RAM is still used by them (or at least partly) so the next program you run has chances to not run properly.
Erm, the language itself is somewhat similar to Lua or Basic in parts. But its something new after all and works differently in some parts. To make it easy, we are providing many features already known from BASIC, Lua or C but we added some extra functionality or require some other ways of writing some code. The only thing that is entirely different from what you are used to are the arrays and functions that return or use those. But apart from that I am sure you will get used to it pretty quickly :)
For the garbage collection ;):
Quoteuse a block based approach (like C) to get rid of old variables and save a ton of processing and memory this way
So basically we are using blocks like in C for variables management. Variables live until the block that they have been created in is left, then they are automatically deallocated and the memory is freed :)
Quote from: Streetwalrus on November 10, 2015, 12:17:46 PM
Quote from: DJ Omnimaga on November 10, 2015, 06:47:52 AM
As for lack of garbage collection, my only worry is having to reboot the console after every Claw game execution if the games are particularly RAM-hungry. This is a major issue on the HP Prime because when you run programs, the RAM is still used by them (or at least partly) so the next program you run has chances to not run properly.
When there is no garbage collection there should be manual memory management. I'm sure he won't forget to include functions to release the memory used by a program, and the OS should automatically release leaked memory on program exit.
Well as above, but we will provide some more instructions to deal with them inside the ASM blocks better.
We are facing a very big decision:
Change processor for the last time and ditch SD support, but have a memory mapped 16MB flash from where one could run games from. So no more size limit for c games but we would have to slow the processor down a little. We could also have expansion for RAM and flash as modules then.
Tell me what you think. Big c games and built-in flash (16MB) or SD card with claw (unlimited size games) and RAM loaded c.
The flash and new processor would cost something too. About additional 5 euros total. We could keep SD card for one more euro too (though it probably won't fit space wise).
IT'S DECIDED!
The microcat will now cost about 55 euros (we try to go below that again) and have built-in 16 MB of flash. It will loose the SD card support but gain support for huge C games and still support Claw.
16 MB of Flash would be nice, although I hope it won't fill too fast with large games. Would it actually save space inside the console by the way?
Also sorry i was extremely busy this weekend so far so I didn't reply yet. I hope you don't have to restart the hardware from scratch, though.
Wait. Is the new console not supporting sd because of the hardware change, or is it due to a price increase/some other reason?
I think it's due to lack of space inside the console.
Quote from: DJ Omnimaga on November 15, 2015, 02:38:55 AM
16 MB of Flash would be nice, although I hope it won't fill too fast with large games. Would it actually save space inside the console by the way?
Also sorry i was extremely busy this weekend so far so I didn't reply yet. I hope you don't have to restart the hardware from scratch, though.
Well we estimate games to be between .5 and 1 MB. About the hardware, we have to redo much and pay a lot more ourselves for prototyping.
But after all and some more calculations I think we can stay at 50 euros and not go up.
Quote from: semiprocoder on November 15, 2015, 02:46:45 AM
Wait. Is the new console not supporting sd because of the hardware change, or is it due to a price increase/some other reason?
Hardware change.
Quote from: DJ Omnimaga on November 15, 2015, 03:02:29 AM
I think it's due to lack of space inside the console.
Yes indeed.
Ok but do you think this will be the final hardware restart? Because with too many restarts, you'll waste lots of money with unused parts and eventually alienate the crowd that gives up easily on calculator projects that get rewritten from scratch 6 times before finally dying. I can understand that things won't work sometimes, though, but make sure to plan this new hardware revision as good as you can.
Quote from: DJ Omnimaga on November 15, 2015, 03:08:06 AM
Ok but do you think this will be the final hardware restart? Because with too many restarts, you'll waste lots of money with unused parts and eventually alienate the crowd that gives up easily on calculator projects that get rewritten from scratch 6 times before finally dying. I can understand that things won't work sometimes, though, but make sure to plan this new hardware revision as good as you can.
We were happy with the old hardware really. But many people want C games so we had to do something. We finally decided to restart again. For the last time guys, really!
I see now. Will Claw support be preserved?
Quote from: DJ Omnimaga on November 15, 2015, 03:51:39 AM
I see now. Will Claw support be preserved?
for the moment yes claw will be preserved with a bit adjustments since the memory format change
this has been a though one to sudenly drop a feature but it seems to be an improvment overal
I think we will either go back to the old SD card way or have flash as modules so that it can be replaced or upgraded. Like having a high speed board to board interconnect and having another PCB stacked (we have the space) and the flash chip(s) soldered on that. Then the flash could be replaced or upgraded by buying a new module (which would be reasonably cheap).
Please vote!
It's very, very important for the future of the microcat!
I voted. (first option)
While I would be ok if you were forced to switch to option 2, 16 MB of RAM means that we will only be able to have about 16 games at a time on the Microcat, which won't be convenient. Option 3 would be an alternative, but the price would get a bit too high I think and I'm unsure if I am a fan of having to buy upgrades to get more memory.
Quote from: DJ Omnimaga on November 16, 2015, 12:13:12 AM
I voted. (first option)
While I would be ok if you were forced to switch to option 2, 16 MB of RAM means that we will only be able to have about 16 games at a time on the Microcat, which won't be convenient. Option 3 would be an alternative, but the price would get a bit too high I think and I'm unsure if I am a fan of having to buy upgrades to get more memory.
Erm its 16 MB flash. And no we aren't forced to use it if people say the old approach was better and they don't care that much about C support. I just found a new, fourth solution.
Anyways to your question, no, games have different sizes. If your games tend to be 1MB in size each, then yes, you can only fit 16 of them unless you upgrade to 32 MB.
But I doubt any game will reach more than 512KB so you can fit about 32 by default or 64 when upgraded.
Oh right, my bad. Flash I mean. And yeah I meant even if it would have been the final decision I would have been ok with it. I prefer option 1, though.
As for game size I was taking in account moderately sized games with a significant OST (about 7 minutes of music each in average)
Quote from: DJ Omnimaga on November 16, 2015, 12:22:35 AM
Oh right, my bad. Flash I mean. And yeah I meant even if it would have been the final decision I would have been ok with it. I prefer option 1, though.
As for game size I was taking in account moderately sized games with a significant OST (about 7 minutes of music each in average)
Ah I see. Well that is why I prefer Claw as it has no limits for music or game code at all. And SD cards of up to 32GB allow for a lot of games.
I'm confused about the fourth option. What do you mean? Is it allowing both sd and flash, because I'm confused. If the fourth option weren't there, I would probably go with flash, due to c support, but why doesn't the sd card support c as much?
Quote from: semiprocoder on November 16, 2015, 02:39:17 AM
I'm confused about the fourth option. What do you mean? Is it allowing both sd and flash, because I'm confused. If the fourth option weren't there, I would probably go with flash, due to c support, but why doesn't the sd card support c as much?
The console would be entirely different in options 2-4. Option 4 is just a mix of option 2 and 3 that is cheaper overall.
So if official!
We will be keeping the cheaper, SD based solution as it really was a lot better that the flash based one.
C games will be possible but restricted to a maximum size of 52KB.
I like the idea. While this might bee a bit more constraining for C games, keeep in mind that 52 KB includes the code, not the audio nor the sprite data. I hope to see Microcat come to fruition at one point. :)
Audio can be partially buffered into memory but the sprites need to be kept in ram for performance. You don't need to load all the sprites at once though.
Quote from: Streetwalrus on November 19, 2015, 04:40:35 PM
Audio can be partially buffered into memory but the sprites need to be kept in ram for performance. You don't need to load all the sprites at once though.
Yes we planned it exactly like this.
Quote from: Streetwalrus on November 19, 2015, 04:40:35 PM
Audio can be partially buffered into memory but the sprites need to be kept in ram for performance. You don't need to load all the sprites at once though.
Yeah that was my guess for sprites in particular. For audio it's best to buffer it, else every game OST will be like Hong Kong 97.
For sprites, if memory is really a serious concern, people can simply create multiple sprite sheets and make sure that sprites for walls and floor have the same layout for each set, then simply switch sprite sheet when switching dungeons. That way they could even re-use the same dungeon multiple times with different sprite sheets.
That's of course if sprite sheets ever gets supported (I think it might be better than having 120 small 8x8 images, because loading 120 images one by one into memory would be tedious x.x
I sadly have to announce that the project will be put on hold as we cannot continue at this point. This is only for the hardware side of things, the software (Claw and the OS) will still be actively developed during the hold phase.
This is not the death of the project, but we have come to a point where we can't continue until we have the financial power to do so.
We need another 300 Euros to continue at this point and our personal resources are currently exhausted. We already exhausted our budget of 500 Euros that we took from our own savings. Having no real income, reaching those 300 Euros will take time. Maybe half a year, maybe less. I personally can't save more than about 10 Euros a month and adekto won't be able to save much either.
If you want to support the project, we do accept donations (early donators will certainly be rewarded specially) or, what need even more, is help. There are many ways to help getting the project to life. If you happen to have a CNC machine or somebody who owns it and can cut some prototyping parts out of some plastic, or if you have a reflow oven and maybe even a pick and place machine, we would be glad if you could solder the early prototypes. If you happen to know something about switching power supplies or how to build a LiPo charger, we would love to know more about it.
I'm sorry to hear. :( Is it due to cost overruns? I am glad that you still plan to finish the software or at least the Claw language, though. I hope Microcat lives on, and hopefully one day as an hardware too.
Good luck!
Quote from: DJ Omnimaga on December 04, 2015, 12:28:20 PM
I'm sorry to hear. :( Is it due to cost overruns? I am glad that you still plan to finish the software or at least the Claw language, though. I hope Microcat lives on, and hopefully one day as an hardware too.
Good luck!
Thanks :)
Well the issue is that we lack money and manpower.
We have so much work to do and so much money to pay, but with some help of either we could finish it. We are trying to get it to live under any circumstances but its pretty hard recently.
What I don't get, though, is that a few months ago, you said that the entire projects and parts were funded already and you had pretty much all parts ordered or at home. So why even more money is now needed? Did you have to replace several parts?
Quote from: DJ Omnimaga on December 14, 2015, 07:37:21 PM
What I don't get, though, is that a few months ago, you said that the entire projects and parts were funded already and you had pretty much all parts ordered or at home. So why even more money is now needed? Did you have to replace several parts?
That was not really the problem. We always knew that we will come to the point that we have to design and build a PCB prototype. We have sadly reached this point. We never knew where we should take the money for the prototype and I really can't spent this much. The parts we bought already were only for the breadboard prototype alone.
After the PCB prototype is done and works, we are pretty much ready for getting it into production and doing the kickstarter.
Ok but I still don't get all of it. You told me a while ago that you received a lot of money from someone for this project (I forgot who). I didn't realize that the final cost would be in the thousands of euros in the end.
I see about the prototype, though. I thought that the breadboard parts could be re-used for a PCB prototype.
Quote from: DJ Omnimaga on December 14, 2015, 08:16:32 PM
Ok but I still don't get all of it. You told me a while ago that you received a lot of money from someone for this project (I forgot who). I didn't realize that the final cost would be in the thousands of euros in the end.
I see about the prototype, though. I thought that the breadboard parts could be re-used for a PCB prototype.
Actually not. I got a comparatively small donation from p4nix (it was really awesome of him, but sadly certainly not enough to fund the prototype though it is certainly a good step in the right direction :)). The big amount of money is needed for mass production but now we need money to do the prototype.
About the parts, we cannot reuse them.
Ah I see now. I hope at one point you can get enough money to continue (and won't end up getting it when they decide to increase the price of parts)
Great news everybody! I will be resuming development on the microcat platform and we will be starting with the PCB side of things at some point too. Before that, I will have to clear some things up: So first we still lack the required money to do the PCB prototypes and we still have no licence for eagle (and the knowledge for it or KiCad).
We were thinking of doing a smaller, alternative to the gaming microcat which is more IoT friendly. It will not have a display, buttons and a LiPo, but it will have the audio amplifier, wifi, sd card and the same processor. This way programs will stay compatible if needed between the microcat and the smaller IoT board. They will also run the same OS.
Interesting, but will it work on a TV or PC monitor?
And will Claw remain?
Quote from: DJ Omnimaga on December 20, 2015, 12:24:54 AM
Interesting, but will it work on a TV or PC monitor?
And will Claw remain?
Well, theoretically it is possible to hook it up to VGA monitor with some special adapter and we might sell one eventually.
And yes, Claw will remain; C won't.
Ideally, if your console loses its screen, then it would be better to not require the use of a proprietary screen or one specific screen. It would be better in such case to make it like home consoles, where you need a TV or a standard LCD monitor. I don't mind if it doesn't support HDMI nor composite if it means lowering the costs, but of course it depends if newer TVs still offers old connections.
If the Playstation 3 for example only worked on the PS TV that they were selling for a while in game stores, then I bet that almost no one would have bought it and would have instead went with the Xbox 360 at the time.
On a side note, I wonder if it would be expensive to make such console shaped like a :walrii: ? :P
Quotewe still have no licence for eagle (and the knowledge for it or KiCad).
For such a (relatively) small product, eagle is not really necessary. You should really go for KiCad, which is a good alternative that does everything you want to and it is actually easier to work with than eagle.
Quote from: DJ Omnimaga on December 20, 2015, 04:20:35 AM
Ideally, if your console loses its screen, then it would be better to not require the use of a proprietary screen or one specific screen. It would be better in such case to make it like home consoles, where you need a TV or a standard LCD monitor. I don't mind if it doesn't support HDMI nor composite if it means lowering the costs, but of course it depends if newer TVs still offers old connections.
If the Playstation 3 for example only worked on the PS TV that they were selling for a while in game stores, then I bet that almost no one would have bought it and would have instead went with the Xbox 360 at the time.
On a side note, I wonder if it would be expensive to make such console shaped like a :walrii: ? :P
No you totally misunderstood. We want to make two seperate products based on the same chip set. We want to start with TBS IoT module first as it's easier and cheaper to develop and get to the console later. The IoT module has no buttons, no screen, no sound and no battery, but it will have aa webserver and a Claw based CGI. It will allow multi tasking (multiple connections at once and a background process that has nothing to do with the webserver.
The real console will of course have a screen and everything that we decided earlier.
Yes it would be very expensive and add a lot of work :P
But putting a small walrus on the silkscreen would be very easy and free.
Quote from: Vogtinator on December 20, 2015, 10:09:48 AM
Quotewe still have no licence for eagle (and the knowledge for it or KiCad).
For such a (relatively) small product, eagle is not really necessary. You should really go for KiCad, which is a good alternative that does everything you want to and it is actually easier to work with than eagle.
Yes, but I don't like kicad. adding parts is so hard. Also getting the footprint right will be hard too.
Oh I see now. I thought you were ditching the original portable console idea and switching to something closer to the OUYA.
Quote from: DJ Omnimaga on December 25, 2015, 05:33:10 AM
Oh I see now. I thought you were ditching the original portable console idea and switching to something closer to the OUYA.
Huh?! I never said anything that could lead to this conclusion, did I? ???
I mainly focused on the part about no screen and mostly skimmed through the post, but I guess the fact I am completely technology-illiterate when it comes to hardware and PCB's might not have helped either. I think the key part I missed was "IoT" so from your other post it seemed like you were making a standard home console. I have absolutely zero clue what "IoT" is, anyway.
Internet of things. The new stuff. Connecting everything in your house everytime and everywhere to the internet :P
Oh ok. Does it mean that this version of Microcat would not work without Internet? Because if for example aeTIos decided to buy that Microcat, then this means he would not be able to use it on Sundays or past 10 PM, since his Internet connection gets shut down during those times. I bet most people under 18 would have the same problem as well.
Quote from: DJ Omnimaga on October 05, 2015, 06:04:21 AM
I am still unsure since I need to save for Microcat (assuming it ever gets done, and no, I won't back any project on Kickstarter, because of what happened with Mighty No 9)
Aw thanks, DJ :D
I will start programming some demo games on the current hardware prototype to see how they work. I hope that we will be able to make a proper prototype soon.
The issue is, that I don't have a proper PCB tool yet, but I am still searching.
Does the current prototype accept any user input? I forgot.
Quote from: DJ Omnimaga on January 12, 2016, 02:30:48 AM
Does the current prototype accept any user input? I forgot.
Yes, over the serial port.
I will hereby lock this topic until more is clear.
Please discuss (if you want) here (http://codewalr.us/997/29836)
I should probably reopen this topic as there is no real use in closing it.
I took the prototype apart yesterday. This is the final end of the project. I will be releasing the BIOS code for the ARM processor under a permissive license.
Sad :'(
I hope the other project takes off, though
Quote from: DJ Omnimaga on February 11, 2016, 08:30:24 PM
Sad :'(
I hope the other project takes off, though
Yes, it was quite sad, but I needed the breadboard and the jumpers for the ZPX-128 and also wanted to finally end the project.
Quote from: DarkestEx on February 11, 2016, 09:26:02 PM
Quote from: DJ Omnimaga on February 11, 2016, 08:30:24 PM
Sad :'(
I hope the other project takes off, though
Yes, it was quite sad, but I needed the breadboard and the jumpers for the ZPX-128 and also wanted to finally end the project.
Cant you just get coiled wire? :P i just have a long coil that i cut to whatever length i want.
Quote from: c4ooo on February 11, 2016, 11:15:58 PM
Quote from: DarkestEx on February 11, 2016, 09:26:02 PM
Quote from: DJ Omnimaga on February 11, 2016, 08:30:24 PM
Sad :'(
I hope the other project takes off, though
Yes, it was quite sad, but I needed the breadboard and the jumpers for the ZPX-128 and also wanted to finally end the project.
Cant you just get coiled wire? :P i just have a long coil that i cut to whatever length i want.
I really don't like breadboarding this way. I have tons of wire and parts in general, but I prefer the jumpers.
I guess Microcat *might* rise from the dead. While this is still quite uncertain, we are currently developing a new and cheaper version of it :)
Oh, and it's way faster too :D
it's April 6th, so the date checks out
@DarkestEx wuuut? Fill me in, what going on? :)
Quote from: Caleb Hansberry on April 06, 2016, 08:04:28 PM
it's April 6th, so the date checks out
Well it's not an April fool. We are working on a 160 MHz, 160 KB RAM, 32 MB flash version of it. It will still be a 32 bit CPU, but no ARM anymore. WiFi is integrated too, no USB. There won't be a rechargeable battery either but either coin cells or better AAA batteries.
What about the z80 based computer ???
Quote from: see-four-thousand on April 06, 2016, 08:13:32 PM
What about the z80 based computer ???
That is still the highest priority. The Microcat resurrection was adekto's idea and as we have so much spent on it so far, we have to bring it to an end at some point. The new CPU will be easier to work with and be better and even half the price of the old one. The Microcat will be done after the ZPX-128.
Sorry for not replying sooner. Just make sure to not cause too much hype about the console like last time, though, else if it dies again it might alienate people even more (since that would be the 2nd time it dies if it happens), and preferably work solo on it so you have full control on deadlines, funding and stuff.