Baremetal Amiga Emulator
 

Hi all,

Last week, after having some fun with some bare metal coding on my RaspberryPI (http://www.valvers.com/open-software...mming-in-cpt1/), I decided a fun little project would be to build a 68k emulator and then run it on a Raspberrypi without a host operating system, giving the 68k access to the whole Raspi's address space... essentially making a 68k raspberrypi!

Obviously this is a pointless exercise without some software to run on it, so I decided to add some extra parts to it so that I could get AmigaOS 1.3 to boot (I would worry about patching the graphics.library and input.device etc. to access Raspi hardware later)... I figured I would only need to emulate the CIAs and some Paula interrupt handling to make this work.

Since trying to debug on a bare metal pi is really difficult, I have built the Emulator as an application and used libSDL2 as my 'hardware platform' (I planned to remove the SDL parts once it works).

Naturally, since I have a SDL, I have added a few parts of the Amiga graphics emulation so I can see what is going on... Now the kickstart boots, but it would appear at some point during the boot (after the screen is set to white), the OS calls enable() and there is a pending SoftInt bit set in INTREQ, which causes the machine to jump to the exception table at Reserved vector #15... this causes a Guru...

Any hardware guru's able to give me some pointers where I need to look to figure out what is going wrong?

(please don't spend to much time on this, as it is just a fun project for me to help flex my brain after 20 years of not looking at 68k asm) :great

if you have a Mac and libSDL2 installed you can play with it here:
https://drive.google.com/file/d/1oOQ...ew?usp=sharing

You'll need a copy of kickstart 1.3 or 1.2 (doubled up to 512k, because I load in at 0xF80000 as I was testing with KS 3.0 as well).

I think your interrupt bit to exception mapping is wrong. There is no way any intreq interrupt bit would generate reserved exceptions.

btw, I have thought about doing something similar, having only UAE CPU emulation (including JIT if possible) and Fast RAM running in some microcontroller board with external hardware that handles all the required interface magic to make it drop-in 680x0 replacement :) Of course this is just fun plan, I don't do hardware and debugging something like this would be extremely painful.

I will investigate my interrupt handling some more... Many thanks for the steer!

Yes, These are fun ideas, I have tried to make my code small enough to fit on a Teensy 3.2 ;)

Bring on the WinUAE Raspberry Pi super accelerator :crazy

Hey Toni, you were correct, my exception handling on the 68k was slightly wrong. I have changed it, now the emulator just loops through the task switching functions (KS 1.2). I'm guessing this is "good thing" (tm) (does that mean my CIA emulation is working correctly?!)!

I think I'm going to need to emulate the Copper so I can see something more than a Color00 background... This will be fun, I have almost no idea what I'm doing with the Copper... But cop1lc points to 0x420 and cop2lc points to 0x474 so I definitely have a valid copper list in there! :D Which I guess also means I need working DMA emulation... :lol:

Nice. I was thinking along the same lines :

http://www.fpgaarcade.com/punbb/viewtopic.php?id=1221

I've using the SMI (Secondary memory interface, which normally connects to NAND flash) as a low latency interface to the chipset. I had to suspend this briefly while I completed the 68060 daughterboard, but back on it again.

Ok, so the Copper was really simple to implement... but It only ever loads 0 into the biplane pointers... my VBL interrupt is working fine, but I notice my CIAs are not generating any interrupts... should they be doing so?

This sounds really neat. Can't say I have the knowledge to help but I am very curious to see the results when they roll in.

I'll put up some more builds (Mac and RaspberryPi) as they progress... Right now I have a problem, I have rewritten my CIA code, but it hasn't totally fixed the boot process.

I think perhaps the problem might be that my emulation doesn't really take bus timing into account...

-edit- it now halts with a light green screen... BTW I'm happy to post the source if anyone is interested, but it's nothing pretty (it was never meant to be a full system emulation).

Interesting stuff. This is also being researched for MiSTer, a very low cost FPGA platform which has a built in quad core ARM. They are terming it Hybrid emulation. The Amiga chipset is recreated in the FPGA

I suspected that my Interrupt dispatch code was probably doing something wrong, I rewrote it to try and nest the interrupts better...

Now something seem to be loading cop1lc is being loaded with some odd value causing the copper to try and execute randomly in ram :(

Well, I achieved my original goal... The OS is up and running, but I moved the goal posts as it is really fun trying to get this to work, so I have tried to get some basic graphics working.

The blitter isn't working properly (and I don't bother with line drawing at all) ... But it is doing something (see attached) :D

This is very interesting. I don't understand all the low level challenges you face but i think you're definitely on to something with an rPi emulator that does not need a host OS. Like alexh said above, it's like an fpga Amiga only on the Pi and not fpga. And we all know Mist is shutting down, not selling anymore. This could very well fill a much needed gap. Godspeed and all the best - lurking anxiously.....

I wish someone would do this for x86 as a competitor to AROS since AROS is such a pain with hardware that it's hardly worth fishing for appropriate gear anymore. In that regard I have one more desktop PC to try IcAros on in the coming weeks, if that fails, I'll be done trying it for good unless some huge breakthru happens with the drivers..

After some testing, it was clear my planar to chunky conversion was a bit off. I have rewritten it (previously I was fetching each pixel individually, now I fetch a byte from each plane and build 8 chunky pixels in one go) and as a consequence found my beam counters were also not quite right, and now count properly.

I have decided to ignore the DDF settings for now, and generate the display based upon the values found in diwstrt and diwstop.

This works really well when diwstrt=0x2C81 and diwstop=0xF4C1; nice standard lores display, but during the kickstart boot process the VSTART is set to 0x5 and the VSTOP is set to 0x40 by the copper.

Which amounts to a 59 line display (-edit- 20 lines of which should be in the Vblanking period!?!)... I assumed this was a problem with my Copper... But I just checked with WinUAE (running in Wine - so much easier than the ARIII on my A500, Cheers Toni:great), and this appears to be correct behaviour! I must be missing something subtle here as that is far too small to display the kickstart image?

Sounds a great project !
Btw that shot of the screen reminds me of a Spectrum i upgraded in the early 80s ,, I hadnt seated the extra ram chip properly and it looked identical :laughing ..
but it does look like an 8 bit screen !

This is supposed to be the 1.2 kickstart screen, the drive head is being stepped every second or so... but the Display isn't being set up right, I need someone to give me a hint :)

-Edit- tonight I will try and add line drawing to my blitter code...

I made a little floating onoscreen C= logo (the same dimensions as the one on my A500) above the power and drive LEDs, because I was getting bored :lol

I've managed to get the Blitter to do something right...

Also attached is a fresh Mac build those of you to try at home... let me know how it goes.

https://drive.google.com/open?id=1oO...jEb8v9xg0AQpum

It's almost already possible to read "Workbench" :great
You are on the good way !

Slowly getting the AREA copy to work... I've not started on the fill modes, and my line drawing nukes something important in ram :(

you're getting there! That's amazing!