[quote name=Jeff1138 post=12647]@Jeff1138 - Hi, Welcome, it might be worthwhile staying with virtual or hosted. For native hardware choose an intel 3rd or maybe 4th gen with a realtek ethernet. FYI find AMD has too many quirks at the moment to be reliable. USB3 is getting better but not ready just yet.[/quote] Yeah I understand serious coding is better done on Host with AROS Bootstrap/Virtualbox. However, I like that feeling of hammering code and playing around on the real thing, that's why I write a lot of my code in Devpac on the Amiga1200 without helpful coloring and a native git client. Im complicating things but oh the joy :P And.. my Virtualbox is so small on the screen, old mans eyes .. So no AMD? I had a discussion with Claude analysing the HCL and he came up with ASRock B550M-HDV, AMD Ryzen 5 5500 and DDR4 16GB Kit (2 x 8GB) 3200MHz (PC4-25600). I already have an old box/psu, 2TB SATA and a GTX1050 and a GTX1060 card so I thought that woould do the trick, but perhaps not then..

Perfect, I’m glad my 64-bit AROS One is running well on VirtualBox. As soon as it’s available, I’ll test your programme and I hope to try future versions too.

Hi, Welcome, it might be worthwhile staying with virtual or hosted. For native hardware choose an intel 3rd or maybe 4th gen with a realtek ethernet. FYI find AMD has too many quirks at the moment to be reliable. USB3 is getting better but not ready just yet.

welcome and thanks for your support;)

So, I managed to get AROSOne up & running in VirtualBox yesterday with some help from this forum. I immediately pulled down the nightly and started coding a FTPclient with assistance from good old Claude.ai. Worked as expected, but of course I shouldn't build against the nightly, so had to run over it all again when I found Deadwoods github with the proper instructions. I always tend to complicate things, this old man never learn. Anyway, it might be a fully working and good looking FTP program one day and if not, AROS is still fun. Next step is to scan the HCL list and build a proper box of it's own, and then code some more apps. A good weekend this, cheers

In the process of compiling and testing the most recent PCX Datatype I noticed that it currently only supports loading & saving 8bit & 24bit images. Although it should support 1,2,4,8 & 24bit PCX images. I noticed that it's very similar in some ways to the original Windows BMP file format which supports 1,2,4,8,16 & 24bit BMP images. I may be able to re-use the bit depth code for 1,2 & 4bit PCX images but I'm not sure if they will be planar images with rle compression? While looking at BMP datatype I noticed that it supports loading 2bit images but that bit depth is missing from the save function. I'll need to check the code repository. If so I can add that to the BMP datatype. Targa datatype will be finished soon. JNG & MNG Datatypes depend on LibMNG. MP3 Datatype depends on LibMpega. I also thought about writing an OGG (Ogg Vorbis?) and maybe a MOD datatype. FONT datatype for bitmapped fonts? Then there are the DOC & RTF datatypes that maybe just allow displaying just plain text. Not sure about those yet. More is better!!

Hi, could someone elaborate this issue for me? (is there libraries that i should check for version mismatch error?) I am out of idea, mine rom version has a mouse pointer different than other places (like winuae). Winaue pointer is a triangle, mine is an arrow. anyway, if i dont have any new insight about this i will not be able to go foward. I use aros.rom and it boots lot of non-os disks, but if i try aros ou workbench, no success, aros gave me a gray screen with the mouse pointer working, workbench the same, but blue screen. regards,

New & Updated Datatypes Status: Edits & code cleanup for Targa Datatype is nearly completed. When completely finished I will post the new datatype & the source code. PCX Datatype is not as bad as I remember it. I started collecting my current sources so I can start testing. Also started three new Datatypes: JNG Datatype, MNG Datatype & MP3 Datatype. The last one uses Lib Mpega. We will see how it goes!

[quote name=Templario post=12597]@Templario - Perhaps a little solution to this problem is that the Hollywood programs and games have the plugins embeded the plugins inside of executables.[/quote] Absolutely, but if you want to cut down the size of the executable or app, being able to use dynamically linked pugins is very handy. Chers, Nigel.

Perhaps a little solution to this problem is that the Hollywood programs and games have the plugins embeded the plugins inside of executables.

Had a reply on the Hollywood forums. Neither issue is a bug, rather a change to how how Hollywood works on Amigaoid systems. For the GUI not working, it seems the Hollywood compiler, key and Hollywood.sys are no longer stored in Hollywood:system but rather in Hollywood: directly. Then the GUI works fine. For the libs:Hollywood issue, it seems some new pre-processor @OPTIONS need to hbe set. From the manual: [quote]would be a waste of CPU time and memory (especially on low-end systems like AmigaOS 3) to always load all of the installed plugins on startup so only the plugins that the scripts explicitly requests by using the @REQUIRE preprocessor command will be loaded now. If you want the old behaviour back, you can set the new AutoLoadPlugins tag in the @OPTIONS preprocessor command to True. In that case, Hollywood will behave as before and load all installed plugins on startup every time. Note that this change also affects executables compiled by Hollywood: Executables compiled by Hollywood will no longer automatically load all Hollywood plugins that are stored in the same directory as the executable either now. Only plugins that the script explicitly requests by using the @REQUIRE preprocessor command will be loaded. This behaviour is much better than the old one because previously you could manipulate how a Hollywood program behaved just by dropping some new Hollywood plugins in the same directory as the executable, which isn't a good default behaviour. Once again, if you want the old behaviour back, just set the new AutoLoadPlugins tag in the @OPTIONS preprocessor command and Hollywood executables will automatically load all plugins that are in the same directory as the executable, just like it was in previous Hollywood versions. Amiga users do note that if you also want to have plugins stored in LIBS:Hollywood loaded, you need to set the GlobalPlugins tag in @OPTIONS to True as well, but only when compiling executables. When running scripts Hollywood will automatically scan LIBS:Hollywood too if AutoLoadPlugins is set to True or you use @REQUIRE or LoadPlugin() to load a plugin.[/quote] So Hollywood authors writing for AROS (or any other Amigaoid system) will need to set these when using Hollywood 11. Cheers, Nigel.

Here is the updated version of MultiView for testing Targa Datatype and some Targa test images. Pay no attention to the MultiView version. It was just a quick update so I didn't change the version. To test the datatype open any of the sample Targa images in MultiView. Then choose "Project->Save As" to save a "new copy" using the datatype save function. This process will test the load and save functions. Although all the images will be rle compressed the original file size and new file size may not match. Mostly because my Datatype doesn't yet write the Targa 2.0 Footer at the end.

AMIGASYSTEM When I finalize the source code for Targa Datatype in the next two weeks then there will be a 64bit version after that. This binary is the one I'm using for testing. It's functional. I'm planning to make a few code changes that won't affect the performance of the datatype - just cosmetic changes. In order to test the new Targa Datatype you will need the updated MultiView and some test pics. I'll upload them here later today.

Thank you, there’ll be a 64-bit version too!

Here is the latest binary for ABIv0. It uses rle compression for 8,16,24 & 32 bit Targa images.

[quote name=CoolCat5000 post=12510]@CoolCat5000 - Hi @deadwood , i updated the readme, now it should be clear what it is, [/quote] Yes, thanks. It's now clear :)

"I dont know how or when i can got this rolling again, but maybe it can spark interesset there (like omega emulator did with me)" I also thought about omega once i saw what bellatrix emulator was doing... it is quite interesting

Hi @deadwood , i updated the readme, now it should be clear what it is, [quote]Using release images The released .img files are Raspberry Pi kernel images, not complete SD card images. Use one of them on an Emu68-style Raspberry Pi boot FAT32 partition, together with the usual Pi firmware files and a config.txt. Example config.txt: kernel=bellatrix_musashi.img initramfs kick.rom arm_64bit=1 enable_uart=1 Copy your Kickstart ROM to the same boot partition and make the initramfs line point to that file. For example, with initramfs kick.rom, the file must be named kick.rom on the SD boot partition. Use a legally obtained Kickstart ROM. The Musashi images are currently the recommended hardware builds. The Emu68 JIT images are published for testing the JIT integration path.[/quote] There was some regressions, i will hunt it sometime (the diagrom scroller test was ok before), but at least a first release. (if someone is curious enough) https://github.com/JJDSNT/bellatrix/releases i would love to keep it rolling, but i have some other (personal) stuffs that i should take care before. Regards, Ps: its far from usable, its better understood as a proof of concept than as a done software

[quote name=AMIGASYSTEM post=12236]@AMIGASYSTEM - With the new version of the Hollywood language released a while ago, there have also been changes to the binary files, where, in my opinion, something doesn’t quite add up. In practice, the new development version of Hollywood significantly streamlines the binaries by removing libraries that are now required externally. Well, or rather badly: previously, some applications ‘that didn’t include the library internally’ would look for it in the programme folder or in the system’s Libs/Hollywood folder. Now, however, all required libraries, “and there are quite a few”, must be located in the programme folder. In practice, this means the system will end up with dozens and dozens of duplicate libraries. If we then add that some older Hollywood applications refuse to use new libraries and instead require a specific older version, the confusion only increases. The Amiga philosophy dictates that all libraries, as is the case with other operating systems, must be located in a single system folder: ‘Libs’ for AROS and Amiga. This ensures there is only one copy, making updates straightforward; otherwise, they would all need to be updated as applications are updated.[/quote] I finally got round to downloading and installing Hollywood 11 yesterday and absolutely agree with the issues you've identified above. I've checked the documentation and it should still be possible to have the plugins in libs:hollywood/. Also, the Hollywood display/compiler GUI for AROS does not work (this is on 32 bit) . I've reported both issues as bugs over on the Hollywood forum. Cheers, Nigel.

Working on the Targa Datatype the last couple years has been interesting. Yes, I said "years" because I'm not consistent with the time I spend with AROS. Thankfully I have some good project notes. For Targa Datatype it was very much an exercise in learning about RLE (run length encoding) which is also needed for the PCX Datatype which I have also been working on over the past few years. The ILBM datatype also uses RLE but when I updated it previously I didn't include that. This time around I'll implement ILBM RLE. RLE for Targa is optional but RLE for PCX is mandatory. PCX RLE is per byte, but Targa RLE is per pixel which is more difficult to implement. I'll finish Targa Datatype in a couple weeks though a binary will be available before that. Completion of PCX Datatype will be after that. It's working now but the source code is really messy. It needs to be cleaned up and streamlined. I'll release a binary in a few days. I still have to add a few things to the source code but it won't affect the overall functionality of TGA datatype.