AmigaOS 3.2 and beyond

[Thomas Richter]

Originally Posted by boemann

In texteditor.gadget there has been this unimplemented API for style (bold, italic, underline, and textcolor), but not different fonts.

Can any of you think of a use case where you would use the gadget for editing rich text (not font or images, but only style)

Not really, unless you use the gadget as the basis for a full-fledged editor, and the feature would be used for example for syntax highlighting. But this would then reqiure a plug-in syntax parser, and is too much and too heavy for an Os component. I would leave such things to third parties.

[boemann]

Originally Posted by Thomas Richter

Not really, unless you use the gadget as the basis for a full-fledged editor, and the feature would be used for example for syntax highlighting. But this would then reqiure a plug-in syntax parser, and is too much and too heavy for an Os component. I would leave such things to third parties.

as for highlighting it is already there, via a hook so the rendering of the bold underline and colors are already there. But these attributes are temporary in nature and only under control of the hook. It is up to that hook to do any kind of syntax parsing.

My question was more of the wordproccessing kind of attributes where you assign bold to a word you as a writer wants to emphasize. As it uses the same rendering code it can already draw it but before i spend more time (and code size) on the editing part I was wondering how useful it is. Implementing it is not that much work, but right now i was just wondering if it would be better to deprecate it completely.

[boemann]

Originally Posted by Warty

Maybe to make a pseudo-WYSIWYG AmigaGuide editor? Or more generally, a code editor with syntax highlighting?

Build it and they will come?

So yes i guess pseudo-WYSIWYG amigaguide editor would be somewhat possible, whereas just explained syntax highlighting is already possible via a hook. (the hook i use in the TextEdit program)

[Don_Adan]

Idea for Amiga OS 3.3.
I dont know if it was already mentioned, but adding support for DATA/STORAGE ONLY memory from $8000000 to $FFFFFFFF, via extending (new D1 value) current Alloc/Free memory LVOs or via adding 2 new LVOs to exec, AllocDataMem and FreeDataMem. Wasting 2GB of possible memory is not very good.

[kamelito]

And also out of the box FUNCDEF macro and avoid ASM dev to have to use this.
http://aminet.net/package/dev/asm/incupd
All necessary includes and macro should be in the NDK and usable without having to do xyz

[boemann]

Originally Posted by kamelito

And also out of the box FUNCDEF macro and avoid ASM dev to have to use this.
http://aminet.net/package/dev/asm/incupd
All necessary includes and macro should be in the NDK and usable without having to do xyz

We certainly aim to make the NDK as complete as possible

[kamelito]

What would be really nice is to have debug versions of the KS and libraries that verify that the parameters used to call a function are valid among other things. That would help find and fix bug easier no?

[Thomas Richter]

Originally Posted by kamelito

What would be really nice is to have debug versions of the KS and libraries that verify that the parameters used to call a function are valid among other things. That would help find and fix bug easier no?

Exists. PatchWork:


http://aminet.net/dev/debug/PatchWork.lha

[kamelito]

Nice thanks didn’t knew about this but it is stated to be incomplete and it is not maintained anymore so it will not be of any use for not supported Libs and newer version of AmigaOS.
I know that AmigaOS 4 provide a debug kernel don’t know about other libs.

[kamelito]

In Orlando Devcon doc it is written that SAD should have been set to the NMI vector but wasn’t due to some Amiga models having HW issues. Is this fixable and so provide such functionality in the OS?

[Thomas Richter]

No, it's not fixable, it's a hardware issue. I had such a board. The "best possible" replacement I can offer is the "break" hot-key of COP (typically mapped to the "."-key on the numeric key pad). Of course, this interrupt can be blocked.

[kamelito]

Isn't it possible to check the board and does not set it if it's xyz and set it if the board is not having HW issue?
A replacement is better than nothing.

[Thomas Richter]

Which problem do you want to solve, actually?

[kamelito]

Originally Posted by Thomas Richter

Which problem do you want to solve, actually?

I like the idea of having a cartridge like functionnality built in the OS.
The idea is to bebug program that crash the system.
I know about COP, or KnightRider even Adebug.
About COP the keyboard routine is not working well on accelerated Amiga, tested under WinUAE , I just type one letter and many more are displayed making it unusable.

What would be nice to is instead of showing a system failure requester we could just to a low level debuger instead. If the system is still responsive you could add a button to the software failure requester, if it's done jump to the debugger with call to system displayed using symbols like what does Adebug.

https://github.com/dverite/adebug-amiga

[Hedeon]

Originally Posted by kamelito

About COP the keyboard routine is not working well on accelerated Amiga, tested under WinUAE , I just type one letter and many more are displayed making it unusable.

Seems to work almost flawless on my accelerated real Amigas. Except that going out of COP sometimes make some of the following keys stick (ctrl, alt, shift, amiga keys). I press em all and then it is solved.

[kamelito]

under winuae I use others low level debugger older than COP that do not have issue, so I guess that the code handling the keyboard could be improved IMHO.

[jbenam]

Originally Posted by Thomas Richter

However, to give you a tentative estimate, a release this year is highly likely.

I guess this is not that likely anymore, right?

I was holding off formatting my A4000 in the hopes that 3.2 would be out soon, but that doesn't seem to be the case now

[Minuous]

@jbenam:

That statement was regarding P96, not OS3.2.

[jbenam]

Originally Posted by Minuous

@jbenam:

That statement was regarding P96, not OS3.2.

Whoops, my bad. Thanks for your reply.

Time to format, then

[Thomas Richter]

Originally Posted by kamelito

under winuae I use others low level debugger older than COP that do not have issue, so I guess that the code handling the keyboard could be improved IMHO.

It is not at all related to that. It is really related to execution speed. COP gets its timing from the host CPU and the CIAs, so everything is fine on a real system. On an emulated system, a loop is executed at 100x times the native speed if not more, and then the timing is completely off and keyboard repeat kicks in much earlier than on the real system. The problem goes away if you adjust the execution speed of the emulator.