News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_ssg

Read error pages

Started by ssg, 09:29, 27 January 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ssg

I'm thinking of explaining read error codes in the wiki, however I'm not sure about the difference between a and b. Here's what I know:

read error a: signal dropped. means there was an unexpected cut in the data signal. that's why we usually get a when we suddenly stop the tape during loading.

read error b: signal not understood? usually due to head alignment or low quality magnetic signal on tape.

read error c: invalid file type?

read error d: block is too large to fit in the buffer. (given when you do a cat on large blocks)

are there any others? corrections are welcome.

arnoldemu

Quote from: ssg on 09:29, 27 January 11
I'm thinking of explaining read error codes in the wiki, however I'm not sure about the difference between a and b. Here's what I know:

read error a: signal dropped. means there was an unexpected cut in the data signal. that's why we usually get a when we suddenly stop the tape during loading.

read error b: signal not understood? usually due to head alignment or low quality magnetic signal on tape.

read error c: invalid file type?

read error d: block is too large to fit in the buffer. (given when you do a cat on large blocks)

are there any others? corrections are welcome.

read error a is down to the timing of the signal, so the timing is too fast, or signal dropped.

read error b is checksum incorrect (so data read ok, but when checksum was calculated then compared to checksum on cassette, they were different).

read error d is block too large.

read error c seems to be used with "CAS CHECK". This is where you are comparing data in memory with data written to tape. So effectively a verify that data was written correctly.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ssg

Ok I added the initial version. Firmware disassembly excerpts could be added in the future to prove in which exact cases they are used.


http://cpcwiki.eu/index.php/Read_error_codes

Gryzor

Thanks for adding it :)

Tip: take a look at http://cpcwiki.eu/index.php/Special:WhatLinksHere/Read_error_codes : this shows that no other articles link to the one you created. While your effort is visible when someone searches for it, it's not easy to get there through other articles... so it'd be great to add links to it to any relevant pages you can think of - guides, troubleshooting, hardware even...

Bryce

I've added links from the two DIY tape sockets I did:

http://www.cpcwiki.eu/index.php/DIY_464_External_Audio_Socket

http://www.cpcwiki.eu/index.php/DIY_Plus_Tape_Socket

But it needs to get added to a main software / hardware page directory too.

Bryce.

Gryzor

Thanks mate!

As for the main soft/hard pages, hm, maybe it's not the best place... we're really lacking a 'troubleshooting' ueber-category I guess?

Bryce

At the moment, the only trouble-shooting is lumped in at the bottom of the DIY & Repair, but as most trouble shooting is hardware related, it's probably still the best place to have it, it just lacks in content?

Bryce.

Gryzor

You mean DIY&Repair? Probably... could even rename it to DIY&Troubleshooting, which somehow I feel also covers repairing...

Bryce

Nah, DIY & Repair is the better description, troubleshooting is just a step within the repair process, eg: A read error on the disc, Troubleshooting = Does the drive belt need to be replaced, Repair = The description of how one changes the belt.

The other option would be to put DIY in its own category and make a new Troubleshooting and repair category? But there's very little content at the moment to justify this.

Bryce.

Gryzor

Nah, you're right abot that.

mr_lou

Sorry for reviving an old thread, but I have a question about read error codes:

Is there no way at all a "Read error d" can occur when trying to RUN a file? Will it always only occur when CAT'ing a tape?

mr_lou

Bumping this again.
Really no one knows?

Is there no way at all a "Read error d" can occur when trying to RUN a file? Will it always only occur when CAT'ing a tape?

I'm asking because of a memory I have that I'm writing about in "8bit Stories". If a "Read error d" is not possible when trying to RUN a file, then I remember wrong.

EgoTrip

I have never seen a read error d when run, only cat. It always loads long blocks fine (unless there is a read error a or b).

Johnny Olsen

This is what I could find in Soft 968 Firmware Guide.
I have only seen read error d if I cat a file saved with "amsback"


       c. Error messages.

           Rewind tape

 While searching for a block of the file being read, a higher  numbered
block than that required has been found. The required block  has  been
missed. This message is often produced  after  a  read  error  in  the
required block when the next block is found.


            Read error X
            An error of some kind occurred whilst reading from tape. The tape
            should be rewound and the block played again. The X is  a  single
            letter indicating what kind of read error occurred:
            'a'           Bit too long        An impossibly long one or  zero
                                              has been measured.  This  often
                                              indicates reading past the  end
                                              of the record.
            'b'           CRC error           Data   was   read   from   tape
                                              incorrectly.
            'd'           Block too long      The data record  contains  more
                                              than the expected 2048 bytes of
                                              data.
            Write error a
            An error occurred whilst writing to the tape. There  is  only  on
            possible write error. This indicates that  the  Cassette  Manager
            was unable to write a bit as fast as was  requested.  This  error
            will never occur unless the user has set the write  speed  beyond
            the maximum possible.


AMSDOS

I recall that Read Error D when I was doing Tape To Tape Transfer of my AMSOFT games using JL-Copy. The First Block was ok, as soon as Block 2 would come up, Read Error D appeared when CATaloguing the Tape.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

mr_lou

Quote from: AMSDOS on 05:55, 28 September 15
Read Error D appeared when CATaloguing the Tape.

Yes, this is what I keep hearing.

I guess I have to accept that I remember wrong.

Bryce

I'm not 100% sure, but I think I used to get a read error D on some dodgy tape I had. I never tried CAT on a tape, so I must have been loading something. I think it might have been Gauntlet while loading some of the levels.

Bryce.

AMSDOS

Quote from: mr_lou on 07:17, 28 September 15
Yes, this is what I keep hearing.

I guess I have to accept that I remember wrong.


Sorry, I was reading from the 1st poster, and didn't realise the thread had been revised.  :o


I don't recall those kinds of errors happening with Headerless Files, though back when AA had Headerless Files on their Covertapes, their Menu was able to detect Load Errors.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

mr_lou

Quote from: Bryce on 08:19, 28 September 15
I'm not 100% sure, but I think I used to get a read error D on some dodgy tape I had. I never tried CAT on a tape, so I must have been loading something. I think it might have been Gauntlet while loading some of the levels.

This was kind of a dodgy tape too.
Recorded on one CPC and then trying to RUN it on another. I let the tape run despite of lots of "Read error b" messages and then came a "Read error d" afterwards.
That's how I remember it. But I know our memory can't be trusted 100%. Experts say that when we remember something, we're only remembering last time we remembered it. So we actually rarely remember things the exact way the occurred.

Bryce

Quote from: mr_lou on 10:10, 28 September 15
Experts say that when we remember something, we're only remembering last time we remembered it. So we actually rarely remember things the exact way the occurred.

And then there's all that beer that deletes half of it anyway :D

Bryce.

AMSDOS

Quote from: Bryce on 10:41, 28 September 15
And then there's all that beer that deletes half of it anyway :D

Bryce.


Thank God for those Service Manuals then!
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Bryce

Quote from: AMSDOS on 23:32, 28 September 15
Thank God for those Service Manuals then!

Yeah, they make great beer mats!... Oh wait, that's not what you meant :D

Bryce.

ssg

#22
Quote from: mr_lou on 16:35, 05 July 15
Is there no way at all a "Read error d" can occur when trying to RUN a file? Will it always only occur when CAT'ing a tape?


I think it can occur when it's the first block. The first block has a length limit of 2048 bytes if I recall correctly. First blocks are always loaded into a temporary buffer and then moved to the actual memory position after a successful load. You can observe this when loading a screen file to &c000. If you write a first block with a greater length, you get a Read error d when you try to run it. That's why those loaders put the big block in the second block. I remember experimenting with "raw write" firmware calls to create my custom file types on tape and whatnot and experiencing exactly that.

Powered by SMFPacks Menu Editor Mod