WinUAE 2.7.0 beta series

[mark_k]

Originally Posted by Toni Wilen

(not yet interested in downloading install iso)

I think any ISO should do for this test, since the problem seems to be with the installer detecting the CD drive. But if you do decide to download an actual Debian ISO, the smallest is the ~37MB business card ISO.

Redownload winuae.zip and test again (same commad line, there should be more logging now). Could you also test which beta broke it?

Will do. As for which beta broke the installer CD detection, that might be tricky because of the hang-with-lost-interrupt issue that was in at least beta 7. But I'll try. Edit to add: the lost interrupt problem was present in all betas.

Here's the log output with the new winuae.exe.

15-414 [20402 227-096]: CMD=00
15-414 [20402 000-099]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-415 [20402 226-109]: CMD=00
15-415 [20402 000-111]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-416 [20402 025-138]: CMD=43
15-416 [20402 225-140]: SCSIEMU 0: 43.02.00.00.00.00.00.00.04.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-416 [20402 226-142]: -> DATAOUT=4 ST=0 SENSELEN=0
15-417 [20402 165-152]: CMD=43
15-417 [20402 225-152]: SCSIEMU 0: 43.02.00.00.00.00.00.00.14.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-417 [20402 226-155]: -> DATAOUT=20 ST=0 SENSELEN=0
15-418 [20402 175-170]: CMD=43
15-418 [20402 225-170]: SCSIEMU 0: 43.02.00.00.00.00.00.00.0C.40.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-418 [20402 226-173]: -> DATAOUT=12 ST=0 SENSELEN=0
15-418 [20402 226-188]: CMD=51
15-419 [20402 000-190]: SCSIEMU 0: 51.00.00.00.00.00.00.00.02.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-419 [20402 224-192]: -> DATAOUT=2 ST=0 SENSELEN=0
15-419 [20402 148-202]: CMD=51
15-419 [20402 228-202]: SCSIEMU 0: 51.00.00.00.00.00.00.00.22.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-419 [20402 223-205]: -> DATAOUT=34 ST=0 SENSELEN=0
15-420 [20402 227-216]: CMD=52
15-420 [20402 223-217]: SCSIEMU 0: 52.01.00.00.00.01.00.00.08.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-420 [20402 225-220]: -> DATAOUT=8 ST=0 SENSELEN=0
15-421 [20402 225-230]: CMD=52
15-421 [20402 228-230]: SCSIEMU 0: 52.01.00.00.00.01.00.00.1C.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-421 [20402 226-233]: -> DATAOUT=28 ST=0 SENSELEN=0
15-421 [20402 225-247]: CMD=00
15-421 [20402 225-247]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-422 [20402 226-261]: CMD=00
15-422 [20403 000-000]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-428 [20403 223-010]: CMD=00
15-429 [20403 223-010]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-430 [20403 225-046]: CMD=28
15-430 [20403 225-046]: SCSIEMU 0: 28.00.00.00.00.10.00.00.01.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-431 [20403 223-064]: -> DATAOUT=2048 ST=0 SENSELEN=0
15-432 [20403 227-091]: CMD=28
15-432 [20403 224-093]: SCSIEMU 0: 28.00.00.00.00.11.00.00.01.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-432 [20403 226-097]: -> DATAOUT=2048 ST=0 SENSELEN=0
15-433 [20403 147-134]: CMD=28
15-434 [20403 151-137]: SCSIEMU 0: 28.00.00.00.00.D8.00.00.01.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-435 [20403 000-168]: -> DATAOUT=2048 ST=0 SENSELEN=0
15-438 [20403 225-249]: SCSI command 2B, no direction specified!
15-438 [20403 226-252]: CMD=2b
15-438 [20403 223-254]: SCSIEMU 0: 2B.00.00.00.27.DE.00.00.00.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-439 [20403 225-257]: CDEMU: unsupported scsi command 0x2B
15-439 [20403 225-258]: -> SENSE STATUS: KEY=5 ASC=20 ASCQ=00
15-439 [20403 227-261]: -> DATAOUT=-1 ST=2 SENSELEN=18
15-453 [20404 225-021]: CMD=03
15-453 [20404 225-021]: REQUEST SENSE length 18 (18)
15-453 [20404 225-021]: REQUEST SENSE 18, 70.00.05.00.00.00.00.0B.00.00.00.00.20.00.00.00.00.00
15-466 [20404 226-233]: SCSI command 2B, no direction specified!
15-466 [20404 223-235]: CMD=2b
15-466 [20404 226-237]: SCSIEMU 0: 2B.00.00.00.14.C9.00.00.00.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-466 [20404 226-238]: CDEMU: unsupported scsi command 0x2B
15-467 [20404 225-239]: -> SENSE STATUS: KEY=5 ASC=20 ASCQ=00
15-467 [20404 225-239]: -> DATAOUT=-1 ST=2 SENSELEN=18
15-472 [20405 000-004]: CMD=03
15-473 [20405 000-026]: REQUEST SENSE length 18 (18)
15-474 [20405 000-026]: REQUEST SENSE 18, 70.00.05.00.00.00.00.0B.00.00.00.00.20.00.00.00.00.00
15-815 [20425 125-213]: CMD=00
15-815 [20425 000-224]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-815 [20425 224-245]: CMD=00
15-815 [20425 227-247]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-816 [20425 158-258]: CMD=00
15-816 [20425 224-258]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-820 [20426 000-007]: CMD=00
15-820 [20426 000-007]: SCSIEMU 0: 00.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=0861A784 LEN=262144
15-821 [20426 226-027]: SCSI command 2B, no direction specified!
15-821 [20426 000-029]: CMD=2b
15-821 [20426 225-031]: SCSIEMU 0: 2B.00.00.00.00.10.00.00.00.00.00.00 CMDLEN=10 DATA=0861A784 LEN=262144
15-821 [20426 226-032]: CDEMU: unsupported scsi command 0x2B
15-821 [20426 227-034]: -> SENSE STATUS: KEY=5 ASC=20 ASCQ=00
15-821 [20426 224-036]: -> DATAOUT=-1 ST=2 SENSELEN=18
15-823 [20426 103-067]: CMD=03
15-823 [20426 224-069]: REQUEST SENSE length 18 (18)
15-823 [20426 000-071]: REQUEST SENSE 18, 70.00.05.00.00.00.00.0B.00.00.00.00.20.00.00.00.00.00

[Toni Wilen]

Originally Posted by Retroplay

Latest WinUAE 2.7.0b7 gives me a guru if I run "Icon Info" through DirOpus in ClassicWB 3.1 Full.

Program failed (error #80000004).
Guru Error: 8000 0004 Task: 10318E10

Previous WinUAE 2.7.0b6 works and doesn't guru.

Logs from b6 and b7 attached.

Only if CPU is 68030? (What happens if 68020 or 68040?)

[Retroplay]

No it's not just 68030, same thing happens with 020 and 040 cpu.

[Retro-Nerd]

Then maybe related to Scalos somehow? I can use the Icon Info in DirOpus without problems in CWB LITE = normal WB.

[Retroplay]

I use the same HDF (RDB + PFS3-AIO) in b6 and b7 and it only crashes when I use b7.
My real A1200 has an identical ClassicWB Full setup (my UAE config is based on my A1200) and that's working too.

[Retro-Nerd]

Sure, but i meant the changes in b7 maybe causes the problems with Scalos now since in CWB LITE it works fine, b6 and b7.

[Toni Wilen]

Originally Posted by mark_k

I think any ISO should do for this test, since the problem seems to be with the installer detecting the CD drive. But if you do decide to download an actual Debian ISO, the smallest is the ~37MB business card ISO.Will do. As for which beta broke the installer CD detection, that might be tricky because of the hang-with-lost-interrupt issue that was in at least beta 7. But I'll try. Edit to add: the lost interrupt problem was present in all betas.

Fixed. Yet again "only worked accidentally". Returned sense data was not always correct which apparently made it to work in older versions. sort of...

Debian assumes SEEK (10) (0x2b) does not return "invalid command" error. But SCSI spec says SEEK is optional command. (No idea why it even uses SEEK command, it is not needed for accessing CD)

btw, it did require Debian install CD. It did complain if CD was incorrect.

[Retroplay]

Originally Posted by Retro-Nerd

Sure, but i meant the changes in b7 maybe causes the problems with Scalos now since in CWB LITE is works fine, b6 and b7.

Perhaps idk.
I made a couple of videos, pictures say more than a thousand words.
[ Show youtube player ] - OK
[ Show youtube player ] - Guru

[mark_k]

Originally Posted by Toni Wilen

Debian assumes SEEK (10) (0x2b) does not return "invalid command" error. But SCSI spec says SEEK is optional command. (No idea why it even uses SEEK command, it is not needed for accessing CD)

I didn't check later MMC spec documents, but SEEK is shown as mandatory for ATAPI drives in at least MMC2. Google mmc2r11a.pdf, see page 303 (PDF page 323). Also in the SCSI-2 spec (s2-r10l.pdf) on page 299 (PDF page 335) it says "SEEK commands may be issued to any logical block address within the reported capacity of the disc." However, on page 305/341 it does list SEEK (6/10) as optional.

I don't know whether it's the Debian installer or the Linux kernel issuing the SEEK commands, but doing that does make some sense. After finishing reading one file, issuing a SEEK to the beginning of the next file to be read, before unpacking/processing the first file data, could save time. Older CD drives can have pretty long seek times.

Edit to add: in MMC3 and MMC4, if a drive supports the CD audio external play feature, then SEEK (10) is mandatory. In MMC5 that feature is mentioned in Annex E Legacy Specifications (see page 659/711 of mmc5r04.pdf).

[Toni Wilen]

1996 ATAPI spec does say SEEK is mandatory.

ATAPI vs SCSI does have weird differences. (I think most common is ATAPI must not have MODE SENSE (6), only (10), SCSI must have both)

[mark_k]

Something went wrong with the power supply frequency setting between 2.7.0b2 and 2.7.0b3.

I used an NTSC A3000/040 config with Compatible Settings checked, and booted my Debian installer HDF. With 2.7.0b2 or earlier amiboot reports the power supply frequency as 60Hz. But with 2.7.0b3 or later it reports it as 50Hz.

[Toni Wilen]

Originally Posted by mark_k

Something went wrong with the power supply frequency setting between 2.7.0b2 and 2.7.0b3.

Fixed.

[Toni Wilen]

Originally Posted by Retroplay

Latest WinUAE 2.7.0b7 gives me a guru if I run "Icon Info" through DirOpus in ClassicWB 3.1 Full.

Illegal instruction: 013c at 1016D978 -> 00F80B2A

I didn't know "btst dn,#<data>" is valid instruction. I fixed some old bugs in table68k and broke this instruction..

Fixed in winuae.zip.

[Retroplay]

Thanks Toni, that did the trick.

[mark_k]

I finally managed to get Debian installed with X, Openbox and fvwm95. I have uploaded an HDF (~138MB archive) to and Multiupload.

Networking is set up to use A2065/DHCP and /etc/apt/sources.list uses archive.debian.org, so you should be able to apt-get various packages, even OpenOffice, Mozilla, GNOME or KDE if you have a really fast PC. (I plan to install mt-st to experiment with the SCSI tape drive emulation.)

Boot the HDF and at the CLI prompt type Boot-sda1-Cirrus to run Linux.

One normal user is configured in addition to root.
root password: root
user1 password: password

Eventually a graphical login prompt will appear on an 8-bit 1024x768 RTG screen. Enter user1 and password. Once the Openbox window manager has loaded (the pointer changes from X to an arrow) right click to bring up the Openbox menu. From there you can run fvwm95 or various other programs.

I noticed that something (maybe WinUAE converting the 8-bit RTG screen to 32-bit for display?) takes a lot of CPU time. Compare the CPU/FPS indicator readings with the RTG screen showing, and (after pressing End+F9) with the blank native chipset display. Does WinUAE rewrite the entire RTG display each frame, even if the display hasn't changed since the previous frame?

On switching to the native chipset display with End+F9, the HD/CD indicators are missing from the status bar.

If you click exit (or run fvwm95 then exit that), get a crash/hang with log text like this

23-381 [29873 000-000]: GFXBOARD 640x480x8
23-427 [29873 000-000]: window already open (484x53 640x480)
23-494 [29873 000-000]: Device name: 'NVIDIA GeForce Go 7300' 7000f000c1a02.0
23-503 [29873 000-000]: D3D9: 00000056 ALPHA DYNAMIC 
23-503 [29873 000-000]: D3D9: PS=2.0 VS=2.0 640*480*0p VS=0 B=1I 32-bit 0
23-503 [29873 000-000]: Using non-shader version
23-504 [29873 000-000]: D3D9: 640*480 main texture, depth 32
23-505 [29873 000-000]: Buffer size (640*480) RTG
23-509 [29873 000-000]: RTGFREQ: 262*59.9579 = 15708.9631 / 60.0 = 262
23-510 [29873 000-000]: POS (0 0 640 480) - (0 0 640 480)[640,480] (0 0)
23-553 [29873 033-169]: Exception 3 (80589f90) at 80589f2a -> 0! ???????? at 2626
24-734 [29941 000-064]: winuae_inactive(0)
48-727 [31377 000-000]: GFXBOARD 1024x768x8
48-752 [31377 000-000]: window already open (484x53 1024x768)
48-815 [31377 000-000]: Device name: 'NVIDIA GeForce Go 7300' 7000f000c1a02.0
48-828 [31377 000-000]: D3D9: 00000056 ALPHA DYNAMIC 
48-828 [31377 000-000]: D3D9: PS=2.0 VS=2.0 1024*768*0p VS=0 B=1I 32-bit 0
48-828 [31377 000-000]: Using non-shader version
48-830 [31377 000-000]: D3D9: 1024*768 main texture, depth 32
48-831 [31377 000-000]: Buffer size (1024*768) RTG
48-832 [31377 000-000]: RTGFREQ: 262*59.9579 = 15708.9631 / 60.0 = 262
48-832 [31377 000-000]: POS (0 0 1024 768) - (0 0 1024 768)[1024,768] (0 0)

[emufan]

really cool, mark_k.
14.54 BogoMips - thats almost frozen
but it is not so slow at all - windows moving/refresh is fast, typing in the console and textoutput is also no problem.
i did exit fvwm95 using the start-menu option - no crash, it came back to the login screen.
( winuae 2.7.0 public beta 7, 2013.09.01 - with your config file, nothing changed )

thanks for the bootfile/config

Edit: after exiting fvwm95, it took a while until the X login screen came up again, until this happened, the screen/mouse was frozen - maybe 1-2 minutes, then the login screen came back.
one of those Exceptions i also have in my log:

14-469 [107813 000-203]: winuae_active(0)
28-325 [108641 000-000]: GFXBOARD 640x480x8
28-352 [108641 000-000]: window already open (59x117 640x480)
28-397 [108641 000-000]: Device name: 'ATI Radeon HD 5670' 80011000a04a7.0
28-441 [108641 000-000]: D3D9Ex: 00000056 ALPHA DYNAMIC SCANLINE 
28-441 [108641 000-000]: D3D9Ex: PS=3.0 VS=3.0 640*480*0p VS=0 B=1I 32-bit 0
28-441 [108641 000-000]: D3D9Ex: Attempting to load 'D:\WinUAE\plugins\filtershaders\direct3d\_winuae.fx'
28-473 [108641 000-000]: D3D9Ex: pixelshader filter 'D:\WinUAE\plugins\filtershaders\direct3d\_winuae.fx':-1 enabled
28-476 [108641 000-000]: D3D9Ex: 640*480 main texture, depth 32
28-476 [108641 000-000]: Buffer size (640*480) RTG
28-478 [108641 000-000]: RTGFREQ: 262*59.9579 = 15708.9631 / 60.0 = 262
28-478 [108641 000-000]: POS (0 0 640 480) - (0 0 640 480)[640,480] (0 0)
28-500 [108641 226-186]: Exception 3 (80589f90) at 80589f2a -> 0! ⸮⹜尮敮捷異挮灰 at 2626
53-552 [109871 000-197]: winuae_inactive(0)
53-657 [109875 000-105]: winuae_active(0)

00-737 [110255 000-000]: GFXBOARD 1024x768x8
00-747 [110255 000-000]: window already open (59x117 1024x768)
00-791 [110255 000-000]: Device name: 'ATI Radeon HD 5670' 80011000a04a7.0
00-835 [110255 000-000]: D3D9Ex: 00000056 ALPHA DYNAMIC SCANLINE 
00-835 [110255 000-000]: D3D9Ex: PS=3.0 VS=3.0 1024*768*0p VS=0 B=1I 32-bit 0
00-835 [110255 000-000]: D3D9Ex: Attempting to load 'D:\WinUAE\plugins\filtershaders\direct3d\_winuae.fx'
00-867 [110255 000-000]: D3D9Ex: pixelshader filter 'D:\WinUAE\plugins\filtershaders\direct3d\_winuae.fx':-1 enabled
00-874 [110255 000-000]: D3D9Ex: 1024*768 main texture, depth 32
00-874 [110255 000-000]: Buffer size (1024*768) RTG
00-876 [110255 000-000]: RTGFREQ: 262*59.9579 = 15708.9631 / 60.0 = 262
00-876 [110255 000-000]: POS (0 0 1024 768) - (0 0 1024 768)[1024,768] (0 0)
47-055 [112844 000-157]: winuae_inactive(0)

[mark_k]

I've uploaded another Debian HDF here, ~119MB. This one doesn't have X installed but does have fbset, which is used to change the console display mode. (If you already downloaded the larger HDF with X, you can just boot that and do apt-get install fbset.)

Possible modes are listed in /etc/fb.modes

With Picasso IV, it seems that the sense of the native/RTG switch is reversed, i.e. Linux tries to switch to RTG display => WinUAE switches to native instead. You can press End+F9 to manually switch to the correct display. Once booting gets to the stage where you're asked to log in, WinUAE switches back to the native chipset display. I can again press End+F9 to switch back to RTG. If after logging in I change the RTG console mode, e.g. by doing
fbset 1024x768-60
WinUAE switches back to the native display again.

One of the modes in the default fb.modes is 768x576-75 which is 32-bit. With both Piccolo and Picasso IV, that mode appears garbled/corrupted, see pic. With Piccolo SD64 however the mode isn't garbled (but all text is cyan/turquoise instead of light grey; maybe that's normal?). Changing the 768x576 mode definition in /etc/fb.modes to 8 or 16 bit, those modes do display correctly.

(This problem isn't specific to that resolution. You could edit the entry for 640x480-60 to be 32-bit, set that mode and get the garbled display.)

[emufan]

i have the same here - using now winuae 2.7.0 beta 7, 2013.09.18
emulating "Piccolo SD64 Zorro II 4MB VRam size":
first screenshots shows framebuffer mode 768x576-75 in 32 bit.
the screen does not get updated on the right 2/3 side - only the left 1/3 of the screen gets refreshed.
(just a long line of letters, then press *enter*)
second screenshot shows 768x576-75 in 8 bit . text color is normal and the whole screen gets refreshed.
maybe this helps somehow.

edit: if you issue in the console: cat /proc/fb you see something like:
0 Cirrus
1 Amiga ECS

( dont have a screenshot atm). I should read more about the framebuffer commands - is it possible the access the native "amiga ecs" modes?
is it worth to explore?

man fbset:

Frame buffer device nodes: 
-fb <device> 
device gives the frame buffer device node. If no device via -fb is given, /dev/fb0 is used

so something like that:
fbset -fb /dev/fb1 768x576-75
may work - does not work. see 3rd screenshot

[amilo3438]

Originally Posted by emufan

using now winuae 2.7.0 beta 7, 2013.09.18

Where you found a link for version 18.09.2013 ?!

[emufan]

Originally Posted by amilo3438

Where you found a link for version 18.09.2013 ?!

http://www.winuae.net/files/b/winuae.zip