Baremetal Amiga Emulator

bloodline · 19 January 2018, 12:03

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)

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).

Toni Wilen · 19 January 2018, 12:20

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.

bloodline · 19 January 2018, 12:32

Quote:

Originally Posted by Toni Wilen

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

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

Quote:

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.

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

Amiga1992 · 19 January 2018, 14:40

Quote:

Originally Posted by Toni Wilen

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.

Bring on the WinUAE Raspberry Pi super accelerator

bloodline · 19 January 2018, 14:53

Quote:

Originally Posted by Toni Wilen

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.

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!

Which I guess also means I need working DMA emulation...

:

fpgaarcade · 19 January 2018, 15:23

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.

bloodline · 19 January 2018, 17:34

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?

Devlin · 19 January 2018, 20:23

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.

bloodline · 19 January 2018, 21:47

Quote:

Originally Posted by Devlin

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).

alexh · 20 January 2018, 08:14

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

bloodline · 20 January 2018, 11:07

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

bloodline · 27 January 2018, 14:51

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)

Sinphaltimus · 27 January 2018, 16:31

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..

bloodline · 30 January 2018, 16:35

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

), 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?

Genlock · 30 January 2018, 23:12

Quote:

Originally Posted by bloodline

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)

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

..
but it does look like an 8 bit screen !

bloodline · 31 January 2018, 00:04

Quote:

Originally Posted by Genlock

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

..
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

bloodline · 31 January 2018, 16:44

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

malko · 31 January 2018, 21:08

It's almost already possible to read "Workbench"

You are on the good way !

bloodline · 05 February 2018, 12:42

Quote:

Originally Posted by malko

It's almost already possible to read "Workbench"

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

Devlin · 05 February 2018, 12:47

you're getting there! That's amazing!

27 January 2018, 14:51	#12
bloodline Registered User Join Date: Jan 2017 Location: London, UK Posts: 433	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) Attached Thumbnails

30 January 2018, 16:35	#14
bloodline Registered User Join Date: Jan 2017 Location: London, UK Posts: 433	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), 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? Last edited by bloodline; 30 January 2018 at 16:48.

31 January 2018, 16:44	#17
bloodline Registered User Join Date: Jan 2017 Location: London, UK Posts: 433	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 Attached Thumbnails Last edited by bloodline; 01 March 2018 at 15:51.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Amiga emulator for iOS	steviebwoy	support.OtherUAE	35	15 November 2014 10:14
Amiga emulator for a PSP?	Vars191	support.OtherUAE	1	09 May 2010 02:08
Frederic's Emulator inside and Emulator thread	Fred the Fop	Retrogaming General Discussion	22	09 March 2006 07:31
ADF Files -> Amiga(amiga with dos Emulator)	Schattenmeister	support.Hardware	8	14 October 2003 00:10
Which Amiga emulator is best?	Tim Janssen	Amiga scene	45	15 February 2002 19:52

19 January 2018, 12:03	#1
bloodline Registered User Join Date: Jan 2017 Location: London, UK Posts: 433	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) 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).

19 January 2018, 12:20	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	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.

19 January 2018, 15:23	#6
fpgaarcade Registered User Join Date: Jul 2009 Location: sweden Posts: 30	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.

19 January 2018, 17:34	#7
bloodline Registered User Join Date: Jan 2017 Location: London, UK Posts: 433	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?

19 January 2018, 20:23	#8
Devlin Bane of Magic Join Date: Nov 2005 Location: Bradford, UK Age: 37 Posts: 335	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.

20 January 2018, 08:14	#10
alexh Thalion Webshrine Join Date: Jan 2004 Location: Oxford Posts: 14,331	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

20 January 2018, 11:07	#11
bloodline Registered User Join Date: Jan 2017 Location: London, UK Posts: 433	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

27 January 2018, 16:31	#13
Sinphaltimus Registered User Join Date: Aug 2016 Location: Cresco, PA, USA Age: 53 Posts: 1,126	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..

31 January 2018, 21:08	#18
malko Ex nihilo nihil Join Date: Oct 2017 Location: CH Posts: 4,856	It's almost already possible to read "Workbench" You are on the good way !

05 February 2018, 12:47	#20
Devlin Bane of Magic Join Date: Nov 2005 Location: Bradford, UK Age: 37 Posts: 335	you're getting there! That's amazing!

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)