• Please review our updated Terms and Rules here

Commodore P500

I don't know if this helps or not. I've been looking at the P500 schematics, plus the PLA equations. It appears that there are 4 lines that control what the VIC chip sees. There are two 6525 chips, one controls the keyboard and the other the IEEE. Well, two lines from each chip seem to be involved.

* U101 controls the keyboard normally. The PC6 and PC7 lines are labelled VICBNKSEL0 and VICBNKSEL1. I think these determine the upper two addresses that the VIC sees when in bank 0. So:

00 = $0000 to $3FFF
01 = $4000 to $7FFF
10 = $8000 to $BFFF
11 = $C000 to $FFFF (David seems to use this)

* U20 controls the IEEE normally. The CA and CB lines are labelled VICDOTSEL and STATVID. These go to the PLA chip(s). The PLA chips are used to generate chip selects for the various ram/rom/io chips. I think one or both of these may be flags to tell the VIC to use BANK 0.

Steve
 
As I understand on the C64 it uses memory location 2040-2047 to tell the vic where to get the sprite data, ie 2040,13 would look in memeory location 832 (13*64).
2040 is the last eight in the screen memory. Would it be safe to assume the eight sprite pointers are in bank 15?
 
Pet Rescue said:
As I understand on the C64 it uses memory location 2040-2047 to tell the vic where to get the sprite data, ie 2040,13 would look in memeory location 832 (13*64).
2040 is the last eight in the screen memory. Would it be safe to assume the eight sprite pointers are in bank 15?
Click to expand...

You have to remember the C64's screen memory is low in RAM, and the VIC-II's 16K window is set from $0000 to $3FFF. On the P500 screen memory is at $D000 so the VIC-II window is set at $C000-FFFF so the sprite pointers would be inside that block NOT in low memory like the C64. Since there is little RAM there in BANK 15 one must force the P500 to use RAM from BANK 0. BANK 0 is also used for your BASIC program, starting at $0002. It looks like David's routines use $C000-FFFF in BANK 15, meaning the sprite pointers and definitions are all inside that range. I supposed it would be possible to relocate the beginning of BASIC pointers to move everything higher up, allowing you to put the screen low like on the C64. If you are converting a C64 program to P500 that might be the best option... not sure.

I contacted David and he sent me the source code to his sprite/video routines with permission to post them, so I will be updating my CBM-II page shortly.

Steve
 
sjgray said:
Hi, got those files posted. Look under the Software section. David also sent an extended monitor for the B-series that was adapted from the C128 monitor.

http://www.6502.org/users/sjgray/computer/cbm2/index.html

Steve
Click to expand...

Thanks Steve I really appreciate your efforts! It's amazing how little information is available on this machine compared to the B128's.

Then again it's also amazing how some info still survives especially with the low number of machines in use.
 
You're welcome. I'm constantly looking for info to add ;-) I wrote some ML programs back in the day that I've been meaning to post as well.
Yes, the info is still out there if you know where to dig. There is a lot of good info in the CBUG disks and their newsletter.

Steve
 
So David's program reconfigures the VIC-II memory map to a more convenient location, as well as adding ML routines for easier access? Hm, it sounds like the original mapping leaves a lot to be desired, and everyone grunting about all the POKE's required to program C64 video should rather be relieved Commodore didn't mass market the P500 instead.

By the way, I still wonder exactly which machines were displayed at the Hannover Fair Trade in April 1982. According to MicroComputer Printout, May 1982 they saw an Ultimax, a VIC-40, a Commodore 64 and a Commodore II. However another magazine The Torpet, May 1982 refers to the PET II and CBM II, and briefly mention the base model Commodore 64 which already was an established fact in North America, but appears to not have been the case in Europe. Even more confusing is that what MicroComputer called a VIC-40 appears to be what Torpet already at the same time said was a Commodore 64, and what MicroComputer called a Commodore 64 matches the PET II according to Torpet's review of the very same fair!

I know model names and specs changed almost weekly around then, and that there was a difference between what Commodore USA and Commodore Germany cooked up, but in this case at least two magazines reported from the same fair, but with different information?

Besides, is P128 simply an early synonym for P500 or is there some subtle difference between those names: P500, P128, C128-40, PET II?
 
Btw, David makes more notes on the memory setup, and it appears there are no sprite pointers in the default configuration, thus you need to remap it in order to use any custom defined sprites, as well as other graphics. Ugh! Also the issues that you need to copy ROM routines to RAM and possibly patch them in order to use machine code properly makes me understand why there yet really doesn't seem to be any homebrews going on with this platform, although most of that is a matter of a one time inconvenience.

http://www.davidviner.com/cbm3.html?name=Discoveries+Part+2
http://www.davidviner.com/cbm5.html?name=500+Video+Memory
 
carlsson said:
So David's program reconfigures the VIC-II memory map to a more convenient location, as well as adding ML routines for easier access? Hm, it sounds like the original mapping leaves a lot to be desired, and everyone grunting about all the POKE's required to program C64 video should rather be relieved Commodore didn't mass market the P500 instead.
Click to expand...

David's routines help the BASIC programmer and seem like they do a good job of addressing the problem. I assume if the P500 was actually widely available that any commercial software would be written in machine language just like on the C64. I don't think it would have been a big deal. It seems strange today because we just know so little about the P500 and what it is really capable of. Commodore would also have finished the firmware and produced a programmer's guide that would have cleared up all the confusion.

By the way, I still wonder exactly which machines were displayed at the Hannover Fair Trade in April 1982. According to MicroComputer Printout, May 1982 they saw an Ultimax, a VIC-40, a Commodore 64 and a Commodore II. However another magazine The Torpet, May 1982 refers to the PET II and CBM II, and briefly mention the base model Commodore 64 which already was an established fact in North America, but appears to not have been the case in Europe. Even more confusing is that what MicroComputer called a VIC-40 appears to be what Torpet already at the same time said was a Commodore 64, and what MicroComputer called a Commodore 64 matches the PET II according to Torpet's review of the very same fair!
Click to expand...

Yes, I think you have it right. My understanding is:

VIC-40 would be the C64
Commodore 64 and PET-II would have been the P500
Commodore II would be the CBM-II B-series

I know model names and specs changed almost weekly around then, and that there was a difference between what Commodore USA and Commodore Germany cooked up, but in this case at least two magazines reported from the same fair, but with different information?

Besides, is P128 simply an early synonym for P500 or is there some subtle difference between those names: P500, P128, C128-40, PET II?
Click to expand...

It was all marketing. They are all the same machine. Commodore were working out how much ram to put in the machines and which models to release. I have no idea why they decided to name the machines differently for the US or European markets. They even had weird variations. If you look on my page I break down the machines by configuration, which means you only have 3 basic models:

BL - Monochrome, no monitor (B500)
BH - Monochrome with monitor (B700)
PL - Colour, no monitor (P500)

The "x00" models seem to be pre-production runs to work out manufacturing. Commodore planned models based on RAM capacity, so:

x05 = 64K
x10 = 128K
x15 = 192K
x20 = 256K

Then I suppose someone noticed there were two "500" models, so they changed the B500 to B600 (although no B600 models are known). So in Europe they went with "Commodore XXX" with XXX being just the number. In North America they decided to use the RAM capacity as the model number and use "CBM" rather than Commodore. Some marketing genius decided that wasn't complicated enough so he thought maybe adding "-40" or "-80" to the end to indicate the video size would help. So basically you mix up all these concepts and that explains why there are so many different models. Welcome to my world ;-)

Steve
 
Last edited:
If the machine in Hannover had 64K (which seems reasonable if it partly was referred to as Commodore 64), it would have become a P505 in that case, but if I understand correctly, the known P500 models all have at least 128K? Of course that is just speculation based on two articles, of which the Torpet one actually mentions 505 but alas we have no proof it ever got into the wild.
 
carlsson said:
If the machine in Hannover had 64K (which seems reasonable if it partly was referred to as Commodore 64), it would have become a P505 in that case, but if I understand correctly, the known P500 models all have at least 128K? Of course that is just speculation based on two articles, of which the Torpet one actually mentions 505 but alas we have no proof it ever got into the wild.
Click to expand...

I have never seen a P505 but the way the board is laid out it seems like a 64K option would have been possible. I have a collector friend that supposedly has a P520 but several requests for more info haven't been helpful (machine is boxed and in storage). But yes, all known P models have 128K. Commodore source code can be configured to produce firmware for all memory options from 64K to 256K. I think Commodore knew that in order to distinguish the P500 from he C64 that they would need to make 128K ram as the base model. I have no doubt that if the P500 was actually released properly that they would have also made a P520 model.

Steve
 
Nice work André!

Plenty of photographs too which are really helpful when stripping and cleaning!

Regarding your picture of the Rom daughter board yours was socketed to the mainboard.

Interesting as the daughter board on my P500 was soldered directly to the board without a socket just the header.

I did socket mine just as yours is in the picture, only to realise the P500 has a keyboard above that won't allow it due to the height restrictions
and so had to remove the socket!

I had to sacrifice my 710 to bring the P500 back to life due to the 6509 being u/s this after hunting for a 6509 to fix my 710, oh the irony!! :D

At least I can swap out the 6509 to get it working if needed!
 
You must log in or register to reply here.
Back
Top