-Edit- The loaded data in memory looks exactly as it should starting with the second sync mark of the first sector.
Also, I've tried to feed the data without the track gap, doesn't make any difference

Hmm.. Seems like the problem is something completely different, then :-/

Quote:

Originally Posted by bloodline

-edit2- I'm going around in circles with this floppy disk issue... Until someone has any ideas, I'm looking at the gayle IDE registers... so far my emulator is doing this at startup... now to find some info on what these registers are:

You mean it is a log of what the ROM code does?

DC0000-DCFFFF is real-time clock, not IDE.
DE0000-DEFFFF (I think) is config registers in various ASICs, not IDE - what Amiga does the ROM you're using, belong to?

Very impressive mate. I couldn't even work out how to get Musashi to run some code. I know there's an example included with it, but it's overly complicated.

Yeah, Musashi was a bit fiddly to get working, but once I got it sorted out back in 2017, it found it actually a really nice self contained CPU Emulator. The difficult part is instruction table and setting up the callbacks.

If you want a plain 68k Emulator, download my Emulator and rip out everything except the Musashi code and CPU.c (and CPU.h), then just call the functions in CPU.c to interface with it.

What have you done with pi bare metal so far, care to post the source for that (I was just starting with bare metal myself).

I thought about taking parts of the UAE4ARM code rather than starting the emulation from scratch.

Hi Eugene, perhaps we should talk offline, but if you look at my first post, I link to the project which allows you to get Baremetal frambuffer and keyboard working. I have written Omega so that I can sit it on top of that!

I’m definitely interested in discussing the RasPi part in more detail, I think UAE4ARM would also be a great idea as a Baremetal emu. Perhaps we should start a new thread (not in the Amiga hardware section for this topic).

I've ran emulators on various flavors of Linux but to me running bare metal would be more Amigaish

I bought the official RPi display and since its wider than the Amiga display I wanted to have the "emulator" controls on each side of the display.
My idea was to take as much of the emulator code from UAE4ARM instead of trying to reverse engineer that myself and just replace the Linux system calls with bare metal code.

I'm doing similar with x48 (hp48 emulator) as well, planning to compile it on a PIC or AVR.

I was meaning anything specifically you had done yourself, I assumed that was your website, but it looks more like a copy/paste of some of the other bare metal tutorials.

No, I started this project after trying to get the various Baremetal RPi tutorials working.

It is fairly easy to get the Pi up to a known good state, with working Keyboard and frambuffer... then I wrote a simple memory allocator, and it was while I was trying to workout an executable loader (I was struggling with the ELF docs and wondered it I could adapt my HUNK loader to work with ARM), I realised I was fed up reinventing the wheel... This is where I wondered if I could just run a 68k Emulator Baremetal and then treat the Pi as 68k based board, and use existing 68k code... that’s how this started, running AmigaOS needs a bit more than just a 68k, so I started adding more stuff to the Emulator and found that this was a lot of fun.

I don’t have any numbers at this time, but Linux should have better performance as that is able to use the “binary blob” drivers provided by Broadcom.

My idea is that my Emulator implements just enough hardware to get AmigaOS booting, after that I would want to write drivers which interact with the raspberry pi directly in AmigaOS.

Are you aware of "Ultibo" - a alternative kernal/os for the rpi?
Thy managed to get native accelerated video support for their non-linux Open Source OS:

The majority of the interface between the ARM CPU and the VC4 GPU is contained with the userland libraries which are maintained by both Broadcom and Raspberry Pi. These have been ported to Ultibo and are provided as a series of static libraries that are included as required in order to expose the appropriate parts of the interface.

I've ran emulators on various flavors of Linux but to me running bare metal would be more Amigaish

Yeah, with my idea the 68k code has full access to the RaspberryPi adress space... So in effect it would essentially be an A500(ish) with a BCM2837 gfx chip on the CPU bus.

Quote:

I bought the official RPi display and since its wider than the Amiga display I wanted to have the "emulator" controls on each side of the display.

Seems like a reasonable idea... FS-UAE does something a bit similar. The problem we face with Amiga emulators is that the mouse X/Y is a relative counter... so the host and the Amiga quickly become unsyncronised. Something I want to do is make the Emulator more aware of the absolute mouse position of the host, this would allow seamless mouse transistion between the two... it’s not an easy task.

Quote:

My idea was to take as much of the emulator code from UAE4ARM instead of trying to reverse engineer that myself and just replace the Linux system calls with bare metal code.

So, yeah my approach was the other way around. I stated with a simple 68k Emulator and added to the emulation whatever parts were need to get AmigaOS booting. This has resulted in a very minimal emulation layer.

I was spiuosed to have moved house by now, but things haven’t gone very well, so all my hobby electronics (including the Pis) have been packed away in boxes for a few months now. This has given me time to fix bugs and add a few nice features to my Emulator.

Quote:

I'm doing similar with x48 (hp48 emulator) as well, planning to compile it on a PIC or AVR.

A few years ago, I started getting Mushashi compiling on a Cortex M3, it would be fun to run a real A500 on an ARM... Where I could then sneak in native ARM code!

Are you aware of "Ultibo" - a alternative kernal/os for the rpi?
Thy managed to get native accelerated video support for their non-linux Open Source OS:

The majority of the interface between the ARM CPU and the VC4 GPU is contained with the userland libraries which are maintained by both Broadcom and Raspberry Pi. These have been ported to Ultibo and are provided as a series of static libraries that are included as required in order to expose the appropriate parts of the interface.