Jump to content
IGNORED

After 32 years: Silent Butler 80 is found by Curt & call for help


luckybuck

Recommended Posts

Hi together!

 

It seems 2019 is the(!) Atari year at all, not only the 40th anniversary. :-)

Thanks to Curt Vendel so many good software, which was believed to be lost or even never existed, came to surface.

Therefore, Curt, we can’t thank you enough for all you have done for Atari and in special for us all. :-)))

post-32599-0-43923000-1558315904.jpg

 

https://atariwiki.org/wiki/Wiki.jsp?page=Thanks

 

Again in 2019 the impossible has happened, Curt brought us the 80 column version of Silent Butler!

This program was for years on the FBI er Atari list for the most wanted ones!

Now Curt got it! :-) And guess what, he is sharing with us again! WOW! Thank you so much Curt.

 

We further would like to thank Kevin and Maciej Grzeszczuk for digitizing all the ATRs and taking the pictures of the disk labels. Thank you both so much! :-)

 

But now, we would like to come to you!

Sadly, I was not able to get just one of the ATRs running. But the data is out there, on the disks, of course. ;-)

Atari Big Data, we all have made in the recent years, now we have to come to Atari 'Big Brain', using all of the Big Data available to get things running.

And that means, we want you:

 

post-32599-0-05439800-1558315989_thumb.jpg

 

to help the community to get Silent Butler 80 running. :-)

Or to say it with Kennedy’s words: Don’t ask, what the community can do for you, ask, what you can do for Keep Atari Great Again (KAGA)!

Please find the whole archive of Silent Butler 80 attached. Further, please take into account, that Silent Butler needs the XEP80:

https://atariwiki.org/wiki/Wiki.jsp?page=XEP80

The original handler from Atari is rather slow, but working, for warp speed, please use the drivers from our Floppydoc and living legend Avery Lee, which he offered on his additions diskette, too.

It is not an easy one, of course, but we are sure, with the help of all, we gonna make it!

The Atari community is strong! Don't mess with Big Brain, you won't make it!

Don’t worry, we won’t send the MP after you, it is fully sufficient, if you can contribute, ideas, tools, suggestions and so on.

Therefore, we would be glad to read from you. :-))))


Curt, Kevin, Maciej, Roland and the force, who is always with us.

SB80.zip

  • Like 14
Link to comment
Share on other sites

Once it working, I hope someone can hack this to work with other 80 column software solutions like Omniview 80 or maybe even to work with SDX's con80 or something. I've been more of the mind to get a Bit 3 80 for my 800 if one comes up when I can afford it! But with my video upgrade software 80 column like in TLWP or SDX and Omnview has been good enough for me, so I hope we can get a modified version for one or all of those options too. After all, it's been done with AtariWriter 80 now for Omniview...

 

I wish I could help.

Edited by Gunstar
Link to comment
Share on other sites

This loading screen was as far as we could get at VCF East. Look at the cool graphics in XEP-80 mode!

 

How long did it take to draw that graphic on the screen? I thought graphics operations were very slow to transfer to the XEP-80...

Link to comment
Share on other sites

 

How long did it take to draw that graphic on the screen? I thought graphics operations were very slow to transfer to the XEP-80...

Depends. The XEP80 has a burst mode, which lets you upload loads of bytes together without sending coordinates for each one. Burst mode seems like the ideal thing to use for a splash screen.

  • Like 2
Link to comment
Share on other sites

Anyone else able to get any of the disk images to boot? The disk images appear to have widespread corruption at sector offset $02, the most direct consequence being that the boot process crashes because the load address set to $1020 instead of $1000. There are more subtle corruptions at this same offset in text throughout the images.

Link to comment
Share on other sites

Almost all the a sides load 10 sectors and the b 16 sectors.....Bad dumps?.......Hence the corruption?

 

There must be a good dump as in respect of Kevins picture?

 

 

The picture was run from one of the disks directly, not from a dump.

 

It took about 7 seconds for the whole picture to display.

 

-Kevin

  • Like 4
Link to comment
Share on other sites

I've been able to patch one of the disks enough to get it to initially boot and display the logo, but not enough to run the main program. The machine code is affected and it is difficult to reconstruct the damaged bytes. All of the disk images seem to be similarly affected.

 

post-16457-0-36510600-1558380772.png

  • Like 5
Link to comment
Share on other sites

So, you mean, the best would be, to re-digitize the disks with a maybe Kryo or SCP? So we know exactly, what is going on?

That is always the best option, as it produces the highest fidelity image with the least wear on the disk and you may only get one more pass with an old disk.

 

I would recommend checking the setup that produced these images, as a disk drive with bad memory is suspect. For further attempts, use a test disk with known image like DOS and verify the image before trying to reimage these disks, then recheck sector 1 of the first reimaged disk before doing the rest. There's no way that consistent corruption on byte 2 of each sector is going to be a problem with the disk media or the drive mechanism, it has to be in the drive controller or host computer.

  • Like 2
Link to comment
Share on other sites

I'm reminded of the 3rd byte being 80h (48h?) with a

happy drive under SpartaDOS if you don't use INDUS.SYS

driver.

 

Didn't know a thing about it for years except the

3rd byte was always stepped on using Sparta on that

Happy so I just didn't use the Happy with Sparta.

 

Supposed to be a bug in the Happy OS and it has been

fixed IIRC. Nezgar would know exactly all about it,

I'll refer you to him if you need more info.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

I'm reminded of the 3rd byte being 80h (48h?) with a

happy drive under SpartaDOS if you don't use INDUS.SYS

driver.

 

Didn't know a thing about it for years except the

3rd byte was always stepped on using Sparta on that

Happy so I just didn't use the Happy with Sparta.

 

Supposed to be a bug in the Happy OS and it has been

fixed IIRC. Nezgar would know exactly all about it,

I'll refer you to him if you need more info.

Ah right, I missed that detail. This corruption lines up exactly with that Happy bug. It's not just a SpartaDOS problem.. It will happen with any software that writes to a stock happy drive using UltraSpeed in Single Density without first issuing the happy 'enable fast writes' command. Once that command has been sent, either by Sparta X indus.sys, the Happy utility menu disk, or by any other program, it will be fine with any software until the drive is turned off.

 

Kevin, I know you have a Happy enhanced 1050, so I suspect the backup process you used first involved copying the disks to a second real disk with a Happy-unaware sector copier before copying to the ATR via SIO2SD. Some options:

  • Enable 'ultraspeed emulation' using the happy utility disk prior to using your existing sector copier.
  • The sector copier built into the Happy utility disk is safe, but will only read/write at ultraspeed to actual Happy drives.
  • MyCopyR DOES issue the 'enable fast writes' command on startup, so is safe to use for writing with Happy drives at ultraspeed all the time, and will also work reliably ultraspeed with SIO2PC/SIO2SD type devices as well.
  • I haven't used it (yet), but for marginal disks, it may be good to use "Disk Wizard II" since it will apparently copy the contents of bad sectors, with errors included if need be. Most other sector copiers leave bad sectors blank in the copy.
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

This definitely looks similar to the Happy 1050 high-speed bug. The bug is caused by the USD transmit routine stomping location $02/$0102 with 2*A for A = byte to be transmitted. In normal circumstances this is $82 because of transmitting $41 (ACK), but in this case it's the previous byte at offset 1. This explains how the corruption is deterministic across all the images. Unfortunately, this also means that there is no evidence of what byte 2 was in the image, so the only ways to fix this are either re-image or manually reconstruct (guess).

  • Like 5
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...