Try it... :evilgrin5:
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
8250 faulty drive
- Thread starter giobbi
- Start date
MikeS
Veteran Member
I will, but are there actually any M/L programs at this time that calculate ROM checksums?This will be extra useful when the petester diagnostic EPROM performs check sums as well as RAM checks in assembly language. Now you have to add these PET Drive ROMs to your table. So you recalculate those numbers!
I'll see if I can talk Mike N. into putting it on 6502.org somewhere.
dave_m
Veteran Member
Mike,
A special restriction for our M/L version will be that the code should not rely on RAM as we will not know how reliable the RAM is in the PET so no subroutines using the stack either.
I suppose we can wait to run the ROM tests only after we pass the RAM tests??
dave_m
Veteran Member
Code:
[COLOR=#333333]40 print " Sumcheck = " s and 255
[/COLOR]The problem with at least PET BASIC is that before it can perform the LOGICAL AND with 255, BASIC will need to convert the floating point variable "s" into an integer number. That step will fail if the number of the checksum is over 32767. I tried it.
giobbi
Veteran Member
Mike, Dave, I had no time yet to do all of the tests you suggested me, but I got a strange result from the only one I did:
- Instead of 477492, I got 485835 ("normal" adapter, all pins connected).
- Instead of 485835, I got 474766 (eprom pin 23 to ground only -not connected to pcb pin 21).
Since I have another identical board, I tried to swap all the main ICs, but I'm still getting the same error code: it's blinking twice, with both eprom+inverter and original rom.
Next step I will check the original rom. But have you any idea about what's going on with the eprom adapter... why those strange results? I checked twice my adapter, but maybe there's a mistake somewhere I didn't discover yet?
I have two 2316 rom, so probably one of them is working, but I will also check them to be sure.
--Giovi
billdeg
Technician
Catching up with this thread. I have a few diagnostics program that can help. Load a program using an 8050 or some working drive first, and then swap in the 8250 after you load the program. You might be able to get a feel for the status of your drive's remaining issues. Note: Any test programs for an sfd-1001 would test drive 0 of the 8250.
http://vintagecomputer.net/commodore/D80_BSeries/TECHDISK.D80
http://vintagecomputer.net/commodore/IEEE_drives/
Bill
http://vintagecomputer.net/commodore/D80_BSeries/TECHDISK.D80
http://vintagecomputer.net/commodore/IEEE_drives/
Bill
giobbi
Veteran Member
Bill, thank you for that! I still need to check it (I still need to check a lot of thing suggested in this thread, but I'm running out of time these last days), but however: do you think think it will help even if the drive is failing its diagnostic initial test?
----
Mike, reading your comment on cbm-hackers ("Reverse engineering printer sharing device") gave me an idea; the RAM/ROM adapter from Nicolas Welte can also replace RAM/ROM in 1541 devices. Do you think it could be possible to use it for 8050/8250 drives too? And how? I have the personality chip for pet, vic and 1541 and my adapter has a jumper that allows to use it in these three devices. But I'm not sure if the ieee drives require a proper personality chip and in any case if the adapter can replace the ram or, at least, the rom.
--Giovi
MikeS
Veteran Member
No, I just swapped the high and the low checksums to see if you were paying attention ;-) (and I've erased the evidence); I'm not used to people actually following my suggestions, so my mistakes rarely get caught except by Dave...
But that 474766 should really be 477492. Try it again in case you made a typo or had a bad connection; if it's still wrong, can you go back and compare it to the image with your programmer?
Failing that, you could compare it to the original ROM if you put one into the $9000 socket (with CS inverted of course).
Yeah, I haven't heard of those failing, but why not check anyway...
MikeS
Veteran Member
I suppose it could, but it doesn't really seem worth the trouble; if the 6530 is bad it's a different ballgame anyway and replacing the three ROMs would be pretty straightforward. Maybe if the RAM is bad, but I'm sure there are easier ways, and the fact that there are two CPUs in there may rule it out anyway.
giobbi
Veteran Member
Mike,
I don't understand why the 2764 adapter returns a wrong value (please see my previous post). However, one step at time, I'm going to perform all the checks you required.
Actually: I did a little adapter for 24 pin socket, inverting pin 20 only:
ROM pin 20 to 7404 pin 6
pcb pin 20 to 7404 pin 5
Vcc from pcb pin 24 to 7404 pin 14
Gnd from pcb pin 12 to 7404 pin 7
I tried the 901887-01 ROM: it returns 485835 and 477492 with the rom pin 21 to Gnd. I think it should be ok, isn't it? The UL1 rom should be ok.
I tried the 901888-01 ROM: it returns 514630 and 465382 with the rom pin 21 to Gnd. maybe that's the problem?
Out of curiosity, I was trying to erase an program the 2764 as 901888-01, but it's giving me a writing error: I think the only 2764 I had gave up and died on the battle field... so I have to wait for the lot of ten I bought some days ago... :-/ ppppffffff......
:wallbang:
However I will do another erasing cycle and will see....
I discovered maybe I could have a possible way to fix it even in case of a broken 6530. I could swap in this config:
UL1 901482-07 2364 ROM DOS 2.7 C000-DFFF (need a 2764 + adapter)
UH1 901482-06 2364 ROM DOS 2.7 E000-FFFF (I have one, status unknown)
UK3 901483-03 6530-47 RIOT DOS 2.7 Micropolis (I have one, probably working)
I need to check if I have two micropolis 8050 drives (8050031-01). Of course, this way it will be an 8050 inside the case of a 8250.
QUESTION: how I can detect the rev. of the analog board? This case requires an analog board 805006 rev 01 but there's no rev. marked on the pcb...
-----edit: It took a while to write this post, I was testing and writing, so I've seen your answers only later, when it was already posted on the forum.
Last edited:
giobbi
Veteran Member
AH AH AH AH ok so it seems the UL1 ROM is ok.
Maybe it was due to a faulty eprom. I'm trying to see if it's still writable or not, but it's probably deceased...
Ok for the RAM/ROM adapter, it was just a thought, anyway...
------------UPDATE - EPROM status: deceased. I need to wait for the ones I ordered a couple of weeks ago, with a little luck they will be here before Xmas... :-/
Mike, Dave, I will keep you informed as soon as they arrive. ...unless you have any idea about how to do the trick with a flashrom ATMEL AT29010C + the Welte's adapter...
Last edited:
I see. I don't have any experience with PET BASIC, only QBASIC/QuickBASIC. I take it there is no equivalent to the LONG INTEGER variable type in PET BASIC? I also noted that the FOR statement is incompatible with QB ("FOR higher TO lower" doesn't work without STEP -1).
Would something like this work? (I guess not)
Code:
40 print " Sumcheck = " s and 255!MikeS
Veteran Member
No.I see. I don't have any experience with PET BASIC, only QBASIC/QuickBASIC. I take it there is no equivalent to the LONG INTEGER variable type in PET BASIC? I also noted that the FOR statement is incompatible with QB ("FOR higher TO lower" doesn't work without STEP -1).
Would something like this work? (I guess not)
Code:40 print " Sumcheck = " s and 255!
QB is incompatible with most BASICs of the day; why don't you "try it!" ;-)
Several good PET emulators out there (e.g. Vice) and GWBASIC is pretty representative of the various MS BASICs of that era.
Last edited:
MikeS
Veteran Member
I'm really getting confused now; aren't those ROMs & 6530 DOS 2.5?
I'm not certain, but I don't think it matters whether you use SS or DS drives as long as the analog board matches (except for the MPI board which does both) and the two jumpers are set appropriately. My 8050006 analog board doesn't show a revision either; I wouldn't worry about it at this point
I'm off to a TPUG meeting, but I'll try to make sense of it later; I've got an 8050 myself that needs investigation.
giobbi
Veteran Member
Mike,
I attach here the page of the service manual:
Looking at the ROM section, my config should be the one explained in the 4th line, at least basing on ROM and 6530 PIA codes. If I'm right. it should be DOS 2.7
BTW I later found this table: http://www.commodore.ca/manuals/commodore_1541_4040_8050_8250_comparison.htm telling 8050 uses DOS 2.5 while 8250 uses DOS 2.7
About the drive, I read the first section and I assumed the "drive#" means the drive unit and in the drive section of the manual it's referring to 8050 drive (8050031-01) and 8250 drive (8250016-01). So, if I'm right, analog and digital boards with its own ROMs are strictly related with its drive. If I'm right....
I found a 2764 in another board, I'm going to check if the problem was related with UH1, I will post the result soon, as EDIT of this post.
---- EDIT --- NEW H1 EPROM --- THINGS ARE GETTING BETTER
Ok, I swapped the 901888-01 rom with a 2764 eprom, and this way I moved the problem in another place....
The two-flashes error code went away. I also tried to remove the 6530 and I got 5 flashes, put it back again and it this error code disappeared, so I'm hoping it is ok.
I only get a single red blink at disk boot (and, later during the 8032 boot), when the disks stop to spin. It seems an error code (1 flash) but it isn't repeated. Just once. I tried to swap both 6532 without luck.
I'm believing the error code table isn't 100% accurate and reliable. Two flashes should mean error in UL1, while I got a problem with UH1 (or, at least, is what it seems to be).
So I decided to ignore the red led and to do a little check, and I connected the drive to my 8032. I haven't any 8250 formatted disks, so I put a DD floppy into the unit 0 and I run the command:
HEADER "Giovi", d0 onu8, i01 - and, later, HEADER "Giovi", d1 onu8, i01. They seems to have an identical behavior, but since drive 1 is more visible because it isn't covered by the analog PCB, I'm referring to d1 behavior.
I'm describing everything, since that's the first dual disk I see during operations and I don't know what to expect.
The green leds (drive and main) are on, no flashes, The disk spins, the header moves back until to reach the external tracks of the disk and then it seems to fall into an endless state. I left it there for few minutes. I suppose the header should move across the disk, but I don't know for sure. Does it delete only the FAT (admitting there's a FAT there) or does it delete the whole surface of the disk?
I haven't another floppy disk here at moment, tomorrow I will take some more to check, in case the problem is the floppy (but in this case should have a time-out, I believe...)
Last edited:
giobbi
Veteran Member
GIANT LEAPS HERE! :D
Finally I had some luck here...
I downloaded the PRG from the /IEEE_drives/ folder as suggested by Bill, but they doesn't work with PETdisk + 8032: the computer stuck on "loading" sentence. I can only load'n'run the "screen 80" program, just as proof the petdisk is still working. Maybe those PRGs were made for PET series (not CRTC models)....?
Instead, one of the programs contained in the .D80 image saved my day. I run the micadj4_1 dr1.PRG (I started from disk 1 because of its easier access -d0 is under the analog pcb- and that was really good because if I started from d0 maybe I would give up without to test d1 too).
This alignment & diagnostic program drives you through some steps. Unfortunately I can't do some of them because of lack of "AC" disk (as named by the program). I suppose it was an alignment tool disk they shipped with the software (i.e. I tried the one with the scope, but I couldn't get the same wave form described, so I suppose the disk is needed at that point).
However, at certain point the program tells you to loosen the collar on the stepper motor, then it drives the head to the right track and you need to put the collar back in place. Probably this was the magic that solved the d1 problem: actually d1 is able to format, save and load programs.
The d0 disk still has some problem, probably related with the electronic rather than mechanic/alignment. The micadj4_1 dr0.PRG quits at the first step with a "device not present" error. And, of course, I can't read the disk written by d1. As blind shot, I tried to change the two 6532, but it didn't solved.
Have you any idea or any suggestion about how to fix the d0 problem?
---EDIT
today, without any apparent reason, things changed a little bit. Now the micadj4_1 dr0 doesn't quit immediately; it performs a couple of tests, but it hangs at the 3rd test, the speed adjustment. It requires the AC disk, but testing the drive 1, I simply skipped the test. Here the program hangs and if I try to skip the test modifying the basic program, at certain point it goes into ML monitor mode. I suppose it's am hardware problem, but of course I'm not sure.
Finally I had some luck here...
I downloaded the PRG from the /IEEE_drives/ folder as suggested by Bill, but they doesn't work with PETdisk + 8032: the computer stuck on "loading" sentence. I can only load'n'run the "screen 80" program, just as proof the petdisk is still working. Maybe those PRGs were made for PET series (not CRTC models)....?
Instead, one of the programs contained in the .D80 image saved my day. I run the micadj4_1 dr1.PRG (I started from disk 1 because of its easier access -d0 is under the analog pcb- and that was really good because if I started from d0 maybe I would give up without to test d1 too).
This alignment & diagnostic program drives you through some steps. Unfortunately I can't do some of them because of lack of "AC" disk (as named by the program). I suppose it was an alignment tool disk they shipped with the software (i.e. I tried the one with the scope, but I couldn't get the same wave form described, so I suppose the disk is needed at that point).
However, at certain point the program tells you to loosen the collar on the stepper motor, then it drives the head to the right track and you need to put the collar back in place. Probably this was the magic that solved the d1 problem: actually d1 is able to format, save and load programs.
The d0 disk still has some problem, probably related with the electronic rather than mechanic/alignment. The micadj4_1 dr0.PRG quits at the first step with a "device not present" error. And, of course, I can't read the disk written by d1. As blind shot, I tried to change the two 6532, but it didn't solved.
Have you any idea or any suggestion about how to fix the d0 problem?
---EDIT
today, without any apparent reason, things changed a little bit. Now the micadj4_1 dr0 doesn't quit immediately; it performs a couple of tests, but it hangs at the 3rd test, the speed adjustment. It requires the AC disk, but testing the drive 1, I simply skipped the test. Here the program hangs and if I try to skip the test modifying the basic program, at certain point it goes into ML monitor mode. I suppose it's am hardware problem, but of course I'm not sure.
Last edited:
giobbi
Veteran Member
Mike, out of curiosity: is there any way to do that in Vice? I mean a simple way to tell Vice you're attaching an eprom with some modified pins? I tried to attach the 901887-01.bin image in the "A" slot, and if I run the above program, it returns 477492. Shouldn't be the 8250 rom incompatible with 8032 slots? I don't understand how can I get that value...
MikeS
Veteran Member
I'm not familiar enough with Vice to say for sure but I assume it just attaches an image logically, i.e. without caring about the polarity of the ROM/EPROM pins or which pins are connected where.
Why? Are you not getting the correct checksums? It sounds like the digital part might be OK and you're just dealing with analog drive/diskette issues.
giobbi
Veteran Member
Yes I think too the problem is analog/mechanical (althout I don't know what to do yet); but since I also have an 8050 to fix, I was trying to find a way to check the ROMs without to bother you, Dave and the forum with questions similar to the ones I posted in this thread. For that reason, I tried to understand if Vice can be a good help at least to identify the checksum of every ROM.
How do you calculate the ROM checksums?
dave_m
Veteran Member
Giovi,
Vice being a software simulator only cares about binary files not physical devices. Vice expects a 4K binary in the A000 socket so it apparently only uses the lower half of the binary file. That is the half equivalent with with pin 21 grounded (A12) of the 2364 ROM.