Baremetal Amiga Emulator

[bloodline]

Originally Posted by hooverphonique

You are probably already aware of this, but the above smells like you have some memory corruption issue that manifests itself differently when having slow fast compared to chip ram only..

I now have a working sprite 0. It's not properly emulated, as I do all the sprite generation in the VBL (just pasting over the currently drawn screen in the chunky buffer) so any neat copper effects will be totally ignored.

But it means I can now interact with intuition... the first thing you notice is the corruption when the window is blitted around the screen, clearly my blitter code is still not right, and my guess is that is causing the chipram errors, thus when the program code is put into slow mem it is no longer being corrupted...

I can't really think what could be wrong with my blitter though...

[ Show youtube player ]

[alpine9000]

Amazing progress!

[bloodline]

Originally Posted by alpine9000

Amazing progress!

Accidentally discovered that screen dragging works

I didn't do anything to make it work... I guess that confirms my Copper is working as it should

Still can't get the corruption fixed... I'm probably going to rewrite my memory handling section see if I can improve it, get rid of all these weird memory errors (I wonder if the host CPU cache might be screwing with this?)

[ Show youtube player ]

[TEG]

This is exciting and amazing

I'm curious to know how fast the emulated 68000 is running. I'm impatient to view benchmarks when you will be able to run programmes.

[Devlin]

Originally Posted by TEG

This is exciting and amazing

I'm curious to know how fast the emulated 68000 is running. I'm impatient to view benchmarks when you will be able to run programmes.

If it's emulating a plain a500 then i imagine it should be around the same speed as that when the benchmarks drop I'm just happy that this kind of development is happening

[Twiggy]

Could you upload the latest binary for Debian? For those following at home. Cheers

[bloodline]

Issue log

I'm still fighting this memory corruption...
only three things are able to write to chipram; the CPU, the Blitter, and the Floppy DMA.

I've confirmed the Blitter and the Floppy DMA are only able to access the first 2meg of ram.

So my only guess now, is that some code in Kickstart is relying on the side effects of the Amiga's incomplete address decoding. Currently I catch known address bases; ROM space, Chipregs, Slow ram (I optionally shadow the chipregs in this space, to activate and deactivate slow ram), CIAs and then any address below the CIAs is just assumed to be chipram. Any address which isn't caught is just treated as ram (the entire 24bit space is backed with a 16meg memory allocation). This naïve model is probably just too simple and some code may have some stray high bits which would normally be ignored by a real Amiga as they don't address any real hardware. Nothing short of a complete rewrite of my memory system will fix this... so I will work on that over the next week or so, unless someone has a better idea of what might be wrong.

There are clues to the memory errors, notice the graphics corruption always occurs in vertical strips usually about a word in width... this is why I think it might be caused by stray high bits in addresses.

Originally Posted by twiggy

Could you upload the latest binary for Debian? For those following at home. Cheers

I'll try and put a build up here tonight please let me know how you get on, test as many ROMs as you own... so far only 1.2 works for me. If you have the latest beta of WinUAE you can make your own raw mfm boot disks to test.

-edit- no promises, but I will try and get a windows build too.

Originally Posted by Devlin

If it's emulating a plain a500 then i imagine it should be around the same speed as that when the benchmarks drop I'm just happy that this kind of development is happening

My Emulator isn't really an Amiga Emulator. It's better to think of it as a 68000 computer, which implements just enough Amiga hardware functionality that KS1.2 (currently, hopefully other Kickstarts in future) can boot. The idea being that when I port this to a platform like the RaspberryPi, it can bring up the OS, load in platform specific drivers and run (largely) free of the Amiga chipset.
Things to remember are that only memory accesses within the 24bit address space are byte swapped, and memory access in the top 32bit address space are platform native endian (which is almost certainly little endian now). If your code relies on the 68k being big endian, then you need to use memory allocated within the 24bit address space (first 16Meg).

The goal of my current project is to keep the Amiga emulation part as simple as possible, the whole thing is in plain C and depends on no external libraries. I currently have a single function, called once every frame which uses SDL to output the frame buffer and get some user input.

[hooverphonique]

Originally Posted by bloodline

My Emulator isn't really an Amiga Emulator. It's better to think of it as a 68000 computer, which implements just enough Amiga hardware functionality that KS1.2 (currently, hopefully other Kickstarts in future) can boot. The idea being that when I port this to a platform like the RaspberryPi, it can bring up the OS, load in platform specific drivers and run (largely) free of the Amiga chipset.

Then you probably don't need e.g. floppy dma at all as you probably won't need floppy support on the target platform.

By the way, did you try taking a look at the kickstart rom for the Macrosystem Draco? It is basically what you're talking about (an 68000 computer running amiga os without the amiga custom chips).

[bloodline]

Originally Posted by hooverphonique

Then you probably don't need e.g. floppy dma at all as you probably won't need floppy support on the target platform.

That's correct, I only want to get floppy emulation working so I have an easy way to load software into the emulator, and test its operation.

Once I have it working with Kickstart 3.0, then I will simply use the IDE to boot it.

I have an idea to split this into two projects in future, I am focusing on the original idea for now... bare minimum to get it booting, but I also want to try for a lightweight SDL based A500 emulator (using what I have developed so far, but probably won't need l for the original idea). Nothing is ever going to come close to WinUAE in terms of Amiga emulation, but I'm having a lot of fun trying to get this to work.

By the way, did you try taking a look at the kickstart rom for the Macrosystem Draco? It is basically what you're talking about (an 68000 computer running amiga os without the amiga custom chips).

Draco was what gave me the idea; What if the RaspberryPI was built around the 68k? That's easy enough to try, simply run a 68k emulator on the baremetal... But now I have no software, so why not try and get a 68k operating system booting on that 68k emulator? So this is where we are currently at.

[Toni Wilen]

I still think problem most likely is in blitter emulation.

Do you handle descending mode correctly? (it is not same as -(an) vs (an)+ CPU addressing modes). Do you load sources twice before first destination write? (Blitter pipeline emulation). Do you keep register contents between blits? (You originally said you didn't. It will cause issues, sooner or later)

[bloodline]

Originally Posted by Toni Wilen

I still think problem most likely is in blitter emulation.

Do you handle descending mode correctly? (it is not same as -(an) vs (an)+ CPU addressing modes). Do you load sources twice before first destination write? (Blitter pipeline emulation).

As you have guessed, my descend mode is simply a reverse of the forward operation.

I saw this in the HRM:

NOTE:
   -----
   This differs from predecrement versus postincrement in the 680x0,
   where an address register would be initialized to point to the word
   after the last, rather than the last word.

I just ignored it, as I didn't really understand what it was trying to say... at my cost it would appear.

-edit- I don't emulate the blitter pipeline at all, as soon as the bltsize register is filled (and the DMA is enabled) the blit is performed immediately.

for each word the sequence is
The sequence is:

Load Source A.
Decrement pointer A.

Load Source B.
Decrement pointer B.

Shift A (using previous A value).
Shift B (using previous B value).

Store (unshifted) A Value for next shift operation.
Store (unshifted) B Value for next shift operation

Load Source C.
Decrement pointer C.

if first word FW Mask A.
if last word, LW MASK A

D = logicFunction(minterm,A,B,C)

Set Zero flag if D = 0.

Store D value.
Decrement pointer D.

Do you keep register contents between blits? (You originally said you didn't. It will cause issues, sooner or later)

I have corrected this.

[bloodline]

Found a problem with the Blitter (after Toni suggested I look into it)...

It wasn't the descend mode... it was my FW/LW masking which needs to happen BEFORE the shifting... not after.

This has corrected most of the corruption issues... but some (very occasional, difficult to reproduce) corruption still occurs... and I'm still getting the Green screen memory errors during boot, and the disk image is still not validating... Something is still not right.

-Edit- Toni, do you think the problem could be related to the early completion of the blits? I have assumed that my blitter works the same as WinUAE's immediate blitter mode, in as much as it returns immediately, and sets the interrupt as soon as the bltsize reg is loaded.

[bloodline]

This morning before work, I was setting up my Debian box to make a fresh build and while copying over the sources, I noticed an error in my floppy code.

My cylinder buffer wrapped around at 6334 words, correcting this to 6333 means that the floppy is loaded correctly, but now since the disk loads fine, intuition doesn't come up and the earlier memory errors appear to be halting the boot.

Summary:

This week there have been three discrete problems, the blitter code was faulty (Thanks to Toni for sugesting that it wasn't working correctly), The floppy drive has been trying to load in an extra word (a word of 0x0000 at the end of the track, when the MFM decoder expects the last word to be 0xAAAA) but due to that error I was able to test see the emulator booting to intuition so it was really quite fortuitous. Finally, we have the memory errors... this seem to be halting the boot.

When I next have a chance, I will rewrite the memory handling code.

[bloodline]

A Debian x86 build.

The q key forces a reset.
The a key "inserts" the floppy disk loaded via the command line
The z key runs a memory test.

[gulliver]

Originally Posted by bloodline

Draco was what gave me the idea; What if the RaspberryPI was built around the 68k? That's easy enough to try, simply run a 68k emulator on the baremetal... But now I have no software, so why not try and get a 68k operating system booting on that 68k emulator? So this is where we are currently at.

If you need it, you can find a DraCo rom for download in The Zone!

As far as I understand this rom only patches an original A3000 v40.68 kickstart at boot time.

Your project looks promising.

[bloodline]

Originally Posted by gulliver

If you need it, you can find a DraCo rom for download in The Zone!

As far as I understand this rom only patches an original A3000 v40.68 kickstart at boot time.

Your project looks promising.

I would love to try a Draco ROM, but I can't access The Zone!

-edit- ignore me, I've figured it out thanks for the rom, I'll see what I can do with it.

[bloodline]

So I have rewritten the memory handling functions. The new functions don't decode the 24bit addresses properly, and this creates "echoes" of the custom chips registers in the address space above 0xC00000, and also any address in the lower 2meg space now wraps around if I have configured less than 2meg.

This has resolved the memory errors.

My default configuration now is with 1meg of chipram and no slow or fast ram.


Ok after struggling with Visual Studio... and failing I have finally managed to get this project compiling on Windows with MinGW.

Attached is a v0.1 build for Mac, Debian 64bit, and Windows 32bit.
[ Show youtube player ]

q key resets.
a key "inserts floppy"
z key, makes the disk valid (don't press this until the OS complains the disk isn't valid, I have intentionally introduced the disk error so intuition is brought up early).

Please test and let me know how you get on. Currently the disk loading seems to get to track 106 and then gives up... No idea why yet.

Any ideas what to look for would be great, my guess is that the OS is waiting for some part of the hardware to respond... but what?

[Sinphaltimus]

I get an error - SDL2.dll not found on Windows. clicking OK closes the emulation.

I googled and found this - https://stackoverflow.com/questions/...l2-dll-missing

I put the 32 and 64 bit version in the correct folder then ran WinZorro again and received another error.

the application was unable to start correctly (0xc000007b) Click OK to close.

I'm on x64 Win10 Pro.

EDIT: I ran in compatibility mode for Windows XP SP3 and received the same error about not starting correctly.

[bloodline]

Originally Posted by Sinphaltimus

I put the 32 and 64 bit version in the correct folder then ran WinZorro again and received another error.

the application was unable to start correctly (0xc000007b) Click OK to close.

I'm on x64 win10 Pro.

I don't have a Windows machine here, so I had to build it in VirtualBox using a discarded Windows7 DVD from work... Sadly that error is rather unhelpful... I'm not sure how else I can proceed with windows builds.

[Sinphaltimus]

Originally Posted by bloodline

I don't have a Windows machine here, so I had to build it in VirtualBox using a discarded Windows7 DVD from work... Sadly that error is rather unhelpful... I'm not sure how else I can proceed with windows builds.

Yeah, I'm not much help beyond that. Sorry. But thanks for giving it a go. Been following this since the first posting and am very excited for you. You'll get there, seems you have all the support you need to help get through whatever challenges are ahead.