• Please review our updated Terms and Rules here

Pet Assembler ROM file for 32k Dynamic PET

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,730
Location
UK - Worcester
Correct.

When you cold start the PET, the firmware uses a value of $AA to test memory out (and find the top of memory). This is fortunate, as $AA is a valid, single-byte instruction that doesn't do any 'damage'.

If you had loaded a BASIC program (playing invaders for example) before going back to your assembler code - entering SYS 4096 would have invariably crashed the machine - as the area of memory concerned would have invariably been overwritten...

SYS n just causes the 6502 CPU to start executing instructions at the address specified by 'n'. If this is a valid program, all well and good. If this is data - or 'random' stuff - bye bye CPU!

This is also why it is very important to SAVE your work BEFORE testing it! Been there, done that, got the tee shirt (when I was young)! Never done it again!

Dave
 

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
8,730
Location
UK - Worcester
Your issue with deleting files.

Are you using the wedge?

This (should) simplify the whole process of using the SD2PET.

Dave

1655368089715.png
 

AndyG

Experienced Member
Joined
Oct 11, 2016
Messages
340
Location
UK
I’ll take a look into my archives also to see if have a rom Version. I tend to use the ACME compiler for convenience on the laptop but yes it is not an authentic experience😀
 

dave_m

Veteran Member
Joined
Feb 2, 2009
Messages
3,581
Location
Southern California, USA
I wonder if you could help with a BASIC syntax question regarding deleting files inside directories on the SD2PET:

Using S for file scratch

OPEN 1,8,15 : PRINT#1, "S1:filename.ext" : CLOSE 1

But, I have not figured out yet how to delete the files I have been saving which live in (and are now crowding out) the C=Development.d64 program directory, somehow the scratch cannot find them. I have tried opening the directory and doing it but no luck yet.
I use the BASIC 4 'Scratch' command and that works, but with BASIC 2, perhaps try without the drive number on the mounted disk image:
Open 1,8,15 : PRINT#1, "S filename" : CLOSE1
 

dave_m

Veteran Member
Joined
Feb 2, 2009
Messages
3,581
Location
Southern California, USA
I tend to use the ACME compiler for convenience on the laptop but yes it is not an authentic experience😀
Andy,
Yes, I really like the idea of assembling on the target PET, but I don't remember the process being so touchy. Every other time it seems to go wrong. I think I will forget about VICE and using a mounted image, and try the real floppy and a 4040 drive and see if it seems to work more reliably. I wonder if the Zimmer archived disk image is an old buggy version?

Does the ACME compiler output a .prg file or how do you get the executable to run on the PET?
 

AndyG

Experienced Member
Joined
Oct 11, 2016
Messages
340
Location
UK
“Does the ACME compiler output a .prg file or how do you get the executable to run on the PET?”

Dave, yes the compiler produces a .prg file that runs directly on PET…. I found it very easy to use. You have to setup the compiler to output for a PET. I have sample code I can send as an example if you want to review it. Steve G introduced me to it when I was creating the high res graphic routines.
 

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
3,046
Location
Australia
Your issue with deleting files.

Are you using the wedge?

This (should) simplify the whole process of using the SD2PET.

Dave

View attachment 1242523
I loaded the universal dos wedge that came with the C=development.d64 package (I guess it is the original vintage version of this wedge). It works and I can scratch the files with the simplified commands there. This "wedge" seems quite handy and simplifies the opening and closing of files.
 

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
3,046
Location
Australia
Now I have some 6502 assembly language questions.

Most of the example routines I have in my books, when it comes to taking a keyboard input or writing out to the screen, use a subroutine that is already in the host computer, by jumping to an address, which does the job.

In the PET, is there an address in the BASIC 2 system with a routine that will print out the character (stored in the accumulator) to the screen, then on doing that again will print the next character to the right of the first one and so on, and would, if still going, simply fill the screen and keep scrolling ?

Also for the PET, with an assembly language routine, what is the better method to clear the screen initially ?

For a keyboard input, say to detect one key and return to BASIC so as to abort a program, what would be a sensible routine ?
 

dave_m

Veteran Member
Joined
Feb 2, 2009
Messages
3,581
Location
Southern California, USA
Hugo,
Somewhere there is a list of key PET subroutines that do all these things for BASIC 2 and BASIC 4. Someone here will know where. The Bombjack site contained a lot of old PET books on assembly language with all this information. I'm not sure that zimmer has a good commented disassembly on BASIC 2 as it has for BASIC 4. Look here to start: http://www.zimmers.net/anonftp/pub/cbm/src/pet/index.html
 

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
3,046
Location
Australia
Look at the book "Compute's First Book of PET/CBM" here: https://commodore.bombjack.org/kim-pet/books-kim-pet.htm
Thanks.

There is an interesting RAM test program in that book, that is a cocktail of BASIC & Machine language. I will be trying that out for sure. It also can test the screen RAM. It is a shame that did not include the source file would have been interesting. I'll look it up in the first book of KIM.
 

Attachments

  • RAM3.jpg
    RAM3.jpg
    184.4 KB · Views: 8
Last edited:

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
3,046
Location
Australia
Possibly the last three bytes of that program above, might answer one of the questions about how to return to BASIC once the assembly language routine is done.

One interesting thing about the KIM-1 RAM test, it was adapted from an Algorithm published by Knaizuk & Hartmann in 1977. It puts an FF into every location under test and then an 00 in every third location and then checks to see if all are correct, then it switches the positions of FF and 00 twice more with the locations shifted. And finally it does it again with the initial positions of FF and 00 interchanged.

The idea is that it is trying to detect for interference. For example if a byte is written somewhere, with a memory malfunction it could alter a value elsewhere. So it is not good enough to check each memory cell, that it will return the correct value written to it, all the other cells have to be checked for interference when any byte is changed elsewhere.
 

MikeS

Veteran Member
Joined
Dec 23, 2005
Messages
7,506
Location
Toronto ON Canada
I finally scanned the "Commodore Assembler Development Package Users's Manual". It is a 12 MB pdf file.

It can be found here:

https://generalthomas.com/wp-content/uploads/2022/07/commodore-assembler-users-manual.pdf
Oops...

Sorry, Dave, I was a little confused and didn't realize this was the version you were going to scan.

FWIW, Steve scanned some of my Commodore documentation and files almost ten years ago but we apparently never realized that there was no public link to them (or that perhaps it got lost in the meantime) ;-(


Maybe there's something else of interest there? The ROMs should also be around somewhere ;-)
<EDIT> Yeah, looks like the PAL and POWER ROMs are on Zimmer's site.
PAL might be worth Hugo's while to investigate.

Meanwhile, good to have an alternate source ;-)

m
 
Last edited:

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
3,046
Location
Australia
Oops...

Sorry, Dave, I was a little confused and didn't realize this was the version you were going to scan.

FWIW, Steve scanned some of my Commodore documentation and files almost ten years ago but we apparently never realized that there was no public link to them (or that perhaps it got lost in the meantime) ;-(


Maybe there's something else of interest there? The ROMs should also be around somewhere ;-)
<EDIT> Yeah, looks like the PAL and POWER ROMs are on Zimmer's site.
PAL might be worth Hugo's while to investigate.

Meanwhile, good to have an alternate source ;-)

m
I have looked at the ASM DEV PAK.d864 and compared that to the Zimmers software package , see attached images. The one I have been using from Zimmers, I think is a "doctored version" of the original disk . The reason is that when the Editor, Loader and Assembler programs are run, the Commodore copyright text and program version does not come up and also the names of these programs have been altered with dots, instead of dashes, that match the manual file naming.

Also I couldn't make the high loaders work on the Zimmer version at all, so there might be errors in it. Somehow, when company programs get tampered with, no matter with good intentions, there always seems to be a quirk added.

In addition, the Zimmers disk has a "Universal Wedge " on it (it works) but the original disk/s has two Fast Wedge programs, 4.1 and 4.2.........I wonder if that was intended for BASIC 4, or it is just a program name? I ran this DOS wedge on my PET it appeared to work.

Also on MikeS's disk, there is an interesting copy disk 2.0 program that appears to be set up to copy between two different disk drives (I'm sure I read something recently that this was difficult with the PET, maybe this program solves that ? )
 

Attachments

  • Assemblerdisks.jpg
    Assemblerdisks.jpg
    107.9 KB · Views: 5

dave_m

Veteran Member
Joined
Feb 2, 2009
Messages
3,581
Location
Southern California, USA
I have looked at the ASM DEV PAK.d864 and compared that to the Zimmers software package , see attached images. The one I have been using from Zimmers, I think is a "doctored version" of the original disk .
This may explain the problems I have been having with the zimmer version. See message #45. I will try Mike's version on Steve's site.
 

dave_m

Veteran Member
Joined
Feb 2, 2009
Messages
3,581
Location
Southern California, USA
Oops...

Sorry, Dave, I was a little confused and didn't realize this was the version you were going to scan.
Mike,
I think the hard copy I have and the floppy was sent to me by yourself so many rears ago I can't remember when! I should have used the floppy with my 4040, but I took the other route of using the zimmer .d64 image on VICE. I have had a lot of problems getting it to run correctly. I will switch over to your version and try that image on VICE. I am thinking the zimmer version is an old buggy version or a corrupted version as Hugo believes.
 
Top