• Please review our updated Terms and Rules here

CBM (PET) 2001-8-BS

It’s too late in the UK to think at the moment... I’ll have a look tomorrow.

I would perform a listing of the disk as the first thing rather than attempting to load anything... That’s the LOAD “$”,8 command followed by a LIST.

Dave
Thanks Dave, it is typical of me to fall into a small trap.

I noticed when I typed LOAD "*", 8 it loaded the file Aliens! fine, and it works ! This loads the first file.

The example given in the SD2PET user manual says LOAD "filename", 8 , but this does not work. It works though if the extension is added;

So if I type LOAD "Aliens!.prg", 8 it works just fine.

So maybe the instruction should have been LOAD "filename.ext",8 ?
 
the LOAD "$",8 should have loaded the directory of the drive as a psuedo basic program that the list command can display
the dos is in the disk drive and the commands from the PET are just sent over GPIB to it.

$ is interpreted as send directory wheras * is interpreted as send first program
 
its amazing what the PET can actually achieve.

:)

bIT Drunk.

Night out with the wibbly wobbly's.

Wonder if Daver2 remembers John WW :)
 
the LOAD "$",8 should have loaded the directory of the drive as a psuedo basic program that the list command can display
the dos is in the disk drive and the commands from the PET are just sent over GPIB to it.

$ is interpreted as send directory wheras * is interpreted as send first program
Thanks.

I listed the directory.
see attached.
Can you explain the first line that is highlighted. Is that where a Volume label would have showed up if I had put one on it (which I didn't) when I formatted the SD card ?
What do the numbers on that line mean ?
 

Attachments

  • sd.jpg
    sd.jpg
    134.4 KB · Views: 10
It is not a game - it is an engineering test program :)...

Yes, the inverse video is where the disk volume label would be.

The 32 is a numeric disk ID that can be added.

The 2A identifies the filesystem format/version.

The numbers at the beginning of each line indicates the block size of the associated file. A block being 256 bytes. Each sector on the disk is 256 bytes. However 1 block is not the same as 1 sector. Each sector contains a 2-byte “pointer” to the next block in the chain of blocks. Therefore each sector of 256 bytes contains 2 bytes for the “pointer” and 254 bytes for the data payload.

To be honest, I am surprised the “.PRG” is included in the filename. This may account for why your LOAD command didn’t work. The .PRG is usually missing from the filename itself, as this is redundant (due to the presence of the PRG filetype byte).

See (for example) https://www.vintagecomputer.net/browse_thread.cfm?id=209. “apl” is a program (prg) file, but it is not called “apl.prg”.

Dave
 
Last edited:
I guess it must just be the way those game (Engineering test files) files were saved on the website I got them from. I selected them for the test only because I recognized the .prg. Now I know about this it won't be a problem.

I've started on the Osborne/Donahue PET book, so that should help me.

I've moved to cleaning up the hardware, it is all in pretty good order. For the IC's in sockets I cleaned them and lubricated them with mx-3, mostly they were good though the occasional one had enough oxidation to possibly cause trouble. This computer has a paucity of sockets, compared to say the SOL-20, where the sockets can be very troublesome. All the sockets though are a good design where the claws grab the pins across the flat and all had good tension. The 4116 RAM IC sockets look like they were factory fitted, on the other hand, the 4116 RAM IC's are 1981 vintage, but every other IC on the board is 1979 vintage. The only non factory looking soldering is that two IC's on the board, of the 2114 variety UF7 & UF8, though one is an MCM21L14, were placed in sockets, and they had a blue dot sticker on the bottom surface by each socket, so maybe it was factory, but inspection shows they were once 20 pin sockets cut down to 18 pin.

On the bottom of the board it says Part No. 320350 Rev E. On the top it says Assy No. 320351.

All the electrolytic caps on the board test ok on the ESR meter so I'm leaving these alone. I have not got to the VDU yet.

Over the years, electrolytic caps have got a lot smaller. For example a modern 22,000uF 16 V cap is about half the size of the 1979 vintage 23,000uF 15V cap in the PET (that failed).

So I looked around to try to find a replacement cap that looks the part in the computer. ( I like the way vintage computers had gigantic caps in their power supplies) .To get a cap these days of the approx same physical size as a 1980 vintage part it is necessary to go up in voltage rating (which is ok). After some hunting I found the new manufactured cap (a Vishay part) at RS. So I'm going to fit this to my PET as the replacement. Not cheap, but you get what you pay for at least with a part like this. It is better to do this than buy a 1980's vintage part. This Vishay part is just a little shorter and same diameter as the original.
 

Attachments

  • PETCAP.jpg
    PETCAP.jpg
    149 KB · Views: 6
I made Dave R's Pettester Rom. What a great diagnostic tool to have.

(I put the ROM in place of UD8, that is correct right ?)

When the computer is powered it runs through the VDU test super quick about a second and a half, just enough to briefly see the screens. I assume it did that because all is ok, but I'm not sure. (is there a way to alter the .bin file to slow that down ?) After that it stops on the ROM/KBD test and does the countdown. The 16 bit checksums shows BASIC 2.

Then after the countdown it identified the 32k of memory, did the Memory test, and it passed, I let it run to 000005. So the 4116's are fine I would expect.

I tried it again, the VDU test is so brief that if the PET is switched on from cold, the VDU(CRT) doesn't have time to warm up to display it, so the testing appears to start with the ROM/KBD test and that cool countdown. But, once the VDU's CRT is warm, and the computer power cycled, it is easy to see the VDU test starts first, but is brief.
 
Last edited:
I cleaned up & lubricated the keyboard. I do this on all my vintage keyboards, the same for the SOL-20, just applying a very tiny amount of silicone lubricant to the the plastic sliding surfaces, not enough to spread anywhere else and it is non chemically reactive with the plastic. It makes the keys feel beautifully smooth to operate and avoids that sometimes dry sticking feeling.

Somebody in the past had drastically over tightened the keyboard mounting screws which mount it to the body of the PET. The keyboard mounts on fairly tall posts. Two of the screws had stripped threads. The rest were ok.

Looking at this I had a few thoughts. I have some metal screw inserts for plastic that take a 4-40 machine screw. But, to fit them I would have had to enlarge the holes to 3/16 removing material. I measured the depth of the hole, and luckily it was much longer than the original screws and about 3mm diameter. Rather than going for longer self threading screws, I decided to run a 6-32 UNC Roll Tap down the hole (this type of tap removes no material and makes a very nice 6-32 thread in plastic). So then I replaced those two screws with 6-32 x 5/8" long machine screws, solved the problem without removing any plastic material.
 
Nice work on the re-tapping. Never thought about roll taps (been too long since my apprenticeship basic training), but they should be perfect for vintage stuff.
 
Hugo,

Thank you for your kind words regarding my diagnostic tool and the associated documentation.

Yes, UD8 was the correct place to install it (it works after all). It was designed to replace the EDIT ROM. In some (most?) PETs, all of the ROMs are sometimes soldered in - with the exception of the EDIT ROM.

You asked a question a while ago about the 'names' of the ROMs. The Kernel ROM (UD9 at $Fxxx) contains the PETs 'Operating System'. This consists of the RESET, IRQ and NMI vectors, a couple of other 'unused' 6502 CPU vectors plus a load of code to deal with the IEEE488 bus, file handling, cassette load/save routines, clock handler and a load of other (smaller) utility tasks. The EDIT ROM (UD8 at $Exxx in the memory map) contains hardware initialisation (in particular the CRTC) and keyboard/screen handling. Basically, all of the stuff that is locale-specific. The other ROMs contain the BASIC interpreter. As all of the screen and keyboard handling is done within the EDIT ROM, this is the device that is usually socketed (to allow customisation based on the country the PET actually gets shipped to). As a result, this is why my diagnostics were written to execute at $Exxx to replace the EDIT ROM.

The only downside of this is that a small amount of code in the Kernel ROM has to work in order for the reset vector to enter the EDIT ROM. I believe this is a small trade-off. As you get the source code, you can assemble my diagnostics to run at $Fxxx to replace the Kernel ROM if you wish. Some have done this (for example, it is residing at $Fxxx in some of the ROM/RAM replacement boards).

I designed my diagnostics to be compatible with all (known) versions of PET BASIC. The only one that it will not work with (out of the box) is a 40 column CRTC machine. This requires a tweak to the code (included) to initialise the CRTC correctly.

I decided there wasn't much point in having a longer delay if the diagnostics decided the VDU and pages 0 and 1 of RAM were healthy. I don't think there was much benefit in it to be honest. Incidentally, you don't have to keep power cycling the PET to reset it. Fit a normally-open pushbutton across C68 (0.1uF) in the LM555 reset circuit and you can have a manual reset button located inside the case...

The 'countdown' test is the first major milestone - and I display all of the 256 characters on the screen at this point - so you can check if there are some visual issues (from the VIDEO RAM data latches onwards) to contend with.

There are a couple of known issues that I will probably address in Version 5:

1. Longer delay between tests (as you say). I have to hold everything in CPU registers at this stage - so it makes for some 'interesting' code at times...
2. My page 0 and 1 RAM test is a bit too simple, and some faults can slip through the net. This causes the MARCH-C memory tests to crash. I have a more thorough test to implement next. Again, I have to hold everything in CPU registers because I can't trust the RAM until I have finished this test...
3. Include a 'beep' somewhere - for PETs that have a sounder. This will also (partially) test the VIA.
4. Test the USER PIA PORT.
5. A screen set-up test card (cross-hatch).
6. Just been reminded that my ROMs don't test the interrupts out either.

I think that will fill up the 2K EPROM...

Dave
 
Last edited:
OK - I have started a Version 5...

Item 1 (a longer delay between passing tests) added. It is now 16 times longer. I had to use register 'A' as the additional loop counter, and then realised why I hadn't done this before - there is no "INC A" in a 6502. I had to clear the carry flag and add-with-carry #1 to A. That solved the problem...

Item 3 now done. I have added a chime after each iteration of the full DRAM memory test has completed. Of course, if your PET hasn't got a sounder, the electrons will just fall out onto the floor :)!

Item 6 (interrupts) is too much of a pain. Like the entry point into the EDIT ROM from the KERNAL ROM on a reset - the interrupt vector ends up at different locations depending upon the version of the Kernel ROM (1, 2/3 or 4). I designed my diagnostics to cope with the reset entry points - but the differing IRQ vectors are a pain to accommodate. I may have another look at this once I have included the majority of the V05 code to see what I can do. All I am going to do anyhow is to return from interrupt...

Dave
 
Last edited:
I have the code added for item 5 (VDU calibration screen) - I just have to work out the correct screen locations to store the '+' characters in. This will also be 40/80 column specific - so I may have to add a conditional assembly clause. This could also be useful for any CRTC initialisation code anyhow.

Ran into a small problem with stopping the memory test and invoking the VDU calibration screen. I thought all of the PET RUN/STOP keys were at the same row/column position. I tried this with a 4016 and an 8032 (in VICE) and this does not appear to be the case. May need to rethink this a bit...

Need to stop now and think about the 'better' page 0 and 1 memory test for a while BEFORE attempting to implement it :)...

Item 4 I meant the USER VIA port and the IEEE488 PIA port of course. I may do a 'simple' test of the data lines rather than an exhaustive test of every signal line. That will provide some degree of testing to give you a reasonable coverage. I also don't want people to have to start making up test (loopback) cables.

Dave
 
Item 3 now done. I have added a chime after each iteration of the full DRAM memory test has completed.
daver, your new items will be great. Regarding the chimes, please add one right off the bat to give a clue that your code was started in case a garbage screen or blanks ensue.
 
Dave,

The trouble is I have 'pinched' the code out of the BASIC 4 EDIT ROM. It uses a subroutine call/rts that uses the stack and (at this stage) I don't know whether the RAM even works! It could just go into the weeds...

I have to assume nothing at start-up...

I have decided to terminate the DRAM memory test now when any one (and only one) key is pressed on row '9'. I will document which keys will work for the various PETs and keyboards when I get around to the documentation - but you can also work it out from the previous 'countdown' test by poking each key on the keyboard in turn and noting down which one sets a bit in row [9] (the last value on the KBD line).

Is there a website that has the various PET keyboard matrix arrangements documented in an easy-to-undesrtand format I wonder?

Dave
 
Hi Dave,

Great work.

Good idea about adding a reset button !

You could maybe make two ROM .bin files with the 40 in the name for one, and the 80 in the name for the other, that way the owner could just cut the ROM that suited their PET, or maybe an instruction of what bytes to change in the .bin file to convert them. I liked the way you put your name in there. I did that once with my 2465b scope .bin files where some spare space was available and with the calibration date that created the data in the Scope's RAM after I calibrated it.

I was thinking that your program & ROM is so useful, I would store my ROM inside the PET, so it was there right away, if a fault developed and the PET needed a trip to the Doctor.

Can't wait to try the new one.

In the meantime I've discovered that the VDU in my PET is the early model which does not have a width or H linearity coil. It has a quirk that I'm working on. I will write up an article on restoring these VDU's to top order.
 
The trouble is I have 'pinched' the code out of the BASIC 4 EDIT ROM. It uses a subroutine call/rts that uses the stack and (at this stage) I don't know whether the RAM even works! It could just go into the weeds...

I have to assume nothing at start-up...
Oh, I see. OK, I'm glad you thought that through!
-dave_m
 
Hugo,

You shouldn’t need the wedge.

The only commands you should need are:

LOAD “$”,8
LIST

The above lists the disk catalogue.

LOAD “filename”,8
SAVE “filename”,8
VERIFY “filename”,8
Daver and Hugo,
No...
For the SD2PET, you want the wedge for easy access to the subdirectories and disk images!

The best thing about the SD2PET is its ability to use subdirectories.

With gigabits of storage, having only one directory on the PET will lead to endless frustration trying to find your files.

for example:
@CD:FOLDER - will change to the subdirectory named folder.
@CD:VISICALC.D64 - will mount your Visicalc diskette image to then allow load of VC programs and data files. All image types are supported.
@CD← - will unmount a disk image and/or go back to parent folder.

I think you can do all this without the Wedge, but you'd need a lot of OPEN and CLOSE commands and remember to use quotes, etc.

To create the subdirectories in the first place, simply use your PC with the SD chip inserted. I think generally one does not use the .prg extension with PET program files, but SD2PET can work either way. Some other PET disk emulators will not work with the .prg extension on the file.
-dave_m
 
Daver and Hugo,
No...
For the SD2PET, you want the wedge for easy access to the subdirectories and disk images!

The best thing about the SD2PET is its ability to use subdirectories.

With gigabits of storage, having only one directory on the PET will lead to endless frustration trying to find your files.

for example:
@CD:FOLDER - will change to the subdirectory named folder.
@CD:VISICALC.D64 - will mount your Visicalc diskette image to then allow load of VC programs and data files. All image types are supported.
@CD← - will unmount a disk image and/or go back to parent folder.

I think you can do all this without the Wedge, but you'd need a lot of OPEN and CLOSE commands and remember to use quotes, etc.

To create the subdirectories in the first place, simply use your PC with the SD chip inserted. I think generally one does not use the .prg extension with PET program files, but SD2PET can work either way. Some other PET disk emulators will not work with the .prg extension on the file.
-dave_m

Interesting, thanks.

Is the software for the DOS wedge a file that just gets loaded randomly on the SD card as an isolated file, or does it have to be in some sort of folder or directory to work ?
 
Sorry Dave. What I meant was Hugo didn’t need the wedge to start with to get the SD2PET working.

Thanks for the clarification though, I forgot about the sub-directories etc.

We had endless fun and games writing the correct wedge for his AIM-65 that I just shudder when the word “wedge” is mentioned! Still, we got it to work in the end!

Dave
 
Back
Top