[meynaf]

Originally Posted by Thorham

True. Without JIT, UAE would be quite a bit slower. Not a problem, because it creates a substantial speedup, and it's perfectly acceptable for such aplications.

But even with that UAE is totally beaten up by real hardware in multitasking speed on the Amiga side...

Originally Posted by Thorham

Hmm, well yes, I guess my intuition sucks 'a little'

I too was very surprised when I discovered this. My debugger still doesn't work on 060

Originally Posted by Thorham

Ok, but I thought for moving a whole bunch of numbers around, then it makes no sense, or just not always.

It's the sort of instruction that you don't use often, I agree, but when you need it you happily use it. Yet I have no proof this won't work on 060 : my "move.l a7,-(a7) / move.l (a7)+,d0 / sub.l a7,d0" test failed on both 040 and 060 ! (you really get 0, not -4)

Originally Posted by Thorham

In this system frame, the functions which are added to make use of the frame, are to handle the error codes the frame returns. In the case of a file not existing, the added program can just call the frames exit function. Ultimately, the situation you describe is a programmers error. How much do you want automated, and more importantly, how much makes sense to automate?

It makes a lot of sense to automate, because 1) those are just too easily forgotten and 2) they're cumbersome, boring and repetitive code.
So, unless told otherwise, my own frame just aborts with an error message.

Originally Posted by Thorham

Haven't looked at it yet. But it sounds like they've just explained it in a bad way. Any alternatives?

Nope. No alternatives found. The only other references that I know of are (not very readable) code.

Originally Posted by Thorham

RTD? Nope. Looked it up in my 68000 book, but it's apparently 68020+. But link/unlk, yes. I've just forgotten about them, I guess. Time to use those in my frame instead, because they make more sense

Yeah, it's 020+, but it's not hard to simulate with a few 68000 instructions.
I can give you a small macro if you want. Now the callee will correct the SP, not the caller. Say, just rtd #4 in the callee rather than make the caller do an addq.l #4,a7.

Originally Posted by Thorham

Oh, they did? Not cooperative I hope? And yeah, msdos just plain sucks. Period And again, it's true. Os calls often don't need speed. Although I may have written this before, in witch case I , in my Os (written over ten years ago), I started out with passing registers to functions, and got in trouble real fast, because some of the functions required a relatively large amount of parameters. I then did a rewrite of the whole thing, and actually used link and unlk instead (why I forgot about those I don't know...). Using memory for parameter passing resulted in cleaner code in this case, so it's a method I've kept using.

Not cooperative AFAIK. And with memory protection :-)
Strangely enough I never had the problem of too many parameters to be put in registers, except for parameters given to printf-like calls, which simply takes them in the stack.
Can you give me an example of a function that would take lots of regs ?
About link/unlk I can't forget them right now, as there are a LOT of them in compiled code :-)

Side note : I think I'll start using ":-)" as smiley, because this 15 image limitation is driving me nuts !

Originally Posted by Thorham

I have! The reason for a hardware version if overcoming the chipmem limit. Simply copy some of the chipmem to fastmem, display the image, and afterwards copy the memory back, then restore the system. More times then I care to remember, have I had to close programs to simply show a picture because of running out of chipmem. Or worse, having to reboot. Although rebooting is fast, it's silly if you have to because of wanting to check some pictures In this case, that single advantage outweighs the disadvantages, especially since the program would be intended as a second viewer for cases where chipmem is running low (happens all the time, really).

I didn't think about that. Well, then. A viewer doesn't have to perform any i/o while displaying an image, just preload.
A good idea would be to add this as an option. Furthermore, it can allow to try this neat aga-sliced ham
Strangely I don't often run out of chip memory. Maybe you run some programs which eat too much.

Originally Posted by Thorham

Never had a problem with them for some reason

Sure. You don't have a resourced DM game to handle

Originally Posted by Thorham

Nope, it's not the patches. I've only replaced MCX with MCP very recently (about a month ago), and I doubt fblit and ftext have anything to do with it, either. The weird behavior happens when booting without a startup-sequnce, as well. Trust me, it's not the patches, so I still recommend you check out the mentioned programs

I checked MCP and it simply refused to work. Ok, I hate installers and tried it by hand

Originally Posted by Thorham

Hitting the hardware is not necessarily that dirty. Can't you allocate the audio channels with the os, and then write to the audio regs directly?

That's exactly what I'm doing !

Originally Posted by Thorham

I always write long posts such as this one in OpenOfficeWriter. I simply proof-read using the forum's preview function, and by the time I'm done correcting things, I can post the second half of the post.

I use the pre-view a lot, too.

Originally Posted by Thorham

Quite a shame, really. Msdos is great for the fact it can be killed.

Oh, you probably don't even have to "kill" it. Just do your hardware-banging stuff and it won't annoy you. Yet this way can probably only work on old machines, as gfx boards don't have any standard specs.

Originally Posted by Thorham

Oo is a great extension of structured programming. That's it's primary use to me. And think about, in assembler it's used, as well. A good example would be the linked list system in my sysframe. You have the list header structure, and you have a bunch of routines witch only act on that data structure, while at the same time, those routines are the only ones witch access that structure directly. In the frame, two such lists are made; a memlist and a filelist, so that there are two instances of the linkedlist object. The only difference with oo languages is that you don't define anything as actually being a class, while in essence, it's still object oriented.

Both the structuring capabilities (if not over used) and the fact that it can be common in assembler (!), leads me to believe oo is an essential addition to (at least) any structured language.

What you describe here is not oo and can easily be done without it.

Originally Posted by Thorham

Hehe, Chinese abacus Indeed, 68k is rediculous compared to 6502; it's almost a higher language if you compare the two And I know, because I've done a few simple intros on teh c64 in the old days. Haven't tried PPC, though.

68k rIdiculous compared to 6502, you probably meant the opposite

Originally Posted by Thorham

Do you have a problem with that? I certainly don't

Me, no. But the forum iself apparently has

Originally Posted by Thorham

Hehe, I've looked at that (thank you Wikipedia). Seems simple enough, and it's actually a good idea I never thought about that sort of thing, though, and didn't even knew it existed!

We learn things every day, pal.

Originally Posted by Thorham

A human does at the information level. The hardware that processes that information is probably just as clueless as a computer is.

Probably, but even at the information level the computer is still clueless.

Originally Posted by Thorham

Of course! But perhaps some things don't necessarily require brute force, while simply being very difficult to comprehend. For these tasks the human could prove to be the limit, where it would take a long time before someone came up with an efficient algorithmic approach.

If conscious thought takes billions of neurons to actually work, then it's probably not just a matter of algorithmics.

Originally Posted by Thorham

Maybe not (Sorry )

Maybe not. But if you throw a die, let alone several millions of them at once, even if you know physics you won't predict the result.