Interest at bounties for Aros 68k?

[deadwood]

Originally Posted by clebin

Each step would take Workbook much closer towards being a viable Workbench-replacement.

What would be the use case for Workbook? In which scenario would it be usefull if you already have Scalos or Magellan?

[clebin]

Originally Posted by deadwood

What would be the use case for Workbook? In which scenario would it be usefull if you already have Scalos or Magellan?

Speed, mainly. Lots of classic users run 3.1 over 3.9 for that reason alone so it's hugely important. Others use 3.9 but don't want feature-full replacements like Scalos or Magellan. I think a fast, like-for-like Workbench replacement is still very desirable on classic hardware. I imagine this was one use-case for writing Workbook (you'll know more than me of course), but unfortunately development ended a bit too soon.

[gulliver]

NOT IMPLEMENTED AMIGAOS STRUCTURES

General comments:
I have done just a quick job of what I remember and did a check on both the latest ABI1 Aros68k build (20151130) and AmigaOS 3.1.
With more time, I can probably double check, because I know some functions are implemented on Aros somewhere else.
So take this as a rough guide or draft. If I had more time, I could probably do a more in depth check, which could include bugs,
unimplemented tooltypes, and some behaviour oddities

Missing functionality:
intellifont/compugraphic font support (TrueType is indeed the way forward, but it is another resource pig on anything but high-end
Amigas. And besides, Intellifont should be implemented anyway for backwards compatibility.)
cdrom filesystem (missing L:cdrom-handler. Is it in Aros68k rom? It should be on disk, see note no. 1)
no crossdos (L:fat-handler is missing. Is it in Aros68k rom? It should be on disk, see note no. 1)
recoverable ram volume support is non existant (RAD)
No Overscan support
No PCMCIA ram support

Missing disk components:
C/cpu
ed
edit
magtape (I dont know anyone who has used it, and I highly doubt it is required for backwards compatibility. But you never know)
remrad (no rad support)
setfont (setdefaultfont does not provide the same functionality. eg.: missing setfont tooltypes)
CLASSES/DATATYPES/anim.datatype (these datatypes seem implemented, but their classes are physically absent)
animation.datatype (these datatypes seem implemented, but their classes are physically absent)
cdxl.datatype (these datatypes seem implemented, but their classes are physically absent)
CLASSES/GADGETS/tapedeck.gadget
DEVS/audio.device (AHI is fine as a way forward, but it is a resource pig on anything below a 68020 on native, so I can imagine it is
like a torture if you take into account Aros68k performance)
mfm.device
parallel.device
DEVS/DOSDRIVERS/aux
rad
cd0 (iso0 is present but we have the renaming issue. See note no.1)
pc1 (maybe a small omission)
DEVS/KEYMAPS/ (it is full of PC keyboard keymaps and a SUN one. But what about Amiga keymaps?)
DEVS/MONITORS/ (missing A2024, dblntsc, dblpal, euro36, euro72, multiscan, ntsc, pal, super72 and vgaonly. A generic one doesnt suit,
see note no. 1)
DEVS/PRINTERS/ (missing all printer drivers but postscript. Not that it is really needed, but at least, "generic" and "file" drivers
should be included)
FONTS (not a single one of the old native ones present. I understand that there are TTF replacements, but then see note no1.)
L/aux-handler
cdfilesystem (see note no. 1)
crossdosfilesystem (see note no. 1)
port-handler
queue-handler
LIBS/68040.library (680x0.library exists but see note no. 1)
bullet.library
PREFS/overscan
pallete
printergfx
printerps
sound (yes, there is AHI, but I have already mentioned its issues)
wbpattern
REXXC/hi
rxc
rxset
tcc
tco
te
ts
waitforport
SYSTEM/diskcopy
intellifont (ftmanager doesnt cut it, as I mentioned before)
nofastmem
TOOLS/bru (not that I or anyone else care or require it for backwards compatibility, but some backup option should exist for completeness)
cmd
iconedit
lacer
memacs (I dont use it or care about it, but why leave it out when it is PD?)
prepcard
TOOLS/COMMODITIES/crossdos
mouseblanker (I couldnt care less. But then it is not difficult to implement, isnt it?)

Notes:

1.It is not wise for backwards compatibility´s sake that some AmigaOS components get replaced with other ones with different names. Just
restore them to their original name for gods sake or create placeholders/links to the actual structures.

[wawa]

Originally Posted by deadwood

Isn't Scalos 68k by origin? The original version does not work with AROS 68k?

not entirely alas. its a bit difficult to puzzle it together from scalos amiga binaries with some missing libs. the result is it works, but doesnt open a lister with some dirs and drives. checked a while ago. there must be some incompatibility. but there one way or the other there wasnt anyone able or willing to do anything about it at the time. we can pursue the issue if you want. scalos was rather promising as at least temporary wanderer replacement also on my amiga hardware.

edit: maybe something has changed in this respect due to recent commits. ill try to retest as soon as i come over to install amiga scalos on aros. but what concerns aros 68k version, it good to debug this anyway for a few reasons.

[wawa]

@gulliver
edit> aros has much better editor than the genuine amiga os and not resource hungry. without the ss you need to tools/editor, but otherwise you should be able to invoke it with just "edit". quite handy on genuine amiga in comparison to memacs as default.

besides your list is quite long but not just everything there is essential. at least not at this point. as example some monitor files as 2024. there is no concept of monitor files anyway, as these are undocumented. i have discussed this issue with thor and even him considers it better like that.

what concerns fonts, its reasonable to remove the set of ressource hungry outline fonts (the huge files) on amiga anyway, and maybe prerender owb fontcache on some fast config as uae and the rest works much better.

>LIBS/68040.library (680x0.library exists but see note no. 1)
specific processor libraries are unneccessary. insert setpatch at the beginning of the ss and the universal 680x0.library with the patches for specific processor will be automatically loaded. plug and play. definitely a gain with aros. no libs mess here.

sorry, its late back home, or rather with my gf, so i cannot get in more detail. tommoriw more. not all is so bad as it seems.

[gulliver]

Originally Posted by wawa

@gulliver
edit> aros has much better editor than the genuine amiga os and not resource hungry. without the ss you need to tools/editor, but otherwise you should be able to invoke it with just "edit". quite handy on genuine amiga in comparison to memacs as default.

I do understand this, and I understand the same goes with many other files, but then as I suggest in the notes section, it is not wise for backwards compatibility´s sake that some AmigaOS components get replaced with other ones with different names. Just restore them to their original name for gods sake or create placeholders/links to the actual structures. It is dead easy, and prevents many amigaos users from being clueless when they for eg. have to edit their startup-sequence when booting to cli and get an error when typing "ed s:startup-sequence".

Originally Posted by wawa

besides your list is quite long but not just everything there is essential. at least not at this point. as example some monitor files as 2024. there is no concept of monitor files anyway, as these are undocumented. i have discussed this issue with thor and even him considers it better like that.

I agree that very few should still own and use an A2024.
But one generic monitor driver without overscan support, and in a non amiga format sucks much more. Despite not being documented many developers such as Ratte, to name one, have created new monitor drivers and could provide skeleton files, if not complete source code. So I see no excuse to use something that should in theory be better, but that is indeed worse in practice.

Originally Posted by wawa

what concerns fonts, its reasonable to remove the set of ressource hungry outline fonts (the huge files) on amiga anyway, and maybe prerender owb fontcache on some fast config as uae and the rest works much better.

I am not even dreaming about owb being reasonably useful on 68k in its current state. What I was referring is that TTF fonts are the way forward, but they are pain inflicting on a 68k (even worse on aros), and that Compugraphic fonts should still remain for backwards compatibility. Furthermore, I added that replacements for standard AmigaOS 3.x fonts should be present (some not very clever programs have hardcoded font selections).

Originally Posted by wawa

>LIBS/68040.library (680x0.library exists but see note no. 1)
specific processor libraries are unneccessary. insert setpatch at the beginning of the ss and the universal 680x0.library with the patches for specific processor will be automatically loaded. plug and play. definitely a gain with aros. no libs mess here.

I do understand this, but you dont seem to grasp the issue here, that for backwards compatibility, as I mentioned in the note section, it should be renamed. I can imagine a scenario where some user installs its vintage accelerator driver disk, using its installer, and ends up with a f*cked system.

Originally Posted by wawa

sorry, its late back home, or rather with my gf, so i cannot get in more detail. tommoriw more. not all is so bad as it seems.

You should rather do whatever you do with your girlfiend

No, it is not so bad (functionality wise), but it does requires some work.
Performance is just the other tip of the iceberg, and then, there are some little things that I believe should change for better.

[wawa]

awake again. we have not been doing hell much after being back home from drinking wine and watching tims vermeer.

ed s:startup-sequence

perhaps calling such a program should be wrapped to the replacement. but is there even any scripts invoking an editor in order to cause noticeable incompatibility? doesnt seem logic, at least i have not came across any. whoever looks for an editor navigates to the tools directory and finds it. i have plenty practical experience with aros on amiga and it has never posed any problem for me.

besides is there ed execuatble in all versions of amiga system? perhaps, but im not even sure..

Despite not being documented many developers such as Ratte, to name one, have created new monitor drivers and could provide skeleton files

thor is another one. he wrote the monitor driver for natami. i would have to dig up our correspondence to recall details, he somehow considered these monitor files an inconsistent hack themselves and was in favor of a clean replacement. this way or the other i doubt we will ever see amiga compatible monitor files on aros, while i believe feats like overscan are on to do list.

I am not even dreaming about owb being reasonably useful on 68k in its current state.

not the odyssey, but believe me i ran aros owb on an amiga (with rtg) and it worked given the font cache is precalculated (it is after first execution) and the owb executable is in elf format it even starts rather quickly, otherwise it takes ages. browsing with it needs a fair bit of patience, for sure, but its in the about the same range as netsurf i would say.

What I was referring is that TTF fonts are the way forward, but they are pain inflicting on a 68k (even worse on aros), and that Compugraphic fonts should still remain for backwards compatibility. Furthermore, I added that replacements for standard AmigaOS 3.x fonts should be present (some not very clever programs have hardcoded font selections).

i think its a feature but not a priority. we need to focus on first things first. aros has some replacements for bitmap fonts and can use amiga fonts, while i dont think, its likely, that there is any intelifonts hardcoded anywhere, as they were pretty late addition. again, i didnt came across it being an issue having run a lot of amiga stuff on aros. we should postpone the solution to the moment more people are engaged with aros68k, if it ever happen

I can imagine a scenario where some user installs its vintage accelerator driver disk, using its installer, and ends up with a f*cked system.

this is not necessary as i said and shouldnt be done in first place. you can trash your genuine amiga system using inappropriate drivers as well, but i doubt anyone will ever think of, let alone get over to running some 060 library on aros, and if he did he will probably face an error, but not a trashed system. i think its truly a non issue.

[wawa]

> cdrom filesystem

aros has a replacement for this. i dont remember how this is called, but im pretty convinced its in rom. ill check when im back in studio.

> DEVS/audio.device (AHI is fine as a way forward, but it is a resource pig on anything below a 68020 on native, so I can imagine it is
like a torture if you take into account Aros68k performance)

using aros on an amiga below 68020 really doesnt make any sense even if possible. aros is making sense as an os replacement when there is damand for features not available on original os. such as for instance moving windows out of the screen. you dont need that to run some games on unexpanded amiga, and frankly then you are better off using it as is

> parallel.device

i think its basically implemented. olaf called for this. should be in rom. but i have never needed it.

> DEVS/KEYMAPS/ (it is full of PC keyboard keymaps and a SUN one. But what about Amiga keymaps?)

you can set keymap in prefs. i usually dont bother with it but i guess it works. should retest. possibly needs finetune.

> pallete

yes. i think its possible to set palette, but something should be done to have a prefs setting tool for pens and one screens palette shouldnt be trashed if a new screen opens with another. here some thoughts would be necessary, but i think it wont happen any soon as its amiga-68k exclusive feature.

> wbpattern

no wb to start with. wanderer has own prefs for it and scalos too.

> REXXC/hi

rexx on aros may generaly pose a problem as is. point taken. i have no experience here.

> waitforport

dont know..

> iconedit

id kill for a good replacement

[gulliver]

It seems we both are on a different page here, let me explain why:

I believe that if you target aros on only high-end 68k. It will never gain any traction whatsoever. No one besides tinkerers and some few curious will do something with it (like it is now).

Yes, it is easy to write unoptimized code, and rely on speed to cover the holes. You can do that on x86/x64 already. But point is that if you are looking to become a real feaseable replacement on 68k, you need to stop making excuses for features, performance and backwards compatibility. If you want to ignore these, then better drop 68k support alltogether.

If you are looking for high-end stuff that works the way you mention, you already have ArosVision that may suit you, and does its job very well. No need to look any further.

But if you are an average Amiga user, you wont touch aros68k even with a stick. The vast majority of Amigas are worse specced than your proposed RTG & 68020+ hardware.

Not targetting the lower end Amigas (which is the vast majority) is a huge mistake. But that being said, you dont need to provide these low power systems with all the new features aros brings (it should be stupid to believe you can do that). You just need them to be provided with at least what they already have with their aging AmigaOS 3.1 in terms of features and compatibility. This is the stone that I consistenly try to mention, that steps in the way for aros68k to become a viable alternative for most Amiga users. If not ask Amigakit/Vesalia/etc why they still hold in stock, and sell lots of AmigaOS 3.1 floppy sets and dont even dream of replacing them with Aros68k ones (The same can be said of kickstart roms).

The potential is there, but it definately still requires a lot of work and a change of mentality from developers on 68k (if there is still any) to make it happen.

[Retro1234]

Last time I tried Aros 68k wanderer was just to SLOW!
games etc worked well.

[OlafSch]

Originally Posted by gulliver

NOT IMPLEMENTED AMIGAOS STRUCTURES

General comments:
I have done just a quick job of what I remember and did a check on both the latest ABI1 Aros68k build (20151130) and AmigaOS 3.1.
With more time, I can probably double check, because I know some functions are implemented on Aros somewhere else.
So take this as a rough guide or draft. If I had more time, I could probably do a more in depth check, which could include bugs,
unimplemented tooltypes, and some behaviour oddities

Missing functionality:
intellifont/compugraphic font support (TrueType is indeed the way forward, but it is another resource pig on anything but high-end
Amigas. And besides, Intellifont should be implemented anyway for backwards compatibility.)
cdrom filesystem (missing L:cdrom-handler. Is it in Aros68k rom? It should be on disk, see note no. 1)
no crossdos (L:fat-handler is missing. Is it in Aros68k rom? It should be on disk, see note no. 1)
recoverable ram volume support is non existant (RAD)
No Overscan support
No PCMCIA ram support

Missing disk components:
C/cpu
ed
edit
magtape (I dont know anyone who has used it, and I highly doubt it is required for backwards compatibility. But you never know)
remrad (no rad support)
setfont (setdefaultfont does not provide the same functionality. eg.: missing setfont tooltypes)
CLASSES/DATATYPES/anim.datatype (these datatypes seem implemented, but their classes are physically absent)
animation.datatype (these datatypes seem implemented, but their classes are physically absent)
cdxl.datatype (these datatypes seem implemented, but their classes are physically absent)
CLASSES/GADGETS/tapedeck.gadget
DEVS/audio.device (AHI is fine as a way forward, but it is a resource pig on anything below a 68020 on native, so I can imagine it is
like a torture if you take into account Aros68k performance)
mfm.device
parallel.device
DEVS/DOSDRIVERS/aux
rad
cd0 (iso0 is present but we have the renaming issue. See note no.1)
pc1 (maybe a small omission)
DEVS/KEYMAPS/ (it is full of PC keyboard keymaps and a SUN one. But what about Amiga keymaps?)
DEVS/MONITORS/ (missing A2024, dblntsc, dblpal, euro36, euro72, multiscan, ntsc, pal, super72 and vgaonly. A generic one doesnt suit,
see note no. 1)
DEVS/PRINTERS/ (missing all printer drivers but postscript. Not that it is really needed, but at least, "generic" and "file" drivers
should be included)
FONTS (not a single one of the old native ones present. I understand that there are TTF replacements, but then see note no1.)
L/aux-handler
cdfilesystem (see note no. 1)
crossdosfilesystem (see note no. 1)
port-handler
queue-handler
LIBS/68040.library (680x0.library exists but see note no. 1)
bullet.library
PREFS/overscan
pallete
printergfx
printerps
sound (yes, there is AHI, but I have already mentioned its issues)
wbpattern
REXXC/hi
rxc
rxset
tcc
tco
te
ts
waitforport
SYSTEM/diskcopy
intellifont (ftmanager doesnt cut it, as I mentioned before)
nofastmem
TOOLS/bru (not that I or anyone else care or require it for backwards compatibility, but some backup option should exist for completeness)
cmd
iconedit
lacer
memacs (I dont use it or care about it, but why leave it out when it is PD?)
prepcard
TOOLS/COMMODITIES/crossdos
mouseblanker (I couldnt care less. But then it is not difficult to implement, isnt it?)

Notes:

1.It is not wise for backwards compatibility´s sake that some AmigaOS components get replaced with other ones with different names. Just
restore them to their original name for gods sake or create placeholders/links to the actual structures.

in general you can easily add anything as long as it does not rely on internal structures that perhaps are not implemented or implemented differently. You can f.e. add anything shell related easily, add more libraries and so on. Partly you can even replace existing components. I did f.e. replace Zune with MUI38 because some software I wanted did not work (example is IBrowse). The only disadvantage is that prefs do not work anymore so I created workarounds like predefined prefs files that are copied.

I have not much time now so a short answer... crossdos does not exist and on Aros (except 68k) nobody needs it and no sources are available so chance is pretty slim. The rest you wrote there like the "handler" I do not know. I do not know how complkicated it would be to implement it, in some cases perhaps only wrapper needed so perhaps something for a bounty.

Missing disk components. As I wrote you can add almost anything and as long as it not relys on unimplemented low-level components it works. I cannot remember f.e. "cpu" but I have added many components so it might be there. Also you do not need to include "ed" or similar because you can simply define it in shell-startup. I f.e. define it and execute annotate. Datatype system is different in aros so you cannot simply add or replace datatypes from 3.X (I have tested it). Datatypes would be certainly a candidate for a bounty. In Aros Vision I have created small Hollywood-programs for that and use filetype system of Magellan to execute them. Audio.device missing? It should be there but certainly using AHI that is standard on Aros. Printing and Printing to file works (at least on UAE, not tested it on real hardware). 68040.library can be added easily I think. I use Waitforport in Aros Vision, it is working with Rexxmast from Aros.

Mouseblanker? There is a "blanker" working with moving stars. What sense does mouseblanker make?

Other than that interesting list... I will look at it. Perhaps you can write what you think. Some is easy solvable by just adding/replacing components or configuration, others would need wrappers or even new components. I would like to make a distribution that is as near as possible to the real one.

[wawa]

Originally Posted by clebin

Speed, mainly. Lots of classic users run 3.1 over 3.9 for that reason alone so it's hugely important. Others use 3.9 but don't want feature-full replacements like Scalos or Magellan. I think a fast, like-for-like Workbench replacement is still very desirable on classic hardware. I imagine this was one use-case for writing Workbook (you'll know more than me of course), but unfortunately development ended a bit too soon.

workbook is almost in a workable state, i am under an impression, booted only accidentally into it. im not sure how much faster it is then scalos stripped of bells and whistles like huge png icons. but i think it will be faster and easier to get scalos working dependably first. we need easy short term goals.

[clebin]

Originally Posted by wawa

workbook is almost in a workable state, i am under an impression, booted only accidentally into it. im not sure how much faster it is then scalos stripped of bells and whistles like huge png icons. but i think it will be faster and easier to get scalos working dependably first. we need easy short term goals.

I think Workbook is far from a workable state right now, so Scalos would definitely be the quicker solution. I'm not trying to put a priority on it, just flagging it up as something that I think users would appreciate. After all, if Scalos was a total no-brainer over Workbench, wouldn't most classic users be running it on 3.x already?

[wawa]

Originally Posted by clebin

I think Workbook is far from a workable state right now, so Scalos would definitely be the quicker solution. I'm not trying to put a priority on it, just flagging it up as something that I think users would appreciate. After all, if Scalos was a total no-brainer over Workbench, wouldn't most classic users be running it on 3.x already?

i simply wasnt interested in scalos as preious since i considered it eye candy. which it is not as i discovered. it may not be a no brainer over workbench but it certainly is over wanderer in its current state. and since the programer behind wanderer doesnt seem to be very active currently it may take some timi before wanderer2, as its been a while already.

so, anyone out there to help me debug the issues? they are reproducible.

[deadwood]

Originally Posted by clebin

Speed, mainly. Lots of classic users run 3.1 over 3.9 for that reason alone so it's hugely important. Others use 3.9 but don't want feature-full replacements like Scalos or Magellan. I think a fast, like-for-like Workbench replacement is still very desirable on classic hardware. I imagine this was one use-case for writing Workbook (you'll know more than me of course), but unfortunately development ended a bit too soon.

Sorry I wasn't specific enought. What I ment is that what hardware is target for this. Basically you need 1 MB RAM for AROS ROM. To be able to do anything usable you then need additiona 1MB RAM. This leaves out standard A500 configs and makes it maybe usable for stock A1200. Or are you saying that most of the users already have some sort of memory expansion?

[deadwood]

@gulliver and wawa

From the discussion on graphics part I see two topics rising as potential bounties: performance of OCS/ESC/AGA driver and extention with overscan support.

For the first topic, to be able to see what kind of problem we are talking about, do you know of any available benchmark that uses graphics.library (and not chipset directly) so that comparison of current performance between AmigaOS and AROS can be made?

[deadwood]

@wawa

Can you list the validation criteria that you would see for Scalos bounty (similar to what Clebin did for Workbook)? What sort of functionality would have to be supported.

[wawa]

i wouldnt really target anything below a1200. currently i would assume that if aros was usable at 030/25 with some fast ram it would be fair system requirements, considering what most people should have at hand, especially as this is what fpga amiga replacements are usually offering.

later one might think of better support for even lower specs, but imho thats a fair start.

[wawa]

Originally Posted by deadwood

@wawa

Can you list the validation criteria that you would see for Scalos bounty (similar to what Clebin did for Workbook)? What sort of functionality would have to be supported.

first thing is making scalos version from contribs fully functional. i dont think there is any further demands on my part. im not fully familiar with its functionality, but i think if there is the bounty it should include reasonable maintenance even after its been fulfilled, that is if someone it gets broken again or if someone discovers a bug.
i hope it matches then the performance of the genuine 68k version.

making desktop fast enough on say 030/60 is further matter involving putting together an appropriate iff theme and icon set. i dont think there is any bounty necessary for this part.

unfortunatelly the screenmode prefs bug is making proper testing impossible as of today. i just discovered some bug neil must have introduced to listview, when trying to use unarc on 68k, it busy loops refreshing, but i cant neither cross check with current nightly nor with x86 mingw hosted. sigh..

[wawa]

Originally Posted by deadwood

@gulliver and wawa

From the discussion on graphics part I see two topics rising as potential bounties: performance of OCS/ESC/AGA driver and extention with overscan support.

For the first topic, to be able to see what kind of problem we are talking about, do you know of any available benchmark that uses graphics.library (and not chipset directly) so that comparison of current performance between AmigaOS and AROS can be made?

we should first evaluate the difference of every grahics.lib function using library timer. this particularly on an OCS/ESC/AGA,but im not sure what benchmark to use. anybody, proposals?

trying to get sysinfo run on aros, but its nogo for now (sorry must have cut off left column of the log while copying):

Count Process Name       Action     Target Name                 Options Res...
----- ------------       ------     -----------                 ------- ----..
Gfx] Graphics_175_BestModeIDA().
16    [1] sysinfo        OpenFont   topaz.font                  Size 8  OK  ..
etSwitch() - amiga
repareViewPorts viewport=08040f2c.
etSwitch() - amiga
17    [1] sysinfo        OpenFont   topaz.font                  Size 8  OK  ..
18    [1] sysinfo        OpenFont   topaz.font                  Size 8  OK  ..
our Amiga program just did something terribly stupid 55555555 PC=00FE9F7A
5555535  0000 0000 0000 0000 0000 0000 0000 0000
5555545  0000 0000 0000 0000 0000 0000 0000 0000
5555555  0000 0000 0000 0000 0000 0000 0000 0000
5555565  0000 0000 0000 0000 0000 0000 0000 0000
5555575  0000 0000 0000 0000 0000 0000 0000 0000
0FE9F5A  41F6 8800 2028 0004 671A 2250 222F 000C
0FE9F6A  207C 00DF F000 2F0D 2A40 487A 0006 2F00
0FE9F7A  4E75 2A5F 2C5F 4E75 2F03 2F02 3039 00DF
0FE9F8A  F01C 0800 000E 6754 3439 00DF F01E C440
0FE9F9A  0242 0007 7600 3602 7003 C083 33C0 00DF
0000000    2048K/1 =    2048K Chip memory
0200000   10176K/0 =   10176K <none>
0BF0000      64K/0 =      64K CIA
0C00000    1792K/0 =    1792K <none>
0DC0000      64K/0 =      64K Battery backed up clock (MSM6242B)
0DD0000      64K/0 =      64K <none>
0DE0000     128K/0 =     128K Custom chipset
0E00000     512K/1 =     512K Extended Kickstart ROM (CBE62D29)
0E80000      64K/0 =      64K <none>
0E90000      64K/0 =      64K Filesystem autoconfig
0EA0000     384K/0 =     384K <none>
0F00000      64K/1 =      64K UAE Boot ROM
0F10000     448K/0 =     448K <none>
0F80000     512K/1 =     512K Kickstart ROM (E6EAB632)
1000000     112M/0 =     112M <none>
8000000      32M/1 =      32M RAMSEY memory (high)
A000000     864M/0 =     864M <none>
0000000      16M/1 =      16M RTG RAM
1000000    3056M/0 =    3056M <none>
PU halted: reason = 3 PC=00fe9f7a
xception 3 (fe9f7a) at fe9f7a -> fea3d0!
arning: Bad playfield pointer 003fffe8

btw somethin really happened with zune, i think lately, while editing you can see how just any input or scrolling in editor window causes to redraw everything including window decoration. was that previously the case?