RaspARI - an ATARI in credit-card format

[ardi]

Hallo,

I have written a new Emulator for the Raspberry Pi.
The development is still in a very early stage but it will run very fast.

Features:

• m68000 cpu
• MMU and 4MB Ram
• a little bit MFP
• Keyboard ACIA
• Falcon Videl-Shifter
• mount HardDisk image
• rtc

Create HardDisk-Image:
To create an image "mkfs.dos" / "mkfs.vfat" is needed. If not installed, then install it with

Code: Select all

sudo apt-get install dosfstools

Now create the image.

Code: Select all

dd if=/dev/zero of=scsi.img bs=1M count=10
mkdosfs -A scsi.img
mkdir scsi
sudo mount -o loop scsi.img scsi

Now the image "scsi.img" (with 10MB) is created and mountet to "scsi/". To change the size of the HD change "count=...".

Simple copy files to /scsi to fill the image.

Starting RaspARI:before you start RaspARI you mußt unmount the scsi.img

Code: Select all

sudo umount scsi.img

Now start RaspARI

Code: Select all

sudo ./raspari.elf

ardi

[wietze]

This sounds nice, if I would want to try this what would the steps be to do this?

Where can I download the raspari.elf ? Does the default raspian have support for elf format files?

Regards

[troed]

The development is still in a very early stage but it will run very fast.

Features:

• m68000 cpu
• MMU and 4MB Ram
• a little bit MFP
• Keyboard ACIA
• STE Shifter
• mount HardDisk image
• rtc

PLEASE implement GLUE/MMU/SHIFTER properly

http://atari-forum.com/wiki/index.php?t ... _Scanlines

[ardi]

This sounds nice, if I would want to try this what would the steps be to do this?
Where can I download the raspari.elf ? Does the default raspian have support for elf format files?
Regards

I have a download attached to the first post

PLEASE implement GLUE/MMU/SHIFTER properly
http://atari-forum.com/wiki/index.php?t ... _Scanlines

the goal if RaspARI is not a hardware-compatible st.
The goal is a fast emulator for "clean" GEM-App's

ardi

[joska]

This is a great idea It looks like the emulator runs under Linux - it would be even better if the Pi could boot the emulator directly. Is this realistic? That would make it more of a real computer than an emulator IMO, and also a lot simpler to maintain for the user as you only have to relate to the "Atari" and not an underlying OS.

[ctirad]

There are already efforts to port Aranym to ARM platform including JIT 68k compilation. So why to write something similar from scratch?

[joska]

So why to write something similar from scratch?

Because he can. Seriously.

[ardi]

Because he can. Seriously.

[MasterOfGizmo]

This is a great idea It looks like the emulator runs under Linux - it would be even better if the Pi could boot the emulator directly. Is this realistic?

Doing a "bare metal" version would require you to implement all drivers etc inside your binary. The only example for something like that which comes to mind is u-boot. You could in theory include 99% of uboot into your own app and boot that instead of uboot. But you'd still miss minor parts like video

Imho the only feasible approach is to run it directly on top of the linux kernel by replacing init with your app. This is pretty much how android works. You could then strip the kernel down to the bare minimum. And if you compile the required modules into the kernel you end up with pretty short boot times. You might still miss things like sd card auto mounting etc, but that's not nearly as complicated as running directly on the hardware.

[Hippy Dave]

This is a great idea It looks like the emulator runs under Linux - it would be even better if the Pi could boot the emulator directly. Is this realistic? That would make it more of a real computer than an emulator IMO, and also a lot simpler to maintain for the user as you only have to relate to the "Atari" and not an underlying OS.

I think of the underlying OS as a JTAG interface that loads the code. The emulator is not very dependent on the OS, it is dependent on the foreign hardware however. One could make an emulator kernel module. AFAIK Hatariod is a library *.so the next step is *.ko . I agree that a realistic Atari computer must have the distractions removed (os applications games etc.) that detract from the Atari ST experience. I also believe that higher emulation quality and access to hardware features are the most important.

[ardi]

Benchmark

[Omikronman]

Nice project. Please keep in mind that GEM has nothing to do with "clean".

[ardi]

Hi

RaspARI 0.3 is out.

Now with falcon-videl-shifter (16bit currently not supported).
The build-in EmuTOS-VDI-part is pimped a little bit (see new benchmark)

The download is attached at the first post of this thread.

ardi

[jayminer]

Wow!

I love these kind of projects! Gonna try this out on my Raspberry right now!

Are there any plans to emulate more of the Atari hardware in the future? Perhaps make it possible to run games and "hardware-banging" stuff?

*edit*
I should learn to read, just noticed that you said the goal was to be able to run clean GEM-apps, still extremely cool!

[jayminer]

Okay, I just tried this and it felt very fast, but I haven't really tried anything yet except for what you get without a "harddrive" attached. Is there anyway to get the bundled EmuTOS into english?

[ardi]

Okay, I just tried this and it felt very fast, but I haven't really tried anything yet except for what you get without a "harddrive" attached. Is there anyway to get the bundled EmuTOS into english?

try ./raspari.elf -c us
or ./raspari.elf --country=us
see ./raspari.elf --help

ardi

[wongck]

Now with falcon-videl-shifter (16bit currently not supported).

Wow, looking good.
So it can do 800 x 600 like using Videl inside ?

[BlankVector]

The build-in EmuTOS-VDI-part is pimped a little bit (see new benchmark)

Very good project.

Important note: EmuTOS is a GPL project. So if you redistribute modified EmuTOS binaries (are they ?) then you must make the modified sources available, too.

BTW, could you please tell us a bit more about EmuTOS usage in the RaspARI project?

[ardi]

The build-in EmuTOS-VDI-part is pimped a little bit (see new benchmark)

Very good project.

Important note: EmuTOS is a GPL project. So if you redistribute modified EmuTOS binaries (are they ?) then you must make the modified sources available, too.

BTW, could you please tell us a bit more about EmuTOS usage in the RaspARI project?

RaspARI use a normal EmuTOS only configured with localconf.h
The only changes i have made, i have hooked some VDI-functions to run a native-arm-function to do the same think (but faster) as the hooked m68k-funktion.
RaspARI has currently only a build-in EmuTOS because the Emulator is not perfect and runs only with a small amount of hardware aktivatet in EmuTOS.
A normal full-featured EmuTOS will currently not run.
The emulated m68k cpu currenty don't support Bus- or Adress-Error-Exceptions, important for Hardwaredetection.


ardi

[Eero Tamminen]

Important note: EmuTOS is a GPL project. So if you redistribute modified EmuTOS binaries (are they ?) then you must make the modified sources available, too.

Or if the emulator itself uses EmuTOS code e.g. for the ARM accelerated VDI functionality...

[itaboy]

This project is very promising! I am quite interested. Are there any developments?

[GokMasE]

Ok, bumping a rather old thread here...

I totally missed the news on this back in 2014, but it sounds like a very interesting approach!
And early results looks like they were quite inspiring to say the least as well..

Did development get any further than the 0.3 release? Is this project still alive?


Regards,

/Joakim

[GokMasE]

Any news on this one?