@Chris

Quote:

Try putting the filename as the first parameter to NewObject(). At least this is what the DTST_MEMORY example in the OS3.9 NDK does, I also remember reading something to the same effect somewhere else, not sure where (autodocs?).

Quote:

This I would say isn't possible with current sound.datatype unfortunately.

I think if the sound.datatype ever were to be updated something like the PDTM_READ/WRITEPIXELARRAY methods of v45+ picture.datatype would be useful, called SDTM_READ/WRITESAMPLEARRAY or similar, that would do sample conversion when necessary.

@Mitch

When it's a docky?

@Rogue

If you don't mind me asking, what's the status on the Gorky 17 port? Will it be finished and released only once OS4 is done or?

Would be nice to have some more games taking advantage of the 3D capabilities of the A1. I'm not much into Quake but this Gorky 17 thing looks interesting.

My ?A1-C definitely. Fast CPU, truecolour graphics and a great OS to go with it. Don't think I ever want to go back to using OS3.x again...

@Chris

To convert from 8-bit to 16-bit you can simply:

uint8 *src;
uint16 *dst;
*dst = (*src << 8)

@abalaban

Thanks for testing this and reporting back. Since it works I think I can remove the untested alpha warning and do an upload to OS4Depot too.

I've made a simple program "td64patch" that patches the BeginIO method in a .device with a routine that maps the TD64 commands (read, write, seek & format) to their NSD equivalents. If anyone wants to try they can download it from my website:
http://a500.org/index.php?s=downloads&f=td64patch.lha

I make no guarantees as to whether it will work or not. At least it didn't crash for me but I haven't had time to test with any TD64 filesystems yet either...

Assuming the commands are compatible it should work though...

Command line syntax is:
Run <>NIL: td64patch devicename [unit]

devicename = a1ide.device or other device
[unit] = optional, any unit number that can be opened (default = 0)

F.e. Run <>NIL: td64patch a1ide.device

To disable patch send a break signal to the td64patch command (C:Status can be used to obtain the process number to use with C:Break).

@LiveForIt

IIRC the NSD 64-bit commands work the same way (use io_Actual for the high 32-bits of io_Offset).

If that's the case then it should be enough to map the commands to their NSD equivalents?

#define NSCMD_TD_READ64 0xC000
#define NSCMD_TD_WRITE64 0xC001
#define NSCMD_TD_SEEK64 0xC002
#define NSCMD_TD_FORMAT64 0xC003

TD64 is an unofficial extension that adds 64-bit support to the trackdisk-like device commandset. It is not the only one. NSD (New Style Devices), which was introduced in OS3.5/3.9, has its own 64-bit extension and this is the one that is used/supported by OS4.

Quote:

I very much doubt that. If a partition is less than 4GB and all of it is in the lower 4GB of the disk then most filesystems will use the normal CMD_READ/CMD_WRITE instead of the TD64/NSD64 commands as they are not necessary and also slower. Probably this is what happened in this case.

I agree. List of archive contents like on Aminet would be nice to have on OS4Depot too.

@Samwel

If you add new screenmodes to the icon before any existing ones, the screenmode IDs of these existing modes will change. Meaning if you added a new screenmode before your WB screenmode, then the WB will use the previous mode in the list on reboot. If you don't want this to happen simply add all new screenmodes to the end of the list.

Done.

I'll agree with Raziel and say "Battle for Wesnoth". Since that's about the only game I play regularly on OS4. It's a great game especially considering it was started as an opensource project and is still being improved on.

I also like Ur-Quan Masters but I haven't played it for some time since it's quite hard and I'm so bad at the space fights, not to mention lack of time.

I mostly compile OS4 only and sometimes, when it makes sence and it's not too much extra work, I also compile for m68k. More often than not I test the m68k compiles under OS4's JIT emulation since I'm too lazy to start up UAE just for this.

I don't compile for other platforms since they are not available to me so I have no way of testing if it works. At least someone would have to request a port and volunteer to do any necessary testing first before I will bother.

Anyway, I include source codes with most of my stuff, and it's OK by me if anyone wants to port any of the programs to some other OS just as long as they give proper credit and do not try to claim the whole work as their "own".

@Shadow

Have you tried disabling interrupt in the tooltypes on the monitor driver in DEVS:Monitors? XMoto for OS4 has similar rendering problems to those in the video that are fixed by disabling interrupts. Just to see if it is the same problem.

Just registered today. Found this site by following a link from amigaworld.net . Looks like an OK site so far .