I'd like to present you the new console adekto, Cumred_Snektron, gbl08ma, Streetwalrus and I are working on!

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 a great potentional for games and allows for unlimited ressources - files up to 4GB)
- 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 and SPI powered expansion interface
- Digital 16 bit audio and headphone socket with digital volume control
- 680mAh LiPo battery with builtin charge circuit
- USB 2.0 full speed, host and slave

Estimated price is about 49 EUR for the base unit.
About 59 EUR for a full starter kit including microSD with OS, USB OTG cable and a USB client cable.
The prices above are not fixed yet - they can change positively and negatively. The price drops with funding - at 100 sold units, the unit price is almost 10 EUR less.

The console will be very tiny in dimensions. Just about as small as a credit card.
The front will probably be bare black PCB - the backside either laser cut or 3D printed.

We are still in prototyping phase but it is growing constantly and we really hope that you like it

Have fun!

I hate to start out this thread with skepticism, but I've seen a few "make a [better|new|retro] console" projects mixed in with our infinite "make a better calculator" projects, none of which ever seen to pan out. From that list of users, I've only seen polished, finished products from gbl08ma, and I'm not sure about the EE credentials of any of the developers. Can you point me at some existing projects from each of these users? I know Streetwalrus was an Omnimaga user who left during the CodeWalrus fiasco, but I'm not familiar with the other users. Other than that, it seems like a cool retro console idea, although as pointed out on SAX/IRC, the CPU seems a little overpowered for the other components. Good luck.

Well we have been working on this projects for over 4 months now and spent more than 400 EUR on prototyping parts and equipment - we will do it whatever comes!
I crossposted this over from CodeWalrus, where this topic is reasonably active.

About EE credentials, I am the guy who does the HW and I have moderate "experience". It should be certainly enough for this, as it looks reasonably streightforward and we already have the chip pretty much up and running, though we are facing some timing issues currently. Of course will the reference designs help too.

This seems like reasonable hardware, though I'm not particularly a fan of the square aspect ratio for the LCD, and the RAM could go a bit higher.

Well i know the OLED issue. I don't like square displays too much normally too, but the old rectangle display we had in mind was only 0.9in in diameter which is quite small to see. The new 1.5in display is a lot more readable.

About the RAM, we can't upgrade that one sadly. But I think it should be enough for games, also the 84+ has even less ram than our console, though it has mainly monochrome graphics. We will have multiple image modi. Monochrome like on the calcs (1 bit per pixel), 4 bit palette, 8 bit palette (216 predefined not changeable colors and 39 user definable ones) and finally 16 bit RGB565.

When you have something presentable, you've got an interested party over here. will this project allow (if the user wishes it) for the user to modify the device themselves, say, for attaching their own peripherals? I also would prefer a larger case then 'credit card', but i think i could refit it myself. personally, something that small i feel would be fragile, which would keep me from using it.

Yes the device will have some GPIO broken out and usable. About being fragile, I would certainly not want to drop it on concrete, as the display could shatter, but I don't think it will be too fragile.
Apart from that users can, if they have the knowledge, reflash the device with anything they want. I will, even though its possible, not lock it down in any way and allow JTAG, SWD and serial interface to it.

The console will probably run a Lua based firmware, but we might do a C based one after release. The C based one should allow running C games and programs at full speed linked to a shared library in flash.

Currently I am working on the Lua simulator that will allow users to test and debug their code right on their PCs.

The BIOS is working and I set up a 6502 emulator to showcase it:

That looks very nice indeed! Is the slow character draw rate a function of how fast the CPU can update the LCD, or something else? Keep up the good work.

The reason for the slow refresh rate is that I haven't optimized the drawing code yet.
It does redraw the screen on every 6502 character which is why it becomes so slow there.
Also I had some issues with the watchdog which is why I reset the watchdog after every 10 6502 instructions just to stay on the safe side.
After optimizing it should be really fast. I tried it without the display already (only serial port) and it works just fine.

Looking awesome, great to see that progress is being made Can't wait until its finished

Lua seems nice for prototyping, but don't you want a lower-level language to be the main platform given the relatively limited hardware?

That would certainly be my design; a Lua interpreter on top would be fine, but the low-level functions should absolutely be written in C/C++. The Lua interpreter itself is written in C++, so you'd be running Lua on top of Lua on top of C++.

Thanks all

I have been looking into Lua some more and it just doesn't seem fast enough and has a way to high memory usage
So we were thinking again and we split up. One of our team will make a runtime for games written in C. Which is basically a dynamic linker that links assemblies to the graphics and system API at run time.
While I have been developing a new language together with somebody else.
My language will be editable and compileable to bytecode (not machine code) right on the device or on a PC and will be executable on many different devices such as the microcat, on the PC, maybe on the Gamebuino and (very unlikely but probably possible) on KnightOS.
To make it easier to learn the language, it has a very similar syntax to Lua in many parts though it doesn't require things like "then" or "do" and it doesn't have tables. It does have functions and two different variables which are numbers (16 bit signed) and arrays (8 bit values). We have chosen to lower to lower the size of arrays as most arrays will just hold sprites, levels, maps or strings which are all 8 bit. We will have some functions to write and read 16 bit values to and from the arrays (two items, one is the lower and one the upper half of the 16 bit number).
The language should read the programs though a pipeline off the SD card and not require the full program to be loaded into RAM, as this would limit the maximum game size, which is something that we want to prevent. Programs can therefore be way larger than the RAM of the console as only a small sector of it gets streamed through the RAM at a time. The compiler will create a look up table of all functions and variables at the starts of the program and the functions and other blocks to increase the speed and prevent searching for functions.
The variables are created with "var" (for numbers) and "var[size]" (for arrays while size is the size of the array which can probably be set at run time) and they are garbage collected at the end of the block that they have been defined in. We handle this garbage collection using levels of nesting. If the nesting level of a variable is exited, it is discarded. To help with that, there is a "block" block which does nothing but allows to define variables that get discarded after the block and don't require dirty hacks such as a "if true" block.

Here is an example program:

Code:

I'm certainly liking what I see so far; keep up the good work!

I'd suggest that you do static profiling or something to hint which functions should get kept in RAM all the time, otherwise that could be very slow indeed. For example, if the function to draw objects to the screen has to be re-loaded from RAM every time it needs to be executed, you'll see a big slowdown there. On the other hand, I guess you could just maintain an LRU of functions in memory, but then you have to keep track of memory holes or do compaction (ie, exactly the same problems that malloc() and friends face).

I would suggest that the programmer should be responsible for mapping different sections of code in and out, as we currently are on the z80 calculators. This will require smarter programmers but less compiler magic (which is hard to do well).

How would you propose that mapping work? As you know, on the z80 calculators we have the difficult task of either swapping whole 16KB banks in and out (and making sure that we don't accidentally try to access any other code that swaps that same bank at inopportune times), or copying routines to known areas of safeRAM, calling them, then potentially overwriting them. I'd hope that a higher-level language would symmetrically have an easier method of specifying RAM routines, especially since programs will presumably not have locations with fixed addresses and sizes (ie, like our z80 safeRAM) into which to load their variable-sized chunks of functions.

The language is making great progress and it will be reasonably high level, compared to other approaches we thought about.
The source of the compiler is here: https://github.com/ninjabyte/ClawCompiler
And the source of the VM is here: https://github.com/ninjabyte/ClawVM

The language will compile on PC or using a planned web based version of it, to a custom set of bytecode which will execute in any port of the VM. Ivoah has already offered us to magbe port it to the Gameboy Advance and maybe to the TI Nspire. It could also be ported and would run on many other platforms too. People can write directly in the custom bytecode if they want to save a few bytes and maybe speed it up a little more.

By the way, the display is colorful. We will be using palettes to deal with them.
There will be 4 different pixel formats for sprites:
- 1bpp (transparent and one color from the global palette) - 8 pixel per byte
- 2bpp (transparent and 3 colors from the global palette) - 4 pixel per byte
- 4bpp (transparent and 15 colors from the global palette) - 2 pixel per byte
- 8bpp (transparent and all colors from the global palette) - 1 pixel per byte

The global palette used, has 117 static colors that cannot be changed and it has 39 colors that can be set to any 16 bit BGR565 value that one desires. These dynamic colors can be used in sprites to change their colors or to give them custom colors while the game is running.

The table with all the colors is here: http://docs.ninjabyte.eu/microcat/global_palette.html