• Please review our updated Terms and Rules here

How do I format a floppy in Basic 2.0?

That is correct...

Code: 
C  = 127 = 0111 1111
C1 = 255 = 1111 1111

It is bit 7 that is changing state.

Have you entered the program correctly?

Dave
 
Do you have any other way to load programs on this pet 3032? c2n cassette? Without that you have to retype everything every session, which is hopeless for the more complex diagnostic programs.

The "sd to c2n" type adapters are useful for pet owners, put the test progs on the sd card. They are compatible across all the 8 bit commodores.

Or at a pinch, if i remember correctly, isnt there is a simple circuit with an npn transistor (or something like a 7404 inverter) and a few resistors to connect the headphone out from a laptop/pc to the c2n connector? Then just run an emulator on the pc, load/save diagnostic prog to wave file and play that to pet..

Even with a working 3040, you would need some gizmo like that anyway..
 
Last edited:
The IEEE488 test program in the book is fairly well modularised - so (even if you have to type it in by hand and can't SAVE/LOAD it) you can type it in section by section and test out each control/status line or the data bus with a few lines of code each.

Dave
 
Today I have learnt that it's so easy to miss the obvious!
The cassette is working so I have been saving and loading ok but I was so convinced by the program reporting the DAV was bad that I only looked at that area!
I have been wasting my time testing the board and going round in circles and now I feel so stupid :cry:
On line 755 it should be goto 800
But I had typed goto 500 !!!!!!!!!! :mad:
So line 500 is print"DAV IS BAD"
Thats been fooling me.............................

Ok so the good news is that now I have corrected this typo it passes the test.
Bad news is I still need to find the real fault :(
 
If you don't make an error now or then it just means you are doing nothing!

OK, so you have a working PET.

The next thing is to connect the PET to the disk drive and manually 'drive' the IEEE488 control signals from the PET to the drive (using the test program POKE commands in direct BASIC mode) and observe the results at the "far side" of the IEEE488 buffers in the disk drive.

Incidentally, what are the three (3) LEDs doing on the front of the disk drive unit when you power it up when it is not connected to anything? You may have mentioned this somewhere in the thread?

Dave
 
Thanks Dave,

Re the disk drive
With nothing connected, data cable removed from the PET
On power up I get
All 3 leds on for about 2 seconds then all go out
About 1 second later I here the drives running for 2-3 seconds
Then nothing.

I better leave it now until tomorrow.
There are other things I should be doing right now....

Dave
 
>>> I better leave it now until tomorrow.
>>> There are other things I should be doing right now....

I have the same problem...

Dave
 
have you tried sending an initialisation command?

OPEN 1,8,15, "I0":CLOSE 1
(thats letter i number 0)

the drive should rattle, then the error led should flash.
There are test programs that use the "user" command ("U0:...") to upload and execute test code to the drive to test ROM/ RAM etc. But they can be big, again a pc to pet transfer device would help.The tapuino is about £20.
 
Ok thanks for the info, I will give it a try in the next few days but I have other things I mus do first :mad:

I will report back soon....

Btw should the floppy drive power led stay on?

Dave
 
I had some trouble formatting a disk in my PET with the SFD1001 drive and BASIC 2. As far as I am aware it acts similarly to the older drives.

Any tiny defect in the syntax seems to foul it up and examples in the books are often for other, perhaps more forgiving versions of BASIC.

Initially I typed OPEN 1,8,15 to establish the link with the drive (and the drive was specified in hardware as number 8)

then:

PRINT#1,"N0: NAME,xx;"

Where xx was two characters. Then I found the semi-colon after the xx was not needed, despite in being there in book examples.

Then I set about trying to figure out how to scratch a file.

One problem is that some of the examples given only work if the DOS WEDGE has been loaded. (This was unknown to me initially, until I fund out it is a form of DOS support and allows extra commands).

For example the command @S:filename to scratch a disk file, doesn't work, unless the DOS wedge has been loaded first.

So to scratch a disk file with out that:

PRINT#1,"S:filename" works.


Other things:

To mount a disk image, for example ;

OPEN 1,8,15,"CD: programname": CLOSE 1
Then to look at it:

LOAD"$",8
LIST

To un-mount a disk image is @CD With the horizontal arrow symbol (i cannot type here) immediately after that pointing to the left, but again that command only works if the DOS wedge has been run first. I hadn't yet figured out how to un-mount a disk image without the DOS wedge. So I simply reset the computer.
 
Ok I have Progressed a little further but still not there.

When I power up the disk drive all 3 leds come on for about 2 seconds then go out then the drive motors reset the drive.

I can now run the IEEE 488 test program (loading from cassette) without the disk drive connected and it passes the test.
If I connect the disk drive I get>>

DAV IS BAD With C=31 and C1=31
NRFD IS BAD With c=63 and C1=61
All 3 leds are flashing
The disk drive resets when I break (run stop) the program.
I don't know if this is correct with the drive connected.

If I enter >>

OPEN 15,8,15
PRINT#15,"N0:TESTDISK,88"

Without the disk drive connected I get "DEVICE NOT PRESENT". This seems correct to me.

But if I connect the drive the PET just locks up and all I can do is power off then on to get it working.
This happens with or without power to the disk drive.

Its not the IEEE cable as it's ok with only the cable connected without the drive and I have tested the cable for continuity

I have tested the mc3446 bus transceivers in both the PET and the disk drive and all are good!
I also swapped the 6502 and the 6522 in the drive with the ones in the PET and swapped round the 6532's in the drive but its still the same.

Dave.
 
Looks like you forgot a comma:
OPEN 1,8,15,"N0:NAME,ID";CLOSE1
Click to expand...

Thanks but I have got past this, its the locking up problem when talking to the drive I can't get past now

Also I tested the mc3446 bus transceivers by removing them and using a tester : link >>

github.com

GitHub - MyRetroStore/MC3446-Tester: Arduino based tester to check MC3446 chips

Arduino based tester to check MC3446 chips. Contribute to MyRetroStore/MC3446-Tester development by creating an account on GitHub.
github.com github.com

They are now on sockets.
 
It sounds to me as though the GPIB bus is being corrupted by the presence of the drive being connected to it.

The GPIB bus was designed so that multiple peripheral devices could share it, so the bus's data and control lines are effectively each pulled high by a resistor and each device that connects to a line, is by an open collector output, so that each peripheral device "ORs" itself onto the bus for all signals and data, and all signals are active low.

This means that a hardware fault in a device on the bus, can pull one or more of the lines low, hold it there and corrupt the function of the bus.

Probably from the result of your test, DAV and NRFD lines are being held down by a fault in your drive unit.

The hardware fault could be anything affecting those lines, pulling them down.

To confirm this is correct, try disconnecting just one line at a time (if you can access the pins in the connector) with the drive connected, try the DAV and NRFD and both together and run the bus diagnostic until the errors vanish. Then after the defective control and or data lines are identified the fault in the drive can be traced down. If many lines are involved, it could be that the IC's interfacing with the the bus in the drive have a power supply issue.(or perhaps simply use a logic probe or scope to find the offending lines)

In the case of the NRFD line, it is an output asserted by the peripheral device, in some cases there may be a ground tie resistor too as well as the pullup. In the case of the DAV line it is an input at the peripheral device.
In both cases if the power supply to the chip/s connected to the lines (in this case in your disk drive) lines fall to zero and then those chip pins could sink enough current to pull those lines low.Check that the iC's interfacing with the bus in the disk drive are properly powered. If they lost power, it could likely cause more than one line to be pulled low and your diagnostic test suggested two defects.

In another computer I once had a similar fault, but in this instance the bus worked fine with either drive connected to it, but not both. It turned out one drive was corrupting a line preventing the other from working at the same time. Hardware that shares data & control lines can play up like this in peculiar ways when a device interacts with a line when it should not be.

Can you post the schematic of your drive where it interfaces with the bus to show the arrangement ?
 
Last edited:
You can't use the PET IEEE488 test program with anything connected to the IEEE488 bus.

However, the 'fault' does indicate that the disk drive is driving the two signals DAV and NRFD.

This may be intentional, it may not be.

Did you remove the disk drive buffers to test them or did you test them in-situ as I recommended?

If you check the signals on the disk drive buffers that are driving these two signals, what do you observe?

Dave
 
Thanks Hugo and Dave for the continued help with this.

As I now have the line buffers on sockets I tried the test program with all 3 removed (the ones in the drive)
The test program passed ok.
I then tried with one buffer and found it failed, It's the same with any one of the three buffers (only one at a time)
Its the same DAV and NRFD error each time.
This is both with and without power to the drives

I did check the power to the buffers and I get 4.99 volts on all chips

I then pulled all the IC's that are in sockets and tried again (just to see if it would clear the fault but it did not!)
Looking at the schematic for the board I 7414 inverter may be the problem but with this removed there is no change.
Both these tried without power to the drive.

Testing the resistance readings to ground of the 12 lines with the buffers installed all lines are between 1.6k and 1.7K.

As the buffers tested out ok with the inverter and both 6532's removed I decided to remove the 3 logic chips (ul2,uj2 and um2) just to rule them out!

I checked the board for shorts (again)!

After all this still no change....

I am now at a loss as to where to go from here as unless I an missing something with all these chips removed everything is isolated after the buffers.


I am using the schematics I found here>>>


Dave
 
Last edited:
You must log in or register to reply here.
Back
Top