I finally got around to coding up my 65C02 simulator on a Raspberry PI (Pi 1 - B model). It is running with console IO via a UART at 115200 baud. It boots direct from the SD card with no PI OS. I plan to code up a timer to find out how fast the emulated clock speed is. Its is written in C for now. I still need to dig into the ARM assembly language.

I'll report back with a speed as soon as I get that calculated.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

That's nice! I like bare metal projects, and one using C is a tad more accessible than one in assembly.

Any plans on writing up the process to interface with the pi at a raw level, and build and boot the image?

+1

I would also like to know this. I have a RPi Zero and I think it would make an excellent interface to vintage hardware but I just don't want the Linux layer on top (not that I have anything against Linux...I just don't want the latency).

_________________
Cat; the other white meat.

Brian Sidebotham's Valver's Pi Bare Metal Tutorial provided a starting point for our bare metal PiTubeDirect implementation, including the cmake based build system:
http://www.valvers.com/open-software/ra ... ng-in-cpt1
http://www.valvers.com/open-software/ra ... ng-in-cpt2
http://www.valvers.com/open-software/ra ... ng-in-cpt3
http://www.valvers.com/open-software/ra ... ng-in-cpt4
http://www.valvers.com/open-software/ra ... ng-in-cpt5

Dave

Yes, there are many others out there who have done bare metal experiments. I use one created by David Welch that includes a boot loader. I copied the boot loader onto the SD card and it will initiate an xmodem transfer of a raw binary file and will execute it. I added a reset switch to my PI to reenter the boot loader easily.

You create your program using a GCC or ARM assembler and do an xmodem download to test. once your code is working correctly, you copy it to the SD card, replacing the boot loader and you are all set.

I will include all the details once I have the speed calculation completed, including the UART connection and optional reset switch.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Way to go, Daryl. Very exciting! Can't wait to try out your stuff.

I'd like to include a Pi Zero in a couple of my upcoming projects (preview below)...

Cheerful regards... Mike

Nice use of a Pi, as a self-contained text terminal!

For PiTubeDirect as an example, it might be useful to look at the project as it stood in mid 2016, before the GPU was brought into play as a fast bitbanging engine - initially we were using an ISR to do the bit-banging, triggered off a decoded address. As it happens, there's a branch which Dave took at around that point, where he (eventually) got the GPU to handle video out and terminal emulation, also in bare metal. In this case the ARM emulates a second processor, the ISR emulates the peripheral interface, and the GPU emulates a video terminal (output only.) The history of that branch is a good place to explore developments:
https://github.com/hoglet67/PiTubeDirec ... s/atom_vdu

One thing you'll see in PiTubeDirect is that while it is bare metal, and there is necessarily some assembly to get the machine running and configured, for both the ARM code and the GPU code it's also possible, and frequently convenient, to write in C.

I'll link here to David Welch's baremetal tutorials:
https://github.com/dwelch67/raspberrypi

One thing the Raspberry Pi foundation have done, which makes life slightly more complicated, is revised the hardware and even the pinout a few times. Supporting a single revision of a single model of Pi is easier than supporting all flavours, but both are possible tactics. At present, AFAIK, there's only one revision of the Zero and of the wifi-enabled Zero W - but the two of those are different, IIRC, even if you're not using the wifi.

(ETA: While I'm here, there's a tutorial on writing an OS for ARM which might be a good read, for ideas:
https://www.cl.cam.ac.uk/projects/raspb ... orials/os/
)

Thanks for all the links, everyone.

OK, so here’s my tutorial on getting my 65C02 Simulator to run on a Raspberry PI – bare metal style.

This is for an original PI 1. I have a B model with 256MB of RAM.

First you need to download the minimal boot files that will allow the GPU and ARM to initialize and prepare to boot. I got mine from this GIT repository:
https://github.com/raspberrypi/firmware ... aster/boot

The files you need are:
bootcode.bin
start.elf

When the PI powers up, the GPU will start running from an internal ROM image. It will then set itself up and load the two files above. Those will be used to further set up the GPU and ARM. When it’s all done, it will look on the SD card for a file named kernel.img. This file usually contains the code to boot Raspian Linux or some other OS. We will be creating our own file to do whatever we want to do.

David Welch put together a great tutorial site, located here -> https://github.com/dwelch67/raspberrypi

I am using his bootloader06 app to provide an easy xmodem file transfer of my target kernal.img file. In this way, I don’t need to remove/install the SD card a thousand times. It uses the UART02 located on the 40 pin GPIO header. Gnd is on pin 6, TX is pin 8, and RX is pin 10. I connect a cheap USB to TTL serial adapter to the GPIO header for connection to my PC. I also installed a 2 pin header on my board at P6, near the RG2 voltage regulator. In this way, I can add a momentary switch to the header which will reset the PI and start the boot loader. You can download the bootloader’s kernel.img file from David’s site here -> https://github.com/dwelch67/raspberrypi ... kernel.img

A quick note, the kernel.img file expects to get loaded at RAM address 0x8000. The bootloader is installed and moved to RAM at 0x200000. This restricts your kermal.img file to about 2Mb.

Put those three files on your SD card and insert it in your PI, connect your serial cable, and boot it up.

Your terminal needs to be set for 115200,N,8,1 with no handshaking. You should see a small prompt similar to this:
12345678
002002B8
00008000
Then you will get a slow addition of the “section sign” symbol. This is telling you to start an xmodem download. The protocol uses the checksum error detection vs. the CRC error detection, so if you need to select one, be sure its checksum.

My 65C02 Simulator is a 104Kb file called “kernel.bin” It takes about 25 seconds to download. Once the download is done, you’ll get a “DADADADA” response meaning good data transfer. If you see a message like “00BADBAD”, something went wrong and try again. Once you get a good transfer, just press “G” and the bootloader will transfer execution to your program.

If all went well, my SBC2OS prompt will appear on your terminal. You also rename my simulator file to kernel.img and replace the bootloader kernel.img file on the SD card to boot direct to the simulator.

I compiled my C code using GCC v4.7 as David recommended. I’m using Windows 10 so I created a batch file to run the GCC toolchain. My first release is running at a measly 1.1MHz. I plan to try a newer version of GCC. The C code is mostly the same as the one I ran on my other ARM dev board, which ran at about 7.5MHz from a 300MHz ARM. I clearly have some more work to do.

It’s a start, and can only get better and faster. I want to work on the C code before I release it, but I will include the current binary for others to give it a spin.

I'm attaching the 3 boot files and my Simulator binary in the enclosed ZIP.

I will try to put together a similar tutorial for the PI2, as I have one of those around too.

Thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

So I increased the optimization setting in the GCC compiler and have increased the speed to 2.6MHz and reduced the binary size from 104 Kb to 63 Kb. Still pitiful though, given an CPU clock of 700 MHz.

I downloaded the ARM C compiler this morning and will try to get it working. I'd like to see a speed of 8 to 15 MHz.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

So the native pi assumed some kind of filesystem on the SD card? I guess that's a FAT partition, right? I guess a "pi linux" SD card has a DOS partition followed by a Linux (ext2/3/4) partition?

The performance numbers are really surprising. Is there a missing "turbo button" bit that you're not turning on at boot?

I don't have personal experience with the Raspberry Pi, but that seems way too slow, considering that people are routinely using it to emulate whole gaming systems (including Playstation). I doubt the compiler can make that much of a difference - maybe the SoC is not set up correctly (MMU/cache settings come to mind)?

(I dimly recall there is a need to enable the caches, at least in some baremetal cases. See for example
https://github.com/hoglet67/PiTubeDirec ... ache&type=
)

The native Pi is an unusual SoC - the videocore (GPU) is in charge at boot time, and it has boot ROM which reads some code and config files from a FAT filesystem on the SD card. Only after the videocore has initialised and configured the chip does it load a kernel file from FAT, and then start up the ARM. The ARM is a minor part of the chip, but a major part of the Pi. To setup the SoC even for a bare metal project, you may need to pay attention to the config files.

hi all!

Here's an update on my work with a 65C02 Simulator on a bare-metal PI.

I decided to drop C and use ARM assembly. I've finished coding the simulation a week ago and have been debugging the code using Klaus's awesome test suites. As of 15 minutes ago, my simulator is passing both the 6502 and 65C02 tests. I still need to go over the code to optimize it, as I my goal was to get the code working first. Its surprising how many instructions are needed to do 8 bit operations on a 32 bit machine.

I wrote a simple 6502 time delay program using the improved cycle counting of the Kowalski Simulator to come up with a 20 million cycle loop. I then ran 5 of those loops and it took ~7 seconds. That comes out to just over 14 MHz. While that is better than the C code, I was still hoping for more.

I have enabled the program and data level 1 caches. I am assuming the processor is running at the default 700 MHz, as I am not using a config.txt to change any of the defaults. I will spend more time trying to optimize the code and dig deeper into the PI's internals.

Current IO supported is just the serial IO and control of the ACT LED. I plan to add more IO hardware support as well.

Stay tuned.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/