My recommendation here would be to implement an I/O interface device, such that you first write one register with the graphics coordinates you want to access, then read or write another register to actually perform the access. The framebuffer then exists outside the 6502's memory map except for a very small I/O window. Your emulator should trap I/O accesses and emulate the device behind them.

You could look into the Sharp MZ-800 for an example of how to design an interface like that. It's a Z80 based machine, but its display hardware is relatively impressive for its simplicity.

So it's been quite a while since I updated my progress with the simulator.

I have moved from the original PI B model to the PI 2 model. This has a 4 core processor and runs at 900MHz. I have the simulator running on core 0 and its getting about 97MHz effective speed. Simple terminal IO is provided by UART0. I have a simple LED blinker running in core 1. This helped me ensure I was managing the cores correctly and that I had the MMU and caches set up. The LED is blinking really fast vs. much slower before the MMU was set up.

In core 2, I have a 320x200 display set up with 63 colors ( 2 bits for each Red, Green, & Blue). I have it set up as 4 addresses in the simulator IO space
$8040 = pixel color - 0x00RRGGBB
$8041 = Y coordinate 0 - 199, above that and the pixel will not get plotted
$8042 = X coordinate low byte
$8043 = X coordinate high byte 0-319, above that and the pixel will not get plotted

A write to $8044 will tell core2 to plot the point.
Reading $8044 indicated if the core is ready to plot the next point. 0=ready, $FF means its busy

I have posted a short demo of a screen saver written in 65C02 assembly. It sets up random start location, box dimensions, and step distances, then proceed to draw boxes using random colors (all 64). It will plot about a 1000 boxes before it clears the screen and repeats.
The speed is amazing considering there's a 163,000 cycle delay after each box is drawn.

I need to create a clear the screen function as the 65C02 cannot efficiently clear the screen.

I may experiment with adding point, line, box, bar (filled box), circle, filled circle, triangle, & filled triangle routines to the video core, and create a command parser to pass the needed data. This will offload a lot of work from the 65C02.

Core 3 will eventually be used to interface the USB sub-system, where I can add keyboard, mouse, Ethernet, and data storage. I need to get a handle on sound generation also. Core 1 is also free if I need to split the workload.

The source is not quite ready, but I am posting a zip file with the saver.bin file and PI2 boot files. Copy the boot files to a FAT-formatted microSD and put that in your PI2. Connect a TTL serial device to UART0, open a terminal with 115200N81; and power up the PI. You should see the SBC monitor startup message. Type U<enter> and then do an XMODEM transfer of the saver.bin file. It will load to address $1000. Type 1000g<enter> to start the screen saver. Press any key to stop it.

Back to the Pi manuals and ARM manuals.

Video here -> https://youtu.be/CRIty7xRFDg

Have fun!

Daryl

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

Excellent!

Just curious does this work for Raspberry 3 as well? Supposedly different CPU chip but at bare metal level does this change?
Thanks

The Pi 3 support 64 bit and32 bit code. It boots differently so the Pi 2 code does not run on the Pi 3. I may attempt a port to Pi 3 in the near future.

Daryl

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

There's a trap for the unwary here: the Pi 2 comes in two flavours, one of which is more like a 3:
https://www.raspberrypi.org/forums/view ... p?t=162139

Here's a Christmas gift for anyone interested.

This code runs on a Pi3 B+. I have made the changes from a Pi2 to a Pi3 board and found running without Turbo mode was getting me about 95MHz simulated. With turbo mode, I am now getting 220Mhz simulated speed. That equates to a 2 Billion cycle loop completing in 9 seconds.

The kernel7.img file is coded for the Video Core running at 400Mhz (turbo mode) and CPU running at 1400Mhz. This does cause the parts on the Pi3 to run warm. I have a heatsink kit installed on mine with no fans.

I will post a version without Turbo mode for those happy to have 95MHz as well. That one runs pretty cool.

Copy the files from the ZIP file to a microSD that is bootable on the Pi and connect the UART on pins 6,8,10 of the GPIO header to a 3.3V serial to USB adapter and open an terminal to 115,200N81. Power up the Pi and look for the Monitor greeting.

The saver.bin and timing.bin can be uploaded to the Simulator via xmodem file transfer in your terminal. Both load at $1000 so after loading, do 1000G<enter> to run them. Run the saver in both turbo and non-turbo to see the speed difference.

Merry Christmas!

Daryl

P.S. - I plan to go back to the Pi 2 and see if I can boost it with turbo mode also.

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

Thanks for the updates Daryl. I will indeed open my Christmas gift today!

The gain on the Pi 2 was not as substantial, but it did get up to about 130Mhz.

If anyone is interested, the only change needed is to add this config.txt file to your boot microSD card. All else is the same.

Daryl

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

Hi Daryl Just a question on what you are using to talk to the Pi. I tried picocom on linux and while the terminal works fine when I try and use xmodem to upload the saver.bin it complains after the first $80 bytes and doesn't load anymore. Not sure if the sx command used in linux is computing the CRC differently or whether there is something else going on. Since the timing.bin is short less than the 1 sector it loads and runs (although there is no output I can see).
Looking forward to trying more. I appreciate that you have the emulation even working on the Pi.
Thanks.
Larry

I use Windows 10. Hyperterminal and Teraterm both work for me.

Be sure to select xmodem CRC. Xmodem checksum won't work. Also, it does not support 1k packets, so be sure that is not selected. I cannot recommend a terminal app for Linux. Maybe someone else can?

Let me know if you find a solution.

Daryl

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

So here's a low tech way to install the saver.

Send this text file to the pi. use send text or paste it if there's no send text. You may need some intercharacter and/or interline delays to get it to work.

This will essentially poke the program into memory using the monitor's write command.

Daryl

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

Hi Daryl
Thanks for the suggestions. In the end the simple method of pokeing worked with a 10 ms character delay. Even on a Pi3B (no plus) in non turbo mode it is satisfyingly mesmerizing to watch. I did try sending a intel hex version made from the saver.bin (converted using srec_cat.. still had the 00 10 at the head) but the upload method didn't seem to fall back to receiving the intel format. I'm not sure why this failed. It seems the standard sz program that comes with linux only has an option to go from 32 bit CRC to 16 bit CRC for zmodem not xmodem. I will look at alternate implementations of xmodem for linux even if it's a standalone program. It happens that in my work area for electronics I have only linux running on my older PC's. So unless I take a laptop there to connect to my various Pi's and FPGA, AVR projects I will have to sort out the xmodem for linux issue.
Thanks again and looking forward to future developments for the Pi and your 65C02 emulation.
Larry

Yes, it is. My Sbc3 version also randomly selected between rectangles, circles, filled rectangles, and filled circles. I will probably break down and add support for the ARM to generate those in the future. I just finished a 40x25 text generator. It supports full color and some cursor movements. Generating a single character takes updating 64 screen locations. Combine that with scrolling effects, and the throughput is not very impressive. I also managed to up the baud rate from 115200 to 921600, so the UART interface is lightning fast.

I have been reading on SD card interfaces and audio interfaces. I was thinking it would be nice if users could place their own OS's into the Simulator by adding a 32k binary image file to the boot folder on the SD card. I have a C-based program for a keyboard driver that I need to hook into the simulator so users can have the option of keyboard & screen user interface or the UART interface. So many thing to do still, so little time.

Happy new year to everyone!

Daryl

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

I have added the option of loading your own ROM image to the simulator. This is done by placing a 32K binary image on the SD card called "sbcos.rom". The simulator will try to load it and if successful, it will overwrite the built in SBCOS. In the zip download file, there is a quick manual on the IO addressing and the video interface. That should allow others to test out their own terminal-based OS's. This is for the PI2 currently. I will eventually get it updated for other versions as well.

I'm attaching it here and its also available on my website -> https://sbc.rictor.org/pisim.html

Enjoy!

Daryl

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