new os3.x software ?

[utri007]

Gulliver: SDL sucks it works nice with 64mb memory. I ques that 128mb is for UEA users whom want to watch videos etc from youtube

[kolla]

Gulliver: SDL sucks it works nice with 64mb memory. I ques that 128mb is for UEA users whom want to watch videos etc from youtube

You want to watch videos of them on youtube? :hammer:

[lionstorm]

and dont forget that Netsurf currently lacks javascript !
an updated version of AWeb would be nice but dont forget that someone is still working on a CSS browser for all amigaos flavors (Merlin browser http://home.kpn.nl/spijk336/browser/home.html ) and there is also an incomplete webbrowser named Paihia and its author was willing to share the sourcecode to whoever was interested ( http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=22649&forum=15#386963 ).

[Tumbleweed]

The problem with Netsurf is that the current Amiga port is really bloated, it requires 128Mb of ram and may work with 64MB. The original, still being developed RiscOS version only requires 16MB. So either RiscOS is much better than AmigaOS, or the port simply sucks.
Bottomline, I would choose another browser to work on. I have said it sometime ago, there is an excellent candidate that will work with 68000 and a few MB of fastmem. It is opensource, and is working with CSS. It has a small group of developers coding on it.
It is called HighWire, and is an Atari application.


http://highwire.atari-users.net/

What's needed to run this on an Amiga?

Weed

[matthey]

Can do you it the other way around as well?
My minimig craves for it. :hammer:

68020 code can be made to work on the 68000 but it is much more difficult. Code has to be added to support missing instructions for example. The 68k is forward compatible but not backward. From 68000 to 68020 is mostly just deletion and some minor optimizations. Vasm performs many of the optimizations for me on reassembly. It's still possible to do 68020 to 68000. If there isn't many 68020 instructions it can be trivial. It's easy to miss things like the scale factor not being used on the 68000 though. I am really wanting to do a 68020+ for the new BoingBag updates and Natami right now. You might try learning assembler to do the modifications yourself. I really wanted a good disassembler with floating point support. I had never done a program bigger than hello world in C but now I have ADis working well enough to reassemble libraries. You also now have the tool I created to help you. You see how this works .

[Gulliver]

Gulliver: SDL sucks it works nice with 64mb memory. I ques that 128mb is for UEA users whom want to watch videos etc from youtube

It doesnt work nice with 64MB, and i am not even thinking on Youtube videos. I have an Amiga 68040 @50 mhz + 64MB and an RTG card + a fast ethernet card, and let me tell you that if I simply use Netsurf and go to http://www.yahoo.com Then my memory simply evaporates to about 10 MB! So 64MB is barely enough for that browser, and keep in my mind that I am using only one open browser window, and that when you try to switch to another website, during the slow process load, you arent even able to move your mouse pointer (Goodbye multitasking).
If you dont believe me, try it under WinUAE, and you will experience the same thing!
Bottomline: Netsurf is better than nothing on Amiga 68k, but it is not really usefull, unless you have a 060, 128MB and a GFX card. So I wouldnt loose time on it.

IBrowse on the other hand, is A LOT faster, and uses very little fastmem. The sad part as you all know, is that it doesnt support CSS and that development and commercial availability have been non existant for a while

[kolla]

Yes yes yes, a css capable browser for 3.x would be nice, but it's now been more than 10 years of no go, and the demand today is a heck lot less than what it has ever been, with css-capable browsers for all the Amiga OS spin-offs. Why not concentrate on something usefull the 3.x systems can actually do instead of wasting so much time and energy on browsers that hardly will be usable for much anyways?

[kolla]

68020 code can be made to work on the 68000 but it is much more difficult. Code has to be added to support missing instructions for example. The 68k is forward compatible but not backward. From 68000 to 68020 is mostly just deletion and some minor optimizations. Vasm performs many of the optimizations for me on reassembly. It's still possible to do 68020 to 68000. If there isn't many 68020 instructions it can be trivial. It's easy to miss things like the scale factor not being used on the 68000 though.

Yes, I'm aware of differences, and as you say, going from 68000 to 68020+ is much easier that the other way around, that's one of the reasons I dont quite like the trend of dumping 68000 for marginal gains. If at some point in the future you might want/need 68000 compatibility again, it's just so much more work.

And why code for 68000 instead of 68020? Well, first of all Freescale still offers a whole range of cheap 68000 chips that might be used in various minimig incarnations. This is not the case for 68020+ chips, they are mostly out of production, or very expencive.

Secondly there are several 68000 softcore options for FPGA, and as of yet, no 68020 one that I am aware or. The 68000 softcores are already faster than any 68020 was, I dont know how much of a speed gain a 68020 softcore will have over a 68000 softcore or a real 68000 chip. Anyone?

Sure, keep on optimizing for 020+, but please just don't leave 68000 code behind, and please pretty please mark the binaries with what the CPU requirements are, so that "version full" shows it clearly, I have wasted quite a bit of time with programs and libraries that just crashed out of the blue when updating from one version to the next, without any mention of any 020+ optimization in the changelogs.

I am really wanting to do a 68020+ for the new BoingBag updates and Natami right now. You might try learning assembler to do the modifications yourself. I really wanted a good disassembler with floating point support. I had never done a program bigger than hello world in C but now I have ADis working well enough to reassemble libraries. You also now have the tool I created to help you. You see how this works .

You are absolutely correct, I should engage myself more in this.  I have played around with various asm sources I've found, changed and compiled, tested, crashed, changed more, compiled again, tested, crashed again etc... :laughing:

What I never managed to wrap my head around though, is disassembling, so any tool and help in that regard is most welcome

[Rebel-CD32]

I agree with Kolla. While having a web browser that works on more websites would be nice, I think there are more important things to focus on, like a new picture.datatype. A bounty to have IBrowse open-sourced might work, if someone wants to dedicate themselves to writing a CSS engine for it. But then again we do have Merlin, which could evolve into quite a usable browser and already works on systems that OWB and Netsurf wouldn't have a chance of running on.

I also agree with Cammy, if we're going to get these games finished we need somewhere to discuss and work on them, just like our old Underground Arcade forum, and if it was IBrowse compatible it'd be a huge bonus since I could pixel in Personal Paint, chat in WookieChat, and keep an eye on the development forum all from my A1200, which is my system of choice above anything else.

Also, on the topic of 68000 and 020+ code, after seeing how well Workbench and those AGA games run on a fast 68000 softcore, I think it's really important to keep developing 68k and 020+ binaries so these newer Amiga-compatible systems will run them (and run them faster than a 020 would anyway).

I'll always be here, willing to work on any classic Amiga software. I'm only a pixel artist but Amiga applications and games still need graphics.

[matthey]

@kolla
The gains in optimizing for the 68020+ is significant in some cases. It's also easier for an assembler programmer. It's almost as easy to make a 68000 version for a compiled program. I still like to see cpu optimized versions of compiled programs but the trend is not too. It's probably because it doesn't matter much for UAE. I can compile you a 68000 version of ADis if you want to try it. The tricky part about the 68000 is that it only allows byte accesses to odd addresses. It's hard to be 100% sure of this even with testing. It also makes some programs very difficult to modify from 68020->68000.

[Gulliver]

Yes, I'm aware of differences, and as you say, going from 68000 to 68020+ is much easier that the other way around, that's one of the reasons I dont quite like the trend of dumping 68000 for marginal gains. If at some point in the future you might want/need 68000 compatibility again, it's just so much more work.

And why code for 68000 instead of 68020? Well, first of all Freescale still offers a whole range of cheap 68000 chips that might be used in various minimig incarnations. This is not the case for 68020+ chips, they are mostly out of production, or very expencive.

Secondly there are several 68000 softcore options for FPGA, and as of yet, no 68020 one that I am aware or. The 68000 softcores are already faster than any 68020 was, I dont know how much of a speed gain a 68020 softcore will have over a 68000 softcore or a real 68000 chip. Anyone?

Sure, keep on optimizing for 020+, but please just don't leave 68000 code behind, and please pretty please mark the binaries with what the CPU requirements are, so that "version full" shows it clearly, I have wasted quite a bit of time with programs and libraries that just crashed out of the blue when updating from one version to the next, without any mention of any 020+ optimization in the changelogs.



You are absolutely correct, I should engage myself more in this.  I have played around with various asm sources I've found, changed and compiled, tested, crashed, changed more, compiled again, tested, crashed again etc... :laughing:

What I never managed to wrap my head around though, is disassembling, so any tool and help in that regard is most welcome

Really interesting...

And following that concept:
Do any of you know of an assembler & dissasembler that can work nicely together and that that its compiler/linker can generate optimized binaries for 020/30/40/60 FPU and non FPU?

[asymetrix]

This is an interesting thread.

I think we need an uptodate assembler environment, with time have lots of examples and tutorials that work 100%.
A 68k assembler editor with code folding etc - nice
A no fuss installation.

Having a sticky thread that updates info, suggestions etc would be great. The aim to recreate the 68k developer base and educate the next generation of Amiga coders.

[DavidF215]

@fishy_fiz (initial post)

Great things can come from boredom thinking. Good question. I was actually porting some of my game code into AmigaForever when I came across the bridge of wanting to be cross platform friendly. Long story short I ended up landing on SDL/OpenGL, and now working my way in that direction. Amiga has SDL but, by what I've read in this thread, it's not very good, and I'm not sure if the OpenGL calls in Amiga-SDL work with Warp3D (anyone know?). I also discovered that the Amiga compiler I was using didn't like BOOL types; weird. I use AmiDevCPP now. My games are 2D (except one) but I want OpenGL since 2D can be rendered faster on 3D objects (rects) with 3D hardware. My [Windows] games can be found at whitesaber.com.

As far as what to make, I would say 2D games and a web browser. I don't use AmigaForever much because it doesn't have a web browser that doesn't crash a lot. I was using it when I was attempting to program in a classic Amiga environment. On the other hand, I might use it more if it had more modern games or the ability to code cross platform friendly code in OS3.x.

I would think that the user base for UAE is pretty decent. AmigaForever continues to have new releases, so it must be making adequate sales to justify updates and newer versions.

[matthey]

@DavidF215
I'm pretty sure bernd_afa's SDL uses Warp3D. It works well but it's still slow because SDL can only work in a few graphics formats. Many SDL programs also use ixemul which is also slow. These are usually coded with GCC which doesn't optimize well. Get the picture?

[matthey]

Really interesting...

And following that concept:
Do any of you know of an assembler & dissasembler that can work nicely together and that that its compiler/linker can generate optimized binaries for 020/30/40/60 FPU and non FPU?

ADis and vasm work well together as do IRA and vasm. Most of the time, a program can be disassembled and reassembled without errors. The biggest key is removing instruction errors from the disassembler and assembler. This is what I have been testing for and Frank Wille and I fixing. Vasm optimizes and will usually save several hundred bytes by simply disassembling and reassembling. However, an experienced assembler programmer (me should look for mistakes and do further optimizations. I can remove dead code, do a better job than patch020 for integer math routines while recovering space, and switch to faster memory copy routines while saving space again. It is still possible to make mistakes or have a problem with disassembled code. It is especially difficult to tell a small amount of code from text or data. Much testing should be done.

Vasm does some optimizations based on the CPU (and FPU) selected but not much. There is not much to be gained here unlike optimizing for a CPU with a compiler. Most OS components do not use the fpu at all. Using the fpu is almost always slower than using integer routines.

I should have some libraries for you to start testing before long. They are datatypes.library and diskfont.library. I chose these 2 because they are small, relatively easy and usually resident in memory so will save ram. I have finished my preliminary testing of ADis and Vasm for errors and I'm working on Warp3D libraries 1st. I am learning as I go. I'm still not 100% sure I can produce error free enough reassemblies with optimizations to distribute but I should know within the next few weeks.

[Gulliver]

@matthey
Thank you for your answer, that was really what i was looking for. I am waiting for a little vacation and will tinker with those a bit

I will ansiously wait for your datatypes.library and diskfont.library optimized versions.