Altirra 2.80 released

[morelenmir]

http://www.virtualdub.org/beta/Altirra-2.90-test4.zip

http://www.virtualdub.org/beta/Altirra-2.90-test4-src.zip

• Fixes XEGS cartridge crash.
• Fixes bug in SIO acceleration system that caused corruption of an accelerated command that interrupted a non-accelerated command.
• Fixed SIDE 1 cart saving.
• Debugger directives and startup scripts are now supported for cartridges.
• Added 'ib' command to issue non-debug memory reads from the debugger.
• Fixed XEP80 display using point sampling if the display mode was set to bicubic. (It still doesn't support bicubic because I don't care enough implement on that path, but bilinear is closer than point.)
• I could not reproduce the XEP80 sharp bicubic issue, but I did find another issue in the new fxc10 builder that might affect the display. If you're still seeing the problem, please indicate the model video card, OS (XP, Win10...) and whether you see this on 2.80.

 

I could make you rewind the tape in real time... that would make it more representatively painful....

 

 

I couldn't reproduce the clipboard issue either....

 

As for more icons, that would depend on having said icons. I'm artistically challenged.

 

Excellent!!! Many thanks Phaeron for giving the cartridge-debugging system another look. I will give it a shot later on and report back.

 

Update:

 

This definitely seems to be a good step along the way! The console now reports that *.LAB, *.LST, *.ATDBG files are being automatically loaded for a cartridge image and also that 'Source debugging mode is now on.' - all of which behaviour is identical to when you launch a *.XEX image for debugging. However the emulator does not appear to be honouring the breakpoints specified in the Eclipse/WUDSN source code. Instead I get the following two lines: '0 breakpoint(s) cleared.' and 'Extraneous argument: B'. Maybe I am missing something on the WUDSN side of things?

 

Edited September 12, 2016 by morelenmir

[Irgendwer]

As for more icons, that would depend on having said icons. I'm artistically challenged.

 

 

Drop me a note with your requirements (kind of icon, style and sizes) and I gladly support your development.

[phaeron]

Another way to get rid of the glitch is to use "NVIDIA GeForce 710M" video card as the default display for Altirra:

XEP80 view + sharp bicubic + Direct3D 11, display is normal when NVIDIA GeForce 710M is selected.

 

The glitch will occur if:

- Intel® HD Graphics 4600 is selected "AND" Direct3D 11 is checked.

 

Wonderful... I was able to reproduce it, and best I can tell, it's a bug in the Intel graphics driver. The graphics driver is flat out ignoring attempts to update a constant buffer using CopyResource/CopySubresourceRegion() and instead rendering both blits with the pixel shader constants from the first, corrupting the XEP80 blit. I can "fix" it by hardcoding the constants in the shader, and the existing code works fine under WARP and the Debug Runtime, as well as NVIDIA hardware. It's incredible that I managed to trip this by drawing two quads. I'm going to have to rewrite the constant buffer handling to work around this problem, and adding to the fun is that constant buffer updating strategies prior to DX11.1+Windows 8 are very restrictive... ugh.

 

I didn't notice that you mentioned Copy Frame to Clipboard... that's always copying the ANTIC/GTIA output. That I can fix.

 

This definitely seems to be a good step along the way! The console now reports that *.LAB, *.LST, *.ATDBG files are being automatically loaded for a cartridge image and also that 'Source debugging mode is now on.' - all of which behaviour is identical to when you launch a *.XEX image for debugging. However the emulator does not appear to be honouring the breakpoints specified in the Eclipse/WUDSN source code. Instead I get the following two lines: '0 breakpoint(s) cleared.' and 'Extraneous argument: B'. Maybe I am missing something on the WUDSN side of things?

 

I'd need to see the .atdbg script -- I'm not set up with WUDSN and can't generate one myself (and don't really have the desire to install an Eclipse environment).

[morelenmir]

I'd need to see the .atdbg script -- I'm not set up with WUDSN and can't generate one myself (and don't really have the desire to install an Eclipse environment).

 

I did not realize the *.atdbg file was human-readable! Here you go Avery, these are the commands inside the breakpoint script named 'CartridgeCode.atdbg':

.sourcemode on
.echo
.echo "Loading executable..."
.echo
bc *
.onexerun .echo "Launching executable..."
bp `C:\Users\A B Username\Documents\User Programmes\eclipse\CartridgeCode\CartridgeCode.asm:20`

This is the exact text from the console:

 

Loaded symbols C:\Users\A B Username\Documents\User Programmes\eclipse\CartridgeCode\CartridgeCode.lab

Loaded symbols C:\Users\A B Username\Documents\User Programmes\eclipse\CartridgeCode\CartridgeCode.lst

Loaded debugger script C:\Users\A B Username\Documents\User Programmes\eclipse\CartridgeCode\CartridgeCode.atdbg

Source debugging mode is now on.

 

Loading executable...

 

0 breakpoint(s) cleared.

Extraneous argument: B

 

I am wondering if Altirra is having a problem because the path to the various scripts contains spaces? Obviously I have changed my real username shown here to a derivative one for the sake of privacy, but it is in exactly the same format as my real username: <first initial>space<second initial>space<surname>.

Edited September 13, 2016 by morelenmir

[Marsupilami]

Hi,

Fisrt thing, thanks a lot for your excellent work on Altirra.

 

I'm trying to backup some original tape with audio on the left channel and datas on the right.

Once recorded with audacity and saved as .Wav files, i open the result in Altirra.

 

But then i have this behavior :

- If i use c: patch (cassette SIO) then CLOAD, everything is OK, the BASIC program is loaded and complete.

- If i don't use c: patch (cassette SIO) then CLOAD, the sound is distorded and/or the loading fails with an error.

 

Do you know why ?

 

I've checked the signal level in audacity and it seems good.

 

Second question : Is it possible to do a working CSAVE with Altirra ?

I've tried but the virtual tape remains empty.

Recording audio in Altirra after typing CSAVE does not work : if you reload the saved Wav file in Altirra.

 

Maybe i'm doing something wrong.

 

I can send you the wav file if needed.

 

Thanks.

 

PS : The help file seems...empty (Altirra.chm). I can open it, i have the index but no content at all (Vista and 8.1 both 64bits).

Edited September 13, 2016 by Marsupilami

[Mclaneinc]

Here's the fix for the chm issue, its a well known issue with CHM's

 

http://stackoverflow.com/questions/11438634/opening-a-chm-file-produces-navigation-to-the-webpage-was-canceled/11438732#11438732

 

I can't answer 100% re backing up tapes but it they are protected tapes then you are wasting your time unless its a custom copier etc.

 

I'm not much help on the tape side, its been so long but I've unchecked in System / acceleration both the CIO speed ups but when I CSAVE i get the noise of data doing something, its short as its a 2 line basic program I'm saving. Its goes to ready but when I CLOAD I get a 138 which is a missing device. I've tried New tape under the cassette under the file / cassette menu and even saving it in the same place then loading, again in the same place but no matter CLOAD times out?

 

Now its most likely its a simple thing I'm missing and I'll go read the manul as I've not used a tape since the Atari first appeared all that time ago..

[Marsupilami]

Here's the fix for the chm issue, its a well known issue with CHM's

 

http://stackoverflow.com/questions/11438634/opening-a-chm-file-produces-navigation-to-the-webpage-was-canceled/11438732#11438732

Thanks, it works with windows 7 but not with 8.1 (there is no "unblock" button in 8.1).

 

I don't think the tape is protected, it's not an "autoload" tape, just a CLOAD one. One loaded, I can list the Basic program and it's a "real" (vs "encrypted") basic program.

 

Once the program "Cloaded", i tried to use a 30min blank audio file (Audacity/fill with silence/then saved the wav file.)

 

Then i loaded the blank virtual tape in Altirra, and i tried to csave the basic program. And indeed you can hear the "real" saving noise. If you go to File/Casette/Tape Control while "Csaving", you will also see the cursor moving forward, but there is no waveform inside: It remains empty.

"Rewind" the virtual tape or Cold reset to basic, CLOAD and...It fails with an error 143.

 

That's why I also tried to record the audio directly from Altirra (Record/Audio) but the record is not usable (And B.T.W recorded in both stereo L/R channels while it should not).

 

FYI: Here's the .Wav file (345MB) : https://we.tl/QCcSBQtDpl

Edited September 13, 2016 by Marsupilami

[morelenmir]

 

Wonderful... I was able to reproduce it, and best I can tell, it's a bug in the Intel graphics driver. The graphics driver is flat out ignoring attempts to update a constant buffer using CopyResource/CopySubresourceRegion() and instead rendering both blits with the pixel shader constants from the first, corrupting the XEP80 blit. I can "fix" it by hardcoding the constants in the shader, and the existing code works fine under WARP and the Debug Runtime, as well as NVIDIA hardware. It's incredible that I managed to trip this by drawing two quads. I'm going to have to rewrite the constant buffer handling to work around this problem, and adding to the fun is that constant buffer updating strategies prior to DX11.1+Windows 8 are very restrictive... ugh.

 

I didn't notice that you mentioned Copy Frame to Clipboard... that's always copying the ANTIC/GTIA output. That I can fix.

 

 

I'd need to see the .atdbg script -- I'm not set up with WUDSN and can't generate one myself (and don't really have the desire to install an Eclipse environment).

 

Yep, its definitely the spaces that are causing the problem.

 

To test this I first moved a copy of the folder that contains the *.ROM and the attendant list, label and breakpoint files to the root of my hard drive and then manually edited the *.ATDBG file to reflect this change. Next I start a debugging instance of Altirra and attach the *.ROM as a cartridge type 1 image. The cartridge is executed properly and... success!!! Altirra loads the *.LAB, *.LST and *.ATDBG files then halts execution at the breakpoint I set!

 

I don't know if this situation is something you can fix on the Altirra side or if WUDSN will need to be modified so that when it creates the breakpoint script it is sure to embed a filepath with spaces inside double-quotes or substitutes '%20' character codes or whatever.

Edited September 13, 2016 by morelenmir

[Mclaneinc]

@Marsupilami, Now you mention it re the chm I think Phaeron / Avery mentioned about this in another post, I'll see if I can find that post, it was something different causing it..

 

I'll have a look at the file but as said, I'm no tape user these days and I know Avery just added a very basic tape system just to satisfy users, by the sound of what he has said it seems the tape side is a right pain especially with these Eastern European turbo systems (which is not the case here). I just remember the old days of my ZX80 and trying to find the ideal tape player and correct volume to load stuff with, stuff that was recorded with auto levels would almost always fail because the initial beeping was so loud based on the previous silence you got load errors. Getting a tape drive with the Atari that was designed to work with it was bliss compared to the ZX80 etc but I was glad to see the back of the tapes in favour of a nice but horrendously priced disk drive (thankfully I got staff discount on the 2nd one).

 

Paul.

 

Edit: That was the issue under Windows 10, if the CHM file wasn't on a Local drive it would not be viewed, must be on a local drive..

Edited September 13, 2016 by Mclaneinc

[Madi]

The picture shows all the devices in Altirra 2.90 test x that can't be removed individually. "Remove" button is dimmed.

For info, these devices can be removed individually in Altirra 2.80 (test 50).

 

A minor issue: "Remove All" button is not dimmed when there are no devices.

Applicable to releases 2.8 and 2.9

 

madi

[Mclaneinc]

Hmmm...Just added and removed the slightsid here no problem, even added it, shut Altirra down and then ran it again and removed it fine..

 

My suggestion would be to make Altirra in to Portable Altirra, save the ini file and then run altirra without it and see if it then works as it should, I find that I have to delete my settings from time to time in between beta versions because something stops doing what it should.

 

At least with the saved ini file you can put it back and have lost no settings if it still does not want to remove for you..(but mine does work here)

 

The strike out is to slightly amend what I said, make Altirra portable, it will SEEM to lose its settings because its now working from an ini file, unlike above DO NOT delete the ini there and then. Try the device add and remove, to get the settings BACK just delete the INI and it will return to using the registry or simply recreate it all from scratch..

 

Hope I got back soon enough...The other way won't destroy your settings but it will just instantly put your registry settings back straight away so it would be a waste of time to delete the ini at that point.

 

If you use Portable anyway then just save that ini and just reset all the settings, then when done just pop the old ini back in...

Edited September 13, 2016 by Mclaneinc

[flashjazzcat]

The picture shows all the devices in Altirra 2.90 test x that can't be removed individually. "Remove" button is dimmed.

For info, these devices can be removed individually in Altirra 2.80 (test 50).

You mention test "x", but the issue of devices without settings being irremovable was addressed in test 3. I can remove the listed devices here in test 3.

[Madi]

In the process of deleting Altirra.INI, making new empty INI one and importing the 2.8 INI, I did it...

Result was.. Booooooom.. Windows fatal Error,

For sure I did some thing wrong ( Altirra had nothing to do with it). I believe it was the FileTypes.exe which I used to change icon association

 

I had to recover from a previous restore point.

---------------------

 

Note:

I am sorry,

Thank you FJC,. You are right. I was testing the device removal under test 2 (see posted picture).

2.90 test 4 is O.K.

 

I made a mess out of it. Now I have to clean it up . My windows 10 is not stable right now.

 

madi

Edited September 13, 2016 by Madi

[Mclaneinc]

Sorry to hear it went boom, very odd, under 7 if you use an old beta with the registry it just locks up Altirra but does not crash. There's no way deleting the ini was your problem, as said before, Windows 10, not very nice OS.

[flashjazzcat]

As he says, he believes it was the utility he used to change the file associations which blew Windows up.

[morelenmir]

I'm not sure if it works with the newer Windows release numbers, but on Win7 at least I find the control panel applet 'Default Programmes Editor' (http://defaultprogramseditor.com/) very useful for working with file types and extensions.

 

To editorialize a little; I think it is high time the OS keyed off an embedded 'magic number' or perhaps read a file's type identification from one of its NTFS 'Alternate Stream' forks instead of the arbitrary and easily corrupted filename extension. I mean, RISCOS was doing this back in the late 1980's and was the first of many disappointments I encountered when moving to the PC ecosystem from the ARM machines. In fact doesn't the Apple operating system use resource forks to identify the file type?

Edited September 14, 2016 by morelenmir

[phaeron]

But then i have this behavior :

- If i use c: patch (cassette SIO) then CLOAD, everything is OK, the BASIC program is loaded and complete.

- If i don't use c: patch (cassette SIO) then CLOAD, the sound is distorded and/or the loading fails with an error.

 

Do you know why ?

It looks like there is just enough timing jitter that the decoder misses a bit when the XL/XE OS sets up the transfer. The timing is slightly different with acceleration and so it decodes correctly. I'll have to see if I can tweak the decoder.

 

Second question : Is it possible to do a working CSAVE with Altirra ?

I've tried but the virtual tape remains empty.

You need to activate the Record button in Tape Control, just like on a real tape recorder. Failing to do this will result in the computer trying to record but nothing getting recorded; this is the same as on real hardware, since the computer cannot tell if Play or Record is pressed on the tape deck.

 

PS : The help file seems...empty (Altirra.chm). I can open it, i have the index but no content at all (Vista and 8.1 both 64bits).

 

As Mclaneinc noted, you cannot view HTML Help files that have the "mark of the Internet" on them indicating that the came from a network zone. Blame Microsoft for the lame error message that appears. If you open the help file from Altirra's Help menu, Altirra will attempt to detect this and remove the mark.

 

However, there is another case that will cause this, which is attempting to view the HTML Help file from a network share. This will also be blocked by HTML Help, and since it is by location, you can't unblock it except by moving the file or changing global HTML Help settings in the Registry.

 

Then i loaded the blank virtual tape in Altirra, and i tried to csave the basic program. And indeed you can hear the "real" saving noise. If you go to File/Casette/Tape Control while "Csaving", you will also see the cursor moving forward, but there is no waveform inside: It remains empty.

"Rewind" the virtual tape or Cold reset to basic, CLOAD and...It fails with an error 143.

 

That's why I also tried to record the audio directly from Altirra (Record/Audio) but the record is not usable (And B.T.W recorded in both stereo L/R channels while it should not).

 

This happened because the tape deck was in Play mode. The computer has control over the motor, so the tape will begin moving, but nothing will be recorded because it is in Play mode instead of Record. Again, the computer can't tell if Play or Record is actually pressed on the tape deck.

 

Record/Audio is for recording the computer's audio output, not the tape output. This always records stereo in case you have an add-on that has stereo output, but the base computer only produces mono and that's why the channels were the same. Needless to say, this is not meant for recording tape. You also cannot record a tape this way even on a real computer, by the way. It sounds the same, but it's not. The audio output has discontinuous phase as well as an unwanted carrier added on top. Attempting to decode this audio as a tape may sort of work at standard rates (600 baud) but the error rate will be high.

 

To editorialize a little; I think it is high time the OS keyed off an embedded 'magic number' or perhaps read a file's type identification from one of its NTFS 'Alternate Stream' forks instead of the arbitrary and easily corrupted filename extension. I mean, RISCOS was doing this back in the late 1980's and was the first of many disappointments I encountered when moving to the PC ecosystem from the ARM machines. In fact doesn't the Apple operating system use resource forks to identify the file type?

 

Classic MacOS required resource forks, but file handling is mostly standard on OS X. Both Mac resource forks and NTFS alternate data streams suffer from the same problem: there are a lot of systems, network protocols, and programs that won't handle them. Single byte streams tagged with a name, however, are nearly universal. There is such a modern tagging system in common use, but it's more common in network protocols than in files: MIME file types. And even that people frequently get wrong.

 

[Mclaneinc]

 

You need to activate the Record button in Tape Control, just like on a real tape recorder. Failing to do this will result in the computer trying to record but nothing getting recorded; this is the same as on real hardware, since the computer cannot tell if Play or Record is pressed on the tape deck.

 

Its soo bloody obvious I could cry, you always make things work like the real hardware and as you say you need to hit the record button.....DOH!!!

[morelenmir]

It looks like there is just enough timing jitter that the decoder misses a bit when the XL/XE OS sets up the transfer. The timing is slightly different with acceleration and so it decodes correctly. I'll have to see if I can tweak the decoder.

 

You need to activate the Record button in Tape Control, just like on a real tape recorder. Failing to do this will result in the computer trying to record but nothing getting recorded; this is the same as on real hardware, since the computer cannot tell if Play or Record is pressed on the tape deck.

 

 

As Mclaneinc noted, you cannot view HTML Help files that have the "mark of the Internet" on them indicating that the came from a network zone. Blame Microsoft for the lame error message that appears. If you open the help file from Altirra's Help menu, Altirra will attempt to detect this and remove the mark.

 

However, there is another case that will cause this, which is attempting to view the HTML Help file from a network share. This will also be blocked by HTML Help, and since it is by location, you can't unblock it except by moving the file or changing global HTML Help settings in the Registry.

 

 

This happened because the tape deck was in Play mode. The computer has control over the motor, so the tape will begin moving, but nothing will be recorded because it is in Play mode instead of Record. Again, the computer can't tell if Play or Record is actually pressed on the tape deck.

 

Record/Audio is for recording the computer's audio output, not the tape output. This always records stereo in case you have an add-on that has stereo output, but the base computer only produces mono and that's why the channels were the same. Needless to say, this is not meant for recording tape. You also cannot record a tape this way even on a real computer, by the way. It sounds the same, but it's not. The audio output has discontinuous phase as well as an unwanted carrier added on top. Attempting to decode this audio as a tape may sort of work at standard rates (600 baud) but the error rate will be high.

 

 

Classic MacOS required resource forks, but file handling is mostly standard on OS X. Both Mac resource forks and NTFS alternate data streams suffer from the same problem: there are a lot of systems, network protocols, and programs that won't handle them. Single byte streams tagged with a name, however, are nearly universal. There is such a modern tagging system in common use, but it's more common in network protocols than in files: MIME file types. And even that people frequently get wrong.

 

 

Microsoft are in a position to enforce this or at least to integrate it fully in to the API so its use is automated for everything that uses the Common Controls and IO routines. Things will never change until they are changed - I don't expect it to happen though and I despise file extensions. RISCOS had its problems, but I still miss so many of its features and '!Folders' with the scripts they could contain are just one example.

 

Incidentally, have you had chance to confirm that space-character handling bug Avery? I'm pretty sure that is what is causing the problem with loading and obeying breakpoints.

[phaeron]

Microsoft are in a position to enforce this or at least to integrate it fully in to the API so its use is automated for everything that uses the Common Controls and IO routines. Things will never change until they are changed - I don't expect it to happen though and I despise file extensions. RISCOS had its problems, but I still miss so many of its features and '!Folders' with the scripts they could contain are just one example.

They are in a position to... but they're spending all their effort on UWP and neglecting Win32. One year since launch, there is still no page on MSDN that lists new Win32 APIs in Windows 10, even though there have been a fair number of APIs added and extended. Nor do they properly advise on breaking changes, such as the intentional breakage of IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI() used for setting file type associations, which now displays this totally useless screen-modal dialog instead of Set Programs And Defaults control panel and which I had to work around in Altirra:

 

 

</rant>

 

Incidentally, have you had chance to confirm that space-character handling bug Avery? I'm pretty sure that is what is causing the problem with loading and obeying breakpoints.

 

Forgot to respond to this. WUDSN needs to wrap the argument to the breakpoint command in double quotes, i.e. bp "`a b:1`" instead of bp `a b:1`.

 

[Heaven/TQA]

They are in a position to... but they're spending all their effort on UWP and neglecting Win32. One year since launch, there is still no page on MSDN that lists new Win32 APIs in Windows 10, even though there have been a fair number of APIs added and extended. Nor do they properly advise on breaking changes, such as the intentional breakage of IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI() used for setting file type associations, which now displays this totally useless screen-modal dialog instead of Set Programs And Defaults control panel and which I had to work around in Altirra:

 

fileassoc.png

 

</rant>

 

 

Forgot to respond to this. WUDSN needs to wrap the argument to the breakpoint command in double quotes, i.e. bp "`a b:1`" instead of bp `a b:1`.

 

 

 

I guess Jac will look into it as sometimes those BPs enbedded in the WUDSN Editor does work and sometimes not and if that's the reason for some issues than I would be happy

[morelenmir]

They are in a position to... but they're spending all their effort on UWP and neglecting Win32. One year since launch, there is still no page on MSDN that lists new Win32 APIs in Windows 10, even though there have been a fair number of APIs added and extended. Nor do they properly advise on breaking changes, such as the intentional breakage of IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI() used for setting file type associations, which now displays this totally useless screen-modal dialog instead of Set Programs And Defaults control panel and which I had to work around in Altirra:

 

fileassoc.png

 

</rant>

 

 

Forgot to respond to this. WUDSN needs to wrap the argument to the breakpoint command in double quotes, i.e. bp "`a b:1`" instead of bp `a b:1`.

 

 

I agree with you entirely Avery!!! To be honest each time I have a look at a new version of VisualStudio I keep half-expecting them to have deprecated Win32 altogether and now be forcing people to use .NET/MFC for all programming. A straight C++/Win32 GUI or console application is already pretty well hidden on the list of project types we are given when pressing 'New' - its almost an afterthought. Which is actually Microsoft's problem in a nutshell; they can make genuinely excellent products. Way back when it was fashionable for some reason to criticize 'Office 95' I would never join in and got a lot of hate back then for defending the company and their software. However, they are never, ever satisfied just to release excellent programmes. They always want to change how people use their computers, control what we do digitally and even in real life. Don Mattrick really was the exemplar of the MS corporate culture and he only suffered because he was enough of a wanker to openly show this side of the company to the public.

 

ANYWAY...

 

Yep - I feared it might be more of a WUDSN issue than Altirra. I will send off a PM to JAC! and ask if he will consider double-quoting the paths in the various scripts which WUDSN produces in the next release. For now I have got around the problem by making a Junction between the C:\ root and my current project folder, ensuring it does not have a space in the name. It works perfectly in the short term and I must say when it works properly the integration between Altirra and WUDSN is really, really nice to use!

[Marsupilami]

It looks like there is just enough timing jitter that the decoder misses a bit when the XL/XE OS sets up the transfer. The timing is slightly different with acceleration and so it decodes correctly. I'll have to see if I can tweak the decoder.

 

You need to activate the Record button in Tape Control, just like on a real tape recorder. Failing to do this will result in the computer trying to record but nothing getting recorded; this is the same as on real hardware, since the computer cannot tell if Play or Record is pressed on the tape deck.

 

 

As Mclaneinc noted, you cannot view HTML Help files that have the "mark of the Internet" on them indicating that the came from a network zone. Blame Microsoft for the lame error message that appears. If you open the help file from Altirra's Help menu, Altirra will attempt to detect this and remove the mark.

 

However, there is another case that will cause this, which is attempting to view the HTML Help file from a network share. This will also be blocked by HTML Help, and since it is by location, you can't unblock it except by moving the file or changing global HTML Help settings in the Registry.

 

 

This happened because the tape deck was in Play mode. The computer has control over the motor, so the tape will begin moving, but nothing will be recorded because it is in Play mode instead of Record. Again, the computer can't tell if Play or Record is actually pressed on the tape deck.

 

Record/Audio is for recording the computer's audio output, not the tape output. This always records stereo in case you have an add-on that has stereo output, but the base computer only produces mono and that's why the channels were the same. Needless to say, this is not meant for recording tape. You also cannot record a tape this way even on a real computer, by the way. It sounds the same, but it's not. The audio output has discontinuous phase as well as an unwanted carrier added on top. Attempting to decode this audio as a tape may sort of work at standard rates (600 baud) but the error rate will be high.

 

 

Thanks Phaeron for your very clear answers (and your patience), i will try.

Since i'm currently trying to backup some old tapes missing at "AM", i'll wait for the decoder tweaking

Edited September 16, 2016 by Marsupilami

[serj]

It has long been not to see the new beta releases of the emulator.
Avery, you cook something interesting?

[flashjazzcat]

There was an update eleven days ago.