Fast/modern platforms that allow "bare-metal" style coding?
category: code [glöplog]
...sorry, skip the "new" ;-)
Sdw you should check out dreamcast development.
There‘s a nice SDK (KallistiOS), great emulators for testing/development and most importantly you get low-level access to the PowerVR GPU.
Also, Xbox Classic is a great underused platform with lots of potential. Did some demostuff on it myself (unreleased so far), it is a great system.
There‘s a nice SDK (KallistiOS), great emulators for testing/development and most importantly you get low-level access to the PowerVR GPU.
Also, Xbox Classic is a great underused platform with lots of potential. Did some demostuff on it myself (unreleased so far), it is a great system.
Too bad my Pandora was never delivered because some British person(s) took the money to cover their own losses and was never heard from again. When writing the Germans the reply was "your business is with the British" except I never chose who to deal with. Well, you can't go through life without some scars.
Perhaps something along these lines: https://www.clockworkpi.com/
Possibly modern mobile maybe, though the stack there is quite deep I suppose. Need to do a lot to get access to the bare-metal.
the closest you can get to baremetal is actually make the metal yourself: https://store.digilentinc.com/fpga-development-boards-kits-from-digilent/
You could also go for this? https://play.date/
Possibly modern mobile maybe, though the stack there is quite deep I suppose. Need to do a lot to get access to the bare-metal.
the closest you can get to baremetal is actually make the metal yourself: https://store.digilentinc.com/fpga-development-boards-kits-from-digilent/
You could also go for this? https://play.date/
Wow! Long time since I was here; but there's a post right in my current interest! :) I totally get Sdw's reasons for wanting to go bare metal. I feel very much the same way myself, although for some reason I've drifted into operating system design. Actually, I'm currently doing Forth which can simultaneously be interactice, a simple OS, and remarkably close to the metal.
I especially hate update madness, on which point you should know that my OS-developing friends ran into trouble on the RPi 4: the device tree format was changed separately from any hardware update. My friends kernel could no longer find the device IDs at build time. IMO, that's a horrible example of update madness. My friends also had a little problem with 8GB Pis having some unexpected difference from 4GB Pis. That's a little bit more normal in the hardware world.
Raspberry Pis have never been the most open, best quality, or most powerful SBCs for their price. The Pi 4's quality is okay, but see above. Their best point is that they're available in more countries than any other open or semi-open SBC. (Given the mountain of paperwork many countries require for electronics, including the complete lack of EU unity in this area, this is quite an achievement!) They do have some good points. Having a coprocessor (GPU on the Pi) handle a lot of tasks must be very helpful for bare-metal development, especially for beginners. And because the Pi is so very popular, it doesn't take terribly long for all the undocumented parts to be documented.
Some seemingly closed systems get opened up pretty well, including some fairly powerful smartphones, although the only documentation often ends up being Linux driver source. If you can stomach reading it, it might be worth checking out PostmarketOS, a Linux distribution for obsolete smartphones. However, some people say "Reading Linux driver source is where the fun stops."
If you're looking at SBCs in general, bear in mind some SoCs are much more complex than others, and it isn't entirely related to how powerful they are. For instance, years ago, I wanted to develop bare-metal for my already-old Kindle 4. I got the data sheet for the SoC, got very confused, and gave up. This SoC was nothing special; single ARM core, 128K each RAM & ROM, maybe DRAM & SD controllers, and that's about it. A year or two later, my super-smart friend, a physics student at Cambridge, developed his own SBC around a Zynq SoC: dual-core ARM with FPGA on board, a really nice bit of kit. At one point, he found it a bit of a headache. I asked him how many pages the datasheet had. I'm not joking when I say it was about 20% smaller than the datasheet for the old Kindle's SoC! I didn't feel so bad about giving up after that. :)
Did you know you couldn't entirely get the OS out of the way in the 8-bit Atari 400 and 800? It always responded to vblank. You could cut out the majority of what it did in vblank, but not all of it.
If you want something really wild, try to get hold of a GA144 - 144 tiny computers on a single chip. :) They run at about 700 MIPS with 4 instructions per cycle. They only have 64 18-bit words of RAM and ROM each, though. ;) It can be hooked up to RAM and ROM, but dynamic generation is obviously a big thing, which of course involves cycle counting. Timing is primarily done by cycle counting. The eval board has a VGA port, and I'm sure it would be easy to hook up the chip's 2 spare DACs for audio - just right for demos, no? (Actually, the board has 2 GA144s. Surround sound demo? ;) There was a cheaper board too, but the power rails weren't decoupled well enough, so it's flakey. I'm apparently not gloepy enough to post links, so you'll have to search greenarrays and paste colorforth.github.io (it's a mirror). Greenarrays has some GA144 stuff on the front page as I write. On the colorforth site, see the "eval blog" link, it's Charles Moore's record of developing for the GA144 and a predecessor. He starts with dynamically generating video. Oh by the way, it's a Forth chip, ;) but 18 instructions is easy to learn no matter what language you think of them as. (Or maybe 21, not sure.) Oh... documentation for some parts of the chip seems a bit light. I think if you buy an eval board, you get to talk to the company, maybe? It's a small company. Or maybe the simulator helps you understand. It's free.
Speaking of dynamic generation, one of my minor goals is to bitbang video and audio with a more convential microcontroller, essentially making a display and maybe demo with a device never meant to drive a display. :D Some microcontrollers can be powerful; I don't think there's a clear line between them and SBCs. I've recently bought some BBC microbits. They have ARM cores, albeit with only 16KB RAM. (There's more ROM.) Not quite sure they're powerful enough for video, but will have fun trying. Might have to settle for a PAL or NTSC resolution rather than VGA. Got an Arduino Mega too, although I mostly bought that for all the junk that came with it. Haven't got started with them though. (Somebody buy me a round tuit.)
Returning to coprocessors, the microbit has a coprocessor which A: handles flashing the ROM, and B: is not itself programmable. The combination makes it impossible to brick the board. Having gone through the scary process of flashing brickable devices in the past, I very much appreciate that! :) It's also impossible to brick a device with an unflashable boot rom, if I understand right, and some boot roms are nice enough to just load your 'kernel' and leave all the fun stuff to you.
I especially hate update madness, on which point you should know that my OS-developing friends ran into trouble on the RPi 4: the device tree format was changed separately from any hardware update. My friends kernel could no longer find the device IDs at build time. IMO, that's a horrible example of update madness. My friends also had a little problem with 8GB Pis having some unexpected difference from 4GB Pis. That's a little bit more normal in the hardware world.
Raspberry Pis have never been the most open, best quality, or most powerful SBCs for their price. The Pi 4's quality is okay, but see above. Their best point is that they're available in more countries than any other open or semi-open SBC. (Given the mountain of paperwork many countries require for electronics, including the complete lack of EU unity in this area, this is quite an achievement!) They do have some good points. Having a coprocessor (GPU on the Pi) handle a lot of tasks must be very helpful for bare-metal development, especially for beginners. And because the Pi is so very popular, it doesn't take terribly long for all the undocumented parts to be documented.
Some seemingly closed systems get opened up pretty well, including some fairly powerful smartphones, although the only documentation often ends up being Linux driver source. If you can stomach reading it, it might be worth checking out PostmarketOS, a Linux distribution for obsolete smartphones. However, some people say "Reading Linux driver source is where the fun stops."
If you're looking at SBCs in general, bear in mind some SoCs are much more complex than others, and it isn't entirely related to how powerful they are. For instance, years ago, I wanted to develop bare-metal for my already-old Kindle 4. I got the data sheet for the SoC, got very confused, and gave up. This SoC was nothing special; single ARM core, 128K each RAM & ROM, maybe DRAM & SD controllers, and that's about it. A year or two later, my super-smart friend, a physics student at Cambridge, developed his own SBC around a Zynq SoC: dual-core ARM with FPGA on board, a really nice bit of kit. At one point, he found it a bit of a headache. I asked him how many pages the datasheet had. I'm not joking when I say it was about 20% smaller than the datasheet for the old Kindle's SoC! I didn't feel so bad about giving up after that. :)
Did you know you couldn't entirely get the OS out of the way in the 8-bit Atari 400 and 800? It always responded to vblank. You could cut out the majority of what it did in vblank, but not all of it.
If you want something really wild, try to get hold of a GA144 - 144 tiny computers on a single chip. :) They run at about 700 MIPS with 4 instructions per cycle. They only have 64 18-bit words of RAM and ROM each, though. ;) It can be hooked up to RAM and ROM, but dynamic generation is obviously a big thing, which of course involves cycle counting. Timing is primarily done by cycle counting. The eval board has a VGA port, and I'm sure it would be easy to hook up the chip's 2 spare DACs for audio - just right for demos, no? (Actually, the board has 2 GA144s. Surround sound demo? ;) There was a cheaper board too, but the power rails weren't decoupled well enough, so it's flakey. I'm apparently not gloepy enough to post links, so you'll have to search greenarrays and paste colorforth.github.io (it's a mirror). Greenarrays has some GA144 stuff on the front page as I write. On the colorforth site, see the "eval blog" link, it's Charles Moore's record of developing for the GA144 and a predecessor. He starts with dynamically generating video. Oh by the way, it's a Forth chip, ;) but 18 instructions is easy to learn no matter what language you think of them as. (Or maybe 21, not sure.) Oh... documentation for some parts of the chip seems a bit light. I think if you buy an eval board, you get to talk to the company, maybe? It's a small company. Or maybe the simulator helps you understand. It's free.
Speaking of dynamic generation, one of my minor goals is to bitbang video and audio with a more convential microcontroller, essentially making a display and maybe demo with a device never meant to drive a display. :D Some microcontrollers can be powerful; I don't think there's a clear line between them and SBCs. I've recently bought some BBC microbits. They have ARM cores, albeit with only 16KB RAM. (There's more ROM.) Not quite sure they're powerful enough for video, but will have fun trying. Might have to settle for a PAL or NTSC resolution rather than VGA. Got an Arduino Mega too, although I mostly bought that for all the junk that came with it. Haven't got started with them though. (Somebody buy me a round tuit.)
Returning to coprocessors, the microbit has a coprocessor which A: handles flashing the ROM, and B: is not itself programmable. The combination makes it impossible to brick the board. Having gone through the scary process of flashing brickable devices in the past, I very much appreciate that! :) It's also impossible to brick a device with an unflashable boot rom, if I understand right, and some boot roms are nice enough to just load your 'kernel' and leave all the fun stuff to you.
cuda
Tuna, because it's a whole bunch of posts in one. Baracuda hunt singly, tuna in groups.
Well... FPGA.
Minuteman's ZZ9000 Amiga gfx card with ARM cores on FPGA. :)
But what about ESP32 (mentioned before), 240 MHz dual core or single core with FPU, companion chip (RISC V in most recent model), and available on boards with touchscreens? WLAN, BT, audio capable board variants...
And NO OS.
But what about ESP32 (mentioned before), 240 MHz dual core or single core with FPU, companion chip (RISC V in most recent model), and available on boards with touchscreens? WLAN, BT, audio capable board variants...
And NO OS.
So, have you been able to do anything with the Pandora?
Otherwise, I was gonna suggest the GP2X or GP32. Not so recent but at least they're 32bits. From what I remember on the GP2X, you had to put a line of code when your program ended to restart the GUI. :D
Otherwise, I was gonna suggest the GP2X or GP32. Not so recent but at least they're 32bits. From what I remember on the GP2X, you had to put a line of code when your program ended to restart the GUI. :D
Quote:
If you want something really wild, try to get hold of a GA144 - 144 tiny computers on a single chip. :)
This reminds me of the Propeller 2, the successor of the hardware this fine demo was made for.
Quote:
Minuteman's ZZ9000 Amiga gfx card with ARM cores on FPGA. :)
It's mostly an ARM CPU with a framebuffer, and an FPGA for the boring tasks (eg. bus control, interfacing everything with the amiga properly, etc.)
Quote:
GP32
Well there's also the Nintendo DS :p I'd love to have some competition for it!
I managed to get my Pandora running (and update to latest OS as well), and I actually also ordered a RasPi 4, if I end up wanting to give RISC OS another go.
However, I soon realized that for both of these options to actually be able to compile any code, I would need to set up some kind of GCC-ARM cross-compiling environment, meaning I'd need to install a Linux VM and then all that other crap that is needed, and then it started to feel a bit too close to "work" and too far from "fun"... :)
However, I soon realized that for both of these options to actually be able to compile any code, I would need to set up some kind of GCC-ARM cross-compiling environment, meaning I'd need to install a Linux VM and then all that other crap that is needed, and then it started to feel a bit too close to "work" and too far from "fun"... :)
GCC works on windows and osx as well, no?
(on windows you could also use mingw, msys or cygwin)
(on windows you could also use mingw, msys or cygwin)
I am more and more leaning towards sticking to old platforms, where cross-development is simply running a 6502/z80/whatever assembler that outputs bin code, because I'm getting nowhere with this endeavor.
RiscOS + raspberry Pi turned out to be a dead end, since RiscOS didn't support the RasPi 4 hardware... OK, I guess that's a bit my fault for not reading all the fine print! :)
I've been focusing on the Pandora instead, I got recommendation that actually compiling the code on the Pandora itself was an option, installed some stuff on the Pandora, got it setup so I can SCP files to it (for easier editing on PC), but then the development shell on the Pandora is completely broken, and noone seems to know why, *sigh*
I think the whole Linux/GCC/whatever world is for certain people, of which I am not one!
RiscOS + raspberry Pi turned out to be a dead end, since RiscOS didn't support the RasPi 4 hardware... OK, I guess that's a bit my fault for not reading all the fine print! :)
I've been focusing on the Pandora instead, I got recommendation that actually compiling the code on the Pandora itself was an option, installed some stuff on the Pandora, got it setup so I can SCP files to it (for easier editing on PC), but then the development shell on the Pandora is completely broken, and noone seems to know why, *sigh*
I think the whole Linux/GCC/whatever world is for certain people, of which I am not one!
On Amiga AGA I think most demos do turn off the system. Usually A1200s have plenty of RAM so that's not really a concern, you can allocate as much as you need and load all data at the beginning (or in between parts).
You do need to choose which flavour of AGA you want to code for though. 060 is fairly standard but the hardware is a bit scarce / expensive if you don't already have it from years ago. Also if you optimise the code for that it won't really run on anything less.
You could also code for slower accelerated A1200s like 030. If you optimise for that it won't be optimal on 060 but obviously fast enough. The issue is that some people might not realise (for example during a compo at a party) what the difference between an 030 and an 060 is and it can be difficult to judge if polygons are jumping because of optimisations or simply bad code.
Stock A1200 could be an interesting platform. It was never that popular though because most users who weren't purely gamers got at least a memory expansion quite quickly and many demos from 1994 already at least take advantage of it. On stock it can be fun that you can still utilise things like the blitter and sprites because you are forced to use chip memory anyway. The A1200 is obviously faster than an A500 but the extra colours, 24 bit palette and more RAM would make it possible to do demos in a slightly more modern style, even if the effects might end up being quite similar to something that can be achieved on 68k + OCS.
You do need to choose which flavour of AGA you want to code for though. 060 is fairly standard but the hardware is a bit scarce / expensive if you don't already have it from years ago. Also if you optimise the code for that it won't really run on anything less.
You could also code for slower accelerated A1200s like 030. If you optimise for that it won't be optimal on 060 but obviously fast enough. The issue is that some people might not realise (for example during a compo at a party) what the difference between an 030 and an 060 is and it can be difficult to judge if polygons are jumping because of optimisations or simply bad code.
Stock A1200 could be an interesting platform. It was never that popular though because most users who weren't purely gamers got at least a memory expansion quite quickly and many demos from 1994 already at least take advantage of it. On stock it can be fun that you can still utilise things like the blitter and sprites because you are forced to use chip memory anyway. The A1200 is obviously faster than an A500 but the extra colours, 24 bit palette and more RAM would make it possible to do demos in a slightly more modern style, even if the effects might end up being quite similar to something that can be achieved on 68k + OCS.
@Sdw: Risc OS does support the RPi4, running here since months, I published something for this years Revision already (linky)...you just need some small extra hardware workaround for the lacking onboard USB support. But within the next weeks this will be solved also...beta ROM is already taking care of that...check the RISC OS site/forum for updates.
dodke: I have a (stock) A1200, but as you say - 060 accelerated is too expensive, 030 accelerated (which is still a pretty expensive upgrade) gets unfairly lumped in with 060 demos by everyone but the most technically interested viewers. The stock 1200 is a nice target, that I do plan to dig into some time, but from a coding/effect point of view, it's fairly similar to A500. You still need to work with bitplanes/blitter etc. to get anything moving at decent speed.
I'd like to be lazy for a change and target a system with a linear chunky framebuffer, and fast enough to write most stuff in C.
Kuemmel: Yeah, you're right, I did see that there were some workarounds with powering the RPi via some special GPIO solution, but it seemed a bit too cumbersome. I'll keep my eyes out for the full support release though!
I'd like to be lazy for a change and target a system with a linear chunky framebuffer, and fast enough to write most stuff in C.
Kuemmel: Yeah, you're right, I did see that there were some workarounds with powering the RPi via some special GPIO solution, but it seemed a bit too cumbersome. I'll keep my eyes out for the full support release though!
Kuemmel: Could you advocate Risc OS a bit? What makes it hip?
Shadow, yeah in that case 060 would be the one. On that you can easily use optimised C for most things and only rewrite inner loops in assembly which allows for more tricks to be used. It's too bad they're so expensive. Perhaps 040 with those new accelerators could be a sort of cheap enough, fast enough solution. Possibly not.
@la_mettrie: Okay, I'll give it a try, at least from a coders point of view ;-) ...if you are into coding you can check my sizecoding wiki here
Pro:
- runs on cheap hardware like all the Raspberry PI's
- low system overhead, as the OS historically was supplied in ROM
- easy coding access via BASIC (built in Assembler) or C (!GCC)
- linear memory, linear graphics memory, Full HD and whatever the PI resolutionwise
- 16 Bit sound system
- small but lively community (mostly british, due to the history...). Check here
Contra:
- lacks coders and software developement in general, there are limited web browsers, but better ones are in the making, but not yet there
- no multicore support
- no GPU support via OpenGL or DirectX or similar...so software rendering it is...
I'm a bit biased as an Acorn Archimedes was my first advanced computer back then after having a Commodore C128...so I really liked to do stuff with BASIC and the built in Assembler...and I'm happy to do so still on that advanced hardware.
If you need a specific info, just ask.
Pro:
- runs on cheap hardware like all the Raspberry PI's
- low system overhead, as the OS historically was supplied in ROM
- easy coding access via BASIC (built in Assembler) or C (!GCC)
- linear memory, linear graphics memory, Full HD and whatever the PI resolutionwise
- 16 Bit sound system
- small but lively community (mostly british, due to the history...). Check here
Contra:
- lacks coders and software developement in general, there are limited web browsers, but better ones are in the making, but not yet there
- no multicore support
- no GPU support via OpenGL or DirectX or similar...so software rendering it is...
I'm a bit biased as an Acorn Archimedes was my first advanced computer back then after having a Commodore C128...so I really liked to do stuff with BASIC and the built in Assembler...and I'm happy to do so still on that advanced hardware.
If you need a specific info, just ask.
through my own upbringing's bias I advise a pentium 166 (or 200+) with ms-dos
can even toss dos if you want to be hardcore but i'd advise to use turbo assembler and watcom, write your own pmode extender, write your own sound player, write your own vesa lib (now that's a neat exercise) or go modex and well, have fun
i had, though i'm happy i'll never involuntarily be put through that wringer again
and i didn't code my own player nor extender
can even toss dos if you want to be hardcore but i'd advise to use turbo assembler and watcom, write your own pmode extender, write your own sound player, write your own vesa lib (now that's a neat exercise) or go modex and well, have fun
i had, though i'm happy i'll never involuntarily be put through that wringer again
and i didn't code my own player nor extender
"RPi is the most modern and you can go completely bare metal there."
"Having a coprocessor (GPU on the Pi) handle a lot of tasks must be very helpful for bare-metal development"
But what's left of baremetality then?
Raspberry Pi uses so much closed firmware that it is said to have a sort of parallel OS running next to kernel (and ARM has no direct access to video processing unit's firmware).
A guy who has been developing RPi custom firmware told me that Raspberry Pi's baremetal is mostly a lie. ...though the concept itself can perhaps be understood in different ways. I've assumed that the default meaning is "without OS".
"And because the Pi is so very popular, it doesn't take terribly long for all the undocumented parts to be documented."
AFAIK many firmware calls in RPi3 are still not documented. While RPi itself is very popular, projects to replace its firmware are not so.
"Having a coprocessor (GPU on the Pi) handle a lot of tasks must be very helpful for bare-metal development"
But what's left of baremetality then?
Raspberry Pi uses so much closed firmware that it is said to have a sort of parallel OS running next to kernel (and ARM has no direct access to video processing unit's firmware).
A guy who has been developing RPi custom firmware told me that Raspberry Pi's baremetal is mostly a lie. ...though the concept itself can perhaps be understood in different ways. I've assumed that the default meaning is "without OS".
"And because the Pi is so very popular, it doesn't take terribly long for all the undocumented parts to be documented."
AFAIK many firmware calls in RPi3 are still not documented. While RPi itself is very popular, projects to replace its firmware are not so.
buy a classic xbox 1, install a mod chip (512kb at least), flash it with the debug bios, reverse engineer the d3d8 api calls and write your own nv20 driver
it's not that hard. i could do it.
it's not that hard. i could do it.
FWIW people have hacked the Nintendo Switch to bits so that you can install your own bootloader, OS, and they have written their own GPU drivers. So that's maybe something. (There's a TrustZone but it doesn't do anything, and an ARM7TDMI chip that is used for booting, but after that it's also just stuck.) So I guess the RPi wasn't as popular as the Switch. (But, most homebrew devkits for it target the regular OS and stuff.)
Also idk if a Pentium can be called "modern" :p
Also idk if a Pentium can be called "modern" :p
What about the Nintendo DS or 3DS? I do realize there are hardware differences, but which model is the least hassle to get software running on?
