Franklin Ace 1000 Won't Floppy Boot but seems OK?

[shevett]

I picked up an Ace 1000 and I'm trying to get it up and running. I have a floppy drive on it, and a BMOW emulator as well. I don't have a bootable floppy disk unfortunately.

Powering on the drive makes the traditional clunkitah-cllunktah, so I know it's initializing.

Plugging in the BMOW board, and selecting a ProDOS boot image (or anything, actually) - never shows any activity on the controller (the track selector never moves, no activity light).

If I hit Reset, it drops to the BASIC prompt, where I can type in a simple HELLO WORLD app and it works.

From the command line, if I do a PR#6 to do a boot, still no activity on the controller. If I do the PR#6 with the drive plugged in, nothing happens on the drive.

Occasionally when I hit PR#6 I'll get an ?OUT OF MEMORY error or possibly ?ILLEGAL QUANTITY ERROR :

I've pulled all the cards out except the Franklin disc controller. Note this machine also has an 80 column card, so I'm patched into that for video. It also also has a RAM expansion board. I've pulled out the ACE 80 and the Microsoft Softcards just to keep things simpler.

I've forgotten so much about how to work with these machines. Am I doing something stupid?

 

[VERAULT]

The franklin 13/16 floppy controller can be bad. I have a dead one for instannce I,havent gotten repaired yet. Can you pop in a standard apple ii disk ii controller and try again?

 

[shevett]

The franklin 13/16 floppy controller can be bad. I have a dead one for instannce I,havent gotten repaired yet. Can you pop in a standard apple ii disk ii controller and try again?

Maybe? I have to go to my storage unit and see what I have there. I'll try and do that tomorrow. I take it I'm doing 'the right thing' here, something's amiss?

 

[VERAULT]

A franklin ace is just an apple ii clone. So it should behave the same using the same parts. I repaired a 1200 which is the same board as you have.

 

[cryu]

(quick aside to prevent incorrect information from being propagated)

The BMOW FloppyEmu doesn't work in an ACE1000 with an Apple controller -- timing difference between the ACE1000 and the ][+. It will, however, work with the Franklin controller.

Steve@BMOW is aware of the issue but there is no timeframe for a fix; I reverse-engineered the Franklin controller (https://codeberg.org/cryu/weyoun) with the intention of putting things on a logic analyzer to give Steve data for A/B comparison, but life keeps getting in the way.

If I had to guess, that big transistor that (needlessly!) switches the power rail on the TTL state machine fried, with bad cables to the floppy emulator in second place.

 

[VERAULT]

Thats very interesting. I cant say whether or not I ever used a floppy emu on the Franklin Ace. So best to take Cryu at his word.

 

[d5aa96]

Even if you get the BMOW gear working, I am not sure you will have success with a ProDos boot disk. It was my understanding the ProDos was programmed not to work with clones such as the Franklin. I have an ACE 1200, but I have yet to test this... ;-)

 

[shevett]

So a slight update here. Turns out I do NOT have a spare franklin controller (my other Ace 1000 has no cards in it, boo hoo). I have found one on ebay and put an offer in, just in case this is the controller.

Thanks for the information about the BMOW not working with the Apple II controller in a Franklin,

I think one of my next steps will be to haul out one of my IIe or II+ machines that has drives on it and see if I can get it up and running and boot from there, and create a new boot disk.

@d5aa96 I hear you - but the BMOW board wouldn't even show that it was reading tracks - if ProDOS were crashing on boot it would have at least shown some activity. I tried a couple different images (like AppleWorks and a few others), nothing ever showed any data being read.

 

[VERAULT]

Even if you get the BMOW gear working, I am not sure you will have success with a ProDos boot disk. It was my understanding the ProDos was programmed not to work with clones such as the Franklin. I have an ACE 1200, but I have yet to test this... ;-)

ProDos worked fine on my Franklin 1200 which has the exact same board as the 1000. Franklin offered multiple Roms. Maybe original ones had issues but not all.

 

[cryu]

Apple ProDOS (i.e., versions before John Brooks' 2.0.3, starting with 1.01 IIRC) checked the machine ROM signature early in the boot process. If the check failed, ProDOS locks at the boot splash screen.

If the problem was ROM incompatibility, you would see/hear disk activity, then see the splash screen, then the machine would hang. You're not getting that far, so it's going to be controller or cables.

You might try to jumper the middle two pins of the four-pin firmware select jumper block together. That should display a "jumper this card like *this*" splash screen; doing so would indicate whether the 2708 EPROM is still good. If it is, then you can kick the firmware into technician mode and narrow down the problem from there.

 

[shevett]

If the problem was ROM incompatibility, you would see/hear disk activity, then see the splash screen, then the machine would hang. You're not getting that far, so it's going to be controller or cables.

This is remarkably close to what is happening - So on power up, There's a beep, there's disk activity, I see the ACE 10000 splash screen, and then it just sits there. I can hit the RESET, and get the ] prompt. PR#6 (or whatever) does NOT do anything - no disk activity and nothing on the BMOW.

However, I took your advice and pulled the jumper (i don't think it matters if the jumper is on the middle two pins or missing completely, and I get the status display

I consider this a good thing .

Do you have guidance to next steps? It was jumpered for 16 sectors, so that should have been correct. I'm not familiar with technician mode here...

 

[cryu]

This is remarkably close to what is happening - So on power up, There's a beep, there's disk activity, I see the ACE 10000 splash screen, and then it just sits there.

Okay, yes, it's not loading anything from disk. You'd see a ProDOS splash screen otherwise, where it would lock if it was a version that checked if it was running on a clone.

(strongly, *strongly* recommend you test with ProDOS 2.4.2 from here to forestall further WAGging about ROM incompatibilities. 2.4.2 works just fine on just about every clone as long as it has 64k, and I use it nearly daily on my ACE1000)

However, I took your advice and pulled the jumper (i don't think it matters if the jumper is on the middle two pins or missing completely, and I get the status display

Yes, that indicates that the EPROM is still good (or, at least, the splash screen code). Pulling the jumper completely is equivalent to jumpering pins two and three -- 1 and 4 are connected to EPROM address lines, 2 and 3 are ground, I suspect the "jumper 2 and 3" bit was to keep end-users from losing the jumper.

(your JPEG didn't come through, but if you're seeing a crude ASCII diagram of the jumper settings, you're good to go)

Do you have guidance to next steps? It was jumpered for 16 sectors, so that should have been correct. I'm not familiar with technician mode here...

It's okay, practically nobody nowadays even knows that the technician mode exists. It's poorly documented in the floppy controller "service manual"; the best reference is the disassembly in the weyoun repository.

The quickstart is essentially this:

• jumper 1-2 and 3-4 on the jumper block,
• turn on the ACE1000 (which will dump you directly to a BASIC prompt),
• execute "CALL 50688" (assuming slot 6)
• you're now in technician mode.

Once you're there, try getting the drive (the real drive, not the FloppyEmu) to seek to track 18 by executing "18S". If the head seeks, then try to seek to tracks 34 and 2.

If all of that works, then the stepper motor circuit on the controller is okay, and we'll start looking at the read/write circuit. Based on the behavior you're reporting, though, I suspect that the tracks seek tests are going to fail.

Oh, dumb question: you were trying to use the FloppyEmu with it plugged into the header labelled "Drive 1", right? Not with the real floppy in the drive 1 header and the FloppyEmu in the drive 2 header? I made that mistake a few times while testing weyoun

 

[shevett]

(your JPEG didn't come through, but if you're seeing a crude ASCII diagram of the jumper settings, you're good to go)

That's odd, it's showing on my screen here okay - yes, there's the ASCII diagram showing the jumper positions, so win there.

• jumper 1-2 and 3-4 on the jumper block,
• turn on the ACE1000 (which will dump you directly to a BASIC prompt),
• execute "CALL 50688" (assuming slot 6)
• you're now in technician mode.

This worked! I got the line of text from the monitor:

(The jumpers changed two things. There was no 'ratta-tatta-tat' of the drive initializing on power up, and it dropped immiediately to the BASIC prompt.)

However, running the 18S command did nothing . No noise from the drive at all.

This is sounding more like a problem with the controller huh? I have a line on a possible replacement. This is slightly stymied by the fact that I have no physical media, so I can't run a diagnostic floppy until I get the BMOW controller to work - maybe what I"ll do is haul one of my Apple II's out of storage with it's floppies, hook the BMOW to it and generate a few working disks.

In the meantime, this sure looks like the controller is whacked, huh?

Oh, dumb question: you were trying to use the FloppyEmu with it plugged into the header labelled "Drive 1", right? Not with the real floppy in the drive 1 header and the FloppyEmu in the drive 2 header? I made that mistake a few times while testing weyoun

HAHA. No, the only thing I have cabled in is either the floppy drive _OR_ the BMOW board, and I'm only using DRIVE 1 for the connection. Good to check though

 

[cryu]

Ah, hmmm. It looks like you didn't enter technician mode:

• that screenshot (which *did* go through) indicates that you're in the monitor, not technician mode (you should see a "#" as a prompt, not the monitor's "*"),
• the floppy controller looks like it is in slot 5 rather than 6, so jumping to the non-existant ROM in slot 6 will drop into the monitor.

If you can, move the controller into slot 6 and try the seek commands again. If you can't, try CALL 50432 instead (that jumps to $C500, which is the ROM entry point for slot 5).

That's progress, though, as the ACE1000 is behaving the way that it should. By the way, it looks like you have a Saturn clone in slot 0, so you'll want to make sure that the onboard high 16k is disabled (bowtie solder jumper X3 is cut on the bottom of the board, and Y3 on the top of the board is connected). That isn't causing the floppy controller issue, but the Saturn fighting with the onboard memory will cause problems down the road.

 

[shevett]

The 3 seek commands worked! I heard the heads moving back and forth as needed.

However, hooking the BMOW board back up and doing a PR#5 shows no signs of life.

I have ordered another disk controller, so maybe that'll help. I can't think of a way to 'generate' a bootable floppy off one of my other machines - the apple drives are so odd. :-/. I may have a source of floppies from a friend, so I'm going to dig around there.

 

[cryu]

That's good, very good. If the real drive is seeking, then the FloppyEmu should be able to do the same thing. Try connecting the FloppyEmu to the drive 1 header, selecting a blank disk image (.do, .po, .woz, shouldn't matter), and trying the same seek commands. You should see the FloppyEmu track indicator seek up and down to the desired track.

That, at least, should work. If it doesn't, I'd look very closely at the cable between the controller and the FloppyEmu, and maybe cross-test with one of the Apple machines you have in storage.

(um, another dumb question: you're using the FloppyEmu with the latest Apple ][ firmware, yes? It might have shipped with Macintosh firmware {but in that case, it should complain when you select an Apple ][ image, so *shrug*})

If you have an oscilloscope (which I suspect you do, based on that snapshot of your workbench , you can go through the controller calibration procedure to verify that the controller's data clocking circuit is functional. You don't need a floppy for that. That procedure is:

• connect oscilloscope to TP1
• start machine
• execute "call 50688"
• execute "AAW" (and immediately hit ESC)
• adjust R1 until waveform period is 5.4 microseconds
• connect oscilloscope to TP2
• execute "99W" (and immediately hit ESC)
• adjust R2 until waveform period is 3.8 microseconds

Those test points are unmarked on the Franklin board, and look like simple vias. They're below the two variable resistors at the front of the card. Before adjusting, measure the resistance of the variable resistors so that you can revert changes ... made that mistake too

Edit: I'm starting to wonder if perhaps Steve@BMOW recently made a change to the FloppyEmu firmware that broke the already tenuous Franklin support -- he tests releases by watching a logic analyzer, and there's no debug port on the FloppyEmu, so firmware QA boils down to "works for Steve on his gear". While diagnosing the issue with an Apple controller a few years back, I discovered that really old firmware revisions would boot with the Apple controller, albeit *very* slowly, and then-current revisions would boot as long as I lobotomized the ACE1000 video circuit to match the odd Apple timing. It might be worth testing with downgraded firmware; I can send older revisions to you privately if you can't find them on his website.

 

[shevett]

So I did a firmware update with the new femu.bin (dated Dec 12). I did try as you suggested with the older firmware - asking it to seek on the BMOW board just changed the diplay to say WRITE and it wedges. No track motion at all.

Firmware update, same thing is happening.

My silly-scope is off-site right now, I'll try and get it back to try as you suggested. In the meantime I have a new Franklin card coming. I'll also reach out to Steve to take a look at this thread and see if he has any insights. Let me know if this pic shows you what's going on - note it says WRITE on the display - that happens immediately upon anything like PR#5 or similar

 

[cryu]

The FloppyEmu saying "WRITE" suggests that U10 is (de)asserting the signal to pin 18 on the floppy connector -- that's a "must not happen" case during a pure read operation. I'd test U2 (74x02), U3 (74x14), U6 (74x05), U8 (74x08), and U10 (74x109). That's nearly everything in that signal path between the card bus and the floppy connector.

Assuming the FloppyEmu cabling is okay, one or more of those five chips is going to be marginal. Maybe something as simple as an oxidized socket. I'm not sure why the FloppyEmu isn't stepping the head like the real drive, but it might be doing extra sanity checks (like not stepping while WRITE is active) and dropping directives that it can't make sense of.

 

[shevett]

By the way, had a very good conversation with Steve at BMOW - covering most of what was said here. What I'm going to do is take the Floppy Emu and try it on an Apple machine with an Apple disk controller to make sure the Emu is working correctly - jiust to eliminate variables. I should be able to do that tonight.

 

[cryu]

That's good news -- Steve is a very good (and patient!) guy.

If the FloppyEmu works okay with the Apple gear, then no worries, we'll figure out what's wrong with the Franklin controller and get you running.