English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.FS-UAE (http://eab.abime.net/forumdisplay.php?f=122)
-   -   Bug: Reading from address $BFE400 and $BFE500 always returns 255 (http://eab.abime.net/showthread.php?t=105377)

Waxhead 13 January 2021 11:30

Bug: Reading from address $BFE400 and $BFE500 always returns 255
 
Howdy,

Ages ago it seems I made a little program that needed some random numbers. Being a young and stupid programmer I pulled the randomness by reading a char/byte from address $BFE400 and $BFE500 and multiplied those together.

My program used to work on WinUAE but suddenly my program failed. Apparently WinUAE changed something, I can't remember when (but can probably try to find out if needed).

Real Amigas return "noise" by reading these addresses e.g. a random number. fs-uae (and the last time I checked WinUAE) does not. Since UAE strives to be accurate (CPU cycle accurate for example) then in the name of accuracy for the emulation UAE should at least return some pseudo random number to mimmic real Amigas if a read is done on those addresses.

Decided to report this for fs-uae since I don't use WinUAE anymore (I am exclusively on Debian GNU/Linux).

StingRay 13 January 2021 11:44

The "noise" is undefined behaviour and emulated if "more compatible" checkbox is set (in 68000 mode only I think). At least in WinUAE.

FrodeSolheim 13 January 2021 12:09

What configuration are you using?

Waxhead 13 January 2021 12:54

Quote:

Originally Posted by FrodeSolheim (Post 1453333)
What configuration are you using?

For this particular test I use a config that looks like so:

Amiga model: A4000 , 3.1 ROM 68040 CPU (ROM rev. 40.70)
Accuracy: High
512K slow ram, 8MB Fast ram
Everything else is the default e.g. no JIT or any other settings.

Anything else? I think this is the most relevant ones.

Regarding the comment about undefined behavior. Well if undefined behavior returning something rather than 0 / 0xFF then I would argue that it is not undefined from a emulation point of view. It is as simpe as the real thing returning something while the emulation does not.

Incidentally I talked with a friend that used to run my program , I remembers that my program worked until (and including) WinUAE 3.20 , after that the "noise" disappeared.

StingRay 13 January 2021 13:21

Quote:

Originally Posted by Waxhead (Post 1453344)
Regarding the comment about undefined behavior. Well if undefined behavior returning something rather than 0 / 0xFF then I would argue that it is not undefined from a emulation point of view. It is as simpe as the real thing returning something while the emulation does not.


It is undefined. What do you think your program does? Reading CIA registers or bus noise?


And btw, it is a very bad approach to get "random" values.

Waxhead 13 January 2021 14:00

Quote:

Originally Posted by StingRay (Post 1453351)
It is undefined. What do you think your program does? Reading CIA registers or bus noise?

And btw, it is a very bad approach to get "random" values.

How can it be undefined when real hardware output something that varies and the emulation does not? There is a difference and the difference is something rater than nothing.

I believe my program is reading bus noise, but then again I have not written code for my Amiga in 24 years or so.

But does it matter?! On real hardware it reads something that varies , but on emulation it read static values. I would again argue that something rater than nothing is something that is NOT undefined. Is not bus noise a definition after all?

jotd 13 January 2021 15:17

I've never seen such things done in games.

Exodous 13 January 2021 15:37

If it is not defined as being an official source of random number generation then it must be considered "undefined".

Technically, this means your operation could have failed on any legitimate hardware if a minor tweak or revision was made that meant your view of "randomness" was no longer present.

Toni Wilen 13 January 2021 16:22

It is fully emulated if 68000 and more compatible (prefetch) enabled. Returned data is not random.

68040+ has always returned either all zeros or all ones when reading unknown memory address.

Some 68020 configs may have returned something else but it has never been accurate. (Most likely this isn't random either but returns something from some buffer)

Waxhead 14 January 2021 14:04

Exodous : Yes , you are correct - but no minor tweak was apparently done which means that the behavior as far as real Amiga's goes should be "defined". E.g. we can at least say that most Amiga's did behave either so or so.

Toni: Well on my real hardware (which is packed away somewhere) I had a A500 with a GVP HD8+ and a Microbotics VXL030 accelerator (+ ramboard). The CPU was a 68EC030 at 40Mhz and my program worked perfectly (despite being coded badly) on both that CPU and the regular 68000. If I recall correctly it was only tested on kickstart 2.04 and 3.1.

I can't find any option in fs-uae-launcer that allows me to set anyting more accurate than what I have (some help about what options would be appreciated).
I tested with various CPU's and I was NOT able to replicate the behavior you describe. I got all 0xFF back all the time.

And I talked with my friend again - he says that no matter what CPU was used on WinUAE 3.20 or before it always worked e.g. always returned some random(ish) value. After 3.20 and with the latest version it return 0. He also tested with and without JIT and various other options. No effect.

We did a comparision back in 2017 ( picture: http://www.se2a1.net/tmp/UAE_vs_REAL.png )
This are screenshots of a program that shows byte reads from memory run under real amiga + uae 3.20 and uae 3.50+. The output is colored (how it is colored, we don't remember)

ROW 1 = $BFE000 to $BFEF00
ROW 2 = $BFE001 to $BFEF01
ROW 3 = $BFD000 to $BFDF00
ROW 4 = $BFD001 to $BFDF01

There is a difference....

FrodeSolheim 14 January 2021 16:35

@Waxhead The easiest is to use one of the Amiga 1000, Amiga 500 or Amiga 600 models with default settings. Then you'll get a cycle-exact 68000. When you use the Amiga 4000 model, you get a CPU without cycle-exact (and without compatible/prefetch) by default, even if you change the CPU model.

Toni Wilen 14 January 2021 17:01

I think you only got "lucky" with your board. I just tried A500 + Hurricane 530 and only get $FF. It probably depends on board's data buffers and how they work.

Waxhead 14 January 2021 17:23

@FrodeSolheim: Ok thanks, this is about what I have done so I should be good.

@Toni Wilen: Ok understand, but I got a friend that has many Amiga's. I'll ask him if we can try this out on MANY machines. A500, A1200 etc... it will probably take some time but if we get this done it will be interesting to see the results!

Toni Wilen 14 January 2021 17:25

Quote:

Originally Posted by Waxhead (Post 1453792)
@Toni Wilen: Ok understand, but I got a friend that has many Amiga's. I'll ask him if we can try this out on MANY machines. A500, A1200 etc... it will probably take some time but if we get this done it will be interesting to see the results!

Probably every accelerator board can have slightly different behavior :)

I have lots of A1200 boards (and other models and everything) but testing is so boring..

Actually _every_ undefined address space should be checked. Which makes it even more boring..

EDIT: This needs two tests: one that reads register multiple times in a loop and another that reads it one by one not in loop. Because what usually happens is that data buffer(s)/latches keep the old value and when reading memory address that does not drive the bus, it reads the buffered value. Or all zero or all one if there are pullup or pulldown resistors. Two tests are needed because we want to see if data is always the same when CPU does not do any other accesses (=whole loop in caches) and if CPU prefetches affect the result.


All times are GMT +2. The time now is 14:19.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.

Page generated in 0.04540 seconds with 11 queries