---

New build v0.68

https://axrt.org/development/EmuV0/EmuV0-0.68.x86_64-aros-v11.zip

This is the last build before v1.0 with major functionality changes. For the next few days I want to focus on testing and fixing small remaining bugs where possible, not adding support for more applications. Please still report errors, crashes and "Unhandled" alerts. Where possible, they might still get solved

Changes:
- added support for rendering button and text gadtools gadgets
- reworked Intuition message mechanism to avoid memory leaks
- fixed crash when holding LMB over cycle gadget for too long

---

Just in case scrollbars are on the list of last bugs to be fixed: with the scrollgroup scrollbars in SimpleWhiteboard, I had these set to be in the window borders; I just changed them to be normal and they do appear but like the one in the file requester do not respond to the mouse (however, again like the requester their buttons do).

Just to say thank you again for all the efffort in getting these programs working, I appreciate it must have been an immense undertaking.

Cheers,
Nigel.

---

@ntromans

Thanks, it indeed was one of the most complex things I worked so far with regards to AROS. On the same level as Odyssey or 3D drivers. I also see the potential to use the same technology to run AmigaOS m68k programs under AROS with the same level of integration (but that is not something for 2026).

With regards to scrollbars - they are too complext to handle at this point. They will have to wait for the next time I work on EmuV0.

---

@ntromans

Good news for Hollywood. Andreas kindly provided me with a free license for Hollywood 11 and I was able to fix the memory trashing issue in emulator:

https://axrt.org/development/EmuV0/EmuV0-0.70.x86_64-aros-v11.zip

I tested only Hollywood and Miniwood with HelloWorld.hws with -exetype aros, so please do a deeper testing so we can still solve any issues that are out there.

---

New build v0.72

https://axrt.org/development/EmuV0/EmuV0-0.72.x86_64-aros-v11.zip

Changes:
- ZuPaPlayer - starts, loads and plays mod now. Crashes at stop of music.
- HFinder - fixed crash using window scroll bar
- SilkRAW - starts UI now but complains about missing command line file
- ft2clone - now possible rename files - keyboard input works

---

[quote name=deadwood post=10777]@deadwood - @ntromans

Thanks, it indeed was one of the most complex things I worked so far with regards to AROS. On the same level as Odyssey or 3D drivers. I also see the potential to use the same technology to run AmigaOS m68k programs under AROS with the same level of integration (but that is not something for 2026).

With regards to scrollbars - they are too complext to handle at this point. They will have to wait for the next time I work on EmuV0.[/quote]

It certainly has been a Hurculean effort on your part, but it really has moved 64 bit from 'test system' to (in many contexts) 'daily driver' and being able to do the same trick with 68k sounds very exciting

Cheers,
Nigel.

P.S. I looked back at the Hollywood documentation for a virtual group; it detailed the 'top' and 'left' parmeters but called then 'mostly useless'. Actually, not so; setting these moved the drawing canvas witin the window, so I should be to implement a canvas dragging tool as an alternative to scrollbars.

---

[quote name=deadwood post=10783]@deadwood - @ntromans

Good news for Hollywood. Andreas kindly provided me with a free license for Hollywood 11 and I was able to fix the memory trashing issue in emulator:

https://axrt.org/development/EmuV0/EmuV0-0.70.x86_64-aros-v11.zip

I tested only Hollywood and Miniwood with HelloWorld.hws with -exetype aros, so please do a deeper testing so we can still solve any issues that are out there.[/quote]

Great news! I'll be giving that a try asap (as well as finally ordering a copy of Hollywood 11).

Cheers,
Nigel.

Edit: Tried with Hollywood X, so may be different with Hollywood 11. The CLI version worked to run the SimpleWhiteboard sources fine (although I did need to remove the glgalore plugin as it crashed the compiler). However, trying to run the BackupCopy sources gave the attached alert during compilation. The odd thing is I'm not opening a message port in the program, and as previously mentioned when compiled on 32 bit the executable does run via emuv0. Strange...

Edit 2: Tried to run the gui and got 'jpeg datatype not found'. The jpeg datatype is in sys:tools/emuv0/classes/datatypes, and I tried copying the one from my 32 bit install but had same result. When I tried running Hollywood X in Amiberry I had the same problem; installing the WarpJPG from Aminet solved the issue, but that isn't available with AROS, and of course the normal datatype does work on 32 bit.

---

Ok, I only have Hollywood 11 to test, so please keep that in mind.

Please provide me the source codes of BackupCopy and the exact command line you used when compiling through EmuV0.

---

.

---

@ntromans

I tried compiling all the examples in Examples/Hollywood directory with version 0.72 and Hollywood/Miniwood 11 and all of them produced working binaries without any "Unhandled" alert. Attached is a script I used.

---

GUI also worked, but compiling through it most likely won't work. For EmuV0 v1.0 the focus is only on the Hollywood compiler.

---

Here is a release-candidate of EmuV0:

https://axrt.org/development/EmuV0/EmuV0-1.0-RC1.x86_64-aros-v11.zip

The changes are minimal compared to v0.72. Unless some major issues are found, this build will become the official release on Friday.

---

[quote name=deadwood post=10798]@deadwood - Ok, I only have Hollywood 11 to test, so please keep that in mind.

Please provide me the source codes of BackupCopy and the exact command line you used when compiling through EmuV0.[/quote]

Please see attached. The alert occurs if I try to run the script from Hollywood or, after comiling it, try to run it as an excutable:

emuv0-pc hollywood:system/hollywood backupcopy_b.hws

emuv0-pc hollywood:system/hollywood backupcopy_b.hws -compile "ram:backupcopy" -exetype "aros"

I've tried with both the -nocommodity and -console arguments, no change.

Cheers,
Nigel.

---

[quote name=deadwood post=10798]@deadwood - Ok, I only have Hollywood 11 to test, so please keep that in mind.

Please provide me the source codes of BackupCopy and the exact command line you used when compiling through EmuV0.[/quote][quote name=deadwood post=10798]@deadwood - Ok, I only have Hollywood 11 to test, so please keep that in mind.

Please provide me the source codes of BackupCopy and the exact command line you used when compiling through EmuV0.[/quote]

Please see attached. The alert occurs if I try to run the script from Hollywood or, after comiling it, try to run it as an excutable:

emuv0-pc hollywood:system/hollywood backupcopy_b.hws

emuv0-pc hollywood:system/hollywood backupcopy_b.hws -compile "ram:backupcopy" -exetype "aros"

I've tried with both the -nocommodity and -console arguments, no change.

Cheers,
Nigel.

Edit: Found the issue - it's the hidedisplay() function (line 498); if that's removed the alert dissapears.

P.S. just to mention I'm still getting a input device crash on selecting 'cancel' in a file or path requester.

---

Ok, so just to let me understand:

1) the "MsgPort" alert was not in compiler itself, you were able to compile the backupcopy.hws and the alert was shown when running backupcopy, correct?
2) to resolve the alert you needed to remove the hidedisplay(), which I think we already discussed previosly as it was triggering AppIcon. The difference was that back then emulator was crashing and now it is showing an Alert in the same case
3) the input.device crash when clicking Cancel - never had it be honest. Is it happening for you on all requesters or only requester in backupcopy?

---

[quote name=deadwood post=10809]@deadwood - Ok, so just to let me understand:

1) the "MsgPort" alert was not in compiler itself, you were able to compile the backupcopy.hws and the alert was shown when running backupcopy, correct?
2) to resolve the alert you needed to remove the hidedisplay(), which I think we already discussed previosly as it was triggering AppIcon. The difference was that back then emulator was crashing and now it is showing an Alert in the same case
3) the input.device crash when clicking Cancel - never had it be honest. Is it happening for you on all requesters or only requester in backupcopy?[/quote]

(1) Yes, it is the execution of the program rather than the compiler.

(2) Darn it, yes, I'd changed that previously for closedisplay() which works. I've been trying to synchronise my files between my 32 bit machine and the 64 bit and i tlooks like I ended up with older version by mistake. Embarassingly I'd forgotten it was hidedisplay rather than closedisplay that caused the probelm. Really sorry. One thing I have found is that if you put the hide display instruction in the pre-processor @DISPLAY directive it does work, which explains why it's not been seen elsewhere are the latter method will be the usual way to do it.

(3) Just tried this again and no more crash for either a file or path requester. I did get the crash earlier on this evening; I have just updated to the release candidate so did that fix it? Or maybe other testing has left me with an unstable system. Anyway, all seems well now.

Cheers,
Nigel.

---

Great to hear things work

---

Hi All,

EmuV0 v1.0 is now available on the archives. Thanks to everytone who tested all the BETA versions, especially to @AMIGASYSTEM to continous retesting of software with almost each version!

---

Amazing work! Have you written anywhere about how it works?

---

Thanks Neil.

There is some skeleton documentation here: https://github.co...CIFICATION