How much worse can Skype get under Windows 10?

After a number of updates and idiotic animations being added to the initial application window, Skype has become much worse in terms of its core functionality, i.e. connecting people.

Here’s a screenshot of the latest version running on Windows 10:

Skype: becoming worse and worse by Luigi Di Fraia

Skype: becoming worse and worse

I had to hang-up the last call attempt as quality was getting worse: Skype did not even register the call as ended. Obviously the attempt of the other party to call me back failed during the time Skype was deciding the destiny of the call, despite having ended it at my end.

Skype must have become utterly crap as I certainly feel I can code better applications.

Posted in Technical | Tagged , , | Leave a comment

One Bleepload scanner rewritten in TAPClean

As I had some time this evening, I decided to rewrite the “Bleepload” scanner in TAPClean.

If you’re interested in seeing what has changed, here’s a view of the changes in v0_37_pre_6. As soon as I manage to rewrite the “Bleepload Special” scanner, I will start with some regression testing.

Stay tuned!

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

More Bleepload fun

I was checking how “Bleepload” hands control over to “Bleepload Special” in “Bubble Bobble” when I stumbled on some code leftover in one of the blocks involved in the handover (set a breakpoint on execution at $BF1A and then check RAM contents thereabout):

Bubble Bobble: leftover code by Luigi Di Fraia

Bubble Bobble: leftover code

Guess where the source code is from? If you had a look at the Bleepload source I published on my DokuWiki space yesterday, you might have recognized that, in fact, the above snippet is from the tape loader itself:

        JMP B1D12     ; Return from IRQ
 
; --------------------------------
 
; IRQ #2
 
V1CFB   SEI           
 
        JSR S1D15     ; Read bit
 
        BCC B1D12     ; Return from IRQ
 
        LDY $72       
        LDA $BD       
        STA $033C,Y   
        LDA #$01      
        STA $BD       

OK, so the original labels and their corresponding labels in my disassembled listing are:

NOBYTE = B1D12
PROG   = V1CFB
BIT    = S1D15

Why is this relevant? If one of you happens to find a disk with some assembly source that looks like the one below, then you might have found the original Bleepload tape masterer’s source code:

        JMP NOBYTE    
PROG    SEI           
        JSR BIT       
        BCC NOBYTE    
        LDY 114       
        LDA $BD       
        STA 828,Y     
        LDA #1        
        STA $BD       

Happy digging 🙂

Posted in Retrocomputing, Technical | Tagged , , , , , , | 1 Comment

Bleepload F1 documentation

As I am documenting Bleepload ahead of a scanner reimplementation in TAPClean, I thought to share a preview of the loader, disassembled from Bubble Bobble.

The code is available on my DokuWiki space and comments are welcome!

Also, I should mention that in order to more easily integrate user feedback, in the form of pull requests, without having to keep spammers at bay or having to make regular backups of my hosted DokuWiki, I plan to eventually move my loader documentation from DokuWiki to GitHub Pages, at the URL luigidifraia.github.io.

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

Annoying bug in Bleepload F1 scanner fixed

Whoever has been using TAPClean for long enough certainly came across the fact that sometimes the Bleepload scanner enters an infinite loop. Zoë herself has stumbled over this issue too, so I decided to assess the situation here.

Long story short, a number of reads from the tape image were not validated before the results of such reads are used as parameters for the decoder. I’ve now added some minimal validation and I plan to rewrite both Bleepload scanners at some point.

It would help to have a list (not yet the tape images, just a list) of all known Bleepload tapes and where I can get them once I am done with the rewrite as I will need to do some regression testing. Paul, you’re the man for this one, please 🙂

Posted in Retrocomputing, Technical | Tagged , , , , , , | 1 Comment

A reminder on reckless behaviours

A while back, I had mentioned the upcoming availability of the “-reckless” option in TAPClean. A number of users might have missed such announcement but might have been hit by the message “{filename} contains read errors so it won’t be cleaned.” when trying to clean their tape collections.

Over time, this behaviour has sparked criticism and raised the FAQ as per below.

Question: why doesn’t TAPClean just skip the areas with errors and clean the rest?

Answer: Because, in general, people assume that a cleaned TAP file is an error-free one. Being that the case, if a cleaned TAP file already exists, they might not feel necessary to make a digital backup of their own healthy tape with the same contents, so the files with errors might be lost forever.
It is preservation material I am mainly worried about. For home-made stuff, users might want to use the “-reckless” option which disables such prudent approach and enables a reckless user behaviour, which is then out of my responsibility.

A responsible approach would be to:

  • seek multiple sources of the corrupted files/tapes, and
  • fix corrupted areas by comparing multiple sources (hoping that damages are not occurring in the same areas).

As preservation is a shared effort, here’s the deal: if you contact me when you stumble on material to be preserved for the general public that falls in the above mentioned scenario then I will give you some feedback on a case-by-case basis. As example, I might have access to an alternative healthy source that I might be able to share or use to fix your own backups 🙂

Don’t just assume that anything and everything will be automated and/or automatically fixed by software alone: that might not happen, not for the time being. However, having multiple backup sources is definitely the way to go for a successful preservation effort in the long run.

Posted in Retrocomputing, Technical | Tagged , , , , , , | 2 Comments

TAPClean and TCFE updated again!

As requested by Fredric, I’ve now changed TAPClean so that the filename occurring within a Turbotape 250 header file is also embedded in the PRG filename of its data counterpart. As example, for “Pitstop II”, here’s the list of extracted PRG files:

001 (033C-03FB) [PS_II].prg
002 (033C-03FB) [PS_II].prg
004 (0801-0834).prg
005 (0801-0834).prg
007 (033C-03FB) [FL].prg
008 (033C-03FB) [FL].prg
010 (C350-C8CF).prg
011 (C350-C8CF).prg
013 (033C-03FB) [PITSTOP_II].prg
014 (02A7-030C) [PITSTOP_II_DATA].prg
016 (033C-03FB) [LOADER].prg
017 (0800-0900) [LOADER_DATA].prg
019 (033C-03FB) [TITLE].prg
020 (1000-2000) [TITLE_DATA].prg
022 (033C-03FB) [MTNS].prg
023 (1800-3000) [MTNS_DATA].prg
025 (033C-03FB) [PITS].prg
026 (1000-C000) [PITS_DATA].prg

This is particularly useful to archive PRG files extracted from a tape with multiple TT250 files saved on it 🙂

Furthermore, I updated TCFE in order to allow users to easily copy an extracted PRG file to a folder of their choice, as per screenshot below:

TAPClean Front End: users can now save a copy of any extracted PRG file by Luigi Di Fraia

TAPClean Front End: users can now save a copy of any extracted PRG file

Links to the latest binaries for Windows and Linux:

Enjoy!

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment