@NutsAboutAmiga

No, I'm writing about managing an emulator on a system using extended (beyond address space) memory. The emulator has to know that there is EMS to use it.

@cymru

A emulator works a bit like the Rosetta stone, the emulated OS speaks one language, and the host OS speaks another langauge.

Its the emulator that is responsible to translate between the two systems.

The emulated OS does not know what EMO is, the host OS knows what EMO is, if you did make the emulator understand EMO, then there wont be any emulated programs to take advantage of it, how ever the emulator is just a program that runs on the host OS, it can make use of EMO, and it can do so whit out the emulated OS knowing.

Quote:

and that is not just changing a pointer;

All memory translations are handled by memory emulation in Basilisk, you only need to change this code.
And do some minor changes here and there, its not a big issue.

The question is not if its possible to use EMO the question is if its worth it, how fast it is, does it need many operations or can we do it in one.

By using EMO we only manage to move Basilisk memory out of the 4Gbyte sone to free some critical memory space (32bit memory space), but if the speed is going to be crap then EMO is not be worth the effort for basilisk.

The emulated 32bit OS does not get 64bit just because we use EMO in the emulator, nor does it get virtual memory unless you emulate the 680x0 MMU.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

I have degree in computer science and programmed on teams in grad school, so thank you for your tendered explanation; be sure to check your spelling, grammar and punctuation when you turn in your assignment.

@cymru

Quote:

be sure to check your spelling, grammar and punctuation when you turn in your assignment.

Thank for reminding me about my dyslexia.

I know basilisk code well I have worked on that code for years.

Last edited by NutsAboutAmiga on 23-May-2014 at 05:00 AM.
Last edited by NutsAboutAmiga on 23-May-2014 at 04:58 AM.
Last edited by NutsAboutAmiga on 23-May-2014 at 03:44 AM.
Last edited by NutsAboutAmiga on 23-May-2014 at 03:42 AM.
Last edited by NutsAboutAmiga on 23-May-2014 at 03:38 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@cymru

I have a degree in computer science and have programmed for teams in graduate school. Thank you for your tendered explanation. Be sure to check your spelling, grammar, and punctuation when you turn in your assignment.

Now proofread by me, an English teacher,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

@cymru

Quote:

No, I'm writing about managing an emulator on a system using extended (beyond address space) memory.

Sorry but I don't think you have a clue, taking about committees and senior managers and so on.

Quote:

The emulator has to know that there is EMS to use it.

Its called Extended Memory Object (EMO), its not EMS.
Well a emulator does not write it self, some one needs to actually write code that use EMO.

Faceplam.

Quote:

I have degree in computer science and programmed on teams in grad school.

do you really.

Last edited by NutsAboutAmiga on 23-May-2014 at 04:59 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

So it basically some thing like: #define readmem_long(addr,value) *((ULONG *) (Baseaddr + addr)) = value #define writemem_long(addr,value) value = *((ULONG *) (Baseaddr + addr));

Better stick with "something like" that, rather than precisely that :)

(To be reasonably safe in defining these function-like macros, you'd want to add a whole bunch of parentheses and a few more casts; But more importantly, you probably want to change it so that "writemem_long(100,2)" is valid and "readmem_long(100,2)" is not...)

@umisef

Quote:

Better stick with "something like" that, rather than precisely that :)

Shore you go a head and nitpick about my spelling, and about no casting and missing “;” at end of macro that not even you did notice. As it is not accrual code it should not matter, Its just a bl**dy example.

The point I was trying to make before some (edited by moderator to remove personal insults) wanted to start a argument, is that way Basilisk is organized makes totally possible and easy to change the way memory is emulated with in Basilisk.

And should I repeat my self, again I should point at that all memory access happens by calling a macro or function whit in UAE cpu core.

Moderator warning to ALL members; do NOT get personal and throw out insults in these forums. Take it to PM's or private emails if you feel compelled to attack someone, but don't do it here. Take a deep breath and remember this forum and using our Amiga systems (and all variants) is just for fun. No one is making their living from using, or programming for our systems any more, and none of you are finding the cure to Cancer on an Amiga, are you?

Last edited by amigadave on 25-May-2014 at 07:29 PM.
Last edited by NutsAboutAmiga on 25-May-2014 at 05:12 PM.
Last edited by NutsAboutAmiga on 25-May-2014 at 04:39 PM.
Last edited by NutsAboutAmiga on 25-May-2014 at 04:35 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hyperionmp

Well done!

If I understand correctly, 1.5 GB is now like Conventional memory and rest like EMS in MSDOS?

What ammount of memory will show WB title or avail command?

@Thread,

Can someone, in a short description, tell me how Chip/Graphics mem was kept separate from Sys mem on a classic?

Chris

@QuikSanz

As far as I know, the memory is one continuous block.
But when OS knows where certain memory area starts, it can prioritice what memory is used first etc.
http://www.ntrautanen.fi/computers/hardware/misc/amiga_memory.htm
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00D4.html
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00D2.html
http://en.wikipedia.org/wiki/Amiga_Zorro_III


In general, fastest memory is used first, slowest last. For now I do not know how it is told to force certain reservations...

(I have not yet programmed for classic amiga other than scripts, so surely someone explains better...)

Last edited by KimmoK on 25-May-2014 at 08:07 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK,

My thoughts on this are, If there was another memory controller we could Have a 4Gb chunk dedicated to graphics card and other. So lets say you have 2 Gb graphics card, you could then add 2 more Gb to use as Clipboard/Ram disk thus leaving all 4 Gb system memory alone.

Probability=0, wont hold my breath.

Chris

@QuikSanz

Sure you could !! Just without actually useing it ......

All Amiga-GFX API rely on some level on the system and the app to share addresses.

Parts of the system also keep track of all things GFX over all tasks.

So without breaking things your back to keep all GFX at the same fixed address for all tasks and within the 1st 2GB.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @QuikSanz Sure you could !! Just without actually useing it ...... All Amiga-GFX API rely on some level on the system and the app to share addresses. Parts of the system also keep track of all things GFX over all tasks. So without breaking things your back to keep all GFX at the same fixed address for all tasks and within the 1st 2GB.

So since the OS can keep track of all things graphic it can be altered slightly to send Graphics to Bank "B instead of "A".

Chris

@QuikSanz

Breaking every app written before that API-change happened....

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@NutsAboutAmiga

Quote:

wanted to start a argument

Chill, dude! Nobody wanted to start an argument. I just wanted to share the slight chuckle I got out of the fact that your readmem_long() macro writes to memory, whereas you writemem_long function reads from it. You know, in a friendly "we have all been there, done that" kind of way....

That being said, I just can't let the following go uncommented:

Quote:

missing “;” at end of macro

You should never ever put a semicolon at the end of the definition of a function-like macro. The reason being that a macro definition is not a C statement, but rather a preprocessor directive; And the preprocessor will not consume that semicolon, but rather include it, literally, in the expansion of the macro later on.

Thus, if you have "#define foo(x,y) (x)+=(y)*(y);" (note the semicolon) and then try "if (a&1) foo(odds,a); else foo(evens,a);", this expands to "if (a&1) (odds)+=(a)*(a);; else (evens)+=(a)*(a);;". Which will cause the compiler to produce a rather confusing error message about there being an "else" without an "if", due to the double-semicolons.
Similarly, if the function-like macro is "returning a value" (i.e. expands to a non-void expression), a trailing semicolon breaks things. E.g. "#define square(x) ((x)*(x));" makes it impossible to write "c=sqrt(square(a)+square(b));", leading once again to a rather unhelpful error message --- which I know from painful experience, having been bitten by a bunch of thus-broken definitions in a commercial Zigbee stack just a couple of weeks ago :)

(On a somewhat more subtle note, I am also not fond, especially in pure C programs, of function-like macros which treat one or more of their arguments as lvalues, i.e. change them. The reason here being that usage of that macro then might *look* like a function call, but it actually does things a function couldn't possibly do --- namely change the value of variables in the "caller" event though the "caller" never took a pointer to those variables).

Quote:

all memory access happens by calling a macro or function whit in UAE cpu core

Until you want to use the JIT with "direct_access" enabled. Which is highly likely if you are running something in the emulator which needs hundreds of megabytes of memory.

But even if every access *did* go through a function, trying to stash away, say, a gigabyte of emulated Mac memory in an EMO with, say, a 128MB window in the Amiga address space would require something like this as part of every single memory access:
[code]
if ((address&highBitMask)!=currentHighBitMask)
{
unmap_EMO(currentHighBitMask);
currentHighBitMask=(address&highBitMask);
map_EMO(currentHighBitMask);
}
address&=lowBitMask;
//...accessing memory at offset "address" in the address window goes here
[/code] (yeah, I know this doesn't work at AWN...)

Even if that first "if" happens to be almost always false, just having to make the comparison for every single access will slow things down. And once you actually start using that gigabyte of Mac memory (which, presumably, you will do, because what's the point of having it otherwise?), you'd end up asking the OS to change MMU setup quite frequently. And that is anything but a fast operation.

So no, emulators are not really good candidates for being EMO'ed.

Last edited by umisef on 26-May-2014 at 02:48 PM.

@Kronos,

Seems as though great minds think alike.

"Rogue
Another example is mapping a large graphics card area. Right now, you are limited to the size of the PCI address space; graphics card drivers will make sure the right stuff is copied in the right addresses. However, ExtMem could be used to access the memory directly for cards capable of 64 bit PCI access, which would be interesting for things like Compute shaders that might need to work on a large dataset."

We shall see. Sorry Kronos, you need to expand your thinking.

Chris

Last edited by QuikSanz on 26-May-2014 at 07:10 PM.

@umisef

Quote:

Until you want to use the JIT with "direct_access" enabled.

Yes depends on how Álmos Rajnai did the micro blocks for powerpc jit, I have not looked at the code yet.

(Memorybase + mac_address) will always apply, if its written in c or powerpc assembly language, but I guess if its assembly language it will not be that easy, but I think it might be, because memory emulation in EUAE is more complicated, it should be possible to do the same.

“direct_access” does not work on AmigaOS4 because prepareemu does not work anymore.

Quote:

a 128MB window in the Amiga address space would require something like this as part of every single memory access:

Well the idea was to map the memory once and keep the memory window until I was done whit it.

Hans-Joerg made a comment.

http://www.amigans.net/modules/xforum/viewtopic.php?post_id=91207#forumpost91207

Quote:

2) Currently, nothing enforces sharability of the memory, since there is no per-task MMU setup yet.

Basically I can't keep the EMO mapped forever like I want to because it will block other task from using that address space, so I most unmap after etch write as you say.

Quote:

Right now the rule is that tasks and sub-tasks can share the memory.

On the other hand it does enable child process to access to the same memory like I want it to, so sound/video/Ethernet emulation has access to the same memory.

So in other words it is possible, but its useless to implement some thing like this in Basilisk right now, when the MMU is per-task this will make more sense.

It seams you code sniped whit masking bits etc, suggest you want to emulate 64bit memory access, that was never my idea, the idea was simply to use high memory >4Gbytes to free low memory

Last edited by NutsAboutAmiga on 26-May-2014 at 09:24 PM.
Last edited by NutsAboutAmiga on 26-May-2014 at 08:46 PM.
Last edited by NutsAboutAmiga on 26-May-2014 at 08:42 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@umisef

code]
if ((address&highBitMask)!=currentHighBitMask)
{
unmap_EMO(currentHighBitMask);
currentHighBitMask=(address&highBitMask);
map_EMO(currentHighBitMask);
}
address&=lowBitMask;
//...accessing memory at offset "address" in the address window goes here
[/code]

If we wanted to do that then I don't think it big problem, considering what EUAE has to do.

http://sourceforge.net/p/euaeppcjit/code-0/16/tree//trunk/src/memory.c

EUAE memory emulation is pretty bloated already, but we don't need to think about all the memory types in Basilisk.

Most of EUAE and Basilisk memory functions end up calling:

do_get_mem_long()
do_get_mem_word()
do_get_mem_byte()

etc.

in some cases functions are calling functions that are calling functions, many levels up.

In Basilisk 1.0 some one had changed do_get_mem_*() macros for functions, I changed back to macros got a nice speed up

Last edited by NutsAboutAmiga on 26-May-2014 at 09:49 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@32+bit addressing

Interesting idea of handling 64bit:
"The main disadvantage of 64-bit architectures is that, relative to 32-bit architectures, the same data occupies more space in memory (due to longer pointers and possibly other types, and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache utilization. Maintaining a partial 32-bit model is one way to handle this, and is in general reasonably effective. For example, the z/OS operating system takes this approach, requiring program code to reside in 31-bit address spaces (the high order bit is not used in address calculation on the underlying hardware platform) while data objects can optionally reside in 64-bit regions."
(source in wiki) ( z/OS )

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?