Baremetal Amiga Emulator

[Samurai_Crow]

No, I meant I could do it unless someone has Visual Studio, I could do it in MSYS2 GCC.

[bloodline]

Originally Posted by Samurai_Crow

No, I meant I could do it unless someone has Visual Studio, I could do it in MSYS2 GCC.

Please do! It would be great to have a Windows build up!

[Samurai_Crow]

I'm having a little trouble finding the includes for SDL2 although I have the package installed under MSYS2. I haven't found the Developer install of it so it can't find the SDL2/SDL.h file.

EDIT: Found the header in /mingw64/include and libs in /mingw64/lib

Now GCC is complaining about stray unicode characters in DMA.c

I'll see if I can put spaces between the comment marker and the character.

[bloodline]

Originally Posted by Samurai_Crow

I'm having a little trouble finding the includes for SDL2 although I have the package installed under MSYS2. I haven't found the Developer install of it so it can't find the SDL2/SDL.h file.

Yeah, I had loads of problems myself trying to get things to compile on Windows, my mind boggles how this is such a popular platform!

I think you also need to rename main() to SDLMain()... or something... it’s all very strange.

[Samurai_Crow]

Actually MSYS is a Unix compatibility layer for Windows with the Arch Linux package manager.

See my edited post.

EDIT2
The deal with SDL_main is that it needs to add startup and shutdown to the main function so SDL2/SDL.h includes a main() macro that feeds the parameters into SDL_main call and then links in the custom startup and shutdown code. The SDL_main function you supply will be the same for all platforms but will link to different code on all platforms.

EDIT3
It appears all the invisible characters embedded in DMA.c are throwing off GCC. Clang generates a bunch of errors too.

[bloodline]

Originally Posted by Samurai_Crow

I'm having a little trouble finding the includes for SDL2 although I have the package installed under MSYS2. I haven't found the Developer install of it so it can't find the SDL2/SDL.h file.

EDIT: Found the header in /mingw64/include and libs in /mingw64/lib

Now GCC is complaining about stray unicode characters in DMA.c

That's a weird tab character from the text editor I used at work to write that bit of code, in the function table just delete it and use a normal space.

[Samurai_Crow]

Originally Posted by bloodline

That's a weird tab character from the text editor I used at work to write that bit of code, in the function table just delete it and use a normal space.

DONE! Now it's not linking right but I think I can get it yet.

It looks like the latest stable open-source build of Clang likes #include <stdint.h> and won't compile without it. GCC doesn't care but still won't link yet.

[Locutus]

run sdl-config --libs to see what exact -l<lib> you have to add, note that this is case sensitive so -lSDL2 not -lsdl2 as in a previous example line.

Also depending on your compiler/environment you might have to #include <stdint.h>

[Samurai_Crow]

Originally Posted by Locutus

run sdl-config --libs to see what exact -l<lib> you have to add, note that this is case sensitive so -lSDL2 not -lsdl2 as in a previous example line.

Also depending on your compiler/environment you might have to #include <stdint.h>

Thanks, that got me farther but it still wouldn't link. It couldn't find -lmingw32 or changing it to -lmingw64 either. It must be looking for a standard WIN32 build process instead of MSYS2.

I'm going to try to use CodeLite to generate a makefile.

EDIT
It looks like CodeLite is using native Windows paths and filenames so it is not a good port to MSYS2.

EDIT2
I've submitted bug reports on the MSYS2 repo for the half-ports. In the meantime I've forked the Omega repo and committed my changes. When I get it working, I'll submit a pull request.

[bloodline]

Originally Posted by Samurai_Crow

Thanks, that got me farther but it still wouldn't link. It couldn't find -lmingw32 or changing it to -lmingw64 either. It must be looking for a standard WIN32 build process instead of MSYS2.

I'm going to try to use CodeLite to generate a makefile.

EDIT
It looks like CodeLite is using native Windows paths and filenames so it is not a good port to MSYS2.

EDIT2
I've submitted bug reports on the MSYS2 repo for the half-ports. In the meantime I've forked the Omega repo and committed my changes. When I get it working, I'll submit a pull request.

Good work! I think it would be helpful for for me to remove the unix file handling stuff, currently in main, but will be move to Host.c and replaced with SDL file handling, as I formalise the interaction between Omega and floppy disk images. The current approach was a quick and dirty hack to get something loading.

[Leffmann]

Originally Posted by Samurai_Crow

How about MSYS2 on Windows since I can't get the freeware Visual C++ any more?

How come? VS 2017 community edition is still freely available.

I built the emulator with VC++ a couple of weeks ago (just to try it out, I didn't keep the files) and it'll be a bit of a chore. It's mostly the POSIX file-handling stuff and VC++'s poor C support you have to deal with.

[bloodline]

I have rewritten the floppy drive emulation, honestly no idea how the old code managed to work.

New code supports up to 4 drives, currently only two ADFs can be added via command line. Two disk should suffice for testing.

Omega ./Kick13.rom ./disk1.adf ./disk2.adf

Not a thrilling video, but progress.
[ Show youtube player ]

I'll be looking to getting Kickstart 3.0 booting at some point.

[Genlock]

Originally Posted by bloodline

I have rewritten the floppy drive emulation, honestly no idea how the old code managed to work.

New code supports up to 4 drives, currently only two ADFs can be added via command line. Two disk should suffice for testing.

Omega ./Kick13.rom ./disk1.adf ./disk2.adf

Not a thrilling video, but progress.
[ Show youtube player ]

I'll be looking to getting Kickstart 3.0 booting at some point.

Fantastic work getting it running this well !
Will you be working on Kickstart 3.0 before catching up with the RPi3 version project?
I would love to see the pi running this baby




Oh and nice work on the car in the link on your first post What a rush

[bloodline]

Originally Posted by Genlock

Fantastic work getting it running this well !

Thank you! I'm still a bit surprised it works as well as it does!

Will you be working on Kickstart 3.0 before catching up with the RPi3 version project?
I would love to see the pi running this baby

Yeah, Not sure where my focus is right now, I was chatting with Michal Schulz this morning about running this on the Rpi. I'm currently in the process of moving house, I might have to wait until I've moved before I can really commit to getting it working on the Rpi. So I will probably focus on working out bugs and, yes, getting kick3.0 booting, as my original plan was for the system to boot via the IDE not via any floppy images.

[Samurai_Crow]

I got it to build now. Pull request submitted. It appears to have a merge conflict with blitter.h though.

[bloodline]

Originally Posted by Samurai_Crow

I got it to build now. Pull request submitted. It appears to have a merge conflict with blitter.h though.

Don’t worry, I’ve merged the changes. And I think I’ve fixed the issue, hopefully this should be resolved now. It’s great to work out these teething troubles, early! Thanks for your help here.

Jbl007’s success at building the current sources suggest your changes are a success, good job!

[bloodline]

Dirk Hoffmann and I have found a weird graphical glitch... My guess the Blitter is not calculating a stride properly... Does anyone here have a better idea (before I rip into my blitter code)?

Also how can I make my Agnus appear to be a Fatter Agnus?
2Meg of Chipram is reported to the system, but some software thinks my Agnus is 512K and ignores the extra memory.

-edit- Ok I think I’ve figured it out, the upper bits of vposr seems to indicate Agnus revisions.

[jbl007]

I managed to compile successfully, but it segfaults very early on.
gdb session:

(gdb) break ADF2MFM
Breakpoint 1 at 0x1fafb: file Floppy.c, line 51.
(gdb) run
Starting program: /tmp/Omega/omega kick13.rom wb.adf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
wb.adf
Breakpoint 1, ADF2MFM (fd=-1, mfm=0x5555556926a4 <df+20> "") at Floppy.c:51
51          int size =(int) lseek(fd, 0, SEEK_END);
(gdb) step
54          int sectors = size/512;
(gdb) step
57          int tracks = (sectors / 22);
(gdb) step
62          uint8_t adf[size];
(gdb) print fd
$1 = -1
(gdb) print size
$2 = -1
(gdb) print sectors
$3 = 0
(gdb) print tracks
$4 = 0
(gdb) step
67          lseek(fd, 0, SEEK_SET);
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
0x0000555555573bae in ADF2MFM (fd=-1, mfm=0x5555556926a4 <df+20> "") at Floppy.c:67
67          lseek(fd, 0, SEEK_SET);
(gdb) step
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Does ADF2MFM already get wrong fd for some reason, but why?

Edit: I found the reason: My wb.adf was read only. I made it writable and now the first call to ADF2MFM succeeds but still segfaults afterwards. Is it trying to enable DF1 to DF3? I spotted the last "enable all 4 drives" commit...

[bloodline]

Originally Posted by jbl007

I managed to compile successfully, but it segfaults very early on.
gdb session:

(gdb) break ADF2MFM
Breakpoint 1 at 0x1fafb: file Floppy.c, line 51.
(gdb) run
Starting program: /tmp/Omega/omega kick13.rom wb.adf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
wb.adf
Breakpoint 1, ADF2MFM (fd=-1, mfm=0x5555556926a4 <df+20> "") at Floppy.c:51
51          int size =(int) lseek(fd, 0, SEEK_END);
(gdb) step
54          int sectors = size/512;
(gdb) step
57          int tracks = (sectors / 22);
(gdb) step
62          uint8_t adf[size];
(gdb) print fd
$1 = -1
(gdb) print size
$2 = -1
(gdb) print sectors
$3 = 0
(gdb) print tracks
$4 = 0
(gdb) step
67          lseek(fd, 0, SEEK_SET);
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
0x0000555555573bae in ADF2MFM (fd=-1, mfm=0x5555556926a4 <df+20> "") at Floppy.c:67
67          lseek(fd, 0, SEEK_SET);
(gdb) step
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Does ADF2MFM already get wrong fd for some reason, but why?

Edit: I found the reason: My wb.adf was read only. I made it writable and now the first call to ADF2MFM succeeds but still segfaults afterwards. Is it trying to enable DF1 to DF3? I spotted the last "enable all 4 drives" commit...

Yeah, there were some bugs... It still tried to load the ADF even if it couldn't find one. I've updated the sources, please try again

-edit- Thank you for trying this, I need others to do this, or we won't find the bugs.

[jbl007]

Works now, and I must say it's quite impressive.
I loaded some programs from my old tools disk, many of them work very well f.e. DirOpus 1.5, Cygnus Ed. II, BootX, Powerpacker...

XCopy Pro has wrong palette, no mouse pointer and host cpu is at 100%

It seems that programs using overscan screen do are not displayed correctly. Is this a known problem? For example VTSchutz and Scene Generator. Screen is trashed and mouse pointer warps around (if moved to left it appears of the right)

BTW: Did you already notice: the mouse busy pointer Zzzzz is missing it's lower part of the bubble