Who's Online |
73 user(s) are online ( 32 user(s) are browsing Forums)
Members: 1
Guests: 72
jarokuczi,
more...
|
|
|
|
|
Re: Switching to SATA - worth it?
|
Posted on: 2007/8/12 21:59
#1621
|
Just can't stay away 
|
@Chris Quote:
Chris wrote:
@joerg
I didn't know the sii cards could be used in a PCI66 slot.
Check the card, PCI cards compatible to both PCI33 and PCI66 have 2 holes in the connector. You have to check it youself since the pin is missing in the PCI66 slot of the A1-XE, they used PCI33 ones for all 4 PCI slots and you can put a PIC33-only card in the PCI66 slot, but doing that would be a very bad idea since AFAIK PCI33 and PCI66 use different voltages. Quote: Is the PCI66 slot operational when the AGP slot is being used? No, you can only use one of both.
|
|
|
|
|
|
Re: AmigaOS future if Amiga Inc. "wins"
|
Posted on: 2007/8/12 20:44
#1622
|
Just can't stay away
|
@Helge Quote: I understand that you won't hand over your source code, but are you 100% sure of that for other developers? Why should anyone do that? It wouldn't make any sense. Even throwing the sources into the largest trashcan of abandoned AmigaOS software, sourceforge.net, would make much more sense, that way there would be a tiny chance that someone does something usefull with them, donating them to Amiga Inc. instead would be the equivalent of deleting them. Quote: Maybe they [Amiga Inc.] will offer them money, who knows, Just like they promised to refund the money they owe to thousends of people from the PartyPack and ClubAmiga scams, not paying former employees like Bolton Peck although they were sentenced to pay by a court, the Kent arena sponsoring, etc.? The OS4 developers might be mad because of still working on AmigaOS4 despite all problems, but we are not that stupid 
|
|
|
|
|
|
Re: Switching to SATA - worth it?
|
Posted on: 2007/8/12 20:05
#1623
|
Just can't stay away
|
@tldaley Quote: I have just tried to put in a LG DVD burner and no matter what I do it is not seen by the OS, no CD0: shows up at all. Any help appreciated. If the DVD burner has a higher unit number than the last HD start MediaToolBox and save the changes it should detect (it's no longer the last unit) to the last HD.
|
|
|
|
|
|
Re: Switching to SATA - worth it?
|
Posted on: 2007/8/12 19:58
#1624
|
Just can't stay away
|
@Jack Quote: So the best setup when disk access is crucial is to have a pic gfx card in 33MHz slot and HD controller in the 66 MHz slot
Hmmm.... I have such a setup now, and HDs which are fast enough to make a difference. Sequential reading of 250 MB in 64 KB chunks using the device (not through a file system) from identical HDs using UDMA5: sii3112, PCI33 slot: 5.955 sec., 41.982 MB/sec. sii3114, PCI66 slot: 3.204 sec., 78.017 MB/sec. Unless there is a difference between the 3112 and 3114 or the drivers, I didn't test the 3112 in the PCI66 slot, using the PCI66 slot instead of a PCI33 one makes a much larger difference than it should. But it's a quite useless test, there are no seeks and it's reading everything to the same 64 KB buffer without using the data (just using 2 64 KB buffers instead of one and alternate both drops the speeds to 37 and 63 MB/sec. already). On normal usage, through a file system, actually using the data read, etc., the difference is probably minimal.
|
|
|
|
|
|
Re: AmigaOS future if Amiga Inc. "wins"
|
Posted on: 2007/8/11 21:26
#1625
|
Just can't stay away
|
@Helge Quote: I think if Amiga Inc wins, it is still VERY unsure if the developers hand over the source code. No, it's not unsure at all. Of course I wont hand over my source code to Amiga Inc., source code of software for which Hyperion only has a non-transferable object code licence. And I don't see any reason why other OS4 developers should give away their sources to Amiga Inc., except for the few parts which are based on AmigaOS 3.1 sources of course, to a company which did nothing but try to kill AmigaOS4 since years. If Amiga Inc. would be interrested in AmigaOS4 they'd either have to reimplement large parts or try to buy the sources from the owners, instead of lawsuits with which they can only try to stop Hyperion from releasing AmigaOS4, but not get (enough of) the sources to continue AmigaOS4 development themself, not even the rights to distribute the current AmigaOS4 binaries.
|
|
|
|
|
|
Re: OS4&DVI&LCD?
|
Posted on: 2007/8/10 9:29
#1626
|
Just can't stay away
|
@PR1 Quote: The story: Bought an expensive DVI-cable in the hope that the Radeon9250 output would give a better picture from the ViewSonic monitor in this XE. This has been discussed in aw.net but I hope there is the wisdom here to tell that it does/does'nt work when the os4 should pop up. No, the Radeon driver included in OS4 Final didn't support DVI yet. Only OS4 beta testers have a newer version with DVI support, but AFAIK it doesn't work with all cards yet. Quote: No signal just comes out in the digital output but U-Boot can be seen in every different cabling(vga or not) setups. U-Boot includes a x86 emulator, it executes the BIOS of the gfx card which sets up all outputs. AmigaOS4 doesn't use U-Boot and it has no x86 emulator either, the AmigaOS4 drivers have to support it themself.
|
|
|
|
|
|
Re: Mplayer versions
|
Posted on: 2007/8/8 20:10
#1627
|
Just can't stay away
|
@Swoop Quote:
Swoop wrote:
@LiveForIt
Quote: In Icon/Information there is an option to select workbench or shell tri that, because I don't think mplayer is workbench program.
Quote:OS4:C/mplayer -slave -vo cgx_vmem::ALWAYSBORDER: Unknown command.
MPlayer is definetly in C: so I must have the flags wrong, or in the wrong place. Maybe as a tooltype?
That way it's searching for a program named "mplayer -slave -vo cgx_vmem::ALWAYSBORDER" in OS4:C. You can only set the path and name of the tool, but you can't add arguments (at least not that way, there might be another method I don't know). Create a shell script, for example S:Shell/MPlayer_DefIcon, with the contents .key filename/A .bra { .ket } stack 1048576 ; no idea if it really needs a MB stack, but the default is too small OS4:C/mplayer -slave -vo cgx_vmem::ALWAYSBORDER {filename} Set the script protection bit, for example with "protect S:Shell/MPlayer_DefIcon +s" in a shell, change the default tool of def_flv to S:Shell/MPlayer_DefIcon, make sure "Startup from:" is set to "Shell" and disable "Prompt for input".
|
|
|
|
|
|
Re: CD/DVD burning tool
|
Posted on: 2007/8/5 19:11
#1628
|
Just can't stay away
|
I've uploaded a new version of AmiDVD today, the most important change to versions < 1.32 is the fixed U-Boot booting support.
|
|
|
|
|
|
Re: .hdf files (diskimage.device 52.x)
|
Posted on: 2007/8/4 1:42
#1629
|
Just can't stay away
|
@salass00 Quote: It's still a fact though that it returns the wrong dimensions in this case since it assumes the following:
BlockSize = 512
BlocksPerTrack = 1
Heads = 1
Cylinders = filesize / 512 Except for dg_SectorSize it's correct even for image files using a different block size since AmigaOS file systems only support block sizes which are a multiple of 512. Quote: So some way of letting the device know the correct BlocksPerTrack, Heads and BlockSize would be needed hence the command I propose above. File systems don't use SectorsPerTrack, Heads or Cylinders, they only use dg_SectorSize and dg_TotalSectors. If LowCyl isn't 0 they calculate the number of sectors themself using the data from struct DosEnvec (totalsectors = (de_HighCyl-de_LowCyl+1) * de_BlocksPerTrack * de_Surfaces) on startup, but never use the number of sectors per track or heads later, only the start offset of the partition, the number of blocks and the blocksize is used. Even image files using a different block size are no problem, you just need a seperate mountlist for each block size you use, but you'd need that anyway even if you'd add support in diskimage.device for different sector sizes. For the file systems for example SectorSize = 2048, SectorPerBlock = 1 is exactely the same as SectorSize = 512, SectorPerBlock = 4 since they only use the block size (SectorSize * SectorsPerBlock). If there wouldn't be UAE image files with a wrong size, UAE never accesses the spare additional space in them either, there would be no problem and you wouldn't have to add special support for wrong sized image files. IMHO correcting the size of such image files would be better than adding workarounds in diskimage.device.
|
|
|
|
|
|
Re: .hdf files (diskimage.device 52.x)
|
Posted on: 2007/8/3 22:10
#1630
|
Just can't stay away
|
@salass00 Quote: Still not a very ideal solution though. I'll have to think on this. If this error is common in UAE hardfiles I'd include a small tool to fix the broken image files. BPTR fh = IDOS->Open(filename, MODE_OLDFILE); if (fh) { if (!IDOS->ChangeFileSize(fh, correct_size, OFFSET_BEGINNING)) { IDOS->PrintFault(IDOS->IoErr(), "fixing the size failed"); } IDOS->Close(fh); }
|
|
|
|
|
|
Re: .hdf files (diskimage.device 52.x)
|
Posted on: 2007/8/3 21:32
#1631
|
Just can't stay away
|
@salass00 Quote:
salass00 wrote:
@joerg
Thanks for the explanation. So I guess if I modified TD_GETGEOMETRY to return the correct size it would work also. I'll have to try this out.
No! If the size of the image file is 64000000 bytes you'd have to change TD_GETGEOMETRY to return the wrong size (124992 sectors, 63995904 bytes), that would make it work with this broken image file, but all correct image files would stop working.
|
|
|
|
|
|
Re: .hdf files (diskimage.device 52.x)
|
Posted on: 2007/8/3 21:02
#1632
|
Just can't stay away
|
@salass00 Quote:
salass00 wrote:
@Raziel
If I make a copy of the hardfile and then mount and format it the header looks very different.
FFS2 stores the geometry in the first sector when formatting a partition, recovery tools like the "Find Partitions" option in PartitionWizard can use this data to find lost partitions on a HD with a destroyed RDB. Old versions of FFS didn't do that. But it shows your mountlist doesn't match the size of the image file: Mountlist: 63995904 Bytes ((3905+1)*32*512) Actual size (FFS2 using TD_GETGEOMETRY since LowCyl is 0): 64000000 Bytes ((124999+1)*512) If the file is 64000000 bytes but you used an old version of FFS in UAE with the parameters from the mountlist it can't work, the old FFS uses the mountlist size, FFS2 the real size. Either change the size of the file to 63995904 Bytes, or fix the geometry used in UAE to match the file size, for example 2500 Cylinders, 1 Head and 50 Sectors per Track. If you want to read the existing image with FFS2 you have to fix the file size, for example create copy with "dd if=broken_imagefile of=fixed_imagefile bs=512 count=124992". Edit: Reserved has to match as well, usually it's 2, but if the image file was formatted with Reserved=1 in UAE you have to use that in the diskimage.device mountlist as well.
|
|
|
|
|
|
Re: SmartFilesystem 1.273
|
Posted on: 2007/7/28 18:00
#1633
|
Just can't stay away
|
@Snuffy Quote:
Snuffy wrote:
Hi @joerg
Thanks! Wow, 1.270 was working pretty good.
What does 'ACTION_WRITE' refer to.
The ACTION_WRITE packet is used by the dos.library function Write(). In SFS < 1.273 writing to files > 2 GB didn't work correctly, for example creating larger ISO9660 image files didn't work with AmiDVD 1.30. Quote: I hit the 'panic button' the other day! AS IS copy the SDK directory to flash drive and crapped out in LOCAL/Perl5.85. I Locked-up into a infinite loop in the shell! Ironically, Python saved me! Very likely a problem with USB and not related to SFS. Quote: Questions:
DoesSDK directory have sub dir. depth limits? Not in AmigaOS file systems like SFS, FFS, etc., but I don't know if FAT has a limit. Quote: Does CopyDisk to USB device (FAT32) require extra parameters? No.
|
|
|
|
|
|
Re: Older versions of SFS?
|
Posted on: 2007/7/28 17:49
#1634
|
Just can't stay away
|
@micro Quote:
micro wrote:
@joerg
So, if i have understand it right, i?m supposed to use SFS_68k on my boot-partion (idh0: which holds my amigaos_3.9), SFS PPC on my morphos (idh1: which holds my Morphos) and plain SFS_68k on my other partitions?
Yes. For all partitions you want to use under AmigaOS you have to use the AmigaOS SFS, unless there is an AmigaOS 3.x/m68k version of the MorphOS SFS. I don't know how much faster the MorphOS PPC native SFS is compared to using the emulated AmigaOS 3.x/m68k SFS on MorphOS, if it's not much faster I wouldn't bother using it at all but only the AmigaOS 3.x/m68k SFS, that way you don't risk destroying AmigaOS SFS partitions by using the incompatible MorphOS SFS on them by accident, or the other way round. Quote: What if the big difference between sfs aos 3.x and sfs aos 4.0? The AmigaOS4 version is much faster (independant of the faster CPU), some operations are more than 10 times faster. Quote: Can i use sfs aos 4.0 on my workbench 3.9, i mean sfs_aos_4.0 is for ppc and i have ppc, so can i use it instead for aos_sfs_3.9(68k)? No, the AmigaOS4 version of course requires AmigaOS4. A PPC version for AmigaOS 3.x using WarpOS might be possible, but I guess it would be slower than the m68k one because of the very slow context switches in WarpOS.
|
|
|
|
|
|
Re: SmartFilesystem 1.273
|
Posted on: 2007/7/26 17:54
#1635
|
Just can't stay away
|
@Bloodwych Quote:
Bloodwych wrote:
@joerg
Thanks for the continued development of SFS. :)
I've just had a look at the complete 1.273 archive and have a few questions regarding the following tools:
SFSconfig
SFSdefrag
SFSobject
SFSquery
There are two copies of the above programs in the archive. One set in the "Smartfilesystem" directory and more in the "Smartfilesystem/AmigaOS3.x" directory.
Which are the correct to use? It's left me a little confused as they have different creation dates and file sizes.
Depends on which Version of AmigaOS you are using, the executables in the Smartfilesystem directory are AmigaOS4 PPC native ones (not all, only the ones for which there are duplicates in the AmigaOS3.x directory), the executables in the AmigaOS3.x directory are m68k executables. If you are using AmigaOS 3.x move the programs from the Smartfilesystem/AmigaOS3.x directory to Smartfilesystem (replacing the PPC ones you can't run), if you are using AmigaOS4 you can delete the AmigaOS3.x directory.
|
|
|
|
|
|
Re: Another CPUTemp.docky question.
|
Posted on: 2007/7/26 0:30
#1636
|
Just can't stay away
|
@dwolfman Quote: Cool! I'll be looking forward to it.  I've just uploaded the new version.
|
|
|
|
|
|
Re: Another CPUTemp.docky question.
|
Posted on: 2007/7/25 2:16
#1637
|
Just can't stay away
|
@dwolfman Quote: Something I would like to be able to do, but the current CPUTemp.docky doesn't seem to have an optioin for, is to be able to adjust the update rate for the CPU usage graph scrolling. I've always preferred my usage graphs to run slower, say one update every 1 second or so. The next version of CPUTemp.docky, probably available tomorrow, will have an option to configure the update rate (1/4, 1/2, 1 or 2 seconds).
|
|
|
|
|
|
SmartFilesystem 1.273
|
Posted on: 2007/7/25 2:08
#1638
|
Just can't stay away
|
A new version of SFS is available on the SFS homepage.
|
|
|
|
|
|
Re: Switching to SATA - worth it?
|
Posted on: 2007/7/24 21:38
#1639
|
Just can't stay away
|
@Raziel Quote:
Raziel wrote:
2. Can i boot from SATA drives as i can with ATA?
U-Boot supports the sii3112, it doesn't support the sii3114. I don't know if the sii3512 is supported or not, it's not mentioned in the docs. Booting in AmigaOS4 works with all 3 of course, but if you use a controller not supported by U-Boot AmigaOS4 has to be loaded from something else, for example the PATA HD you are currently using. If you are currently using a sii0680 and need the PCI slot for the SATA controller you can connect the HD to the motherboard VIA controller instead. Quote: 3. Whats the speed difference, is it worth it? There is no speed difference. Like with the PATA sii0680 and it8212 controllers the max. theoretical speed is 133 MB/s (UDMA6), and since you'll use it in a PCI33 slot it can't be faster anyway. The motherboard VIA PATA controller only supports up to UDMA5 (100 MB/s), but that doesn't make any practical difference either, there are no HDs which are that fast, only reading/writing from/to the drive caches, not the disk itself, could be a little bit faster with a PCI UDMA6 controller compared to the motherboard UDMA5 one. You can connect 2 drives to a sii3112 and sii3512, 4 drives to a sii3114.
|
|
|
|
|
|
Re: x11 Abiword starts up faster..
|
Posted on: 2007/7/24 11:37
#1640
|
Just can't stay away
|
@jahc Quote: But anyway.. today, I had to do a job with Abiword. Previously, it would take around a minute for it to startup. But I noticed that it now starts up in around 10 seconds like on my friends A1! I wonder if SFS on my SYS: partition made the difference? I didnt think there were many x11 files used on SYS:.. TTF fonts used by X11 on SYS:? Your Cygnix:Home/root/.fonts.conf probably includes <dir>/sys/Fonts/_TrueType</dir>
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
