arm-none-eabi-as

[psiie]

arm-none-eabi-as -march=armv6z bios.s -o obj/bios.o make: arm-none-eabi-as: No such file or directory make: *** [obj/bios.o] Error 1

I am attempting to compile for the Pi. Not qemu. Am I missing something? A pre-requisite? I absolutely love the idea of this project by the way.

[gberthou]

Hi! Thanks for checking out this repo and for giving me feedback. It seems that you don't have the ARM assembler. What is your system and what are the ARM-related packages that you installed on it? For instance on my Arch Linux you would have to install the package arm-none-eabi-binutils.

By the way this is not a fully operational emulator: lots of bugs and bad performance. So don't expect to play video games with it ;) . If you simply like the idea, then you might want to hack with it. And I will be glad to see pull requests to make it work! Otherwise you might want to download a real emulator instead.

[psiie]

Thanks for the heads up. I think I will pull away for now and play with ASM a bit more (I'm a web developer so even though I love projects like these, I feel out of field :P .)

I did figure that this wasn't fully functional but was hoping it was at Proof-of-Concept stages for official roms. I look forward to seeing continued progress on this. I originally found this because I was looking for a non-linux OS's for the Pi. Something more ASM-like.

On a side note: Where does someone even start developing an emulator? Been considering making a 6502 emulator in js. Would love some advice/resources :)

[gberthou]

Yes for me it was like a Proof-of-Concept and a way of improving skills in embedded software. Unfortunately official roms use hacks and complex mechanisms that my emulator doesn't support yet. I have to dig deeper into this topic, but I think my interrupt routines are not reentrant at all, which makes nested interrupts - due to user code - broken at some point.

I'm going to buy a new Raspberry Pi since the one I had is now dedicated to some other project, so I might resume development.

May I ask how your search led you to this project? I think my choice of name was poor since all hits for "advance os" refer to OS for phone...

If you want to create your own emulator, some prerequisite would be basic knowledge of embedded systems/software. For example, if you haven't done it yet, building a bare metal OS for anything - probably Raspberry Pi - with basic features such as controlling leds, or even drawing onto the screen through mailboxes would be a cool spot to start with. You'll acquire skills in fetching information in datasheets: which datasheet? What am I looking for? And so on... Interrupt management is also something to be implemented in emulators so it's mandatory to know how they work. After some practice, you'll have to get the datasheets of the system you want to make an emulator for - NES maybe, I'm not familiar with consoles older than Game Boy. For example this page was really useful in my project: http://problemkaputt.de/gbatek.htm Actually there are two main pieces of software to write: the processor emulator and the 'hypervisor'. To emulate the processor, you'll have to find its datasheet, or at least the one that shows what its instructions are and what the corresponding binary codes are. This will enable you to decode the binary rom and know what to execute. The processor is not the only thing to emulate, there is a whole environment behind. For instance there is an address that corresponds to raw screen pixels in GBA. But that address is meaningless on the host - emulator - and accessing to it would likely result in a segfault. So you also have to setup a fake environment with all peripherals and addresses set in a way that the rom actually "thinks" it is running on real hardware.

Good luck for your emulator, I hope that there are enough resources online :)

[jan-kleks]

@gberthou Hello! It seems that the emulation community really likes your project (even though it's unfinished). I really hope that you will resume the development one day...

BTW, what is the potential for reducing emulation input lag (you can read about the sources of emulation latency in this article by the famous creator of a cycle-accurate SNES emulator) when it comes to projects like yours?

Do you think that this project could benefit in some way from combining it with an FPGA like this one?: "Flea Ohm can operate standalone or as a co-processor 'hat' for a raspberry pi computer."

Regards Jan

[gberthou]

@jan-kleks Hey! I'm no reddit user - yet! - and to be frank I'm glad that my project is referenced somewhere else than this github page. You seem to have a nice community there, I may want to join ;) . I read the thread you're talking about and pretty much everything I read there seems true. It's only, for now actually I hope, a proof of concept, based on the fun fact that there is backward compatibility in ARM instruction sets. I did it mainly for learning purposes and because I like challenges. I really wanted to see if I could go anywhere with this idea in mind. So basically, there is no interest in using the code as is, but I'd love to see this idea reused and serve as a base for a far better implementation. Actually I planned to release on this repo a piece of 'paper' written in a scientific way to explain what my idea was, with the code as a demonstration. But I was waiting for a better development state and finally it might never happen :( . And people out there are right, I'm simply running the GBA binary on the processor without prior modification, everything is based on virtual addresses and traps in peripheral address range. As mentioned in your thread, performance are really bad, but it's more likely to originate from my poor implementation rather than the idea itself. For instance I'm never using the GPU, which was something I'm really interested in doing. I don't remember well the numbers, but I guess that without display, performance are ok but the software-managed display part is pretty awful...

I also really hope I - or maybe we? - resume development or restart from scratch one day. Now I'm working on RPI 3 and I still no longer have RPI 1, so either I buy one or - more interesting in my opinion - I spend some time adapting my code to make it run on RPI 3 and to take advantage of the numerous cores. It seems feasible since I think I have built a code base for bare metal coding on every core of RPI 3.

I'm not very familiar with FPGAs - this is something I'd like to fix - so I'm not sure I got everything about the project. Since we're here targetting ARM, maybe the best fit would be to keep an ARM chip, as main processor instead of the GPU, and use the FPGA as coprocessor+other functions. Because if the processor is to be part of the FPGA, then it results in reduced amount of available LUTs for other purposes, such as peripheral emulation. So yes, I guess we could benefit from using FPGA if we manage to port the greatest amount of peripherals that we can on it, so that very few traps would be needed. People of your community tend to say that trap overhead might not be that huge, so maybe it's not a big concern. But with my implementation I noticed that trap overhead is quite substantial so dedicated hardware might be a solution. Aside from the platform and the code doing what we want them to do, as you already know I like doing stuff for the idea itself. So even if you're not sure about using this kind of platform, I'd say go for it if you can buy such a platform!

As far as input lag is concerned, we cannot do many things about hardware input polling. Even though the software part is based on interrupts, if the hardware layer slowly polls its inputs, then we could simply change hardware! One first attempt could be to solder buttons and connect them to gpios so that we can achieve full interrupt latency. I don't remember well the input lag on RPI 1 with my software, but the limiting factor clearly was the display. My insight would then be to try to optimize the most time-consuming piece of code and only then see if input lag is not acceptable with USB hardware and my adapted version of USPi as driver.

Regards, and looking forward to seeing updates from your community!

Gautier