I am close to porting AppleWin for Amiga.

[emufan]

i made some checks of data read in from within the source:

char Disk2_rom[] =
		"\xA2\x20\xA0\x00\xA2\x03\x86\x3C\x8A\x0A\x24\x3C\xF0\x10\x05\x3C"
....
;

void DiskLoadRom(LPBYTE pCxRomPeripheral, UINT uSlot)
{
	const UINT DISK2_FW_SIZE = 256;

BYTE* pData = (BYTE*) Disk2_rom;	// NB. Don't need to unlock resource


memcpy(pCxRomPeripheral + uSlot*256, pData, DISK2_FW_SIZE);

    int i;
    printf ("Disk2_rom: pdata\n");
	for( i = 0; i < DISK2_FW_SIZE; i++ ){
  	printf (" %02x", pData[i]);
    }

    printf ("\n\nDisk2_rom: pCxRomPeripheral\n");
	for( i = 0; i < DISK2_FW_SIZE; i++ ){
  	printf (" %02x", (pCxRomPeripheral  + uSlot*256)[i]);
    }
    printf ("\n\n");

	//

	RegisterIoHandler(uSlot, Disk_IORead, Disk_IOWrite, NULL, NULL, NULL, NULL);
}

result in shell output:

Disk2_rom: pdata
 a2 20 a0 00 a2 03 86 3c 8a 0a 24 3c f0 10 05 ...
...
Disk2_rom: pCxRomPeripheral
 a2 20 a0 00 a2 03 86 3c 8a 0a 24 3c f0 10 05 ...

is this a proof, the byte order thing is ok ?

#1) i did add SDL_BIG_ENDIAN to the preprocessor,
it's a condition in soundcore.cpp and stretch.cpp
Intel vs PPC, but it does not have an impact as of yet.
thats the only occurance of "endian" thing in the whole source.
^^ removed since it was already set in sdl include files.


zoned: updated AmiApple-WIP.lha

[jotd]

doesn't prove anything, you just copied an array of bytes and print them. maybe endianness isn't used at all: you can code everything endian agnostic in an emulator.

[emufan]

Originally Posted by jotd

doesn't prove anything, you just copied an array of bytes and print them. maybe endianness isn't used at all: you can code everything endian agnostic in an emulator.

this output is created in a fucntion, i've added the missing parts above, which is called elsewhere in the source.
still no proof?

Memory.cpp:     DiskLoadRom(pCxRomPeripheral, 6);   // $C600 : Disk][ f/w

zoned: AmiApple-WIP-src_AmiDevCpp.zip
maybe someone can check what is wrong?
maybe it is related to the SDLError: passed a NULL mutex.
noixemul_off.dev is recent project file

alkis, Nova?

[matthey]

Originally Posted by emufan

result in shell output:

Disk2_rom: pdata
 a2 20 a0 00 a2 03 86 3c 8a 0a 24 3c f0 10 05 ...
...
Disk2_rom: pCxRomPeripheral
 a2 20 a0 00 a2 03 86 3c 8a 0a 24 3c f0 10 05 ...

is this a proof, the byte order thing is ok ?

Your test shows that the Disk2_rom array endianess did not change by the memcpy(). It is possible for static data to be stored in little endian order but this is unlikely for the ROM of an 8 bit CPU which is likely to be accessed a byte at a time anyway (big and little endian order is the same for byte address accesses). Data read from Disk2_rom pCxRomPeripheral could be endian swapped somewhere in other code but it looks like the pointers are byte pointers which should be ok as long as there are no casts. Any endian swapping of this data should probably be removed. Look for __builtin_bswapxx() or SDL_SWAPxx() but many older programs roll their own. The main reason for accessing data in larger widths than a byte is to improve performance so it may be more likely to occur around display code for an 8 bit emulator.

[emufan]

thanks for explaining. there are no such swap functions or calls.
maybe we are digging in the wrong pit, could be something endian unrelated after all.

[NovaCoder]

If I get time I'll check the source code archive you uploaded and see if I can help...

[xboxown]

One could easily say we are reaching the end for a successful port The apple is right there at visual sight distance, we just need to be able to figure out how to stretch our arm and grab it.

[emufan]

Originally Posted by NovaCoder

If I get time I'll check the source code archive you uploaded and see if I can help...

thats cool, thanks

Originally Posted by xboxown

One could easily say we are reaching the end for a successful port The apple is right there at visual sight distance, we just need to be able to figure out how to stretch our arm and grab it.

yes, just a littlebit left. I hope we find the issue.

[xboxown]

Originally Posted by emufan

thats cool, thanks

yes, just a littlebit left. I hope we find the issue.

emufan please forgive me for asking this one request..please please please....but...when this project is finished...is it possible you can tackle kegs32 and have that port to Amiga 68k? This way we can port two of the best Apple //gs and Apple // emulator in history. I don't care for kegs32 being able to run apple // mode seeing as this little baby will do it even better . But the current kegs I have made arczi port (if he is reading this, thanks man) have issues with mouse interaction and the emulator....the mouse pointer in the emulator doesn't synch with the Amiga mouse and jumps like 10 steps to the left, right or up when I move the mouse around in my Amiga making it impossible to click or interact with the interface. This issue is also in the windows version...I was using a very buggy emulator to have it port it. But if we can port kegs32 A) we get a windows interface to add disks, remove disks, etc and B) have proper mouse interaction into the interface of kegs.

What do you think? This is just a suggestion you could easily say no and I understand 100%.

[NovaCoder]

Originally Posted by emufan

thats cool, thanks

yes, just a littlebit left. I hope we find the issue.

This code is not very well written

It will be hard to get this running on 68K as it doesn't do proper error handling and includes lots of Unix OS function calls which won't work well on Amiga 68K.

For my old Amiga ports I'd normally replace all the Unix calls with Amiga OS functions.


Looking at the nasty Timer code I think it would be better to just remove the entire Timer.cpp file from the project and replace the Timer.h with this:

#pragma once

static inline void SysClk_WaitTimer() {}
static inline bool SysClk_InitTimer() { return true; }
static inline void SysClk_UninitTimer() {}
static inline void SysClk_StartTimerUsec(DWORD dwUsecPeriod) {}
static inline void SysClk_StopTimer() {}

[Marlon_]

Originally Posted by NovaCoder

This code is not very well written

Yeah, I've stated this earlier in the thread and I'm surprised they've gotten this far even though the code is an absolute mess.

[emufan]

@xboxown: of course i would try, but depends on result of AmiApple

Originally Posted by Marlon_

Yeah, I've stated this earlier in the thread and I'm surprised they've gotten this far even though the code is an absolute mess.

there were other things judged as impossible, so why not this one too

and there is a OS4 port by drHirudo, we still wait for the source, which would make things easier.

Originally Posted by NovaCoder

Looking at the nasty Timer code I think it would be better to just remove the entire Timer.cpp file from the project and replace the Timer.h with this:

I did so, not much changed, but now, after starting the emulation (F2) it seems not to crash.
it reacts to input F3, etc, choose another disk, and u can exit the emulator with
the close button.
i've tested with ixemul v48 ( was using v63 ) does not make any difference.

since using ixemul.library, using shift-F2 - doing a full emu reset, it gives a ixemul, error,
before it loads the apple rom - something in memory.cpp

zoned: AmiApple-Wip.lha (updated)

[xboxown]

drHirudo PLEASE have mercy on us and release the source code!! Please be merciful and release the code! At least email it privately to emufan so that he can look at it and do the modification!
DRHIRUDO! PLEASE help us!!!

[emufan]

#0) btw. it does use valid dsk files only
if you choose a .bmp it says not recognized format.

#1)
i added some printf, just to see where it does idle.
it does loop after F2 , entering MODE_RUNNING

while ((g_nAppMode == MODE_RUNNING) || (g_nAppMode == MODE_STEPPING))
{
            printf("Applewin: g_nAppMode == MODE_RUNNING \n");
		if(SDL_PollEvent(&event)) {
            printf("Applewin: if(SDL_PollEvent(&event) \n");
		if(event.type == SDL_QUIT && event.key.keysym.sym != SDLK_F4) return;
		FrameDispatchMessage(&event);
		printf("Applewin: FrameDispatchMessage(&event) \n");
}

in the shell:

...
Applewin: g_nAppMode == MODE_RUNNING 
Applewin: if(SDL_PollEvent(&event) 
Applewin: FrameDispatchMessage(&event) 
Applewin: g_nAppMode == MODE_RUNNING 
Applewin: if(SDL_PollEvent(&event) 
Applewin: FrameDispatchMessage(&event) 
...

what event does it waiting for?

#2) hmm:

Applewin.cpp:   SDL_Event event;
DiskChoose.cpp: SDL_Event event;        // event
DiskFTP.cpp:            SDL_Event event;        // event
DiskFTP.cpp:    SDL_Event event;        // event
Frame.cpp:         SDL_Event event;     // event

i'll have a look into it.

#3)

DiskChoose.cpp:                         SDL_PollEvent(&event);
DiskFTP.cpp:                                    SDL_PollEvent(&event);
DiskFTP.cpp:                            SDL_PollEvent(&event);
Frame.cpp:                 SDL_PollEvent(&event);

these poll event do work, F3 for example exit the loop and you get the DiskChooser event.

i still need to check, what it actually does, entering the F2 Mode_Running.

#4) updated AmiApple-WIP.lha (alot debug shell output)

[xboxown]

emufan I salute you! You are the only one who is actually going out of your way and making this work when all odds are against you! Thank you! Thank you for everything! I swear ones you get it working I want to donate to you for your time and effort! You deserve all the credit for your effort, thank you!

Also thank you for not quitting and giving up when the odds are pushing you to quit and give up.

[emufan]

there is good help from the ppl arround, and a bit of motivation is good too

i'm stuck now with not knowing what it does when entering the emulation mode (MODE_RUNNING).
I cannot find a link to starting apple code, or the emulated apple cpu.

it goes into a main loop checking keyinputs, but where is the start of the apple stuff ?!
and i'm not able to find the issue with the weird chars vs black screen when using F2, *sigh*

#1) added some more printf. something emulation related is working already:
CpuReset(), CpuIrqReset(), CpuNmireset(), CpuInitialize()

#2) main loop in Applewin.cpp: void ContinueExecution()

#3) thats a bit strange - maybe nothing:

Memory.cpp:     const UINT Apple2RomSize = 12*1024;
Memory.cpp:     const UINT Apple2eRomSize = Apple2RomSize+CxRomSize;

those downloaded from website were 20kb or 32kb size, so 12*1024 doesnt fit that size. *hmmm*

[xboxown]

That is good right, right??!

[emufan]

Originally Posted by xboxown

That is good right, right??!

at least something to look at. we still get that weird chars when starting the emulation,
maybe it is related to the ROMs provided within the src code.

zone updated: AmiApple-WIP.lha

[xboxown]

How hard is it to allow the program to add ROM from the apple2e.rom file in the hard drive?

[emufan]

Originally Posted by xboxown

How hard is it to allow the program to add ROM from the apple2e.rom file in the hard drive?

there is still some unused code left in the source, loading ROMs from files.
dunno if it's worth enabling it.

#1) wincompat.h does those type definitions: are those defintions valid for 68k Amiga OS?
attached wincompat.h.