@Reynolds

No, this won’t work, you need prepare emu or simulate patch, to move AmigaOS3.x out of the way. This patched won’t work on AmigaOS4.x

IFusion never supported real cdroms drives, it only worked with raw cd images. Perhaps flat.device can work, but I never tried.

@Rob

Not sure it has better specifications Sam460 has only DDR2 memory, it also has a cache coherence problem, this causes a performance problem, something A1222 does not have.

the Sam460 issue is perhaps not as critical, but A1222 issue can be overcome, I find hard to say what system is better or worse.

My biggest problem with A1222, is not the hardware, in the sense its not faulty, its different.
the hardware specifications is not that bad, if you do not consider compatibility.

The difference is the problem, developers must spend time making special version of their software for it, wasting time, they can be using on other things.
And I’m sure users of system will find it a bit annoying, seeing one program running really well, while another being really slow.

Sam460 problem will never improve, you never get DDR3 in software update, or the cache coherence problem fixed, but the A1222 problems will grandly improve as software is released.

@mdcatdad

You can use MacOnLinux, not sure how well it runs, we do not have anything similar for AmigaOS4.
Basilisk II and SheepShaver is technically the same source code however, SheepShaver did run on MSDOS, can be run in DOSBOX perhaps, but I guess it will defeat the point.
On AmigaOS4, you pretty much stuck on 680x0 MacOS7.6.1 or MacOS8.x. as far as I know MacOSX requires a more advanced emulator then MacOS9. MacOS9 can perhaps be made to run, but you need a simple JIT compiler, something to virtualize the address space, so that does conflict with host OS. Basically, it only needs to emulate the reads and writes, everything else can be passed on unchanged.

And believe you need to hack branches and return from jumps. To jump into the correct JIT cache block. Illegal opcode can be used, not sure if needed, changing opcode somewhat easier, as does not change codes relative position, however. All that is nice but will there is register conflict with host OS that’s the next question, so basically it can be done, but it’s not without challenges.

If there will be register conflicts, then there will be more code changes needed, to the JIT cache.

Difficulty somewhere between medium to extremely difficult, time consuming, perhaps not worth it, high level of uncertainty.

If someone did it however, then the same code, can perhaps also be used in EUAE, to improve support for Biazzard PPC / CyberStorm PPC. GameCube etc.

The “dolphin” code does have PowerPC interpreter, advantage of using a interpreter, is it won’t conflict with the host OS, it can be a short cut to getting MacOS9 running, disadvantage it will run lot slower, can’t take advantage of native opcodes.

https://github.com/dolphin-emu/dolphin ... /Core/PowerPC/Interpreter

@mdcatdad

I don’t see why it can’t support MIDI, can’t it be connected using USB, perhaps rs232,
if rs232 you can use a adapter.

(you can't buy anthing that needs a windows driver)

@elfpipe

I belive sound blaster is known for hogging interrupts.

@Hans

That should be normal behavior, host does not know what the client OS is doing.

@kikems

maybe 16 or 32, depends on the program, and what you’re doing.

@kikems

Not sure how mixing is done, but its software mixing, so if you increase channels, you also increase cpu usage. It can possibly also degreed sound quality.

I believe this why its configurable.

Typically, it’s something like:

amplitude = (wave1 + wave2) /2
so if it’s 128 channels is (wave1 + …. + wave128) / 128.

let’s say that wave2 to 128 has no sound, this means that
amplitude = wave1 / 128

however there are smart mixing methods, weighted waves, this could reduce loss.
if it’s not averaged out at all you will to easily get clipping, so that’s not good.

I believe the channels are, actually stereo channels,
that means 128 channels is actually 256 channels left and right.

@Maijestro

Quote:

This why it’s important to report actual steps, needed to cause the crash or a bug. Just because it does not crash anymore does not mean there is no problem.

@Maijestro

a forum is not a bug tracker, not sure who is responsible for the driver, ACube-Systems, AEON or Hyperion. but I guess etch have their own bug tracker.

@Maijestro

These two offsets are the same.

native kernel module kernel+0x0006132c
native kernel module kernel+0x000613a4

So it’s related to the first crash, but in case 2, you do not have a NULL pointer,
but it’s a bad pointer (outside of allocated memory, or memory no longer allocated).

the only way for exec routine to call an external routine, is for it to be a callback hook or an interrupt call.

Some of kind of async problem perhaps, something not mutex protected, used before its ready. Or it can be memory corruption.

@Maijestro

"but has the problem that this driver crashes from time to time when booting up and in the final phase of loading AmigaOs4.1."

maybe none initalized variable.
the crash is a NULL pointer something not set.
Perhaps assume success, not checking results, before use, or bad order.

@Maijestro

"successful"???

it's broken!!

@Hans

The only thing you need is a QR codes in AmiStore.no so you pay using mobile.

@Maijestro

Configure is Lnux sh script,
AmigaOS is barely an existing OS.
you might need to generate makefiles for linux
target or posix and modify the makefile and makefile.in etc script as needed.

@joerg

Pritty sure Hans added GART support, but I bet its only for PCIe not PCI.

Random google seartch.

http://www.amiga-news.de/en/news/AN-2024-04-00014-EN.html

@hotrod

EUAE/WHDLOAD is not the correct way run this games, sure X5000 is pretty fast, I really like to see more work on making Alien Bread 3D more system-friendly, its already halfway there.

@dfstudios

I also had issues with AHI prefs from AEON, I’m also using the original that works.

@Maijestro

Ram Disk should be using a new feature called Memory Objects, this are in high memory, Physical memory above 2Gbytes, this will happen on hybrid 32bit/64bit CPU’s.
As I understand if you have two dims they need to be of the same type.

@smarkusg

I translated that from Polish to English, and I can see there is confusion about DSI.

DSI is not a question of runtime or Application,

Runtime is when program, application, game or OS is being used.
Compile time, is when developer makes the game. Uses GCC and produce the application.

DSI can occur during compile time or under runtime.
(sense the development tools are in runtime)

DSI is short for Data Storage Interrupt. And it happens because the OS supports memory protection, when programs write outside allocated memory, or into page null, the running tool, game, program, application, driver or OS will be halted at bug in the software.

Gram Repair provided as detailed information about crash as it can get, and you send that developer, who wrote the software.

There are also other confusions I see all the time on forum, I keep seeing: people with no knowledge of this, are saying.

“AmigaOS does not have memory protection because X program crashes, and bring down the OS“

As I wrote above that is incorrect.
The reason why a crash can bring down AmigaOS, is because the stack is not isolated per Process/Task, like it’s on UNIX. On UNIX the stack is virtual, always at the same memory address, no matter if the stack content is different on a different process, stack is not shared. On AmigaOS the stack is in shared memory, and IPC is shared and lots of other tables, this means that they can easily be corrupted. the shall stack and process stack is one and the same, it is cleared, however, when running a different command. (At least you can’t snoop it from the same shell.)

On AmigaOS4.1
“The Stack” is always shared memory.
“the heap” is shred or private memory (can be virtual)