Altirra 3.20 released

[Faicuai]

3 hours ago, phaeron said:

http://www.virtualdub.org/beta/Altirra-3.90-test10.zip

http://www.virtualdub.org/beta/Altirra-3.90-test10-src.zip

 

Enables support for hardware H.264 encoders in Media Foundation and adds support for YUV conversion within the emulator to bypass the slow stock color space converter. The resampler/conversion routines have been further optimized and the pipeline is now YUV-conversion > upsampling > chroma subsampling, and a faster sample/buffer allocator has been added. Combined with hardware encoding when available, this should significantly reduce CPU usage during encoding. Use the x64 (AMD64) build for best results as the image processing routines run faster in 64-bit. On my XPS 13 potato, this gets 720p60 encoding below 40% of a CPU core.
 

Unfortunately, Media Foundation does not have built-in support for setting the color space properties on the H.264 stream. The emulator always uses BT.709 matrix coefficients when encoding WMV7/9 or H.264, which should be a bit more consistent than previously when msvproc.dll might have used BT.601 for some resolutions. H.264 is still recommended over WMV7/9, with WMV9 being particularly slow -- the profiler shows some unexpectedly poor motion prediction routines. Might be your only option if you are trying to use this on Vista, however.

 

AltirraOS has been revved to 3.22, raises the memory check limit from 48K to 52K on the 800 version.

 

Odd. You're getting to the point where the networking code is establishing the connection but not the emulated modem 'connecting', i.e. ATA or ATS0=1 auto-answer completing to CONNECT. The emulator's not supposed to lock up since networking is asynchronous on a worker thread, but I can't tell where it might be jamming up just yet. I would try a localhost connection with a plain terminal emulator first to see if you can get an incoming connection to work. BobTerm is a good one to use, just change the translation mode from Atari to Ascii and enter plain Hayes compatible modem commands.

 

The Media Foundation encoder only supports 4:2:2 and 4:2:0, it does not support 4:4:4. Even in that case, I'm not inclined to support chroma subsampling formats other than the most common as it would unnecessarily increase the complexity of this feature. 4:2:0 is the common format for streaming video and the upload format recommended by YouTube, and for hardware encoding support. Those who have stricter requirements on their video encoding can capture video at the raw size to one of the lossless formats and post-process it. This won't be as convenient for everyone, but the point is not to spend too much effort on the video recorder. Already spent more time than I had planned on a spur of the moment feature, but at least video recording in 3.90-test10+ should be much more accessible than in 3.20, given video players unfortunately still shipping a broken ZMBV decoder.

 

Shouldn't be that as neither System Protection nor Controlled Folder Access prevent a program from seeing the files, only writing to them. Having CFA enabled, for example, lets a program see the files but causes the Save As dialog to report "file not found" when you try to save into Documents (which they still haven't fixed despite me reporting it years ago, argh). Do you see the files if you change the file filter to All Files?

 

This is VERY nice (!)

 

Just catching up since 3.20 OS-loads... now testing on real HW... 

 

Will fire-up HW video-encoding (H.264) on the Z840 / Nvidia P4000 just for a bit of fun... already know exactly what to record...

 

Cheers and have a GREAT week!

[_The Doctor__]

bah... 10's media foundation, what a mess. surprised your going there... I guess it's a  re usable skill if employed for other work... I just don't think whats in it for 10 etc. is exactly ready for prime time... they keep pushing this stuff though. I think of 10 as terrible trouble any more. Reverted everything I could below it. Just when it was all coming together and looking great I am reading this and wondered about it. oh well it is what it is.

Everything else was looking positively excellent.

Edited September 9, 2019 by _The Doctor__

[+Nezgar]

Initial messing around with 3.90-test10 is crashing when I run the Self-Test Memory test after booting SpartaDOS 3.2d...

 

6502/6502C crashes with popup

65C02 crashes with green squares disapearing (only the active 'white' square remains)

65816 glitches out then blanks the screen

 

Hardware type: 65XE/130XE

Atari XL/XE OS Rev 2 or 3

Altirra or Atari BASIC...

 

But then I tried it again without booting DOS, and it's fine...

 

Then I tried the same disk on a real 130XE, and SAME thing... so false alarm But curious I've never come across this before. Wonder why... Maybe its clobbering some DLI code.

[+Nezgar]

Aaaand solved. Good ol' "KEY OFF" before entering self test and it works just fine.

 

I now return you to regularly scheduled programming...

[Mclaneinc]

Re seeing the files, no, If I change it to zip or all files (the default) I still see no files, will reset the settings and try again and let you know..

 

EDIT: I don't get it, I spent a while shutting Altirra down, rebooting windows and I could not see the files. So I updated to beta 10 and the files are viewable, now I know you did no work on it so its not the update, I then went back to beta 9 and the bloody files are visible...

 

This isn't Dallas, I didn't wake up in the shower, I swear it was refusing to show files....arggh....Scared the daylights out of me that I must have had a virus so scanned with 3 different rootkit and sys checkers, all zero result..My only thought is that installed Sandboxie to have a look at it and and uninstalled it...Maybe that played around with stuff...

 

Oh well it works, sorry for the erroneous report...

Edited September 9, 2019 by Mclaneinc

[Faicuai]

20 hours ago, Faicuai said:

This is VERY nice (!)

 

Just catching up since 3.20 OS-loads... now testing on real HW... 

 

Will fire-up HW video-encoding (H.264) on the Z840 / Nvidia P4000 just for a bit of fun... already know exactly what to record...

 

Cheers and have a GREAT week!

Whoaa!!

 

Found two issues, so far, with 3.22 OS-load (test XLXE and 800/Colleen variants):

 

1. MAJOR bug/issue with SIO handling, boot-time, with IndusGT. The problem is simple: slide in boot disk, then boot system with {OPTION} key pressed, and you will immediately see a long sequence of {Sector Reads} + {device NAK or polling} + {Sector Reads} +...+ {Altirra OS Boot Screen}. Sometimes boot goes through (painfully) and others simply fails. (less of a problem on 3.17, and no problem I could detect with SDrive, or when booting with XEr03, XEr04, Q-Meg 4.04, OSN RamRod, OS.b loads ).
2. The program NATIONAL FLAGS shows significant screen corruption when displaying ANY flag, from any country. This program is really important because it is one of the very few we can objectively use to perceptually calibrate color rendition on host computer (e.g. many of the flags represented there do exist and have not changed, and the program's color rendition was modelled after the flags' true colors which are all well known, therefore, it is easy to determine color reproduction "errors").

Other areas tested:

1. As far as 52K linear-ram boundary, as well as compatibility with SDX QuickED, it definitely working.
2. My FP-package profiler utility continues to crash with Altirra FP + TurboBasic. but I don't really consider that a pressing issue (issue seems way too tangled and buried on TurboBasic side, than Altirra OS / FP).

That's all for now...

 

 

Edited September 9, 2019 by Faicuai

[Gnef]

Any hints on best hardware for M.U.L.E. for accurate emulation?  Catching the wumpus does bad things.  Scrambled screen once.  Hung virtual atari on the second try.

 

Running 400/800 Computer.  NTSC.  Mule.atr.  Default settings overall.

 

3.20 64bit

 

Was running Debugger and see a CPU Illegal Instruction BF0E.  Something isn't happy.  Very reproducible on my system.

 

32 bit shows corruption, but several attempts did not crash it.

Edited September 11, 2019 by Gnef

[Gnef]

10 hours ago, Gnef said:

Any hints on best hardware for M.U.L.E. for accurate emulation?  Catching the wumpus does bad things.  Scrambled screen once.  Hung virtual atari on the second try.

 

Running 400/800 Computer.  NTSC.  Mule.atr.  Default settings overall.

 

3.20 64bit

 

Was running Debugger and see a CPU Illegal Instruction BF0E.  Something isn't happy.  Very reproducible on my system.

 

32 bit shows corruption, but several attempts did not crash it.

Well, an older version of Atari800win does the same thing, so maybe my copy of Mule.atr or one of my ROMs.

[Mclaneinc]

Most likely a bad crack?

 

Try this, remember its a protected disk so in Altirra under System / configure / disk make sure accurate sector timing is on and no Happy drives etc..

 

M.U.L.E. (1983)(Electronic Arts)(US)[disk].zip

[scotty]

Here is 17 copies of the game in ATR, XEX and Cassete images.  No two have the same checksum.  If you can not get any of these to run, it is not going to run.   

M.U.L.E.rar

[scotty]

3 minutes ago, Mclaneinc said:

Most likely a bad crack?

 

Try this, remember its a protected disk so in Altirra under System / configure / disk make sure accurate sector timing is on and no Happy drives etc..

 

M.U.L.E. (1983)(Electronic Arts)(US)[disk].zip 51 kB · 1 download

Oops, sorry Paul.   You sent yours as I was RARing mine.  Did not see it till after I sent it.

 

[Gnef]

3 hours ago, Mclaneinc said:

Most likely a bad crack?

 

Try this, remember its a protected disk so in Altirra under System / configure / disk make sure accurate sector timing is on and no Happy drives etc..

 

M.U.L.E. (1983)(Electronic Arts)(US)[disk].zip 51 kB · 1 download

Thanks.  Resolved.

[Mclaneinc]

A pleasure to help

[phaeron]

On 9/9/2019 at 4:58 PM, Faicuai said:

Found two issues, so far, with 3.22 OS-load (test XLXE and 800/Colleen variants):

1. MAJOR bug/issue with SIO handling, boot-time, with IndusGT. The problem is simple: slide in boot disk, then boot system with {OPTION} key pressed, and you will immediately see a long sequence of {Sector Reads} + {device NAK or polling} + {Sector Reads} +...+ {Altirra OS Boot Screen}. Sometimes boot goes through (painfully) and others simply fails. (less of a problem on 3.17, and no problem I could detect with SDrive, or when booting with XEr03, XEr04, Q-Meg 4.04, OSN RamRod, OS.b loads ).
2. The program NATIONAL FLAGS shows significant screen corruption when displaying ANY flag, from any country. This program is really important because it is one of the very few we can objectively use to perceptually calibrate color rendition on host computer (e.g. many of the flags represented there do exist and have not changed, and the program's color rendition was modelled after the flags' true colors which are all well known, therefore, it is easy to determine color reproduction "errors").

Regarding National Flags, it is relying on undocumented behavior of the Atari OS, specifically the value of ADRESS after writing a byte to the screen:

  + 21233:188: 63 | A=01 X=05 Y=02 (     C) |     4417: 20 10 44  JSR $4410
    21233:188:101 | A=01 X=60 Y=02 (     C) |     441A: A9 0B     LDA #$0B
    21233:188:103 | A=0B X=60 Y=02 (     C) |     441C: 9D 42 03  STA ICCMD,X          ;$03A2
    21233:188:108 | A=0B X=60 Y=02 (     C) |     441F: A9 00     LDA #$00
    21233:188:110 | A=00 X=60 Y=02 (    ZC) |     4421: 9D 48 03  STA ICBLL,X          ;$03A8
    21233:189:  6 | A=00 X=60 Y=02 (    ZC) |     4424: 9D 49 03  STA ICBLH,X          ;$03A9
    21233:189: 11 | A=00 X=60 Y=02 (    ZC) |     4427: AD FB 02  LDA ATACHR
  + 21233:189: 15 | A=01 X=60 Y=02 (     C) |     442A: 20 56 E4  JSR CIOV
    21233:205:  8 | A=01 X=60 Y=01 (     C) |     442D: 60        RTS
- 21233:205: 14 | A=01 X=60 Y=01 (     C) |     46F8: 20 07 47  JSR $4707
    21233:205: 20 | A=01 X=60 Y=01 (     C) |     4707: A5 64     LDA ADRESS
    21233:205: 28 | A=50 X=60 Y=01 (     C) |     4709: 85 BA     STA $BA
    21233:205: 40 | A=50 X=60 Y=01 (     C) |     470B: A5 65     LDA ADRESS+1
    21233:205: 52 | A=00 X=60 Y=01 (    ZC) |     470D: 85 BB     STA $BB
    21233:205: 62 | A=00 X=60 Y=01 (    ZC) |     470F: 60        RTS

ADRESS is documented simply as Temporary Storage in the OS Manual and does not have a defined value after printing a character. Not sure I can work around this, would be a rather invasive change to rewrite the variable usage throughout the screen code. I'd be less inclined to try to support this than TBXL in terms of cost-benefit.

 

There's also something weird about the Start button handling in that program. Even on real hardware I get a corrupted screen about half the time pressing Start.

 

The Indus GT issue is a bit more interesting. Are you using enhanced or double density disks by chance and is the drive showing an error code? I'm seeing some weird issues in emulation where sometimes the drive doesn't successfully switch densities from single density to double density on read sector requests during boot, but I'd need to dig into the firmware to see what's causing this and I'm not sure it's the same as the issue you're seeing. The only pertinent change between 3.17 and 3.22 was a change I did in 3.20 for the boot screen to continue the boot process after a successful disk read instead of rebooting the OS, so it wouldn't cause Option state to be reset. The only time this should matter is if it gets to the boot screen, as that won't even be invoked if the initial sector read succeeds. In emulation, this can be a problem if the drive doesn't init fast enough to service the initial disk read in time, but that's not usually a problem on real hardware where you would power on the disk drive first and then the computer.

 

[Faicuai]

1 hour ago, phaeron said:

Regarding National Flags, it is relying on undocumented behavior of the Atari OS, specifically the value of ADRESS after writing a byte to the screen:

  + 21233:188: 63 | A=01 X=05 Y=02 (     C) |     4417: 20 10 44  JSR $4410
    21233:188:101 | A=01 X=60 Y=02 (     C) |     441A: A9 0B     LDA #$0B
    21233:188:103 | A=0B X=60 Y=02 (     C) |     441C: 9D 42 03  STA ICCMD,X          ;$03A2
    21233:188:108 | A=0B X=60 Y=02 (     C) |     441F: A9 00     LDA #$00
    21233:188:110 | A=00 X=60 Y=02 (    ZC) |     4421: 9D 48 03  STA ICBLL,X          ;$03A8
    21233:189:  6 | A=00 X=60 Y=02 (    ZC) |     4424: 9D 49 03  STA ICBLH,X          ;$03A9
    21233:189: 11 | A=00 X=60 Y=02 (    ZC) |     4427: AD FB 02  LDA ATACHR
  + 21233:189: 15 | A=01 X=60 Y=02 (     C) |     442A: 20 56 E4  JSR CIOV
    21233:205:  8 | A=01 X=60 Y=01 (     C) |     442D: 60        RTS
- 21233:205: 14 | A=01 X=60 Y=01 (     C) |     46F8: 20 07 47  JSR $4707
    21233:205: 20 | A=01 X=60 Y=01 (     C) |     4707: A5 64     LDA ADRESS
    21233:205: 28 | A=50 X=60 Y=01 (     C) |     4709: 85 BA     STA $BA
    21233:205: 40 | A=50 X=60 Y=01 (     C) |     470B: A5 65     LDA ADRESS+1
    21233:205: 52 | A=00 X=60 Y=01 (    ZC) |     470D: 85 BB     STA $BB
    21233:205: 62 | A=00 X=60 Y=01 (    ZC) |     470F: 60        RTS

ADRESS is documented simply as Temporary Storage in the OS Manual and does not have a defined value after printing a character. Not sure I can work around this, would be a rather invasive change to rewrite the variable usage throughout the screen code. I'd be less inclined to try to support this than TBXL in terms of cost-benefit.

 

There's also something weird about the Start button handling in that program. Even on real hardware I get a corrupted screen about half the time pressing Start.

 

The Indus GT issue is a bit more interesting. Are you using enhanced or double density disks by chance and is the drive showing an error code? I'm seeing some weird issues in emulation where sometimes the drive doesn't successfully switch densities from single density to double density on read sector requests during boot, but I'd need to dig into the firmware to see what's causing this and I'm not sure it's the same as the issue you're seeing. The only pertinent change between 3.17 and 3.22 was a change I did in 3.20 for the boot screen to continue the boot process after a successful disk read instead of rebooting the OS, so it wouldn't cause Option state to be reset. The only time this should matter is if it gets to the boot screen, as that won't even be invoked if the initial sector read succeeds. In emulation, this can be a problem if the drive doesn't init fast enough to service the initial disk read in time, but that's not usually a problem on real hardware where you would power on the disk drive first and then the computer.

 

Alright.

 

Went ahead and performed even more testing, here's the bottom-line:

 

1. AmAzEd to learn that there is REAL undocumented stuff on the XL/XE OS load that does work (!)
2. NAT-Flags screen corruption (after repeated and franctic RESET presses) is cured with a simple SYS-RESET button).
3. Not being able to draw the flags, however, is a real bummer, because anything I see that smells-looks-&-walks like calling OS' draw/fill primitives, I immediately dispatch it to Altirra OS. Well, I guess it is what it is, and back to TurboBasic FP woes...
4. With respect to Altirra OS SIO-woes, the nature of the issue is a TIMING / hand-shaking one (e.g. there are no read-errors G4/G5 produced by the Indus, but, instead, just a bunch of SIO-farting, derived from aborted, sporadic sector reads and tons of re-polling along the way).
5. I DID test, HOWEVER, my pristine (and almost never used) 1050, and it works just fine. (UPDATE: just finished testing with UltraSpeed emulation layer pre-loaded on IndusGT and it WORKS fine with Altirra OS with single and medium-density disks, even if Altirra OS is NOT driving the Indus at 06 divisor). 
6. Test-disks have been all SINGLE-density, bottom-of-the-barrel 90KB ones, with no copy-protection, bad-sector tricks, etc.
7. A specific workaround to eliminate the problem (while still running Altirra OS) is to simply enable HSIO for D1 (test-drive) on PBI-Bios and VOILA! Absolutely all problems gone, but we are now bypassing the resident OS SIO routines.
8. Therefore, there is a specific problem in the {OS + Pokey + (Drive + ROM)} chain, when OS=Altirra, and Drive = Indus. However, change the OS variable to any other, and problem goes away.
9. Here are the actual ROMs I am using on my IndusGT drives, for your analysis / testing (they are 1.2 and 1.2-souped-up, BOTH failing):
   1. Indus GT 1.2.rom
   2. INDUS_GT-ROM12X-Intel2732A_3-Main.bin

Thanks, as usual, for your time and dedication... 

Edited September 12, 2019 by Faicuai

[Mclaneinc]

18 hours ago, scotty said:

Oops, sorry Paul.   You sent yours as I was RARing mine.  Did not see it till after I sent it.

 

 

No problem, the more the merrier

[Mclaneinc]

Hi Avery / any one..

Any way to stop Altirra's window dropping below another window when you drag and drop a file on Altirra..

 

Sort of ignore, it was a file inside a zip, files just in a dir don't force the window to go behind...

Edited September 14, 2019 by Mclaneinc
being an idiot..

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.90-test11.zip

http://www.virtualdub.org/beta/Altirra-3.90-test11-src.zip

• Amdek AMDC-I/II emulation (disk only, no printer).
• Fixed 6809 emulation bugs with 5-bit indexing, ADCB #imm, and JMP ext instructions.
• Fixed 6809 disassembly of LDX #imm instructions and some indirect modes.
• Disassembly window now supports function separation and peeking for 6809, 65C02, and 65C816.
• Fixed FDC Read Address command returning incorrect track/side on side 2.
• ATR8000 side select is now hooked up.
• Fixed logical-to-physical sector mapping on side 2 when using full disk emulators. There are now three separate modes depending on the drive: XF551 (side 2 reversed), ATR8000/Amdek (side 2 forward), and PERCOM (side 2 reversed by off by one).
• Indus GT write protect latch is now hooked up so disk change based density detection works, and added button combo for forcing density detection.
• Indus GT SIO ready sensing is now supported.
• Fixed multiple incompatible disk warnings in a row.

 

[+Nezgar]

11 minutes ago, phaeron said:

Fixed logical-to-physical sector mapping on side 2 when using full disk emulators. There are now three separate modes depending on the drive: XF551 (side 2 reversed), ATR8000/Amdek (side 2 forward), and PERCOM (side 2 reversed by off by one). 

What does "side 2 reversed by off by one" mean?

[+Philsan]

Hi Avery.

 

I made a fresh install of Altirra to check default configuration and I noticed three things.

 

1. Default overscan mode is "extended". I think it should be "normal", no TV shows extended overscan.

2. Default XL/XE machine has BASIC disabled. A friend of mine told me that this is not the real default mode and it's strange for a faithful emulator like Altirra. I told him that perhaps you made that decision to help newbies load games. But in fact it's not the default XL/XE behaviour.

3. My friend also told me that he doesn't undertand why you can make impossible configurations on System/Configure System/Firmware menu like Atari 400/800 + Atari Basic. He thinks emulator should prevent those choices.

 

Thanks!

[_The Doctor__]

3. because that is possible and has been done by folks with soldering irons and OS replacement since lord knows when... but a matrix preventing incompatible hardware/hardwired choice might be nice for the average bear... I like the idea that if one choose the wrong OS with the wrong Basic/Language etc... that it would crash/lockup or some other terrible thing just like on the physical items... so such a matrix should be able to be ingnored

Edited September 18, 2019 by _The Doctor__

[+Nezgar]

59 minutes ago, Philsan said:

impossible configurations like Atari 400/800 + Atari Basic

It's quite possible to plug Atari BASIC into a real 400/800.

[+Philsan]

21 minutes ago, Nezgar said:

It's quite possible to plug Atari BASIC into a real 400/800.

Yes, obviously, but plugging in a cart.

I am talking about setting internal BASIC on System/Configure System/Firmware menu.

On Altirra you can select Atari 800 + Atari Basic and Memopad appears.

Perhaps Altirra shouldn't allow that combination.

[phaeron]

21 hours ago, Nezgar said:

What does "side 2 reversed by off by one" mean?

For some reason, the track and sector computed by the Percom firmware for side 2 is one sector lower than that computed by the XF551. For the majority of the disk, you wouldn't notice this unless you tried exchanging disks with an XF551, because the logical-to-physical mapping is the same for reads as for writes. However, this probably means that the very last logical sector of a two-sided disk is inaccessible because it would map to track -1.

 

The reason this comes up with Altirra is that the internal disk storage and the common disk image formats are stored purely in terms of logical sectors, so when running full disk emulation the emulator needs to map the logical sectors back to a physical track/sector layout. This currently depends on the model of disk drive used as that's the only way that the emulator can guess what mapping the firmware uses. Doing this means that you can use the same DSDD disk image with the standard disk emulation as well as the various full drive emulators. However, if you were to run a "fixed" firmware that changed the mapping, it wouldn't match what the emulator provided. I haven't considered this a problem as there hasn't been a flurry of work on custom drive firmware.

 

7 hours ago, Philsan said:

1. Default overscan mode is "extended". I think it should be "normal", no TV shows extended overscan.

2. Default XL/XE machine has BASIC disabled. A friend of mine told me that this is not the real default mode and it's strange for a faithful emulator like Altirra. I told him that perhaps you made that decision to help newbies load games. But in fact it's not the default XL/XE behaviour.

3. My friend also told me that he doesn't undertand why you can make impossible configurations on System/Configure System/Firmware menu like Atari 400/800 + Atari Basic. He thinks emulator should prevent those choices.

Default overscan mode:

Yeah, I could go with that. The Widescreen setting would be more accurate for modern displays, but I think Normal has been around long enough and would be more appropriate given the 4:3 heritage.

 

Default BASIC:

You're correct that internal BASIC enabled is the default configuration on the real hardware, but there is a lot of software that crashes if internal BASIC is enabled and that's more common than running software that needs internal BASIC (which would also still require manual intervention anyway in 400/800 mode). Having to hold Option on start is honestly one of the most annoying aspects of the XL/XE models, to the point that people went out of their way to patch their OS to flip it. My take on this is that anyone who does know the Atari series will already know to deal with this, with the "Option" overlay giving the clue that the emulator is disabling BASIC, and those who don't know the Atari that well are better served by having internal BASIC disabled by default.

 

The same goes for the disk SIO patch acceleration option defaulting to on. It's not realistic, but generally people are not looking to re-experience accurate load times.

 

Impossible configurations:

I'm not sure what you mean here. The internal BASIC option is disabled (grayed out) if you're on a configuration that doesn't support internal BASIC. The BASIC selector, however, is intentionally enabled because that still selects which BASIC cartridge you get when File > Attach Special Cartridge > BASIC is used or the BASIC cart is otherwise added for you. At one point I had it set up such that this option would also insert or remove the BASIC cartridge in 800 mode, but this caused more problems than it solved -- like having a currently inserted cartridge deleted silently because you temporarily switched to 800 mode.

 

The more general issue of whether the emulator should prevent impossible configurations is a sticky one. One problem that arises is that the impossible configurations are sometimes necessary because you can only change one setting at a time and therefore may need to transition through an impossible configuration to get to a possible one -- you may not actually be able to add two dead-end SIO devices in real life, but it would be annoying if the emulator forced you to remove one before you could add the other. This also happens internally when the emulator is trying to switch entire configurations from one profile to another. For that reason, I sometimes bias toward having the emulator warn about an impossible configuration than trying to block it. It is true that the emulator doesn't have complete checks for this and does still allow some configurations that don't physically work without a hammer.

 

[scotty]

I feel like such a noob.....   Where can I find the Amdek firmware/rom?   I looked all over for it.  I did stumble across a page spreading virus/malware I am sure.   I generates a message where someone is asking for it, and someone else posts a link, and then a bunch more people post that it works great, thans, etc....   Hit refresh, and it changes the names of the people, wording and page layout, but still does the same thing.  LOL.   Pretty funny.