Who's Online |
51 user(s) are online ( 37 user(s) are browsing Forums)
Members: 1
Guests: 50
Maijestro,
more...
|
|
Headlines |
-
gifanimdt.lha - datatype/anim
Sep 22, 2023
-
giflib-extras.lha - development/library/graphics
Sep 22, 2023
-
dtconvert.lha - utility/filetool
Sep 22, 2023
-
libx264.lha - development/library/misc
Sep 20, 2023
-
amissl-sdk.lha - development/misc
Sep 20, 2023
-
mce.lha - game/utility
Sep 20, 2023
-
amissl.lha - library/misc
Sep 20, 2023
-
mediathek.lha - network/misc
Sep 19, 2023
-
libwebp.lha - development/library/graphics
Sep 17, 2023
-
reminiscence.lha - game/adventure
Sep 17, 2023
|
|
|
|
Re: Bug RNOXfer
|
|
Just popping in 
|
Maybe this works better, or at least more consistent now. I think there was some bug in Hollywood and plugin locations that could affect to this, which has been fixed.
I have also changed charset handling for the new version now. Earlier versions didn't support UTF-8 in filenames, but handled non-English characters in ISO/Amiga charsets, which basically is against FTP specifications, but old Amiga FTP clients did that too and some servers didn't care. I've now made the program to work according the specs and non-English characters are allowed only in UTF-8 if a server supports it.
Here's a change log for the new version I just released:
Version 1.4: - Added editing fields in the server list window - Added the comment column on the server list - Added the default local path setting - Added the private keyfile setting for SFTP connections - Added a check for server list changes at exit - Added UTF-8 support to be RFC 2640 compliant - Massive speedup in directory handling - More verbose file size comparison when a file exists - Added an option to save selected files/dirs as a text file - Fixed advanced.conf handling - Fixed issues with the settings file format - Adjusted window sleep modes - Disconnects from the previous server when double-clicking a new server from the server list - Uses hURL 2.0 (requires AmiSSL 5 on AmigaOS)
|
|
|
|
Re: MorphOS 3.18 is out
|
|
Just popping in 
|
Hmm.. as the thread is here, here's something I've created recently about the new MorphOS 3.18 release: A video about the really nice integration of Samba (Smb2FS) in Ambient, this is how it should be made: YouTube videoAnd info/screenshots of the new programs: Hex, ArchiveIt, Thermals, and Smb2FS
|
|
|
|
Re: Dynamite- bomberman clone
|
Posted on: 2022/8/18 20:22
#3
|
Just popping in 
|
@VooDooQuote: VooDoo wrote:I do not know how many of you played this game but I know that I spent a lot of hours, nights on it :) I did play it a LOT.. many nights/weeks/months lost back in the day :) It was when there wasn't a public release, but in beta stage... I think the public version got a bit too bloated and started to have more lag etc and I lost the best interest then. Quote: Maybe is time to arrange an date to play some death matches :) what you say? I guess it would be fun to try after a very long time, and setting a date/time would be the best shot nowadays.
|
|
|
|
Re: HTML editor with Syntax Highlightning
|
Posted on: 2022/8/1 15:28
#4
|
Just popping in 
|
Cubic IDE is pretty sweet for HTML too.
|
|
|
|
Re: Dump drawer contents to text file with date file size and version number?
|
Posted on: 2022/7/22 5:26
#5
|
Just popping in 
|
I've been using Magellan2 since 1998, so I don't remember if DOpus4 had configurable columns (or even per dir ones). And if the original doesn't, I also don't know if this feature has been added to newer open source ones... sorry.
|
|
|
|
Re: Dump drawer contents to text file with date file size and version number?
|
Posted on: 2022/7/21 16:15
#6
|
Just popping in 
|
I just have the Version column enabled for Libs:, C:, and such directories in DOpus... and then you can print the directory to a file with it too :)
|
|
|
|
Re: Pixy new pixel editor for amigaos4
|
Posted on: 2022/7/21 6:29
#7
|
Just popping in 
|
@tekmageQuote: tekmage wrote:@jPV
The fun part about this situation is it only happens on X5000s. Other OS4 platforms don't have this crash! I bet the actual bug happens on all setups, but it might be just pure luck if it becomes a visible/fatal issue. For example, if it trashes memory, it trashes it every time, but how it shows up depends on what contents it trashed. Maybe X5000 just happens to have some crucial data (drivers or so) on the affected area more likely than some other setup. The bug I reported is reproducible on both WinUAE and X5000, but at least on WinUAE it's random and you'll have to try to trigger it a bit more before it actually crashes.
|
|
|
|
Re: Pixy new pixel editor for amigaos4
|
Posted on: 2022/7/20 16:08
#8
|
Just popping in 
|
Quote: tekmage wrote:@Raziel
I am not 100% sure but having looked at this a bit I think the Hollywood directory under storage is dynamically created during the runtime of the Hollywood App. Here are my current sys:storage dir: Hollywood used to create these temp files if a 3rd party application was compiled to link plugins in the executable (this is why I didn't link plugins in my programs but included them in the progdir). Hollywood cleared these temp files when you quitted the program, but files were left there if you rebooted or crashed without quitting the program. This has improved in Hollywood 9.0 and you can avoid temp files creation even when linking plugins. This is the changelog entry: Quote: - New [OS3/OS4/MorphOS]: Linked plugins will now be loaded directly from the executable or applet without using temporary files; note that this only works for uncompressed executables or applets; if you activate compression, temporary files will be created Quote: eliyahu wrote:@sinisrus
Just picked up the latest alpha on OS4Depot and still getting same crash on my X5000 that many have also experienced This looks a bit like the issue I have with mui.CreateObject with Hollywood on OS4, I don't know if the same function is used in Pixy. Anyway if you do dynamic runtime object creation on OS4, it seems to be a problem. This doesn't happen on any other platforms, but only on OS4.. so probably codesets.library or OS4's MUI implementation issue. Here's more information about my findings: link
|
|
|
|
Re: Morphos 3.15 stopped booting on my AmigaOne X5000
|
Posted on: 2022/7/4 8:44
#9
|
Just popping in 
|
@SkatemanQuote: Skateman wrote: Since AmigaOS and MorphOS by default both use a DH0, DH1 SYS: WORK: etc.. i did this... (if i recall correct)
I installed morphos on a seperate HD using the folowing..
DH0 => became DH0.1 and i labeled this MOSSYS: DH1 => became DH1.1 and i labeled this MOSWORK:
You probably remember wrong, because labeling to MOSSYS: will break things. MorphOS has the MOSSYS: assign which points to the SYS:MorphOS/ directory (MorphOS separates OS files from user files, and OS files reside in this assign). So, relabeling a drive would collide with it. To avoid confusion I would change the device names of partitions manually to something more explanatory rather than letting OS name them as .1 etc. It's best to do this before or immediatelly after installing the OS, before any applications or configs start pointing with device names (which is a bad practise anyway, but some will do it anyway). SYS: is always automatically assigned to the partition that system was booted from, so this works correctly always and no need to worry about it, and never try to change it in any case. I probably would rename device names of MorphOS partitions, for example, to MDH0:, MDH1:, MDH2: etc. By default the volume name for the system partition is Workbench: on AmigaOS and System: on MorphOS, so this doesn't clash and you can leave them on those names. Other partitions like Work: can be relabeled as you wish. For example, MOSWork: would work :)
|
|
|
|
Re: LHA Archiving questions....
|
Posted on: 2022/4/12 17:35
#10
|
Just popping in 
|
Well.. I combined this with another script I've made earlier, and here's the result: downloadFeatures: - Creates separate archives of directories from the source dir - Adds directory icons into the archives if found - Handles spaces in dir names - Progress output on the shell - If there were errors while archiving, it informs on which dirs it happened - Can be used with DOpus ("Execute S:archive_dirs.script {s} {d}", output to window) Usage: - Execute archive_dirs.script SOURCE DEST - Important: DEST must end to : or /  Hope it doesn't contain much bugs :)
Edited by jPV on 2022/4/12 18:06:39
|
|
|
|
Re: LHA Archiving questions....
|
Posted on: 2022/4/11 17:27
#11
|
Just popping in 
|
@CagemanQuote: Cageman wrote:@jPV
Ahh... yes... well... I got a similar but different solution... see my previous post... I must have made that post while you were making yours. :) Heh, yeah, but you got an ugly solution ;) Why to use 3rd party tools when you can do it in OS, and I also think that the solution you got doesn't work when there are spaces in directory names.
|
|
|
|
Re: LHA Archiving questions....
|
Posted on: 2022/4/11 17:13
#12
|
Just popping in 
|
@Cageman This can be done in the Shell quite easily, for example, like this:
List DIRS LFORMAT="LhA -a -e -x a *"%N.lha*" *"%N*"" > T:lha_script
Execute T:lha_script
This works if you CD into the corresponding dir first, and it creates archives in the same dir. But you could expand this to a better script which would take source and destination directories as arguments.
Edited by jPV on 2022/4/11 17:30:01
|
|
|
|
Re: Bug RNOXfer
|
Posted on: 2021/9/10 19:34
#13
|
Just popping in 
|
Hmm.. I don't remember I've changed anything related in the code, on purpose at least, but I'll try to check it... thanks for the report anyway.
|
|
|
|
Re: AmigaOS 3.2 for all Classic Amigas released and available
|
Posted on: 2021/6/16 8:40
#14
|
Just popping in 
|
@TSK Quote: I forgot the buffer size setting completely. I formatted the other CF card with the default block size 1024. So which way I should do, smaller block size or even bigger ? Amiga filesystems (like SFS) have traditionally recommended to use block size of 512, which is basically good for small files and it wastes less space from the disk. But if you want to speed up handling of big files (like media files, archives, etc), then you might want to consider using bigger values... 1024 as a moderate compromise, 2048 for focusing more on the speed, or even 4096. The bigger the value is, the more it consumes memory (buffers * blocksize bytes for each partition, 500 buffers with 1024 bs would consume 500kB of memory) and more you waste disk space (if you have a 20 bytes config file, it will take 4096 bytes from hd with 4096 bytes block size). So, I wouldn't recommend big block sizes for a boot partition, which contains thousands of small files. In my opinion buffers have actually bigger impact on speed with many real world operations (like when deleting/scanning files) than the blocksize. So if you don't have that much memory, I would use small blocksize, but at least moderate amount of buffers. IIRC HDToolbox on 3.x had default value of 60 or 80, or something like that under 100, for buffers. IIRC SFS documentation recommended to use 128 buffers or so, and I've felt that it's quite good to have it over 100 or couple hundreds on classics. On NG I personally have raised buffers to 4096 on partitions I have lots of small files and I need to delete large amounts of files regularly, and 2048 on other partitions. It really shows in speed when you delete, for example, a system backup directory. As said, buffers can be changed easily, but changing the block size will need a re-format of the partition. So it'd be more important to decide the block size before taking a new disk in use.
|
|
|
|
Re: AmigaOS 3.2 for all Classic Amigas released and available
|
Posted on: 2021/6/15 6:42
#15
|
Just popping in 
|
@Steady
Hmmm... why would disk space affect to memory consumption? Isn't it mostly Buffers * Blocksize in this case? On NG machines people might use buffers as hundreds or even thousands, because memory isn't an issue there, but on classics I'd stay somewhere like 128 or so. And keep blocksize as 512 if there isn't a good reason and memory to make it bigger.
Buffers can be set in HDToolbox or checked (or modified temporarily) by the AddBuffers command.
|
|
|
|
Re: Looping in DOS batch scripts
|
Posted on: 2021/5/24 17:12
#16
|
Just popping in 
|
I once made a file size based counter ;) I don't know if there would be other way, but if you don't have the ForEach command (on OS3, for example), then you could hack it like this (modified it to do what you asked) :P
; some paths you want to handle
setenv 1 "RAM:"
setenv 2 "T:"
setenv 3 "SYS:"
; init our counter to zero
echo "" noline > ENV:counter
; loop start
lab loop
; increase counter by one
echo "" >> ENV:counter
; read the counter value to a local variable
set i `list env:counter lformat "%L"`
; if we have a corresponding file, then do stuff and loop
if exists env:$i
; Get contents
set p `getenv $i`
; Do stuff
echo "Processing $p"
if $p eq "SYS:"
echo " Special case!"
else
echo " Normal case..."
endif
; clear variables
unsetenv $i
unset p
; jump back in the script
skip loop back
endif
; otherwise clean up and quit
unsetenv counter
unset i
And that would output:
Processing RAM:
Normal case...
Processing T:
Normal case...
Processing SYS:
Special case!
|
|
|
|
Re: how many audio channels are recommended in "AHI"
|
Posted on: 2021/5/4 16:50
#17
|
Just popping in 
|
AHI's mixing routines are quite primitive and if you increase channels, playback quality decreases even if you aren't playing concurrent sounds.
I would advice to set channels as few as you still find comfortable in your use.
I've noticed that I don't use more than two programs that output audio at once pretty much ever, so I've set my channels to two. This still allows me to play something like video clips or test a game while listening music on the background, but keeping the quality quite good.
This is why AHI has the Music Unit, which overrides anything else playing to keep the quality at max in certain cases. But if you want to let everything (including the Music Unit) to play simultanously, you can forward the Music Unit to other unit, but especially in this case I would really keep amount of the channels low.
|
|
|
|
Re: Personal Paint on X5000 need 256x192 but No Such Option
|
Posted on: 2021/2/23 7:51
#18
|
Just popping in 
|
@AmigaSociety
Or you could use bigger image on PPaint, but then cut out a 256x192 sized brush and save that. Draw a frame for your image or something like that to make cutting easier.
|
|
|
|
Re: List of wanted Software
|
Posted on: 2020/10/28 20:58
#19
|
Just popping in 
|
@Skateman
Thanks!
|
|
|
|
Re: List of wanted Software
|
Posted on: 2020/10/28 19:35
#20
|
Just popping in 
|
@Skateman
Yes, or actually this has been the case for three years already. I tried to submit my first program for xmas 2017. At first the communication seemed to work and promises were made, but then it faded and it's been harder and harder to get replies, and now nothing for a long time. At one point it was explained that it got under other work, I think it was around the a.org rebuild, or so... This just seems to be too hard and I don't know if I even want them there anymore if offered... what would happen with updates etc? It's just better to look elsewhere now, even though the original idea was to support this ecosystem too and to get at least some compensation for my hard coding work.
|
|
|
|