SWTPC and Percom woes...

[johnx993]

Here's a weird one...

My SWTPC 6800/2 was modified by the previous owner.
A custom Monitor (called only version 1.24, with NO docs) a 4 chip set, came with a missing chip, so some commands don't work.
I restored it to run SWTBUG. All was well until I got to the disk system (Percom LFD400 controller and SWTPC MF-68 dual drives)
The Percom controller has 2 EPROMs, running MPX, and the requisite base Minidos.
I encountered a failure with the Save command, writing to disk then halting with no prompt - perhaps on the directory write as that is done last in the code.
It makes the disk unusable and I have to use BACKUP to write a new disk image on it from a good copy.
All else works well: I can copy files, backup disks, run Percom BASIC (including saving a file from BASIC to disk), etc.

So, I dumped the ROMS, and found some differences.
in the MPX chip, the prompt char was changed and the prefix char for protected files was changed,
The 00 sentinel value at the end of the command table was now 50. Though it still worked!
More interesting changes in the Minidos chip: several instances of LDAs replaced with ANDs and BITs.
And one char value changed from 'S' to 'Q', impacting the display of 'sector' label on some operations

The prompt char changes can be attributed to the prior users preference.
But things like table sentinel values (where the code actually tests for 00 and not 50, I checked), and the LDA changes, and the 'Q' make me think 'chip rot'.
Where the EPROM misses some bits over time.

So... I programmed 2 new chips: Minidos1.4 and the companion MPX.
Now it won't even bring up the prompt at all.
Replacing the original chips, and it works again.
For some reason, what should be the 'proper code' does not work.

Very strange.

 

[jlang]

Where did you get the binary for replacement EPROMs?
The Percom listings did not always match the shipped EPROM.

 

[johnx993]

I've had the binaries for years, originally from Holley's site, I think. Now mirrored on deRamp.
Still, hand reading the code, it should at least give me a prompt, yet it does not.
And even if the existing EPROM code is 'correct', the Save command doesn't work.
That's pretty crucial, and I don't think they would have shipped it without testing that.

 

[jlang]

Back in the day I had a LFD400. The shipped code worked. The listings were a bit iffy.
The Percom ROMs called the monitor ROM directly. If you're not running Mikbug that may cause issues.
Save called Mikbug several times to get start address, end address, starting track/sector.
If get4hex is not at the expected address you're going to hit the wall pretty quick.(for instance)

 

[johnx993]

Jlang, you may have found the problem!

I'm not running Mikbug, I'm running SWTBUG.
I'll start digging through that.
Thanks!
-J

 

[johnx993]

Well.. now I think that's not the problem.
I checked the addresses, and the chapter on Mikbug compatibility for Swtbug.
All the addresses and basic functionality is the same.

I ran the delta between the binary of the the existing EPROMs and the new EPROMs.
None of the call addresses were changed.
And I seem to recall years ago, I managed to get a copy of Uiterwyk's BASIC on a Percom floppy.
Sadly, my notes don't describe the exact process.
if it was convoluted,I would have noted the steps.
Which leads me to believe I used the standard 'Save' command.
Which adds more weight to the 'chip rot' hypothesis.
But that still doesn't explain why, for example, the new MPX chip fails to work, when the known deltas don't look to be an impediment.