Rana ROM images

[Mathy]

Hello Karl, guys

 

9 minutes ago, kheller2 said:

October 12, 1983

November 02, 1983 .. assuming a typo in the revision date.

 

Typo or intensionally left out, but I totally agree on this possibly/likely being the encoded dates you, Karl, mention.

 

Sincerely

 

Mathy

[Jeffrey Worley]

I choked the stepper, head, and spindle today.  It helps a lot but is not a complete fix.  Maybe 90% with a piece of sheet metal atop the drive.  Without, it is super-stable.  With the chokes, however, I can stack the indus on top without it completely flaking out, as it would even with the "T" cut out I hacked into the shell.

 

Best,

 

jeff

 

 

Edited May 15, 2020 by Jeffrey Worley

[+kheller2]

1 hour ago, Mathy said:

Hello Karl, guys

 

 

Typo or intensionally left out, but I totally agree on this possibly/likely being the encoded dates you, Karl, mention.

 

Sincerely

 

Mathy

Well, maybe.   The first post in this thread is talking about the problems with the S110230. version.  So either they really messed up a later revision or...  must I dump my PROM.. hmm... so many screws to take out.

 

[+kheller2]

On 5/10/2020 at 3:09 PM, MrMartian said:

Yeah, I often go back and curse myself trying to remember which file was which... I'm too used to small filenames.

 

But, this should be 8031 as that's the chip (or 8051), not 8531 .. ??

What version did you base each on?

You mentioned originally starting with the 8f9af9f4f08638059e6a88764760aadb  6502 version.  Which 8031 ROM did you start with for the modification:

f2a4a0c4e7fa3b79dd0bb4b6d76a9883 or 24e4742863b1ea30cda1820846f77881

 

[MrMartian]

On 5/14/2020 at 9:12 PM, kheller2 said:

What version did you base each on?

You mentioned originally starting with the 8f9af9f4f08638059e6a88764760aadb  6502 version.  Which 8031 ROM did you start with for the modification:

f2a4a0c4e7fa3b79dd0bb4b6d76a9883 or 24e4742863b1ea30cda1820846f77881

 

I don't remember, but most the whole ROM is rewritten as I made the whole read / write / format routines actually work.

 

[_The Doctor__]

not much of the host creature remains :)

[Jeffrey Worley]

6 hours ago, _The Doctor__ said:

not much of the host creature remains

Not a lot of room for criticism of this rom, but here's some:

 

Density smartness is ok.  One can't, for example, turn the drive on and RPM a disk right off, one has to do a directory or otherwise tag the disk for access before density smartness kicks in and THEN do your RPM or SCOPY or whatever else.  Better than most drives, actually. but not as good as a USD 1050, which is density-smarter by a smidge.  Apparently, the request for a read of a specific sector (via the RPM command) does not cause the rana to test density before trying to execute the sector read, but a Directory command does cause the Rana to go through that test beforehand.

 

The polled? routines for the track led flicker due, I think, to the same chip that drives it doing the bitbanging of data through the SIO port.  SIO of any description steals time from this routine and the track LEDs flicker sympathetically.

 

The track led loses an entire seven-segment when the drive goes to sleep with the Atari computer OFF.   It comes back when you power the Atari.  This is kinda strange.  Again, no harm, as the computer is off and the drive therefore purposelessly on.  That said, it is a cosmetic glitch.  It is not always one or the other seven-segment module that is turned off, so sometimes the drive will display a 3 or a 9 during this time, but not 39, after a period of the Atari being off.  I haven't timed this but it is duplicable.  Just turn the Atari off and wait a while.  Next time you look at the Rana it will be displaying only half of the "39" information.

 

The Drive track indicator does not display the track being formatted during format as the Indus does.  This would be nice, as the Ran MPI mechanism is so quiet one needs some positive indication of function during this time.  Instead the Track indicator indicates "F", for format, as a stock Rana does.

 

Sometimes the Rana fails to finalize a formatting of a disk when coupled with an Indus GT doing a SCOPY from the Indus to the Rana.  I think there is a slight glitch somewhere, with switching the baudrates between the two or something.  I'm using SDX with and without the HSIO routines in the U1MB turned on for the Rana.  HSIO needs to be turned off, of course, for the Indus.  This is done on a drive for drive basis in the U1MB bios.  It took me awhile to notice this glitch.  Might not even be the Rana's fault, but I have not seen this with the USD 1050, Happy, or Speedy in concert with the Indus.  I will attempt to duplicate this glitch with them sometime this week.

 

Mr. Martian REALLY ought to use the extra space at the end of the rom to detail the nature of this rom for posterity.  Who, what, when, why, how, the whole smear.

 

Again, I'm trying hard to find criticism and this is all I could come up with.  Amazing.

 

Best,

 

Jeff

 

 

Edited May 16, 2020 by Jeffrey Worley

[toddtmw]

So. I've decided to get @Dropcheck's burner when she gets more available. In the meantime, I assume that replacing the crystal without replacing the ROM is a bad idea?

 

Correct?

 

Thanks!

[MrMartian]

19 minutes ago, toddtmw said:

So. I've decided to get @Dropcheck's burner when he gets more available. In the meantime, I assume that replacing the crystal without replacing the ROM is a bad idea?

 

Correct?

 

Thanks!

Well, only if you want to use the drive..

[Jeffrey Worley]

22 minutes ago, toddtmw said:

So. I've decided to get @Dropcheck's burner when he gets more available. In the meantime, I assume that replacing the crystal without replacing the ROM is a bad idea?

 

Correct?

 

Thanks!

Pretty sure it is.  I think.  I didn't try the crystal without the rom, but did try the rom without the crystal.  Didn't work.  I think the code is written with very specific timing.

 

Edited May 16, 2020 by Jeffrey Worley

[MrMartian]

6 hours ago, Jeffrey Worley said:

Density smartness is ok.  One can't, for example, turn the drive on and RPM a disk right off, one has to do a directory or otherwise tag the disk for access before density smartness kicks in and THEN do your RPM or SCOPY or whatever else.  Better than most drives, actually. but not as good as a USD 1050, which is density-smarter by a smidge.  Apparently, the request for a read of a specific sector (via the RPM command) does not cause the rana to test density before trying to execute the sector read, but a Directory command does cause the Rana to go through that test beforehand.

Well, like pretty much every other firmware I've seen, the density check is done while reading sector 1, and if there is an error then try after changing density.. That's why modern DOSes always read sector 1 before anything else. I'm guessing the 1050 US will do this on any sector, but then that would affect indicating bad sectors... A longer delay at least?

6 hours ago, Jeffrey Worley said:

The polled? routines for the track led flicker due, I think, to the same chip that drives it doing the bitbanging of data through the SIO port.  SIO of any description steals time from this routine and the track LEDs flicker sympathetically.

 

The Drive track indicator does not display the track being formatted during format as the Indus does.  This would be nice, as the Ran MPI mechanism is so quiet one needs some positive indication of function during this time.  Instead the Track indicator indicates "F", for format, as a stock Rana does.

Like the serial I/O, the front panel display is software controlled on these drives. Normally there is a timer IRQ that swaps which digit is being displayed, but when certain functions are going (like actual disk I/O, serial I/O, etc) where timing is critical, the IRQ is disabled. During sequential I/O then, the display only toggles between sectors. This is why it flickers more at U/S than normal. As for formatting, I could try toggling between each track but I think that would look odd as well.

 

6 hours ago, Jeffrey Worley said:

The track led loses an entire seven-segment when the drive goes to sleep with the Atari computer OFF.   It comes back when you power the Atari.  This is kinda strange.  Again, no harm, as the computer is off and the drive therefore purposelessly on.  That said, it is a cosmetic glitch.  It is not always one or the other seven-segment module that is turned off, so sometimes the drive will display a 3 or a 9 during this time, but not 39, after a period of the Atari being off.  I haven't timed this but it is duplicable.  Just turn the Atari off and wait a while.  Next time you look at the Rana it will be displaying only half of the "39" information.

This is because the drive doesn't monitor the READY signal, so turning off the Atari makes the COMMAND line go low and the drive sits in a loop waiting for the command..

 

6 hours ago, Jeffrey Worley said:

Sometimes the Rana fails to finalize a formatting of a disk when coupled with an Indus GT doing a SCOPY from the Indus to the Rana.  I think there is a slight glitch somewhere, with switching the baudrates between the two or something.  I'm using SDX with and without the HSIO routines in the U1MB turned on for the Rana.  HSIO needs to be turned off, of course, for the Indus.  This is done on a drive for drive basis in the U1MB bios.  It took me awhile to notice this glitch.  Might not even be the Rana's fault, but I have not seen this with the USD 1050, Happy, or Speedy in concert with the Indus.  I will attempt to duplicate this glitch with them sometime this week.

I could do more troubleshooting with multiple drives in the chain..

 

[Jeffrey Worley]

36 minutes ago, toddtmw said:

So. I've decided to get @Dropcheck's burner when he gets more available. In the meantime, I assume that replacing the crystal without replacing the ROM is a bad idea?

 

Correct?

 

Thanks!

If you have roms but no burner, drop one in the mail and I will burn it for you and drop it back.  No charge, unless you want to send me another blank rom, which I will be happy to accept but which is not neccessary.  PM me for details.

 

Best,

 

Jeff

[Jeffrey Worley]

11 minutes ago, MrMartian said:

Well, like pretty much every other firmware I've seen, the density check is done while reading sector 1, and if there is an error then try after changing density.. That's why modern DOSes always read sector 1 before anything else. I'm guessing the 1050 US will do this on any sector, but then that would affect indicating bad sectors... A longer delay at least?

Like the serial I/O, the front panel display is software controlled on these drives. Normally there is a timer IRQ that swaps which digit is being displayed, but when certain functions are going (like actual disk I/O, serial I/O, etc) where timing is critical, the IRQ is disabled. During sequential I/O then, the display only toggles between sectors. This is why it flickers more at U/S than normal. As for formatting, I could try toggling between each track but I think that would look odd as well.

 

This is because the drive doesn't monitor the READY signal, so turning off the Atari makes the COMMAND line go low and the drive sits in a loop waiting for the command..

 

I could do more troubleshooting with multiple drives in the chain..

 

I haven't been able to come up with any hard beefs.  This is a rev A rom, after all, and it shouldn't work nearly this well.  I gotta hand it to you brother.

 

Yes.  I do think that it is best if the drive were to indicate what track it is formatting/verifying during format, even if it is flickery.  That would be in-character and would sure be nice information.  The drive is so quiet that I can't tell til it hits track zero if anything is going on.   Lol.  Klunk.

 

Jeff

[toddtmw]

9 minutes ago, Jeffrey Worley said:

If you have roms but no burner, drop one in the mail and I will burn it for you and drop it back.  No charge, unless you want to send me another blank rom, which I will be happy to accept but which is not neccessary.  PM me for details.

 

Best,

 

Jeff

Jeff,

 

That is really cool of you to offer and I do appreciate it. However, for me, actually doing the burning is half the fun.

 

I just ordered some NMC27C32Q-45 that have a 12.5 V programming voltage. I am hoping I will be able to use those. If not, I will wait until I can get Dropcheck's burner which does work with 21V chips.

 

Thanks again.

-Todd

[_The Doctor__]

yep, the only critical change needed would be a multiple drive (your observation with indus) finalizing format fix... otherwise the rest of it is cosmetic... the rpm bug might be fixable, but a specific RANA rpm tester that does a sector 1 read before the test is also an option.

The only way I think the sleep mode could be handled would be for the segment to show an S in both segments (that would look like a 5) and then it wouldn't matter which was off, s for sleep... or a weird approximated Z

[Jeffrey Worley]

2 minutes ago, toddtmw said:

Jeff,

 

That is really cool of you to offer and I do appreciate it. However, for me, actually doing the burning is half the fun.

 

I just ordered some NMC27C32Q-45 that have a 12.5 V programming voltage. I am hoping I will be able to use those. If not, I will wait until I can get Dropcheck's burner which does work with 21V chips.

 

Thanks again.

-Todd

I can totally dig that!

 

Best,

 

Jeff

[+Nezgar]

7 hours ago, Jeffrey Worley said:

Density smartness is ok.  One can't, for example, turn the drive on and RPM a disk right off, one has to do a directory or otherwise tag the disk for access before density smartness kicks in and THEN do your RPM or SCOPY or whatever else.  Better than most drives, actually. but not as good as a USD 1050, which is density-smarter by a smidge.  Apparently, the request for a read of a specific sector (via the RPM command) does not cause the rana to test density before trying to execute the sector read, but a Directory command does cause the Rana to go through that test beforehand.

1 hour ago, MrMartian said:

Well, like pretty much every other firmware I've seen, the density check is done while reading sector 1, and if there is an error then try after changing density.. That's why modern DOSes always read sector 1 before anything else. I'm guessing the 1050 US will do this on any sector, but then that would affect indicating bad sectors... A longer delay at least?

I think the 1050 US Doubler will do density detection on whatever sector happens to pass under the head on track 0 first as the drive latch is closed, not when the host actually requests a sector. I'm not sure if the rana has ability to detect latch open/closed? Normally, all 18 sectors on a double density disk are formatted as 256 bytes in MFM format, and the format of the whole disk is assumed from any sector on track 0. (128 bytes are just truncated by the drive OS from sectors 1-3 when sent to the Atari) Double Density disks formatted by the 1050 Duplicator upgrade diverges from this standard by physically formatting sectors 1-3 as MFM 128 bytes instead of 256, and 4-18 as 256 bytes. For example, this causes the 1050 US Doubler density detection to fail 3/18 (1/6) of the time by incorrectly detecting the disk as "Enhanced" density if it happens to see sectors 1, 2 or 3 first.

 

SCOPY is a little odd compared to other sector copiers, as it does not read/write sectors in sequential order with or without the ultraspeed /U switch, with a half-rotation offset for ultraspeed or 1 sector offset for standard speed to account for track step delay. I documented the sector orders SCOPY uses in this topic: https://atariage.com/forums/topic/289018-us-doubler-ultraspeed-fastest-sector-reading-order/

 

Briefly, SCOPY reads sector either 9 or 5 first for single density, 8 or 2 first in double density, and 15 or 5 first in enhanced density.

[Jeffrey Worley]

28 minutes ago, _The Doctor__ said:

yep, the only critical change needed would be a multiple drive (your observation with indus) finalizing format fix... otherwise the rest of it is cosmetic... the rpm bug might be fixable, but a specific RANA rpm tester that does a sector 1 read before the test is also an option.

The only way I think the sleep mode could be handled would be for the segment to show an S in both segments (that would look like a 5) and then it wouldn't matter which was off, s for sleep... or a weird approximated Z

Spartados' RPM works just fine once the drive knows what density it is in.  I would't waste time on it.

 

Best,

 

Jeff

[_The Doctor__]

You know how it is... it's going to pester us... it tests us...   it tasks us.....     Kaaaaaaaaaahhhhhnnnn!

 

 

Edited May 16, 2020 by _The Doctor__

[Jeffrey Worley]

1 minute ago, _The Doctor__ said:

You know how it is... it's going to pester us... it tests us...   it tasks us.....     Kaaaaaaaaaahhhhhnnnn!

ROFLMAO.  With my last breath, I spit at thee.  OMFG.  We are such GEEKS.

[BillC]

2 hours ago, toddtmw said:

I've decided to get @Dropcheck's burner when SHE gets more available.

 

[toddtmw]

10 minutes ago, BillC said:

 

Thanks. 

[MrMartian]

3 hours ago, Nezgar said:

I think the 1050 US Doubler will do density detection on whatever sector happens to pass under the head on track 0 first as the drive latch is closed, not when the host actually requests a sector. I'm not sure if the rana has ability to detect latch open/closed? Normally, all 18 sectors on a double density disk are formatted as 256 bytes in MFM format, and the format of the whole disk is assumed from any sector on track 0. (128 bytes are just truncated by the drive OS from sectors 1-3 when sent to the Atari) Double Density disks formatted by the 1050 Duplicator upgrade diverges from this standard by physically formatting sectors 1-3 as MFM 128 bytes instead of 256, and 4-18 as 256 bytes. For example, this causes the 1050 US Doubler density detection to fail 3/18 (1/6) of the time by incorrectly detecting the disk as "Enhanced" density if it happens to see sectors 1, 2 or 3 first.

Yes exactly, I do remember this. That's why it gets it right... And no, the Rana doesn't have any indication of disk present. I do something similar on my Trak rom, which still doesn't have a disk latch input but it does have the write protect input, so as long as the sensor still works I know if a disk has been changed.

 

Which is funny - since I had another quick look at the Rana to verify it didn't have a way to check WP status - I do see that it has SIO ready. And then I look at my code and see that it does check for it and bails. So now I don't know why the LEDs don't work when the system is off.. Hooray! An actual bug...

[+Nezgar]

15 minutes ago, MrMartian said:

Which is funny - since I had another quick look at the Rana to verify it didn't have a way to check WP status - I do see that it has SIO ready. And then I look at my code and see that it does check for it and bails. So now I don't know why the LEDs don't work when the system is off.. Hooray! An actual bug...

Are you saying the CPU in the Rana has no way of seeing the write-protect status? Which is normally a good disk-change detect compromise - I think that's how at least the earlier rev happy 810's did it, which requires some extra consideration for a write-protect override switch...

[Jeffrey Worley]

Does the Indus have some kind of a cache?  Maybe one sector?, my RPM tool shows 323, when I knew if I take it out of Config.sys (Indus.sys), I get 288 without Indus.sys or HSIO on, which is right).  With hsio I get the right number from the Rana, so there seems to be some kind of caching going on, buffering.  Oh, and check this out:

 

A drive programmed with Indus.sys can be crashed such that it has to be power-cycled to come back.  Try