AmigaOS 3.2 and beyond

[pipper]

I think part of the success of 3.1.4 was the notion of making things better and removing bugs without additional cost. Power without the price so to speak ;-)
This made it very attractive to people with even base or moderately accelerated 68k Amigas.
On the other hand, the reason 3.9 never caught on seems to be that people perceived it as bloated and sluggish.

So my wish would be: implement new features in a way that they are either usable on humble machines or give people the option to opt out of things. Don’t make them pay (In terms of ram usage or performance) for features they may not use.
I guess this boils down to the question: what is are the minimum hardware requirements to settle on for 3.2

My personal wish is: better (remote) debugging facilities provided by the operating system. Bebbo implemented a GDBserver that works, but is rather limited. It would be great if exec could provide hooks and other debugging facilities (potentially utilizing the MMU) that make implementing a debugger much easier. Alternatively, the OS could come with a full gdbserver...

Thanks for the hard work!

[boemann]

Originally Posted by Ami

Why no love for standard non blinking block cursor?

First of all the non blinking block cursor was a necessity on old text terminals where you couldn't draw a line in between characters where the text is inserted.

Secondly a block signifies a selection and thus a block cursor could easily be misread as a single character selection. The block cursor is reserved for overwrite mode, where the cursor actually behaves like a 1 character selection all the time. (Overwrite mode is not implemented currently but there is plans for it mostly because the API has promised so for 20 years)

The blinking could strictly speaking be turned off with a setting, but it is important to be able to find the cursor easily with your eyes and blinking helps to that end. So I thought it was not worth the time to make such a setting, as most people will end up having it blinking in the end anyway.

I am aware some people like the block cursor (you being among them) but for most users it is more important to have a cursor with a meaning that is actually logical, and similar to what they work with on modern computers.

[Minuous]

Originally Posted by Ami

Why no love for standard non blinking block cursor?

The block cursor is used in replace (overwrite) mode.

what is are the minimum hardware requirements to settle on for 3.2

1Mb RAM, same as for OS3.1.4.

[th4t1guy]

I may be a bit out of the loop on this topic, but if you look at support.Hardware forum here, there are multiple stickies around getting CF cards to work, maxtransfer, filesystems, etc.
Are there any plans to make any of that process easier?

[gulliver]

@hUMUNGUs

We take all Amiga systems into account. We try to do our best not
to leave anyone behind.

AmigaOS 3.2 will work on any hardware/software combination that is
sufficiently smilar to an Amiga. There are no special provisions for
specific hardware other than what the known Commodore Amiga models
provided out of the box.

And speaking of the future, that really depends on you, the user. We
have some ideas that we collect as a team, but it is yet to soon to
elaborate on them since we have a more immediate task at hand: develop
and test AmigaOS 3.2. So that is why it is of paramount importance
that you have a saying in what are your likes and dislikes as a user,
because these will influence directly on desision making when the time
comes.

@utri007

We would love to help Chris. We need to support other developers. I
believe Olaf tried in the past to help him in some related matters.
Our hands are tied right now because we are very few, with a lot of
work ahead. But at least we now know, thanks to you, the situation
regarding NetSurf annd whom to approach.

@spudje

The AtapiMagic module was supplied by Thomas Richter in order to test
its compatibility on enabling 4 way ide interfaces. The result was not
what was expected, and while it worked on some systems, unfortunately
on others, like yours, it failed. We don't knowingly ship half working
components, as we are commited on quality. So, it is unlikely you will
see this component released, unless it gets seriously fixed. And
realistically I would not bet on that for the time being.

On the other hand, itt is funny that you mention those features,
because they were part of our internal conversations some time ago. I
will take note on those for review when the time comes to trace a path
beyond 3.2.

@th4t1guy

After some back and forth trying to solve this issue, fortunately
enough, the HDToolBox "max transfer" value is no longer required on
the built-in scsi.device driver of 3.2, and also on drive interfaces
made by the manufacturer formerly known as "GVP".

@pipper

We all agree with you to keep everyone on board, not leaving 68000
users behind is still our objective and we are succeding in that.

AmigaOS 3.2 will work on humble machines. The hardware requirements of
3.1.4 are the still much the same on 3.2.

[boemann]

Originally Posted by pipper

I think part of the success of 3.1.4 was the notion of making things better and removing bugs without additional cost. Power without the price so to speak ;-)
This made it very attractive to people with even base or moderately accelerated 68k Amigas.
On the other hand, the reason 3.9 never caught on seems to be that people perceived it as bloated and sluggish.

So my wish would be: implement new features in a way that they are either usable on humble machines or give people the option to opt out of things. Don’t make them pay (In terms of ram usage or performance) for features they may not use.
I guess this boils down to the question: what is are the minimum hardware requirements to settle on for 3.2

My personal wish is: better (remote) debugging facilities provided by the operating system. Bebbo implemented a GDBserver that works, but is rather limited. It would be great if exec could provide hooks and other debugging facilities (potentially utilizing the MMU) that make implementing a debugger much easier. Alternatively, the OS could come with a full gdbserver...

Thanks for the hard work!

Believe me we would like nothing better than to have good native debugging too.

As for speed and requirements. The current requirement is still only an 68000 and the TextEdit application have been tested on such a system to make sure it is usable. The memory requirement is to the best of my knowledge in the same ballpark as 3.1.4 and we intend to keep it like that. A harddisk is all but required like with 3.1.4, and the diskspace used will be a bit higher, but we are not talking bloat at all. And I'm speaking like a person who never wanted to use 3.9, so I sort of know where you come from. We have people happy with 3.9 in our ranks too, so all views are respected.

We murmured over this just the other day, and someone said that when 3.9 came out the thought was that new Amiga platforms would come and then those were the target. But today we want to make something for both the retro computers, as well as be there for the high end systems. So it is a different mindset.

[utri007]

You have now somebody to test/ develop CDTV version of it? Have you noticed this;

https://github.com/terriblefire/cdtv.device

[Daedalus]

Originally Posted by boemann

The syntax highlighters in this version purely coded in C and can not be customized. But for the future yeah my idea is create som sort of plugin system so third parties can created highlighteres usable in all editors. (which is part of the reason I don't want to do more highlighters for 3.2). Such third parties could then make them based on XML or very fast asm versions.

Sounds good!

As for the standard amiga modifers. No is the short answer. The slightly longer is that the Amiga is the only one still holding on to this non standard choice, and even Commodore recognized this back in 93 and were going to change it too. Many wordproccessors on the amiga also use the more modern and world standard modifiers. And this actually goes in line with the fact that shift acts as extended selection modifier in conjunction with the mouse even on the Amiga. That is why Commoodore wanted to fix this. And why I have changed it now. That said, at least inside the code there is a switch to change it.

Fair enough. To be fair, I really think there is no problem holding on to different paradigms if they're sensible and well established. After all, if we wanted everything the same as a modern system we'd be running Windows or Linux instead. For example, hidden application menus behind the right button is totally alien these days, but use an Amiga for 5 minutes and it quickly becomes second nature. But I think that those key shortcuts were (and still are in most parts of the OS) a nice, more flexible and more intuitive substitute for the keys missing on the standard Amiga keyboard, i.e. home, end, page up and page down. I still miss that flexibility all the time when using other systems, and would likely choose another editor for. Given that it's still there in the code, and that the Amiga keyboard layout lacks the buttons to roughly approximate the modern functional equivalent as it is implemented under Windows and Linux, if it was something that could be turned on in the GUI prefs for example, that would be good.

[eXeler0]

Is a new ROM 3.2 planned or is this a pure software update that runs off 3.1.4 ROMs?

[boemann]

Originally Posted by Daedalus

Sounds good!


Fair enough. To be fair, I really think there is no problem holding on to different paradigms if they're sensible and well established. After all, if we wanted everything the same as a modern system we'd be running Windows or Linux instead. For example, hidden application menus behind the right button is totally alien these days, but use an Amiga for 5 minutes and it quickly becomes second nature. But I think that those key shortcuts were (and still are in most parts of the OS) a nice, more flexible and more intuitive substitute for the keys missing on the standard Amiga keyboard, i.e. home, end, page up and page down. I still miss that flexibility all the time when using other systems, and would likely choose another editor for. Given that it's still there in the code, and that the Amiga keyboard layout lacks the buttons to roughly approximate the modern functional equivalent as it is implemented under Windows and Linux, if it was something that could be turned on in the GUI prefs for example, that would be good.

I better clarify that there are still modifiers for going to the end etc, they have just been changed so shift is for selection, alt is for smaller logical moves (words or page up/dnt )and ctrl is for extreme (end of line, end of document).

That does give me a headache for how to activate rectangular selections when I implement that because alt is the de facto standard for that and as you can see that is already used. Oh well it is the lesser used thing to do in a texteditor, so I will have to come up with something else.

[tom256]

Please add:
Installer:
-icons style selection during instalation(standard/GlowIcons).
Bootmenu:
-booting from CD
-possibility to disable CPU features (not only all cache)
-Amiga model/CPU/Memory recognition
Locale:
-polish locale

[fgh]

Keep up the awesome work guys!

I’d love fixes to the cdtv kickstart / extended rom to accept a500 cpu cards. See utri007’s post above. Stephen Leary and Toni Wilen did some work already.
(I have a spare working cdtv I can lend or sell cheaply to olaf or thor if interested)


Adding features for casual retro gamers will greatly improve sales. And what they struggle with the most are prepping/formatting CF/SD cards, and transferring files to the amiga, so anything that can help those two would be nice.
Perhaps these could be possible?

1: compactflash.device bundled (fat95 or crossdos)

2: Bootable pcmcia cf/sd cards. (even better: Bootable with fat format)

3: Feature in hdtoolbox to create one FAT partition after the amiga partitions, to allow access on pc/mac. (Amiga files on FAT gives problems with file attributes, but there could be a warning/disclaimer at least. Plus it might need an MBR, which has to be in front of the RDB)

4: Minimal beginner friendly file transfer tool for serial to usb with tiny matching pc app.

5: More beginner friendly HDtoolbox

6: Small button to toggle view all/only icons in window frame somewhere

[demon-knight]

Will the CD32 get any love this time as it missed out on 3.1.2?

[Hewitson]

You may want to reconsider calling it TextEdit. I don't think Apple will like that.

[Minuous]

@demon-knight:

No, for the same reason as for OS3.1.4: https://www.hyperion-entertainment.c...amigaos-update

@Hewitson:

I don't see how Apple or anyone could have rights over that name; it is a generic functional name. Just like the "Copy", "Delete", etc. commands.

[demon-knight]

Originally Posted by Minuous

@demon-knight:

No, for the same reason as for OS3.1.4: https://www.hyperion-entertainment.c...amigaos-update

@Hewitson:

I don't see how Apple or anyone could have rights over that name; it is a generic functional name. Just like the "Copy", "Delete", etc. commands.

No worries, just wondered if anything had changed.

[Olaf Barthel]

Originally Posted by utri007

Great idee and EAB is right place for that This site is moderated.

As there is a lots of co-operation with OS4 devs could you maybe help a bit Chris Young his OS4 backport of Netsurf? It has some problems now with diskhandling and it has lost 90% of it's speed.

90%? Yikes. I thought that the updated memory management system I built into my clib2 'C' runtime library specifically for NetSurf should make a difference. While I do not know the details, the availability of a current clib2 build for 68k might be the cause of the problems with the 68k version.

[Olaf Barthel]

Originally Posted by utri007

You have now somebody to test/ develop CDTV version of it? Have you noticed this;

https://github.com/terriblefire/cdtv.device

CTDV support, as well as CD32 support, given how thin we are currently spread, are not a focus at the moment.

Access to real hardware for testing and those knowledgeable in how the hardware was modded are another challenge. Also, we can't really build the kind of ROMs which would be needed.

The question of whether we are authorized to reuse CDTV and CD32 code aside for a moment, we currently lack the necessary knowledge to do CDTV or CD32 versions justice.

[Tigerskunk]

Originally Posted by boemann

So I am a developer on AmigaOS 3.2. And I'd like to talk about some of the new stuff I've been working on. In 3.2 we have the reaction classes, and we as a group have been working hard on polishing and bugfixing them. The class I've been mostly concentrating on is the texteditor.gadget.

It is almost a complete texteditor in a single gadget. In 3.9 it is housed in EditPad, but for 3.2 I've also created a whole new editor called TextEdit. A lot of the features I've done will be available in EditPad and other places it is used. But TextEdit has a few more tricks up it's sleeve.

In list form the texteditor.gadget has recieved the following fixes and new features:
- scrollwheel mouse support (also horizontally if your mouse supports it)
- extended keyboard support (like page up and down for keyboards that have those keys)
- complete standard selection of text. (shift acts as a selection modifier when you click with mouse or use cursor keys)
- After you have selected you can click inside and then drag-move the text elsewhere in the document.
- many many smaller bug fixes
- much improved and endless amount of undo redo history
- a framework for applications to do syntax highlighting
- cursor is an I beam and it blinks to make it easier to spot
- both line wrapping and endless lines possible
- framework for doing incremental search and highlighting all hits
- support for TABs as TABs and not just converted to spaces
In short it does like you expect of a modern editor (and it is still usable on a basic 68000)

The new TextEdit application uses this gadget, and thus gains all of the above but also uses some of the gadget's new frameworks to provide some nice new features:
- incremental search and replace
- ARexx syntax highlighter
- shell script syntax highlighter

If people have further wishes or ideas I'd like to hear them so if times allow it can be done (no more highlighters in this release though)

And there is also still known bugs from earlier versions that will most likely not be fixed in this release, but naturally isn't forgotten either.

Ideas (but probably not in 3.2):
- framework for showing linenumbers
- rectangular selections
- C syntax highlighter
- assembler syntax highlighter
- installer syntax highlighter
- amigaguide syntax highlighter
- multi document tabbed interface in TextEdit
- an ARexx port

That's amazing, dude...
Thanks for the what must have been huge amount of work you put into this...

[Olaf Barthel]

Originally Posted by demon-knight

Will the CD32 get any love this time as it missed out on 3.1.2?

What, specifically, is in need of attention?