WinUAE 3.2.0 beta series

[AMIGASYSTEM]

The problem is not only on the GUI, even if "rarely", It does well on Slideshow images (process startup-sequence).

It may be that many do not make case this little problem, if no one here in this issue, then there is something strange in my computer

[Dunny]

Originally Posted by AMIGASYSTEM

The problem is not only on the GUI, even if "rarely", It does well on Slideshow images (process startup-sequence).

It may be that many do not make case this little problem, if no one here in this issue, then there is something strange in my computer

If it happens to you, then it happens to everyone. That's how emulation works.

What Toni is saying is that the monitors and TVs that we used to plug into our Amigas back in the past couldn't show you all of the video frame that the Amiga could generate, as it was too big. You didn't see the corruption because it happened off the bottom of the monitor screen.

WinUAE can show you the entire screen.

D.

[AMIGASYSTEM]

Originally Posted by Dunny

If it happens to you, then it happens to everyone. That's how emulation works.

What Toni is saying is that the monitors and TVs that we used to plug into our Amigas back in the past couldn't show you all of the video frame that the Amiga could generate, as it was too big. You didn't see the corruption because it happened off the bottom of the monitor screen.

WinUAE can show you the entire screen.

D.

True what you say, use WinUAE for a long time, practically since he was born, and I can assure you that until some time ago this was not the case.
After copying the entire system WinUAE (Entire Directory, HD,Roms, config etc..) of other body PC (laptop), suggests that the problem It lies precisely in that directory.

EDIT:

I add that WinUAE is more than perfect, I did a quick test with the system A400/0040 AfA 4.7, and I must say it's a show, i am attaching a small video (watch in HD quality)

[ Show youtube player ]

[Toni Wilen]

http://www.winuae.net/files/b/winuae_3200b13.7z
http://www.winuae.net/files/b/winuae64_3200b13.7z (64-bit)

Beta 13:

- SCSI emulation INQUIRY command didn't clear old data in output buffer (b7)
- Do not abort uaehf.device RDB parsing if drive init or bad block list is set.
- A2386SX 16M+ memory size crash fix.
- Implemented previously empty QEMU byteswap function, fixes 16-bit Cirrus Logic VGA text mode.
- zlib and libpng (used by screenshot function) updated to latest versions.
- Added PC 3.5" HD 21 sectors/track format to PC floppy size autodetection list. (DMF format)
- Renamed GUI Flash RAM file title, it is also used for A2286/A2386SX CMOS RAM.
- Big Aranym JIT merge. 64-bit version JIT supported. Includes big 32-bit JIT changes. May cause breakage. (Frode) PPC support is not (yet) 64-bit compatible.

64-bit compatible JIT notes:

Use this thread: http://eab.abime.net/showthread.php?t=79762 to report following JIT related issues:
- 32-bit JIT works but 64-bit JIT crashes/works differently etc.
- 32-bit JIT works differently than in previous beta. (=before JIT merge)

Do not use above thread for non-JIT issues.

- 2G of Amiga address space available (vs ~1G to ~1.5G in 32-bit version under 64-bit OS). Because JIT still requires Amiga address space inside first 4G of host process address space and Windows allocates few pages in the middle of first 4G, 2G is the current max. Technically this is not a problem because AmigaOS is not really designed to support RAM at 2G-4G of address space, programs may use signed pointers and some exec functions use address bit 31 for error state. (In theory 3G may be possible later if it is really needed)
- Use "UAE" RAM allocation mode (not "Real") if you want max available Z3 RAM (up to 1.5G. Z3 RAM + RTG VRAM + 256M must be less than or equal to 2G. Anything more = crash.
- 64-bit JIT FPU is not fully functional yet. Do not enable.

[AnnaWu]

Thanks Toni.

- zlib and libpng (used by screenshot function) updated to latest versions.

No need any new additional libraries, right?

[Neil79]

[FrodeSolheim]

Originally Posted by AnnaWu

No need any new additional libraries, right?

These are statically linked into WinUAE, so yes, you are right

[AnnaWu]

Originally Posted by FrodeSolheim

These are statically linked into WinUAE, so yes, you are right

Understand, thanks FrodeSolheim.

[ero__]

I'm using win7 x64. What ram config can I use?

[Toni Wilen]

Originally Posted by ero__

I'm using win7 x64. What ram config can I use?

Missing context error. What do you want to do?

[ero__]

I want to use os 4.0 with more than 128 megs of ram with cppc. When I use with UAE allocation mode with 64 bit version of winuae; sometimes it can't find q-emu, sometimes it won't start (HALT3).

[thomas]

Originally Posted by ero__

I want to use os 4.0 with more than 128 megs of ram with cppc.

You can't. CPU slot cannot have more than 128 MB (limited by design) and other RAM is not supported by OS 4.

[FrodeSolheim]

Originally Posted by ero__

I want to use os 4.0 with more than 128 megs of ram with cppc. When I use with UAE allocation mode with 64 bit version of winuae; sometimes it can't find q-emu, sometimes it won't start (HALT3).

Also, you cannot use QEMU-UAE with 64-bit WinUAE / 64-bit FS-UAE on Windows yet. 64-bit QEMU-UAE only works properly on Linux and OS X at the moment.

[hrmes]

Time for Hyperion to allow the use of ZorroIII memory as general purpose RAM in OS4 instead of just as swap buffer.
If they don't do it I'm sure someone will create an OS4 patch sooner or later...

[FOL]

Originally Posted by hrmes

Time for Hyperion to allow the use of ZorroIII memory as general purpose RAM in OS4 instead of just as swap buffer.
If they don't do it I'm sure someone will create an OS4 patch sooner or later...

Apparently its to slow to use as system ram, but fine for swap.

[hrmes]

Yes, in real classic Amigas. In WinUAE there is no distinction in speed between Zorro and CPU slot ram.

[FOL]

Originally Posted by hrmes

Yes, in real classic Amigas. In WinUAE there is no distinction in speed between Zorro and CPU slot ram.

Indeed, but they wont do it for Classic Emulation.

[oissery77]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae_3200b13.7z
http://www.winuae.net/files/b/winuae64_3200b13.7z (64-bit)

Beta 13:
- Do not abort uaehf.device RDB parsing if drive init or bad block list is set.

Hello Toni,

To continue our exchange related to my topic:
http://eab.abime.net/showthread.php?t=79697

I don't have anymore the RDB parse error in winuae.log but the CF can't boot. I've tried to restore the RDB after booting in WB 2.1 with floppy using this command:
driveinit scsi.device 0
the log of the shell says "done" but with no success after reboot(this command has worked to restore RDB on real amiga before, result of this command : scsi.device on reboot is again oktagon.device.

I've put in attachment the winuae.txt file.
=> RDB: checksum error PART block 189

[Toni Wilen]

Originally Posted by oissery77

I've put in attachment the winuae.txt file.
=> RDB: checksum error PART block 189

Either it is really corrupted or oktagon driver accepts bad checksums or something even weird.

My guess corruption due to bug in driveinit, also for some reason RDB driveinit block is still set even after you used driveinit command to remove the driver from RDB..

http://www.winuae.net/files/b/winuae.7z dumps whole block contents to log if checksum error. Perhaps it helps to see the real issue.

[B14ck W01f]

In the last stable release, I was able to install Amiga Unix 2.1 using the exact config I attached below. However, everything changed since Beta 7 onwards. The installation whinges about two missing files on the tape, then aborts. This occurs no matter how many fresh copies of your tape I used.