Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (olsen)

Bottom

(1) 2 »

olsen

Re: Samba Filesystem

Posted on: 2021/4/26 11:35 #1

Just popping in

> @Raziel
> 2.22 seem's to have made it out, but only on os4welt.de,
> search for smbfs, the changes to 2.21 is minimal doubt they even fix any major > bugs,
> but... the sourcecode is available for anyone to take a stab at it,
> compiling it for upload to os4depot, or even implement samba V4+ behavior

I know it's a lot to ask, but please hold your fire. The old version 2.1 is a bit long in the tooth and the 2.2 version is not ready for general release yet

Topic | Forum

olsen

Re: Samba Filesystem

Posted on: 2021/4/26 11:32 #2

Just popping in

@Raziel

> @Joeled
>
> https://github.com/obarthel/amiga-smbfs/releases/tag/V2_1
>
> 2.2 never made it out of beta...wonder if Olaf still preparing some new stuff?

I got side-tracked by a little project known as AmigaOS 3.2, I'm afraid...

Things are slowly returning to normal and making the long delayed changes still on my list is finally happening. I still need to solve the problem of file/drawer names using Unicode characters which cannot be conveniently translated into the Amiga's character set. I had an idea of how to make this work in late 2019, which is when the problem popped up for the first time, but didn't make a lot of progress since then (getting side-tracked by AmigaOS 3.2, etc.).

Topic | Forum

olsen

Re: Samba Filesystem

Posted on: 2021/4/26 11:06 #3

Just popping in

@pvanni

You are correct, the name of the service must be given. It's not sufficient to just provide the server address.

This might work better:

smbfs cache=1024 volume=condivisa Workgroup=WORKGROUP User=davide Password=mypassword Service=//192.168.1.7/condivisa

This is in the documentation, by the way, but given its length it's not for the faint of heart.

Topic | Forum

olsen

Re: Translations need for Basilisk 1.0, please help out.

Posted on: 2020/12/10 15:55 #4

Just popping in

@LiveForIt

> @LiveForIt: What exactly are you missing in Roadshow which AROS TCP (which is built upon AmiTCP V3) is delivering?
>
> Being able to see what TCP/IP stack is doing when I send some packages, and > maybe understand way I don’t get any packages from Roadshow. At that was problem I had, it looked like communication did not go anywhere. From my point of view.
>
> Something like Wireshark for Amiga might helped.

Roadshow ships with tcpdump, which directly hooks into its builtin BPF interface. That should get you somewhere

At the very least, you could capture the packets, have tcpdump write them to a file (using the "-w" option) and feed these files into Wireshark.

> I have no idea what is going on inside of POSIX sockets, I know roadshow is picky about having open the interface per thread or something like that, but that cannot possibly work, I know about socket sharing, but that is below the POSIX api, so not easily accessible. I got lot crashes and count really do anything. Of course is also issues with errno because designed for isolated thread like forks(), but do not work well in Amiga landscape.

The AmiTCP API does not permit socket library bases to be shared (but doesn't indicate so), and Roadshow follows this practice by default. I tried to keep the behaviour of the API in line with how AmiTCP would approach this, but there is a caveat in that the library base sharing is unpredictable with AmiTCP. This is why Roadshow blocks sharing by default and will return an error. With AmiTCP you may not even get an error, your code might just hang indefinitely.

However, you can enable library base sharing through the SocketBaseTags() SBTC_CAN_SHARE_LIBRARY_BASES option, like so:

error = SocketBaseTags(
SBTM_SETVAL(SBTC_CAN_SHARE_LIBRARY_BASES), TRUE,
TAG_END);

Make sure to check if SocketBaseTags() returns an error code instead of 0. If there's an error code, it means that you can't enable or use library base sharing.

> posix select() also behaves strangely, I had to make a work around in mplayer, when streaming you get error message about select() being broken on AmigaOS

WaitSelect() comes with its share of peculiar features and it does not necessarily perform exactly like select() does. For example, Exec signals are checked during the syscalls behind the bsdsocket.library functions, and if your application so happens to use the same default signals (e.g. SIGBREAKB_CTRL_C) then there will be side-effects.

Due to how the TCP/IP kernel code handles time in, for example, the code which backs the select() syscall, you do not have as fine-grained an interval length as you would with timer.device on the Amiga. More recent versions of Roadshow support the more fine-grained microsecond intervals, though. But out of the box, Roadshow versions older than two years do not.

> For example do I need vlink? Well the TCP/IP package be send to roadshow and my program when I open a ethernet device, or will it only be send to roadshow only, does it work the same on all ethernet drivers? Or is different depending on driver used?

I haven't used vlink.device, so I would not know whether it would make it easier for you to add networking support to Basilisk.

If you went the other way through the use of a SANA-II network device, then the tftp client example should at least introduce you to the basics, namely how to open the device, initialize it, check for errors (and how to make sure that you have the right type of hardware!), and then how to receive and send Ethernet frames. Not all Amiga network device drivers support shared access to the same device, which is where things are bound to get tricky... Sending frames is easy enough, but receiving the frames intended for your emulated Mac is harder (it involves a filter function which not all Amiga device drivers support, and some do not support it completely/correctly). Documentation for SANA-II is available on the Amiga Developer CD 1.1 and beyond.

Whether BSD raw sockets can be a viable substitute remains to be seen. Both AmiTCP V3 and Roadshow support these, but I've never used them.

Topic | Forum

olsen

Re: Translations need for Basilisk 1.0, please help out.

Posted on: 2020/12/10 13:25 #5

Just popping in

@mufa

Sorry, I haven't been around on this site for a long time

Some context on what I mentioned with regard to what Roadshow does, and how that tftp client code fits into the picture.

First thing, both AmiTCP V3 and Roadshow are using old TCP/IP stacks, with AmiTCP V3 using the older one, which goes back to the late 1980'ies. Roadshow's a bit younger, being derived from 4.4BSD-Lite2 (1995). That explains in part why Roadshow does things differently. But it also explains why there are limitations as to what the code can do. NetBSD is closest to the state of 4.4BSD-Lite2, yet porting features such as path MTU discovery from old NetBSD to the codebase which Roadshow uses has proven really hard. Not much wiggle room

Roadshow implements the AmiTCP V4 API, as did Miami, for example, but neither of these Amiga TCP/IP stacks use or share code of AmiTCP: They share code with the 4.4BSD-Lite2 release, directly (Roadshow) or indirectly (Miami is likely based upon NetBSD).

@LiveForIt: What exactly are you missing in Roadshow which AROS TCP (which is built upon AmiTCP V3) is delivering?

Roadshow requires that every client which uses it is a Process. How and why that would create trouble on AmigaOS4 threads I cannot tell. If libcurl is not working for you, it's possible that the POSIX interfaces it expects to work may not be supported by the AmigaOS architecture. For example, you can use POSIX signals to abort pending DNS queries and even Unix syscalls such as connect(), but this is not a robust approach on the Amiga. The Roadshow implementation of the socket networking API plays within the limitations imposed upon by the Amiga operating system.

I stumbled upon such issues with the wget port which ships with Roadshow which would use POSIX signals to implement timeouts for DNS queries, for example, and the workarounds I tried to find didn't exactly produce the same behaviour you'd get on a POSIX system. That's a side-effect of how the AmiTCP design integrated the libresolv functionality.

Oddly, some of the code I've seen which uses POSIX signals in order to implement timeouts for network operations makes assumptions about the socket networking API which hold on Linux but not on BSD Unix. For example, the connect() function has its own separate timeout which follows from how it was implemented, and that will take effect before a POSIX signal triggered by a longer alarm() timeout can. This is the kind of stuff you don't expect and will have to spend hours reading the old TCP/IP stack source code over

The SANA-II tftp client available at https://github.com/obarthel/amiga-sana-ii-tftpclient is an example of how SANA-II compliant network device drivers may be used in practice. The example builds both for AmigaOS 2.x/3.x and AmigaOS4 and I tested it in both environments. LiveForIt mentioned having difficulties making SANA-II work, so maybe that example could be helpful. The example pretty much covers what a TCP/IP stack would do when doing, juggling IP and ARP datagrams using asynchronous I/O. Which even for a "simple" protocol such as tftp is surprisingly complex. Careful please: this shows how you could approach this task without using an existing TCP/IP stack, just by going to the lowest available networking layer attainable on the Amiga. Don't try to use this tftp client if you already have a TCP/IP stack or Envoy running at the same time.

Topic | Forum

olsen

Re: OS4 recovery software

Posted on: 2019/3/11 9:46 #6

Just popping in

@JosDuchIt

Sorry for the late answer

As of this writing, there is a working AmigaOS4 port of Disk Doctor, which is currently available to beta testers only. It is based upon the considerably reworked and updated Disk Doctor which is intended to ship as an update to AmigaOS 3.1.4.

I have no idea when either version will become commercially available

Please note that this Disk Doctor is only intended for data recovery on volumes which have been formatted using the Amiga OFS/FFS/DCFS/LNFS file system flavours. If you were using SFS or NGFS you may need specialized software to recover data from the disk.

Topic | Forum

olsen

Re: OS4 recovery software

Posted on: 2018/10/11 17:46 #7

Just popping in

@nbache

> Just because the new DiskDoctor can fix disks using the FFS from OS 3.1, doesn't mean it also knows everything about the ones using the newer FFS found in OS 4.x.

Actually, it does

I started working on what would become the new Disk Doctor when it became apparent that AmigaOS 4 would no longer include a diagnostic, recovery and repair tool for the OFS/FFS/DCFS/LNFS file system flavours.

This turned into quite a long research project and when it became just useful enough to test it, it seemed like it would make a good addition to AmigaOS 3.1.4 and ship with it.

The plan is still to make the new Disk Doctor work on AmigaOS4, but first I have to make the repair operation work well. This is what I "cut" from the version which was released for AmigaOS 3.1.4 since I had misjudged the effort required to make the examine and copy/recovery operations work well and usable, too.

> It may be possible, but I would be very careful and make sure I only work on data I can afford to lose.

The new Disk Doctor is for the time being limited to examining volumes for defects and for recovering their contents. No changes are made to the volume, this is a strictly non-invasive tool.

Given the time to finish development on it, and testing, too, of course, it won't be limited to these operations. There will always be a situation in which copying/recovering data from a volume is not the best option available and a repair in place would be preferrable. I intend to deliver that for both AmigaOS 4 and as an update to AmigaOS 3.1.4 when the repair operation is ready for release.

Topic | Forum

olsen

Re: Float64 printing?

Posted on: 2010/9/29 15:40 #8

Just popping in

@alfkil

Quote:

alfkil wrote:
How do I correctly print a float64? Is it possible with printf, or do I need to look for some other kind of conversion routine?

'float64' is not a built-in 'C' data type. Can you check what it actually represents? I guess it might just be the old "double" type (double precision IEEE 754 floating point number), which according to the standard is a 64 bit entity.

As such printf("%f",...) should work just fine.

Topic | Forum

olsen

Re: AmigaOS 4 ms timer ?

Posted on: 2009/12/23 9:00 #9

Just popping in

@salass00

Quote:

salass00 wrote:
@freddix

UNIT_MICROHZ has ?s accuracy.

For higher accuracy than that you can use UNIT_ECLOCK
...

No, this has not been exactly correct since AmigaOS 2.x. While the old AmigaOS 1.x documentation explains that UNIT_VBLANK timing accuracy is coarser than UNIT_MICROHZ, this explanation only holds for the timer.device versions available in AmigaOS 1.x.

With AmigaOS 2.x the source that drives the timer.device time keeping was switched, yielding much higher accuracy in excess of what UNIT_MICROHZ could deliver in AmigaOS 1.x. In effect, the same source drives UNIT_VBLANK, UNIT_MICROHZ and UNIT_ECLOCK. There is no difference in accuracy between UNIT_VBLANK and UNIT_MICROHZ.

The exception is UNIT_ECLOCK. Since it does not use seconds/microseconds values for time intervals, you can go beyond microsecond accuracy. In practice, however, this may make little difference because task scheduling will tend to get in the way and skew your delay times

UNIT_ECLOCK is really useful only if you want to measure time differences with great accuracy.

Incidentally, if you use the EClock timer, you should not peek SysBase->ex_EClockFrequency, but use timer.device/ReadEClock() instead. This is because SysBase->ex_EClockFrequency may be set to a legacy value on AmigaOS 4.x while the actual EClock frequency returned and referenced by timer.device/ReadEClock() may be much, much higher.

Topic | Forum

olsen

Re: Roadshow

Posted on: 2009/2/6 13:47 #10

Just popping in

@Cyborg

Quote:

Cyborg wrote:
@olsen

Quote:

olsen wrote:
@Cyborg

Um, some notes on this:

- It's OK to set DHCP and a static IP address in the configuration. The effect this has is to alter the DHCP exchange on the client's side. Instead of asking the DHCP server to assign an IP address and provide for information on the default gateway and the DNS servers, the client tells the server "this is my IP address, take it or leave it" and picks up whatever the server could provide. Mind you, this is not recommended unless you are certain that you need things to work like that.

While it might be OK, you say yourself that it's *not* recommended .. that's why i said he should use either DHCP or static configuration..

Yes, but that setup actually selected a static configuration. In this case, assigning the IP address right in the configuration file only modified what the DHCP negotiation process did. Instead of asking the DHCP server to hand out an IP address, the client just reported its assigned IP address to the server.

Quote:

Quote:

- While you are free to choose the IP address range used in your local network up to a point, you should observe certain rules. The 10.*.*.* IP address range corresponds to a network address of 10 and a host address of the remaining 24 bits, which accounts for the netmask of 255.0.0.0. You should not change the netmask to 255.255.255.0 unless you are using the reserved IP address range of 192.168.*.*. Of course, mucking with the netmask works most of the time, but some software will get into hot water if the reserved IP address ranges and their corresponding default network mask values don't match.

*sigh* .. yeah, that darn 10.*.*.* IPs .. mea culpa.. i'm using 192.168.*.* only since 15 years, so i'm probably just too used to a /24 netmask.. :-/

But.. sorry if i sound dumb here, but if i follow your logic also for 192.168.*.* ... shouldn't then the correct netmask be /16 and not /24? I.e. 255.255.0.0 instead of 255.255.255.0 ?

No, the 192.168.*.* shorthand, which I used in a misleading manner, needs clarification. The first "*" in 192.168.*.* stands for the fact that you can choose the third number to set the network address. Hence, you can pick your network address from the range 192.168.0.* to 192.168.255.* - the network address definitely covers 24 bits, not 16. The host address is what the last "*" in 192.168.*.* stands for, which can be picked from the range 1 to 254.

Quote:

And if i have some clients which all use an IP of the form 10.1.1.x ( 0 < x < 255), why would be a netmask of 255.255.255.0 be wrong or "not recommended" ? Maybe i have a second group of clients with 10.1.2.x as IPs but i don't want them (for whatever reason) to communicate directly with the other group.. with a netmask of 255.0.0.0 they actually could communicate directly, couldn't they?

You can always cut a larger network into smaller portions, but care must be taken that these portions do not overlap. This why it's not recommended: if you only have a small IPv4 network with fewer than 254 machines around, it's less error prone to choose any of the 192.168.0.*-192.168.1.* network prefixes than to chop up the much larger 10.*.*.* network into subnets and make sure that the subnets do not overlap.

Of course you can go ahead and use the larger network which gives you 16 million possible machine addresses, but, as I wrote, it's much more straightforward to use the smallest reserved IP range that matches your needs than to always use the largest.

Mind you, some gateway routers default to use the 10.*.*.* address range and won't let you change it. But I would consider that an anomaly rather than a deliberate feature. Most gateway routers I've dealt with that are intended for home use will suggest a 192.168.*.* address range, typically it's 192.168.1.*.

Quote:

Again, sorry if my questions sound dumb, but i'm just trying to wrap my head around your information and what i was used to until now..

Quote:

- It's sometimes useful to reduce the default MTU value if you know that traffic to leave your network will always have to squeeze through a gateway which limits the size of the packets. An example is the PPPoE protocol which is widely used for ADSL services in Europe. PPPoE limits packet size to 1492 bytes payload. If you limit the MTU value in your network clients, it may mean that there will be less friction since converting between the packets that go into the router and have to come out, chopped into smaller units. Chopping up the packets in transit may result in extra traffic since some packets cannot be conveniently broken into smaller units and will have to retransmitted. This "optimization" through MTU limits may, however, accomplish nothing tangible.

hmm .. i really didn't say that a reduced MTU might not make any sense at all .. in fact i wrote exactly that 1500 is default for ethernet, but one might tinker with the MTU in certain situations, like DSL/PPPoE <= 1492. What did you say different than me?

Your original comment asked the rhetorical question "why that funny MTU value?". I tried to give a bit of background as to why it could be useful, and that in practice it often has no discernable effect.

Topic | Forum

olsen

Re: Roadshow

Posted on: 2009/2/5 9:35 #11

Just popping in

@Snuffy

Quote:

Snuffy wrote:
...
5. I click the button -- Test this configuration --
A 'Dialer' window reads:
"The driver eth3com.device, card number 0, sucessfully passed the configuration test."
The 'ppp-ethernet.device' in Devs/Networks will not show up in the wizard anywhere. If 'ppp-ethernet.device' is selected manually, an error occurs:
A 'Dialer' window reads:
The driver ppp-ethernet.device, card number 0, is not am Ethernet hardware driver.

Please do not select ppp-ethernet.device directly. Think of ppp-ethernet.device as a car that needs an engine, and that engine is an Ethernet device such as eth3com.device, which is what the dialer verifies. If you try to select ppp-ethernet.device directly, you are trying to put a car into another car in place of an engine, so to speak, and that is not a useful combination.

Quote:

...
7. ...
A 'Dialer' window reads:
ERROR: Could not broadcast PPPoE active discovery intiation
(inappropriate state, Transmission failed - too many retries).
Another 'Dialer' window reads:
Connection attermpt failed
(Resource allocation failure, Transmission failed - too many retries)

8. I don't know what to do next.

I haven't checked this in a long time, but there should be a dialer option to activate debug output for the connection establishment process. This is what you need to activate, and somebody like me (whote wrote the software) needs to look it over.

OK (two hours later), I have just checked: the current dialer has no support for diagnostic logging, which essentially means that if you cannot connect to your ADSL service, the dialer will not provide any hints whatsoever why it happens. Don't try to make sense of what the dialer tells you right now, it will not be helpful in any way.

It's possible that no traffic passes through your machine's Ethernet ports to the intended destination. But this is hard to verify if you are trying to directly connect your Amiga to the Internet through an ADSL modem: those modems usually don't talk much in case of error which makes it difficult to identify the cause of the problem.

I would recommend that you sink some money into a gateway router which connects to the ADSL modem and maintains the Internet connection for you and then plug in your Amiga into the router's local area network port. That way, you get to verify whether the problem is in connecting to the Internet, or in getting your Amiga to talk to your local area network in the first place. Right now I wouldn't know whether it's one or the other.

Edited by olsen on 2009/2/5 11:49:48

Topic | Forum

olsen

Re: Roadshow Config For SAM

Posted on: 2009/2/3 14:39 #12

Just popping in

@Slayer

Quote:

Slayer wrote:
Has anyone tweaked there Roadshowcontrol settings to run more efficently/quickly with a high speed ADSL connection.

I know there is information already out there concerning this but I'm just pondering if the SAM ethernet ports are different for example.

Ethernet is a standardized technology, with standardization covering both the electrical aspects and the makeup of the data that is committed to the wire. There are differences between the electrical and physical dimensions (connector types, cabling, etc.), but what matters for ADSL isn't this, but how the data on the wire looks like. And for consumer use, that's very narrowly defined: 1500 bytes payload, with a 14 byte header that tells every listener where the data comes from, where it goes to, and what protocol it uses. This is what counts and the SAM Ethernet hardware doesn't do this any differently.

Quote:

Ranger also reports MTU and Hardware is at 1518 I decided to take off 40 from that and set that as my MTU in Roadshow.

What counts is the payload size Ethernet permits, and that's 1500 bytes. You should use this lower number as the basis for your calculations.

Quote:

I think it would have been nice to have a toggle, either set it to something or 0 to disable and then the hardware figures it out. Once established it also changed relevant buffers and caches.

Before I saw the Ranger information I had it set at 1500 which is the setting at my provider. I didn't take off 40, that's just a new thing and seems to be related to other systems, must be a reason for it though.

Not at home, at work with this horrible IBM LOL so can't provide any cut and paste

Thanks for any information

Tweaking the MTU value doesn't necessarily result in noticeable improvements in terms of performance, unless you are connecting directly to the Internet through PPPoE, which you really should not (use a gateway router instead, please: it's safer and simplifies a whole lot of things).

Some useful tweaks involve internal configuration parameters of the TCP/IP stacks related to buffer sizes and packet assembly. Try entering this in the shell:

roadshowcontrol save set tcp.do_timestamps 0
roadshowcontrol save set tcp.do_win_scale 0
roadshowcontrol save set tcp.mssdflt 1460
roadshowcontrol save set tcp.recvspace 65536
roadshowcontrol save set tcp.use_mssdflt_for_remote 0

Topic | Forum

olsen

Re: Roadshow

Posted on: 2009/2/3 13:29 #13

Just popping in

@Cyborg

Quote:

Cyborg wrote:
@Slayer

Quote:

Slayer wrote:
@tlm

okay from devs:

# DEVS:NetInterfaces/PPC440EP_ETH
# File generated by Dialer 52.1 (11.12.2006)
# On Friday, 09-Jan-09 at 06:55:32
device=ppc440ep_eth.device
configure=dhcp
address=10.1.1.5
netmask=255.0.0.0
mtu=1478

Wow, what a mess :p

- Why do you have *both* DHCP and an IP? Either use static OR dynamic configuration.

- You wrote that all your IPs in your LAN are 10.1.1.x ones, right? So why the heck do you then specify a netmask of 255.0.0.0 ? It shouldn't hurt, but correct would be 255.255.255.0 as netmask.

- Why such a strange MTU value? For Ethernet the MTU is 1500 (for gigabit ethernet its actually up to 9000, but that isn't supported yet). Thats also true if you access the Internet through a router. Only if you are directly connected to the Internet with your Amiga (e.g. through PPPoE), you might have to worry about the MTU value and set it to something below 1492 for DSL.. but even that would Roadshow do for you with the Wizard..

Um, some notes on this:

- It's OK to set DHCP and a static IP address in the configuration. The effect this has is to alter the DHCP exchange on the client's side. Instead of asking the DHCP server to assign an IP address and provide for information on the default gateway and the DNS servers, the client tells the server "this is my IP address, take it or leave it" and picks up whatever the server could provide. Mind you, this is not recommended unless you are certain that you need things to work like that.

- While you are free to choose the IP address range used in your local network up to a point, you should observe certain rules. The 10.*.*.* IP address range corresponds to a network address of 10 and a host address of the remaining 24 bits, which accounts for the netmask of 255.0.0.0. You should not change the netmask to 255.255.255.0 unless you are using the reserved IP address range of 192.168.*.*. Of course, mucking with the netmask works most of the time, but some software will get into hot water if the reserved IP address ranges and their corresponding default network mask values don't match.

- It's sometimes useful to reduce the default MTU value if you know that traffic to leave your network will always have to squeeze through a gateway which limits the size of the packets. An example is the PPPoE protocol which is widely used for ADSL services in Europe. PPPoE limits packet size to 1492 bytes payload. If you limit the MTU value in your network clients, it may mean that there will be less friction since converting between the packets that go into the router and have to come out, chopped into smaller units. Chopping up the packets in transit may result in extra traffic since some packets cannot be conveniently broken into smaller units and will have to retransmitted. This "optimization" through MTU limits may, however, accomplish nothing tangible.

Topic | Forum

olsen

Re: Workbench enhancement project

Posted on: 2008/7/6 18:20 #14

Just popping in

Hm... I've looked at the postings in this topic and I'm surprised that so far every idea brought forward works within the limits of what AmigaOS currently can do. As in: let's improve upon what we have.

Improving upon what we have is what essentially went on during the last 6-7 years. What we have today grew out of the need to port the Amiga operating system to a new hardware platform, and fill in the areas where today's hardware can do things that the old Amiga platform hardware could do not, e.g. truecolour screen rendering, USB device support, etc. This was some major effort, and for my own part, I was happy to have been a part of it

However, I believe that there is only so far you can go if you keep looking at what the operating system components can do, and go about improving them. Parts such as the datatypes subsystem or the shell's GUI are, as always, in need of improving. But, at the end of the day, how much more useful is AmigaOS going to be if there's a shell with a tabbed GUI, a datatypes system that can process more kinds of data?

I'm not knocking gradual improvements. After all, this is what we have been busily doing for years, and this kind of work was badly necessary. It was also tough work, since there is probably nothing tougher than having to work within an existing framework, fixing and updating existing code.

What I'm missing is something else, and I hope to direct your attention to it. We need AmigaOS to be useful. If we look at the individual operating system components for ways to make it more useful, then we'll only succeed at making isolated changes that individually might have an impact that won't help as much as a different approach to looking for improvements.

An example: let's say we want to make it possible for several users to share the same Amiga without each user being able to access the other user's files. That's a plan which implies a purpose and has its own requirements: you need multiuser support in the operating system. Now, what can be done to make this useful, and get it to work? What would make it hard to implement this?

Compare this to the isolated requirement of implementing multi-user support in the operating system. What it is good for? What would make it hard to implement it? It's much harder to answer these questions since the isolated improvements lack context and a specific task the changes should enable.

I think it would be very useful to view improvements to AmigaOS in context rather than in isolated form. If we stick to the latter, then we'll have it much harder to make the operating system useful beyond what it can be used for today. What we have today is still very much useful for the kind of tasks AmigaOS used to do in 1994, and not much beyond that.

Topic | Forum

olsen

Re: Partition Size Limitations

Posted on: 2008/3/7 20:08 #15

Just popping in

@acefnq

Quote:

acefnq wrote:
This may have been discussed somewhere but I cannot find a simple answer via search here or at AW. What are the size limitations on FFS partitions. Also what is the size limitation of an amiga dos3 partition (is it 4gb?), I want to set up a share between AOS and Linux on my A1 but I'd rather have something greater than the 3gb I had.

ace

Provided you can find a disk that large, and are willing to go to extremes, the largest disk the FFS on OS4 can theoretically handle is 4,294,967,295 (= maximum number of blocks) times 4,294,967,295 (= maximum block size) bytes in size. That's 18,446,744,065,119,617,025 bytes total. I wouldn't recommend to use 4GByte blocks, though

If you are going to use a single modern hard disk drive, I would not recommend that you go far beyond 8-16 GBytes for an FFS partition, provided you use 8192 byte blocks. FFS becomes pretty inefficient at managing storage media that large very quickly. Beyond the efficiency problem, you are basically free to choose the partition size you prefer. The partition size limits of old no longer apply to the OS4 version of the FFS.

Topic | Forum

olsen

Re: Unicode support in future os4 updates?

Posted on: 2007/7/24 18:50 #16

Just popping in

@TetiSoft

Quote:

TetiSoft wrote:
@Hans

Quote:

You should consider taking up this offer;
that's less work for you and the rest of the OS4 dev team.

Olsen has an account on this site. He maintains both the
con-handler and the technical part of giving access to
OS4 sources.

All true, but I'm not the guy who hands out access permits for the operating system source code.

The situation being what it is, it would be great to have more developers contributing to the operating system, but with great enthusiasm comes the need to sign great non-disclosure agreements.

I don't know what the procedure is. In the past there was a path from the beta test group to becoming an OS4 developer, and something similar did exist for the professional Amiga software developers.

I can ask how this is done today, if need be

Topic | Forum

olsen

Re: Unicode support in future os4 updates?

Posted on: 2007/7/24 18:40 #17

Just popping in

@LiveForIt

Quote:

LiveForIt wrote:
@TetiSoft

Quote:
create UTF-8 keymaps in memory, this would break nearly
every existing shell/console/terminal/KingCON/whatever.

Yes will break KingCon, but so did SnoopDOS.
Console/Shell? will need UTF8 support anyway.

Terminal / whatever? is the problem really.

What you need is legacy API and new style API,
so programs that don?t know of UTF-8 don?t notice it.

Quote:
do you volunteer to create new shells/ consoles/con-handlers etc which can handle ESC[ or UTF-8 escape sequences

Yes, development is a hobby for me not a job, so I even do it for fun, even add the KingCon scrollbar.

I need the source-code of the OS4 con-handler.

con-handler is the wrong place to put UTF-8 support into. This would have to be done in the place that actually deals with putting control sequences, and sequences of characters on the screen, and that's console.device, not con-handler. Similarly, while con-handler would be the right place to add a scroll bar or two to a window, the task of updating the window's contents in response to scroller operations would be for console.device and not con-handler.

Yes, KingCon and just about every other console handler there ever was did these tasks all on its own and ignored the console.device's part. This was mainly because you couldn't change console.device. But it still makes for bad architecture. Small recap: graphics.library renders text on the screen; console.device transforms control sequences into text rendering operations; con-handler transforms file I/O operations for console.device to use them.

Topic | Forum

olsen

Re: HD Formatting Problem

Posted on: 2007/4/3 20:32 #18

Just popping in

@voxel

Quote:

voxel wrote:
@olsen

I can say that the drive is killed as I tryied a low level format on a 1GB HD (a long time ago, when 1GB HDs costed a small fortume : 1996) and suffered a power loss

when I could power back my Amiga the HD was electricaly OK but showed 0 Block, 0 sectors, 0 tracks and I never could use it since : impossible to low level format it again. and I tryied a lot of time with all the formating software I could find...

so it's not a myth at all, it's reality.

"Was", not "is". We were talking about "modern" IDE hard disk drives, and even the technology used ten years ago in making large storage devices has evolved greatly since. I'd say that if you have a drive that's smaller than 4-6 GBytes and was manufactured before 1998-2000 then you have an "old" type of drive. And these old drives would tend to be mechanically less robust, and overall reliability was lower.

Things changed as the market for these devices exploded after the late 1990'ies. There was greater demand, and the greater demand fueled research. The research gave us what we have today, and while what we have today still works within the I/O framework that already existed almost 20 years ago, almost everything else has changed.

For example, modern drives make extensive use of error detection and correction, and one bit of stored information may be spread over several recorded bits: the storage hardware reconstructs the originally stored bit by counting how many recorded bits agree upon it. Also, modern drives store their firmware on the disk rather than in an EPROM. When you power up a drive, the drive loads its firmware from the disk. If the firmware stored on the disk is damaged, and even if the remainder of the disk is still OK, you still won't be able to read data from the disk. Not even if you transfer the electronics from a different disk to your damaged one.

Quote:

BTW, you're right, it was a scsi drive.

No surprise there. IDE drives ceased to respond to low-level formatting requests a long time ago. Part of that may have initially been motivated to pretend that the drives were more reliable than really was the case.

Topic | Forum

olsen

Re: HD Formatting Problem

Posted on: 2007/4/3 8:35 #19

Just popping in

@voxel

Quote:

voxel wrote:
@Atheist

well

Recent hard drives doesn't need low level formating and should never be low level formated by users.

there is no "cancel" button on low level formating just because a canceled low level formating (by a cancel button pressed, rebooting the computer, or switch it off) will KILL the hard drive for good. simple.

It is impossible to restart a low level format on such a killed drive because it appears to have NO SECTORS and ZERO blocks.

Yikes, this doesn't make great sense, does it? New drives don't need to be low-level formatted because the techniques employed in recording information on them no longer makes low level formatting in the old manner (say, 15-20 years ago) necessary. And you couldn't do it if you wanted to anyway.

And a low-level format taking 1-2 weeks is very unlikely. If the disk controller really took control of the medium and did a low-level format (which it doesn't) it should be faster than that. Much of the time in formatting a drive is spent on transferring data between the computer storing the data and the drive.

My guess is that the missing cancel button, etc. for the process related above is due to the fact that the feature came late to the partitioning software and it's a chore to update the GUI.

And as for "aborting a low level format will kill your drive", I think that's a myth. First, you can't low level format a modern hard disk drive any more in the first place. Second, if you can't do that, then you can't abort the process. Third, if you can't abort it then you can't do damage to the drive.

Topic | Forum

olsen

Re: HD Formatting Problem

Posted on: 2007/4/2 14:05 #20

Just popping in

@Atheist

Quote:

Atheist wrote:
Some progress!

Some time between 11 am Sun. (9 days, 18 hrs) and 3 am Mon. (10 days, 10 hrs) the hard drive light stopped flickering and now I have the following on the screen:

A requester appeared and this is what it says.

Title of requester "Secure disk blank function"

Text of requester:
"Are you sure you want to perform a secure blank operation on the WHOLE disk? ALL your data will be permanently lost, beyond any possible repair operation."
"Yes" "No"

What should I do? I thought it WAS doing the formatting already?!

What you should do is complain about what the partitioning software asks you to confirm without giving much of a hint as what is going on, and why. Next thing, you should click on "No" unless you want to spend another 1-2 weeks waiting for the partitioning software to return control to you.

Quote:

It's a new disk, I don't have anything on there that will be lost.

Maybe not on the disk, but you already lost some ten days you're not likely to get back any time soon...

Topic | Forum

Top

(1) 2 »