Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: Os 3.2 development preview  (Read 53329 times)

0 Members and 1 Guest are viewing this topic.

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #270 on: November 23, 2019, 05:14:50 AM »
Is ROMWack back in 3.1.4?   Based on this info: https://theamigamuseum.com/amiga-kickstart-workbench-os/guru-meditation/, it was removed in 3.0?

Yes, it is back. SAD was not really useful...


I'm getting this hit in 3.1.4.1 -- is this one of things getting fixed?  Guru 8000 0004.   This is executing the Workbench Debug->Debugger menu item.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #271 on: November 23, 2019, 07:28:05 AM »
I'm getting this hit in 3.1.4.1 -- is this one of things getting fixed?  Guru 8000 0004.   This is executing the Workbench Debug->Debugger menu item.
That is exactly the problem I mentioned. The ROMWack assumes that the VBR is at 0, which it is not if MuForce or some other tool moved it. So, yes.

Offline kamelito

Re: Os 3.2 development preview
« Reply #272 on: November 23, 2019, 08:27:05 AM »
Is it possible to hook a PC instead of an Amiga over serial?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #273 on: November 23, 2019, 08:37:01 AM »
Is it possible to hook a PC instead of an Amiga over serial?
Yes, of course. You need a 21-pin to 9-pin adapter, and potentially an additional serial-to-USB adapter. Even more exotic combinations are possible. I used an Atari 800XL with a 850XL serial interface box as "debug terminal" for several years. COP has its own serial console protocol which was exactly the protocol the Atari 800XL terminal program ("DASB") spoke - this is why it looks so weird ("COP terminal type 3" = "DASB"). Only recently COP learned to speak VT110.

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #274 on: November 23, 2019, 08:46:47 AM »
More progress: Expansion.

There were still some interesting issues in expansion. In case a RAM-board was unsized and requested auto-sizing by the Os, the Os overwrote the last byte behind the indicated slot size and thus might have trashed another expansion sitting behind it. This was still an old bug from 3.x times of which I do not know when exactly it was made.

Another old bug was the A3000 superkickstart support. What this does is that the code attempts to check whether the MMU is active, and maps the upper 512K RAM to a kickstart image. If so, the A3000 expansion skips this memory region, and does not insert it into the memory list. Or at least, it attempted to do so. Due to a logic error, expansion tested the wrong bit in the MMU configuration register and thus tested the bit whether there is a supervisor MMU table present, and only performed the mapping *if not so*. Instead, it should have tested the MMU-enable bit, and perform the superkickstart logic only if this bit is *set* (not clear). This stole 512K for A3000 users using the mmu.library which does enable the MMU, and uses "supervisor" MMU tables. The 3.1.4.1 SetPatch installs a workaround to merge the upper 512K into the memory list in such cases, though 3.2 will fix the problem at its root. Again, an old bug that survived.

Then, another issue with file systems. Expansion configures file systems with 600 bytes of stack, which is a bit short. This increases now to 1024 bytes. Actually, it is more complicated that this: The stack size in the DosList structure is measured in bytes for C-style handlers, and in longwords for BCPL-style handlers. Thus, if expansion leaves there a "256", this is fine for BCPL style handlers (256*4=1024), but way, way, way too short for C-style handlers (256 bytes!). This problem was addressed in the dos.library and system-startup, though.
 
The following users thanked this post: Tygre

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #275 on: November 23, 2019, 04:05:33 PM »
For Ed, I've noticed default buffer size is 65496 bytes.   Previously, in "ED 2.0", it was 59960.  Documentation manual shows SIZE default as 40,000.   I'm just wondering if the "Buffer size" shown in the "About" menu (ESCsh) is same as SIZE parameter.

If I specify SIZE of 40,000, "Buffer size" shows up as 39960. 

This isn't something that I'm trying to report as bug a but just trying to understand...
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #276 on: November 23, 2019, 04:24:39 PM »
The default buffer size is 64K precisely (65536 bytes). Ed removes from that something it calls "SAVETYAREA", which is precisely 40 bytes large. Not quite clear what this is good for.

Offline kamelito

Re: Os 3.2 development preview
« Reply #277 on: November 23, 2019, 11:29:39 PM »
I remember Olsen writing about the CBM bug database are you also fixing those bugs?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #278 on: November 24, 2019, 08:58:14 AM »
I remember Olsen writing about the CBM bug database are you also fixing those bugs?

The bug database is only half as useful as it may seem. The problem is that it often relates to products we do not have, does not list methods how to reproduce, and (obviously) does not allow us to contact the persons that reported the bugs for reproduction. It also includes feature and improvement requests that are often not very reasonable.

For example, concerning the shell, I remember a feature request on "Execute" saying it should use shell variables instead of the bizarre pattern substitution Execute does nowadays. To give you some insight, if you write ".key foo" and then "echo <foo>" in a shell script, it is the Execute program that finds <foo> as pattern, and replaces it by the argument before feeding the result back into the shell - so despite the word, "Execute" does not execute anything, it only does argument substitution. Shell variables, such as $foo, are however substituted by the shell.

Now, the author of this bug report requests to clean up the mess, and use shell variables all the way.

What can we say? Yes, correct observation. Execute is, indeed, a mess. However, it doesn't help. There are too many Shell scripts in existence to allow such a radical change in the syntax and logic to make it worthwhile, so we did not. Instead, Execute received a renovation (actually, a rewrite) to understand numeric and multi-arguments, and to handle them correctly, while staying compatible with the syntax that grew historically.

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #279 on: November 24, 2019, 10:22:35 AM »
The next ROM component: Utility.

The utility.library contains several utility functions for tag lists, arithmetics, ID generation and so on. We haven't found any old or new bug in it, but extended its capabilities. One of the things that happened is that the long division functions (32/32 division) for the 68K processor were not very adequate as they used a rather slow "egyptian" division algorithm that generates its results by shifting and subtraction. Well, it works, but it is slow, so it was replaced by a better performing "Algorithm D" implementation by Knuth.

It is also weird that we do have a 32x32->64 multiplication, but no 64/32 division function in utility. The latter is, in fact, required by multiple Os components that handle large disk drives, so two functions for that were added, a signed and a unsigned quad-word division. For the 68020 to 68040, it uses the long division of the processors, for the 68000, a long Algorithm D implementation is used, and for the 68060, a similar algorithm D implementation as well as this processor lacks a 64 divide.

Utility also includes a set of new string functions. Strncpy() which is a length-limited string copy receiving a target buffer and a target buffer size. Unlike its ANSI counterpart strncpy, it always NUL-terminates its destination, and returns in case of success the pointer to the terminating NUL character for easy string concatenation, or NULL for buffer overflow, with a partial string then having been copied and terminated.

Strncat() concatenates strings into a length-limited buffer, using the same type of interface, and Snprintf() is a string-formatting function into a lenght-limited buffer on top of the exec RawDoFmt() function, quite similar to ANSI snprintf(), just that it returns the required buffer size, not the size of the result string. This helps to prevent the usual "off-by-one" error one typically runs into by confusing buffer sizes and string lengths.
 
The following users thanked this post: Tygre, SnkBitten

Offline kolla

Re: Os 3.2 development preview
« Reply #280 on: November 24, 2019, 11:34:26 AM »
Hm, so new functions... now it will be possible to write code that relies on this new utility.library, and hence on OS 3.2.

How clever is that?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #281 on: November 24, 2019, 11:43:10 AM »
How clever is that?
Extending an API in a backwards compatible way to make things simpler? About 9 on a scale from 0 to 10.

Offline kolla

Re: Os 3.2 development preview
« Reply #282 on: November 24, 2019, 12:56:20 PM »
So, when writing software one can...
- require OS 3.2
- check for version of utility.library and use those functions only when available, and use own custom code when not
- ignore new functions and use own code and rely strictly on what exists in pre-3.2 to make sure software runs equally well on anything OS3.

If you were a third party software developer, which would you go for?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #283 on: November 24, 2019, 01:06:17 PM »
So, when writing software one can...
- require OS 3.2
Yes.

- check for version of utility.library and use those functions only when available, and use own custom code when not
Or just fail if the library is not the minimum required version, yes.

- ignore new functions and use own code and rely strictly on what exists in pre-3.2 to make sure software runs equally well on anything OS3.
Yes.

If you were a third party software developer, which would you go for?
And why should that prevent us to offer new functions that are used by the Os itself at least?
I wonder how CBM ever managed to get Os 2.0 out of the door.

Offline CBH

Re: Os 3.2 development preview
« Reply #284 on: November 24, 2019, 01:41:08 PM »
I struggle to see the problem with correcting and extending the operating system in a backwards compatible way. Other than bugfixes, it's the entire point of making a new release.

It's definately better than the 3.5/3.9 approach of "here's some shit we downloaded off amibay, hope you have a thousand euros worth of upgrades to run it properly".