Why does the 1541 disk drive keep spinning?

This is a bit of a strange issue that came up during some recent testing.

It only happens if you load the PRG version of Rodman from a 1541 disk drive onto a VIC20 and run it immediately before the disk spins down.

When you do that, the disk activity light goes out, but the drive keeps spinning. The game runs fine, it is just the disk drive that behaves oddly.

It only if the drive is still spinning, there is not time to type R U N and press RETURN, so it is only automatic starts like the Penultimate Cartridge file browser. I also check it does the same thing if you have the BASIC 4 ROM if you do SHIFT + RUN/STOP and have Rodman as the first program on the disk. It both cases, the game starts immediately after loading.

I decided to wire up the logic analyser and have a look what is going on. Here I have the IEC bus side of Data, Clock and ATN, and the IO chip select line for the VIA chips.

This is the end of loading Rodman.

Looks OK to me.

For comparison, this is the end of loading Bertie the Ball, which does not leave the disk spinning.

I zoomed in a little closer for the screenshot, but it is doing the same thing. The three ATN pulses at the end to ask the drive to stop talking, close the file and release the bus.

Hmm. I was thinking it might be some weird edge case if the file was a multiple of some block size or off by 1 etc.

It was only when I zoomed out that I noticed a difference.

At some point, there is some IO activity and ATN gets asserted again and the drive thinks it is going to be asked to do something so keeps the rust spinning.

This is Bertie the Ball, you can see there is some IO activity, but the IEC lines are unchanged.

I think this might be a similar issue to that of the autofire on Bandits I saw previously.

• http://blog.tynemouthsoftware.co.uk/2024/11/fixing-autofire-in-vic20-bandits.html

The problem was with the port A output register on the userport VIA. The pins on there control IEC ATN line output, and are inputs for datasette sense, IEC clock and data and 4 of the 5 joystick directions (don't ask).

The PA7 output drives a 7406 inverter, which will assert the signal (pull the bus low) when PA7 is logic 1.

In Bandit's case, it was writing to that port as part of the initialisation and changing the value of bit 7 to 1. This asserted the ATN signal and because of a previous change to the other signals caused the drive to react, which meant the signals read from port A were different if a drive was connected.

I asked Misfit (the creator of Rodman) if he was writing to $9111, and he was good enough to check and found no writes to that address in his code (or the alternate version at $911F).

Odd.

He sent me the code, which consisted of 7 POKEs, setting up various registers on the two VIAs, but not including $9111.

   POKE(0x911C,0xFE);

   POKE(0x911E,0x7F);

   POKE(0x912E,0x7F);

   POKE(0x9112,0x00);

   POKE(0x9113,0x00);

   POKE(0x9122,0x00);

   POKE(0x9123,0x00);

I zoomed in to the point where ATN was asserted, and I could see those 7 POKEs (it's quite neat when you can actually visualise code happening)

You will see the spacing of those is not quite even. This again is visualisation of code. Due to clever ordering the statements, the compiler is able to optimise out several of the LDA statements where the same value is written to several addresses, and has already been loaded.

Looking at the trace, you can see it is the fifth POKE which causes the problem.

   POKE(0x9113,0x00);

Ah, of course. That is writing to the data direction register for port A, and setting all the pins as inputs.

The ATN out pin, controlled by bit 7, should be an output, as it directly driving the input of a 7406 inverter.

When bit 7 is set as an input, the input of the 7406 buffer will be floating, most lightly read as a 1. In practice, this depends on make, type and age of the VIA, how strong the pullups on the input pins are, and also on the make, type and age of the 7406 if it has an input pullup or what it will consider a logic 1.

This was first spotted by a colleague using Vice with "true drive sounds" on and it continued the "disk spinning" sound after the game had started.

I was testing here with a VIC20-CR and a Mini VIC and a 1541 drive.

The internal pullup in the 6522 most likely means that the ATN signal will be asserted. If this happens before the drive has spun down, it will keep the disk spinning as it thinks it is about to receive a new command.

It probably does this on an SD2IEC as well, but you wouldn't notice as there is no sound.

I tried a few more games, and noticed the same thing on Bolder Dan.

Here there are 20 pokes this time, the 4th one seems to assert clock and / or data, and the 13th asserts ATN.

How to fix this?

Ideally you would set bits 7 as an output and write 0 to those bit 7 in $9111. Both of which should already be the case, so the easiest fix is simply to remove the fifth POKE.

I am not sure this actually needs to be fixed, since it only affects someone using a Penultimate Cartridge and a 1541 disk drive to load a game which was never released on disk, and is already in the Penultimate Cartridge. Normal loads on any device are fine as the drive normally spins down before you have had time to type in R U N and press enter. 

---

Adverts

You can now get a ZX80 kit for $200.

Sorry, right price, wrong advert.

You can now get a Minstrel 2 kit for $200. 1980s pricing.

• https://www.tindie.com/products/tynemouth/minstrel-2-with-keyboard-z80-based-zx80-kit/

Or you can get a Minstrel 3 kit for $200

• https://www.tindie.com/products/tynemouth/minstrel-3-with-keyboard-z80-based-zx81-kit/

Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

• https://www.patreon.com/tynemouthsoftware

Commodore SX-64 Repair and 1541 Diagnostics

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

It seems recently I've had a run of repairs which have turned out to be fairly straightforward, some like last week's C116 repairs are worth writing up as they are interesting machines, the rest are the same old usual suspects on the same old machines, so I've not written any of the up. This one however, qualifies as it's another interesting machine.

The Commodore SX-64, a Commodore 64, 1541 and a monitor, all in a box with a handle on. What Commodore described as an 'executive computer'. Something the busy executive has someone lug around for them so they can do their work by the pool.

This one isn't going to help our executive file his expense claims, it's showing nothing but a grey screen. This is in fact a black screen, with the brightness turned up.

To double check this, there is the same 8 pin DIN monitor connector as the Commodore 64 on the back, so plugging in an external monitor shows the same, a black screen. The disk drive is not spinning up either, so there is something more than just a monitor fault. A quick check with the Dead Test cartridge also showed a black screen, so time to look inside.

Looking on the back, it looks like quite an early one, late 1983, but I'm not sure how long these were in production for.

Inside the SX64, you are presented with the inside of the monitor as well as the computer and disk drive side, so as ever, use a little common sense and don't test voltages on the monitor with your wet fingers.

Leaving the monitor side well alone, it's a little difficult to access the rest, but my first test was to measure the supply rails, and the 5V rail wasn't there. Something was pulling it down and probably getting very warm. I didn't leave it on for too long, to check for hot chips, instead I dismantled it a bit further to gain access to the boards.

The first board, the one that sits along the whole right hand side of the unit, is the CPU board. This contains a large part of the Commodore 64 side of the machine. There is a nicely heatsinked VIC II chip, ceramic by the looks of it, and it's associated circuitry.

There is 64K of DRAM and it's mux chips. These are a common cause of that sort of thing, and you would often find one chip baking hot, shorting out one of the supply rails. I hope it's not that, as it will be difficult to test without making up some extension cables.

In the centre are the main chips, the CPU, the PLA, the SID and three ROM chips. The standard C64 BASIC and character ROM, and a modified SX-64 KERNAL in the centre.

There is a board plugged into this at right angles, this contains the IO side of things, the two 6526 CIAs, and various other miscellaneous parts including the 7406 IEC buffer. The round silver can top left is a 60Hz oscillator that is used to generate the time of day signal which is normally derived from the AC mains. That is not a cheap part, and they could have used mains reference on the SX-64, perhaps there was some plan to run the SX-64 from batteries?

To rule a few things out, I thought it would be easier to try these chips one by one, in a known working C64 board. I skipping the 2564 EPROM for the moment, as that is a non-standard pinout.

The ROMs, the PLA and the CPU, and all were found to be working. The machine had arrived for repair accompanied by a PLA chip on some foam. This was apparently the original chip, and has been removed by a previous owner in an attempt to fix the problem. I also verified that it wasn't working.

Whilst I had the C64 board on the test bench, I thought I would test the SID, make sure that was working, then I could leave it out of the system until I had finished testing. But when I tested the SID on the C64, I got a black screen. I measured the 5V rail and it was low, I touched the chip and it was very hot. Oh dear, it seems the SID was dead, and was causing the black screen.

I reassembled things without the SID and it booted straight away. I ran through the Dead Test again, and all passed. I think it is possible that the previous faulty PLA might have caused the SID to burn out, or it could just have overheated itself.

I'll switch back to the external screen captures at this point, as they are easier to see. I'm running a modified version of the Diagnostic ROM at this point, which knows about the SX-64. The Fails on the IO chips are due to the missing SID and the lack of loopback plugs.

So that's all working nicely. Back to BASIC, and interesting to note seeing these side by side that the SX-64 KERNAL uses the same colour scheme as the Dead Test and Diagnostics cartridges, rather than the less readable blue on blue colour scheme that the standard C64 uses

The keyword was initially a bit unresponsive, but after a bit of use, most of the keys have come back into operation. Could probably do with a full cleanup if any of those don't come back.

Time to test the disk drive. The light comes on, a good start.

It seeks, but doesn't read anything. I wasn't sure that this point if the drive was at fault, or the IEC circuitry, so I disconnected the IEC bus from the internal drive (the two six pin connectors are the IEC bus, and are wired in parallel).

There is a user port and IEC port in the same style as the Commodore 64, so I plugged in a standard SD2IEC drive and tried that out. (Note there is no cassette port on the SX-64, so you need to specify the Userport connector when ordering).

That worked fine, so the problem was the drive.

The drive inside the SX-64 is pretty much a standard 1541 drive, rearranged to fit in the SX-64 case. It's not very easy to access though, as the drive mechanism is blocked by the 'glove box' that fits above it.

I tried a few tests using the 1541 Test/Diag cartridge (by World of Jani, available from TFW8b.com). This has a good selection of utilities to diagnose issues with Commodore disk drives, which all run from the cartridge.

I started out with a few tests, but it was clear it was failing everything.

It does look like you have to remove everything to access the drive, but a handy tip is to unclip the two studs on the front sides of the 'glovebox', this allows it to be flipped upwards.

With that raised, you can access the head and the rails of the disk drive mechanism.

The head is on the bottom side of the disk, and there is a sprung clip above you can lift to access the head. I've propped it up here to get a better view.

Oooh, nasty.

That might explain why it couldn't read anything.

After a good clean, it's looking a lot better.

I also used some Molykote lubricant on the drive rails to allow them to run free.

Back to the 1541 Test/Diag cartridge to repeat the tests. I started with the performance test, that starts with a format and then various read and write exercises.

That all passed, so this is looking good.

I also tried the alignment test, that showed 100% on track and not too bad on the half track reads.

You can also do all sorts of fancy stuff such as the sector viewer.

The last test I did was the speed test, which was also within acceptable tolerance.

I noticed when putting the machine back together, that the strobe marks on the bottom of the drive flywheel are visible through the slot for the keyboard connector, so you could do it that way if you prefer.

The drive appeared to be working, but I wanted to do some further testing, so I again unplugged the IEC bus from the internal 1541 drive and plugged in an SD2IEC. Testing that using the Epyx Fastload to save typing, it responds to commands to the default ID 8.

I wanted to use the two together, but both start off as ID 8, so I will change the SD2IEC drive to ID 9. To change the ID that, use the following command: 
OPEN1,current address,15,"U0>"+CHR$(new address):CLOSE1

This will last until the power is removed. To make it persist, use this command: OPEN1,new address,15,"XW":close1

Note the drive is already drive ID 9, so you need to send this second command to the new address.
With the SD2IEC now as drive 9, I reconnected the original drive, plugged in the Epyx Fastload cartridge and booted up CBM Command to give the drive a work out.

This identified the two drives correctly, and was able to copy files back and forth.

I also tried writing a D64 image from the SD2IEC to a real floppy disk in the internal drive. That takes a while, but completed with no problems.

This was obviously for testing purposes only....

Oh dear, I can't possibly play this without a SID. I had sourced a replacement SID chip, so time to put everything back together.

To prevent further issues, I fitted some heatsinks to the SID and PLA chips.

Time to try that again. Much better, sounds great.

With everything all back together, I thought I'd finish the testing with the new Ms. Rodman cartridge.

That's running well, a nice portable games machine. Only slightly easier to carry around than a full size arcade cabinet.

Just clearing up the test bench, and I noticed, for a machine with an internal disk drive, I seemed to use rather a lot of cartridges in this repair.