8-Bit Software: A Preservation Effort

www.atarimania.com · August 17

On 4/27/2023 at 6:17 PM, SoulBuster said:

Sherlock's Hounds (1985)(Swift Clark Marketing)(US)[BASIC][cassette]

The size of this program doesn't make sense, do you mind checking again? Thanks!

+SoulBuster · August 17

Which file? I've tested them and they work.

Side 1 is longer due to a signature or other recording at the end of the tape.

First pic is from the Zip I uploaded (the one you downloaded). The second pic is of the folder on my computer that I uploaded from.

www.atarimania.com · August 17

3 hours ago, SoulBuster said:

I've tested them and they work.

Absolutely, they do. It's just weird the .cas file is about 50 times bigger than usual for a program that small.

Atarigrub · August 17

2 hours ago, www.atarimania.com said:

Absolutely, they do. It's just weird the .cas file is about 50 times bigger than usual for a program that small.

It probably needs cleaning up. I can do this in a8preservation when I get to this one. I think it's already in the queue there

+kheller2 · August 17

I don't want to derail the thread but wanted to let future people know there are 4 DOS 2.0S images in this thread:

Atari 810 Master Diskette II
Master Diskette II (1980)(Atari)(US)[disk]
Master Diskette II (1983)(Atari)(US)[disk]
Master Diskette II (1983)(Atari)(US)[disk] SET2

All have identical binaries. So I personally know for sure we have original content

But two pairs of ATRs are identical (a pair of A and a pair of B). It looks like the 1983 disks vs 1980.

c3ffae7fda730473571931ee24df067f Master Diskette II (1983)(Atari)(US)[disk] SET2/Master Diskette II.atr
c3ffae7fda730473571931ee24df067f Master Diskette II (1983)(Atari)(US)[disk]/Master Diskette II -p 101.atr
f3d104b00d1ed9e129d0e10a3e6b4f73 Atari 810 Master Diskette II/Atari 810 Master Diskette II.atr
f3d104b00d1ed9e129d0e10a3e6b4f73 Master Diskette II (1980)(Atari)(US)[disk]/Master Diskette II.atr

The only difference is hexbyte b40c (04 vs 00):

0000b3f0  ff ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  |................|                       0000b3f0  ff ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0000b400  00 00 00 00 00 00 00 00  00 00 00 00 04 00 00 00  |................|                     | 0000b400  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0000b410  42 27 00 04 00 44 4f 53  20 20 20 20 20 53 59 53  |B'...DOS     SYS|                       0000b410  42 27 00 04 00 44 4f 53  20 20 20 20 20 53 59 53  |B'...DOS     SYS|
0000b420  42 2a 00 2b 00 44 55 50  20 20 20 20 20 53 59 53  |B*.+.DUP     SYS|                       0000b420  42 2a 00 2b 00 44 55 50  20 20 20 20 20 53 59 53  |B*.+.DUP     SYS|
0000b430  42 01 00 55 00 41 55 54  4f 52 55 4e 20 53 59 53  |B..U.AUTORUN SYS|                       0000b430  42 01 00 55 00 41 55 54  4f 52 55 4e 20 53 59 53  |B..U.AUTORUN SYS|
0000b440  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|                       0000b440  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

I'm assuming this is in the unused area of the VTOC (7C). Which is weird.

luckybuck · August 17

I'm assuming...

That is the problem.... you must know for sure, whether they are untouched or not.

Take for example one of the disks and boot it.

Put in a new disk, format and write DOS to it.

Take a 2nd and do the same.

Take the MD5 of both and you discover the MD5s are different!

Main thing: the binaries are identical.

Edited August 17 by luckybuck

+kheller2 · August 17

1 hour ago, luckybuck said:

I'm assuming...

That is the problem.... you must know for sure, whether they are untouched or not.

Take for example one of the disks and boot it.

Put in a new disk, format and write DOS to it.

Take a 2nd and do the same.

Take the MD5 of both and you discover the MD5s are different!

Main thing: the binaries are identical.

Considering the title of this thread, and the fact same person dumped three of the four using the same tools, and all four disks are visibly physically different, I would think they are untouched. Especially since the byte difference is in an unused portion of the VTOC. At first I was suspecting that the tools to make the ATR might have a bug. However, I just found another master (not in this thread) that has that byte as 05.

Yes if one formats a disk and installs DOS, and repeats on another disk it will be slightly different in the buffer space that is dumped (if at all) .. but this is an oddball area to have a difference. It's almost like a mastering number. Maybe. I speculate.

luckybuck · August 18

We will try our very best, as always... more can't be done.

There will be unanswered questions, that is very sad, but that's the way it is...

Atarigrub · August 19

On 8/17/2024 at 7:24 PM, Atarigrub said:

It probably needs cleaning up. I can do this in a8preservation when I get to this one. I think it's already in the queue there

I've checked and found I'd already recently processed this, but its awaiting Archiving on a8preservation.

Here's the cleaned CAS file (16.4kb). Program is identical between sides, so only one CAS required.

The extra audio at the end of side A, is someone turning on a microphone, so no actual program data there.

SherlocksHounds.cas

Edited August 19 by Atarigrub

www.atarimania.com · August 19

Thanks to all of you!

+SoulBuster · August 24

On 8/17/2024 at 4:19 AM, www.atarimania.com said:

The size of this program doesn't make sense, do you mind checking again? Thanks!

@www.atarimania.com

I think I know why. I have been saving a newly created WAVs from Altirra.

It seems that when Altirra saves a CAS directly from a WAV you get larger files.

I just did a Silent Service Cassette (man that damn thing is almost 19 minutes of load time) and the file that Altirra made was 500k+.

When I used a wav2cas program It came out at 63k. Then I used Altirra to clean the CAS up, saved it out, and it was about the same size as the wav2cas program made it.

I say "a wav2cas program" because I do not know which it is or where I got it and it does not identify itself.