PERCOM ROM

[glurk]

I just fully checked out my old drive, it's an RFD44-S1.  Everything is A-OK, voltages, caps, regulators, etc.  I remounted the regs and added heat sinks on the back.  It's all good.  The one thing I worry about is the ROM.  I think someone here archives these, correct?  I would REALLY like to have a backup (or two) of this, but I can neither read it nor burn a new one due to lack of hardware.

 

So, I'm willing to send it to someone who can read it and make a copy, but I also don't want to be without my only working drive...  Can anyone help me with this?  I don't know if this one has been read/archived already?    That's my question, really...

 

Anyone here can help?  Thanks!  Photos attached:  percom.zip

[+MrFish]

Looks too me like one that hasn't been dumped yet.

 

Probably @Nezgar would be interested to help you with it.

 

[moonlight_mile]

Looks too me like one that hasn't been dumped yet.
 
Probably [mention=53052]Nezgar[/mention] would be interested to help you with it.
 

Yup you are right. My rfd indicated 1.20 on it.

[DavidMil]

22 hours ago, glurk said:

I just fully checked out my old drive, it's an RFD44-S1.  Everything is A-OK, voltages, caps, regulators, etc.  I remounted the regs and added heat sinks on the back.  It's all good.  The one thing I worry about is the ROM.  I think someone here archives these, correct?  I would REALLY like to have a backup (or two) of this, but I can neither read it nor burn a new one due to lack of hardware.

 

So, I'm willing to send it to someone who can read it and make a copy, but I also don't want to be without my only working drive...  Can anyone help me with this?  I don't know if this one has been read/archived already?    That's my question, really...

 

Anyone here can help?  Thanks!  Photos attached:  percom.zip

If you can't get a good dump of your ROM I have a slightly new ver. (2.1)  That I can send you.

 

DavidMil

[glurk]

57 minutes ago, DavidMil said:

If you can't get a good dump of your ROM I have a slightly new ver. (2.1)  That I can send you.

 

DavidMil

Hey, great!  Do you have the actual ROM chip?  Does it support DS/DD and all?  I will pay you for the EPROM and postage if so.  I personally have no possible way to dump my ROM, or burn another one either, and I worry that it may fail/bit-rot, etc...  If I get a working chip, I can send this one to someone to dump and archive, because I can't do it.  Thanks!

[+Nezgar]

On 5/5/2021 at 2:21 AM, MrFish said:

Looks too me like one that hasn't been dumped yet.

 

Probably @Nezgar would be interested to help you with it.

 

Thanks for the ping @MrFish -- Heya @glurk Just looking at your photos, I see your ROM label reads as:

DCA-0065-001

V 1.10 / T3(?) / 8-28-82

 

I appear have two previous matching dumps of V 1.10 (CRC32 E2D4A05C) :

• From an RFD-40S1 from @moonlight_mile label dated 8-28-82  (here)
• From an RFD-40S2 from @ballyalley Label dated 11-8-82  (Referenced here, but can't find the original post at this moment)

So we have an exact same date stamp in a ROM from a RFD-40S1, as well as your RFD-44S1... I'd be happy to dump yourV 1.10 chip just for further verification, but based on the date on the label I think we can be pretty sure it's the same. The v1.2 ROM may work just fine in that drive. (I presume @DavidMil meant 1.2, not 2.1??) I'd also be happy to send you a programmed EPROM with RFD 1.2 (CRC32 C6C73D23 as per a dump from moonlight_mile here)

[DavidMil]

No, it says 2.1, but I'm not sure about it's origin.  Here are a couple of pictures... 

 

David

[+Nezgar]

@DavidMil Right! Wow look at that. I think I may remember you mentioning this now prior to your hiatus - and welcome back by the way!

 

I would very much like to get that dumped. I'll PM you.

[moonlight_mile]

I did burn my rfd44 rom and it is in my rfd40. I don’t have a double sided drive in it but otherwise it works fine.

[+MrFish]

On 5/7/2021 at 6:11 PM, Nezgar said:

DCA-0065-001

V 1.10 / T3(?) / 8-28-82

 

I appear have two previous matching dumps of V 1.10 (CRC32 E2D4A05C) :

• From an RFD-40S1 from @moonlight_mile label dated 8-28-82  (here)
• From an RFD-40S2 from @ballyalley Label dated 11-8-82  (Referenced here, but can't find the original post at this moment)

 

Ah, ok... I didn't have that ROM posted by @moonlight_mile. Thanks for the link to it.

 

[DavidMil]

On 5/7/2021 at 11:01 PM, Nezgar said:

@DavidMil Right! Wow look at that. I think I may remember you mentioning this now prior to your hiatus - and welcome back by the way!

 

I would very much like to get that dumped. I'll PM you.

I sent the dumps for both chips to Nezgar.  He is currently evaluating both of them.

 

David

[_The Doctor__]

bump!

[glurk]

I've already PM'd Nezgar about this (recently) and there is some progress being made, just FYI.   Otherwise, I'm just waiting on new news myself, as well.

 

[Mclaneinc]

I'm sure after his normal expert scrutiny that he will pass on the dumps, too many wrong dumps of stuff around, better it's properly checked out, be it a disk or a rom. Yet again we must thank the efforts of our great archivists and emulation writers for making these dumps useful to those with no hardware..

[DavidMil]

Hello Nezgar.  This has been a while back, and my memory looks and works about as well as a cotton ball.  Did I ever send

you those dumps?

 

David

[glurk]

So I made a trade with DavidMil, and I got him to send me an EPROM of his 2.1 ROM, which I have been testing in my real drive.  Here is the dumpfile of it:

RFDV21.BIN

 

I installed it in my drive, and everything seems to work.  SSSS, SSDD, DSDD, and it works with a 3.5" drive as D2:  (I could do all of this with my old 1.1 also... ) And I "think" I like this new one better than my previous ROM.  It seems a bit faster overall, and one thing for SURE!  My old ROM, when formatting a disk would fill each sector with $1A bytes when formatting in SD, and two odd bytes ($92,$49 I think) when formatting DD.  This new ROM properly ZEROES the sectors, as it should.

 

This is good, because the non-zero sectors could confuse some sector copiers, and they would then copy all of them, instead of skipping the blank ones.

 

As well, and I know almost NOTHING about 6809 assembly, I ran the ROM through the first disassembler I found (f9dasm) and took a stab at making sense of the code.  Knowing that the ROM must handle Percom blocks, I annotated some of the disassembly, and also put blank lines after all RTS and absolute branch instructions, to make it into sections.

 

Everything in my annotations is "guesses" but I'm pretty certain on some of it.  If I spent more time, I could probably figure out more, but hasn't someone done this already?  I think I read that, but I've never seen a disassembly released.  I bet someone else (maybe a CoCo programmer) would have better luck with it.  I've never done ANYTHING in 6809 before....

 

For what it's worth, here is my slightly annotated disassembly of the 2.1 ROM, with likely mistakes in it:

output.rtf

 

EDIT TO ADD:  Ok, at the start of the disassembly, there are 18 non-repeating bytes, followed by 0, then 18 more non-repeating bytes, again followed by 0.  These series are all within 18 values of each other.  These MUST BE the sector-skew layout for both single and double density.

 

This would explain the speed increase, I suppose.  Also, there seems to be NOTHING in there that looks like support for 77 track disks.  I'm quite sure that the Percoms just do not support that.  Or Enhanced density either.

 

Edited July 26, 2021 by glurk
add info

[glurk]

Ok, replying to myself, I did the necessary subtractions to get the skew orders from 1-18.  Here they are:

 

SD:

02,04,06,08,10,12,14,16,18,01,03,05,07,09,11,13,15,17

DD:

18,12,06,13,07,01,14,08,02,15,09,03,16,10,04,17,11,05

 

I'm just absolutely certain that these must be correct.

[+MrFish]

What specific RFD model did this come from?

 

[glurk]

DavidMil will have to answer that, I don't think he mentioned it.  He said it came from an old broken Percom he had.  What I put it in was an RFD44-S1.

 

In the meanwhile, I found phaeron's disassembly of the 1.2 ROM, MUCH better annotated than my sorry effort at it!  I compared them, and there are very few differences between the 1.2 and this new (to me) 2.1 version.  What I found, in the actual disassemblys, was the $1A1A sector fill bytes were changed to $0000 and also the DD fill bytes $9249 also zeroed.

 

I also found the "format timeout" was changed to $8C from $7A or $7B or so (I forgot).  Increased by a small amount, in any case.  Also, a "check deleted sector" bit-compare flag value was changed from $20 to $28.  I don't know what that does.

 

Other than those 4 things, and some code moved around, they are otherwise identical, I believe.  I only spent a couple hours looking at it, 6809 code is complex as heck!  I think phaeron is supposed to be going over it too, and he'll do a better job than me, but I had the dump-file, and I had the time, so I did my best at it.

 

It's a 2048 byte 2K ROM, and it's almost "full."  I was hoping/thinking that some kind of upgrades/changes might be possible, but they would have to be small things, I believe.

[DavidMil]

Sorry MrFisk and glurk; That drive died about 34 years ago.  As I remember, neighbors down the street got hit by lightning,

and it fried everything in the drive with a coil.  I remember because I lost the ability to 'read /use' a lot of floppy disks.  All

I can tell you is the info on the board itself:

 

Percom 1982

510-1260-.01  Rev.E

The serial number line is empty, but I think it had a paper serial number stuck on there???

 

The newest chip on the board is the Western Digital controller chip:  FD1795B-02   Dated 1983 Week 18   (8318).  All

the other chips are dated 8308 or late 1982.

 

DavidMil 

 

[phaeron]

14 hours ago, glurk said:

Other than those 4 things, and some code moved around, they are otherwise identical, I believe.  I only spent a couple hours looking at it, 6809 code is complex as heck!  I think phaeron is supposed to be going over it too, and he'll do a better job than me, but I had the dump-file, and I had the time, so I did my best at it.

That's strange, normally Nezgar is the one who uses the PERCOM bat-sign....

 

V2.10 disassembly attached. This appears to be a backport of fixes from the AT88-SPD firmware to the RFD, since it has almost all the fixes there but a code size optimization to the format routine that all other versions lack. Differences from RFD V1.20:

• Sector fill is reset to $0000 and format timeout increased to $8C, as glurk noted.
• 1.4ms delay added before command ACK and after Complete.
• Density detection on read of track 1, sector 1 is no longer restricted to D1:.
• CRC errors no longer do a recalibrate and only do quick retries before returning.
• Long sector errors (BSY=1) are converted to record not found (RNF) errors. I'm not sure why this was done, it doesn't affect density detection and it would only break some copy protection checks.
• The format routine was modified to pull out a common block of code to save ROM space, to make room for patches. No functional changes.

Strangely, the logical-to-physical mapping is unchanged in this version, so either I'm still misunderstanding something in the asm or all versions have the same off-by-one bug on side 2.

 

It's beginning to look like fixes were made for the AT88 lines and then subsequently backported to the RFD. Compared to the AT88-S1PD firmware, this would lead to the possible version history AT88 V1.11 > RFD V1.20 > AT88 V1.21 > AT88 V1.31-1.41? > AT88-SPD V2.01? > RFD V2.10.

 

6809 assembly is not that complicated, the syntax is similar to 6502 due to the common 6800 design heritage. It's generally more powerful and expressive than the 6502, with the exception of a few WTFs (TFR takes 6 cycles??). There isn't much space free in the ROM, but there's a lot of parts that are not written efficiently and could be compacted a bit. Often it's long relative addressing being used when short addressing would work, but there's also silly stuff like LDA #imm / COMA. Wouldn't be enough space to add anything big, but enough for a simple feature like an execute command. And it's not like any of the PERCOM drives can implement US Doubler high speed mode, at least not without possibly abusing the UART.

 

 

percom-rfd-v21.s

[moonlight_mile]

Has anyone ever put an rfd rom in an at-88?
Just wondering.

[_The Doctor__]

8 hours ago, phaeron said:

That's strange, normally Nezgar is the one who uses the PERCOM bat-sign....

 

V2.10 disassembly attached. This appears to be a backport of fixes from the AT88-SPD firmware to the RFD, since it has almost all the fixes there but a code size optimization to the format routine that all other versions lack. Differences from RFD V1.20:

• Sector fill is reset to $0000 and format timeout increased to $8C, as glurk noted.
• 1.4ms delay added before command ACK and after Complete.
• Density detection on read of track 1, sector 1 is no longer restricted to D1:.
• CRC errors no longer do a recalibrate and only do quick retries before returning.
• Long sector errors (BSY=1) are converted to record not found (RNF) errors. I'm not sure why this was done, it doesn't affect density detection and it would only break some copy protection checks.
• The format routine was modified to pull out a common block of code to save ROM space, to make room for patches. No functional changes.

Strangely, the logical-to-physical mapping is unchanged in this version, so either I'm still misunderstanding something in the asm or all versions have the same off-by-one bug on side 2.

 

It's beginning to look like fixes were made for the AT88 lines and then subsequently backported to the RFD. Compared to the AT88-S1PD firmware, this would lead to the possible version history AT88 V1.11 > RFD V1.20 > AT88 V1.21 > AT88 V1.31-1.41? > AT88-SPD V2.01? > RFD V2.10.

 

6809 assembly is not that complicated, the syntax is similar to 6502 due to the common 6800 design heritage. It's generally more powerful and expressive than the 6502, with the exception of a few WTFs (TFR takes 6 cycles??). There isn't much space free in the ROM, but there's a lot of parts that are not written efficiently and could be compacted a bit. Often it's long relative addressing being used when short addressing would work, but there's also silly stuff like LDA #imm / COMA. Wouldn't be enough space to add anything big, but enough for a simple feature like an execute command. And it's not like any of the PERCOM drives can implement US Doubler high speed mode, at least not without possibly abusing the UART.

 

 

percom-rfd-v21.s 60.27 kB · 5 downloads

Phaeron (Avery), would it be better to revert the long sector patch so it will keep more compatibility? It look's like this is indeed the best version so far save that particular issue. Since this has piqued some interest in you, would you consider giving some of it a touch up?

[phaeron]

7 hours ago, moonlight_mile said:

Has anyone ever put an rfd rom in an at-88?
Just wondering.

RFD, AT88, and AT88-SPD hardware are incompatible designs and can't exchange firmware.

 

3 hours ago, _The Doctor__ said:

Phaeron (Avery), would it be better to revert the long sector patch so it will keep more compatibility? It look's like this is indeed the best version so far save that particular issue. Since this has piqued some interest in you, would you consider giving some of it a touch up?

Unsure if it's a good idea to revert, as the FDC is a fickle chip in practice. As for making mods myself, sorry, no, my interest is limited to existing firmware.

[glurk]

I had this same idea too, even though the "family" of Percom owners is fairly small, we now have the "latest-greatest" firmware, disassembled and documented.  So, if we as a community, took that, fixed all the known bugs, and optimized it for size, taking out all the redundant code and tightening it all up, we could have the "perfect" firmware with added free space to put into EPROM and use.

 

And new features too, no idea what.  Certainly can change around the step-rate, sector skew, etc.  Maybe even add enhanced density, or 77-track support, or whatever.  And I'm TOTALLY willing to help with this!!  No problem.  Except:

 

I'm not a 6809 guy.  Someone else would be better suited.  And I have no idea how to optimize/test a whole bunch of interdependent floppy disk drive  timing-critical settings.

 

My idea to start would be to get the source to compile back into the original first.  Then optimize it for size, taking out all the unneeded code and jumps, etc., without changing functionality.  Then there would be X number of free bytes to add things.  And that would be a community decision, or leave it open for individuals to decide, having more free space in there.  Maybe different ROMs with different features, etc.

 

ABSOLUTELY I'm willing to do what I can.  It's not stuff that is really my forte, but whatever I can.  I'm really pretty good at optimizing code, but really just in 6502....  But I can learn....  And I have the time and inclination to do it.  I love my Percom, LOL, and I'd like to make it the best possible.