support for 680x0 CPUs

[mithrendal]

@Vweber73 you wanted a 68020 CPU ? for the settlers ?

at least sysinfo reports now with the above setting an 68EC020

pushed an early preview to uat

be aware the 68020 CPU implementation is still under heavy construction but already working somehow...

also follow progress on dirkwhoffmann/vAmiga#728

[Vweber73]

Wow this is fantastic! Many thanks to both of you!
Now the settlers can have a map size of 7 instead of 5. For size 8, 68030+ is actually needed. But this is a very good start!
An amusing minor issue: my older snapshots are not marked as obsolete, but nothing happens if I try to load them. I created a new Settlers 020 snapshot... which fails to reload (see nonsense reason attached) :)

Cheers

[mithrendal]

An amusing minor issue: my older snapshots are not marked as obsolete

fixed and pushed to uat

[Vweber73]

Great, thanks a lot!

[mithrendal]

new version without 68020 instruction logging pushed to uat

[Vweber73]

Great, thanks, works fine now!

[mithrendal]

restored cpu type in settings from a snapshot load

and removed the @= in front of cpu clock

pushed to uat environment (https://vamigaweb.github.io/uat/)

[Vweber73]

Great idea, thanks!

[Vweber73]

I restored snapshots from the previous version.
Settlers works fine.
Interceptor starts to work fine for a few seconds, then black screen!! Any clue? Cheers

[mithrendal]

Interceptor starts to work fine for a few seconds, then black screen!! Any clue?

with the 68000 oder 68020 ? I mean what was inside the snapshot, which type of cpu?

If 68020 then maybe still some bug in restoration of the internal CPU state? I see some more commits on vAmiga which I have not yet merged into vAmigaWeb ...

this one

dirkwhoffmann/vAmiga@aaba842

[Vweber73]

Yes, 68020 for everything...

[mithrendal]

Yes, 68020 for everything...

ok ... too new stuff 😅 ... just merging in the latest commits from dirk...

[mithrendal]

merged latest commits from vAmiga (no 68030 yet) but probably more stable than the code base from three days ago

pushed to uat

[Vweber73]

Now both previous snapshots reset the amiga and reload their floppy or hdd! :)

[mithrendal]

That is because the internal structure of the snapshot has changed. There were this missing CPU stuff mentioned above. (Which caused probably the issue after restoring snapshot of interceptor. ) Therefore it cannot load it anymore. I did not increased the version therefore also no compatibility warning. Uat version is only for tests.

[Vweber73]

Ok, understood, thanks!

[Vweber73]

Restoring the Interceptor snapshot now works (after recreating the snapshot) but the initial screen in viewport tracking mode seems distorted (it gets OK on the next screen). Strange...

[mithrendal]

but the initial screen in viewport tracking mode seems distorted (it gets OK on the next screen). Strange...

what exactly means distorted ?

I tried interceptor with 68020 to reproduce it and what I see on iPhone after snapshot restoring in viewport tracking or borderless is that it calibrates the visible screen size for some fractions of a second ... Is it that what you mean with distorted ?

[Vweber73]

No, it is more than calibration, only the first screen is like that for as long as you don't touch the keyboard, once you do the second screen comes in with normal calibration and size, see the difference with previous screenshot. It is the first time I see this...

[mithrendal]

see the difference with previous screenshot.

I don't get it ... I literally searched minutes for something odd on the pictures above ... I mean I can not see the distortion in your picture nor the difference... can you describe with words what you think is wrong ?

[Vweber73]

The first picture is much taller, the letters are quite stretched vertically

[mithrendal]

Ah ok, I understand now ...

reproduced it and now I see it too ...

=> that happens only in borderless and not in viewport tracking and it is quite intentional what happens here... I mean I have programmed it that way...

test case: load it from start
when you load with borderless from the beginning then the calibration already takes the bigger width of the screen (which it saw on the title screen of interceptor) into its calculation and the mentioned screen shot above is not stretched vertically.

test case: load it from a snapshot, where there is not much drawn on the left and right border sides of the screen

1. on snapshot load: borderless resets its calculation, it sees now a very narrow screen and cuts the borders off...
2. when you press a key for the next screen (which is wider) then borderless sees and learns that there is more used screen width and adapts to it

bottom line: when using bordeless it does not care on the correct aspect ratio but tries to eliminate the borders instead (the extend of border elimination is constrained to the max screen borders it already discovered while executing the game)

its kind of a trade off ... borderless when your device has a tiny screen size (to see it as big as possible) and all the others modes when you are on big screen. On big screen maybe the nicest is standard then you see at least some borders

[Vweber73]

Ok, thanks a lot! I thought it was the first time I see it that way... Maybe because my snapshot starts from the intro scren, not the intro image as before...
Cheers

[mithrendal]

Maybe because my snapshot starts from the intro screen, not the intro image as before...

exactly...

also when loading with borderless until the mentioned screen then it looks nice because it learned already that the screen can be bigger ... then when you switch to standard it forgets/resets the learned boundaries and when you switch back to borderless again it is too tall on that particular game screen

What could be done is to not reset borderless when switching the modes and also to save the learned boundaries into the snapshot ... I don't know whether I should do that ... Maybe one wants to reset the learned boundaries? I don't know ...

Or maybe a borderless but not too agressive mode ? Which preserves/calculates the correct aspect ratio on top of the calculated borderless boundaries?

[Vweber73]

I think the aspect ratio should always be preserved no matter what... No reason to have a distorted image! :)

[mithrendal]

ok I see will create a separate issue ...

[Vweber73]

Great!

[mithrendal]

pushed to uat

[Vweber73]

Wow!! Goal is reached at last!! Congrats and tanks to all of you on this idea!!
Now at last map size 8 on Settlers!

Settlers also mentions FPU when available but this doesn't seem to translate in any extra feature for the user...

[mithrendal]

68030 has no internal FPU ... only 68040 starts with an embedded one I think...

concerning the crashes on sysinfo which probably does some extra extensive tests which then lead to a guru meditation ...see here dirkwhoffmann/vAmiga#732 dirk already set up toni wilens cpu tester to iron them out ... probably the crashes will then go away when dirk fixes a bunch of them

[Vweber73]

Yes, I know about the FPU, I meant that Settlers is able to detect 68881 or 68882 but doesn't seem to do anything useful with them.

Indeed let's hope this guru meditation thing can be solved!

I have another problem... I tried to push Settlers to its limit with map size 8 and experienced sluggish sound again with a low number of frames... Even when I load the snapshot again (beginning of Settlers prior to choosing a map size) the problem remains... Even after restarting the phone!!

[Vweber73]

Getting worse... Not only everything is saturated (to few rendered frames whatever the game, reset...) but also my Interceptor snapshot start working fine for a few seconds then... Guru meditation! This never happened before...

[Vweber73]

And suddenly after one hour of sluggishness, now sound and speed is OK again. I didn't do anything! But the guru mediation on Interceptor snapshot is still there...

[mithrendal]

I will looking into the speed thing on a modern i5 gen 11 laptop and watch the rendered frames under different configurations

despite that:

speed should be comparable to 68000 because it is the same way of implementation but maybe still a bit buggy or has still some sort of debug code or superfluous code paths in it ...

I wouldn't test too much by now ... it is still full of bugs and untested as dirk said

much better is it to solve all the errors which tonis cpu_tester reports ... after that it should theoretically not again guru

[mithrendal]

I also saw a slight drop with 68030 on higher clock speeds...

running a 68030 at 7Mhz for now seems safe and ok with the current implementation ...

[Vweber73]

I have saturation problems even with 68000 now...
Reverting to 7mhz seems to solve the frame problem...
I enabled developpers options and monitored cpu and gpu usage. Cpu is around 25% and never goes up to 50%. Fps (surface) is very high at times, not sure how to interpret...
Cheers

[mithrendal]

Is the regular version different?

[Vweber73]

I'm not too sure. Long time didn't use the regular version, my snapshots are not valid any more...

[Vweber73]

I think it found the guru problem.
The Interceptor snapshot was saved with 68020.
Loading it while vAmiga is in 68030 mode triggers the guru. But changing to 68020 prior to loading avoids the guru!
In both 68020 and 68030, 7 and 14 mhz are OK most of the time, 28mhz has a lot of missed frames. Not always! Just at times. Very strange....

[mithrendal]

great finding ... maybe snapshot restore does not correctly restore the cpu type in the describe use case and leads to the guru ... @dirkwhoffmann possibly a fault in the core ?

for the framerate drops I guess thermal throtteling is a candidate to explain the cause for it .... found a german article on the net which says that z3 fold while overall being a great phone is plagued with aggressive thermal throtteling... and it also says that one can disable some settings to partially avoid this

see
https://www.nextpit.de/samsung-galaxy-z-fold-3-test

[Vweber73]

Wow... Many thanks aks for this, I didn't know. I'm so disappointed... You buy the flaghsip model, you pay a bomb, and you still have to deal with issues like this! I activated the "enhanced processing" option (they say it works for everything except games, I hope vAmigaWeb is not reported as a game?). Now it seems from the console that I have no frame drops. Also it is morning, the phone could cool off for the whole night, so maybe it plays a role...

Even when I have no frame drops the sound is not perfect, some glitches here and there in Settlers music... Is it the case for you as well?

Cheers

[Vweber73]

I spoke too fast... Even with this option enabled, I'm back to heavy frame drops... :(

What I don't get is that Retroarch / puae (this again, sorry) never ever game me this. I just tried it again, so the phone is in the same state... 68030, 35Mhz cycle-exact, Settlers works like a charm in perfect sound... For the same kind of processor load, right?

[mithrendal]

for the guru issue you found I asked dirk whether he sees something ...

for the performance thing:

1. you had this problem long before right ? And mostly with settlers?
   is it much worse now ? How much ? Other game titles too ?

2. can you see the cpu/fpu usage when running PUAE vs vAmigaWeb ? Maybe vAmigaWeb takes much more ? Can you also test the regular version as it was compiled with an older LLVM compiler which might do something different....

3. I will run settlers 68030 7Mhz on my iPhone with cable connected (so that it gets hot) and look how long it will take that it goes into thermal throtteling... I will report back

[Vweber73]

1. Yes I always had this problem but it used to be more on and off. Now it is almost systematic. Not that much at 7mhz (although I can happen) but mostly at 28mhz. Not only with Settlers, Interceptor too for instance.
2. I tested cpu/gpu usage with developer options on vAmigaWeb and it doesn't seem to be the problem. Even during frame drops the most I got with 50% usage... I need to try again the regular version, will report.
3. Noted with thanks, but better test at 28mhz I think?

[Vweber73]

I have just tried both versions side by side in comparable situations: 68000 (only option in the regular version anyway), 28Mhz, Settlers.
In both cases I have frame drops ("rendered" sometimes goes as low as 11).
It seems to me that the regular version performs slightly better. Also, it seems the music has a different pitch (lower in the regular version), but it might only be an impression...

[mithrendal]

After 15 minutes listening on a charging iPhone 6s 68030@7mhz with headphones connected (oh boy now I will dream of the settlers music)

no thermal throtteling....

now I will switch to 28Mhz ... we will see whether the 7 year old iPhone can handle that

[mithrendal]

switched the same setup to 28 Mhz ...

use case with closed debug console:
I have generally clean sound .... but with sporadic hiccups in sound every 25 seconds - 40 seconds

use case with open debug console:
rendered fps drops immediately and constantly to 20, despite executed staying at 50 (and therefore sound buffers are filled) I hear constantly cracks/hiccups in sound

bottom line:

1. open debug console eats a certain amount of power too !!
2. old ancient iPhone does its job still quite well
3. why are there cracks in sound under pressure when the audio buffers are filled ? Maybe the total of audio samples in 1000ms are coming in but the they are not evenly scheduled over time ... i.e. sometimes a big chunk and then some gap (all within that 1000ms) ?

[Vweber73]

Ah, thanks, so it is pretty consistent with my findings! Maybe not Z3's fault after all! :)
Yes I also found that closing the console helps a bit, but definitely not enough...