Commodore P500

[crock]

Superb! Well done you, though your attachments don't seem to work.

Out if interest, did you keep the 6525s you removed? we might be able to salvage them if there's enough left of the pin to solder something yo.
Rob

 

[Pet Rescue]

Hi Rob thanks for the help that BANK 0 is a bit confusing, the attachments work my end but only when I'm logged in, strange!

Yes I kept the 6525's I bet you could solder to the clipped edge against the plastic body and breadboard it in a socket.

 

[jltursan]

Great news to have a P500 back into life!, congrats!. I've been looking for one for ages now, I still have hopes of finding one

Indeed, the attachments don't work, have you tried to insert a image instead using attachments?. I'm eager to see pictures of a P500 working

About it, sadly, seems that's there's no specific software for the machine, Commodore never converted a single C64 package, isn't it?

 

[crock]

There's a couple of disks out there which run some do some rolling graphical demo's. I also have this idea to convert a classic game at some point - maybe 'boulderdash', but sadly it's way down the priority list at the moment.

 

[Pet Rescue]

Great news to have a P500 back into life!, congrats!. I've been looking for one for ages now, I still have hopes of finding one

Indeed, the attachments don't work, have you tried to insert a image instead using attachments?. I'm eager to see pictures of a P500 working

About it, sadly, seems that's there's no specific software for the machine, Commodore never converted a single C64 package, isn't it?

Thanks jltursan, it's taken me around six years I think of actively trying. They just seem to go for silly money at times!

I'll be asking more questions on programming it next so!!

My next attempt to add some pictures

Yes it's working the startup banner and message


Daughter board header pins.


Daughter board in situ.


Headroom issues.


Ill fated ROM socket addition.

 

[carlsson]

So is the VICE emulation adequate, or based on guesses? I suppose if one works from source codes, adapting a reasonably simple C64 homebrew shouldn't be terribly difficult once you get the memory maps figured out.

Then again I just realized it seems to exist very little homebrew even for a such "common" system as the Max Machine, which shares even more of the C64 architecture than the P500 does, so in that respect it doesn't surprise me if few or nobody seriously targetted this platform.

 

[Pet Rescue]

So is the VICE emulation adequate, or based on guesses? I suppose if one works from source codes, adapting a reasonably simple C64 homebrew shouldn't be terribly difficult once you get the memory maps figured out.

Then again I just realized it seems to exist very little homebrew even for a such "common" system as the Max Machine, which shares even more of the C64 architecture than the P500 does, so in that respect it doesn't surprise me if few or nobody seriously targetted this platform.

From what I've looked at it's very good, even the startup delay is exactly the same as my real one. Well now it's RAM is repaired, that looking back was a big clue that the RAM count was failing as the startup banner came up in a second instead of 8.

There's a couple of disks out there which run some do some rolling graphical demo's. I also have this idea to convert a classic game at some point - maybe 'boulderdash', but sadly it's way down the priority list at the moment.

I'm going to try a demo that I got off davidviner.com it runs in vice fine! I may be asking you a few programming questions later!
On the subject of questions why does the P500 not have an internal speaker like the B128?

 

[crock]

Then again I just realized it seems to exist very little homebrew even for a such "common" system as the Max Machine, which shares even more of the C64 architecture than the P500 does, so in that respect it doesn't surprise me if few or nobody seriously targetted this platform.

Have you seen this? http://www.multimax.co/

The MAX machine was at least officially released, albeit only in Japan, whereas the P500 only got a handful of prototypes to dealers. I don't think it ever had the opportunity to be targeted. Also, it's a bitch to program in ML and the BASIC is horribly slow - being crippled by running at 1mhz, the banking scheme and ugly kludges in the kernal that write to the VIC-II registers multiple times.

 

[RobertB]

I'm eager to see pictures of a P500 working

Darn! We had Larry Anderson's B128 and North American P500, both fully-functional, at CommVEx v9 2012, but I failed to take a photo of the latter working. All I have is a photo of both, taken during the Friday set-up time.

http://www.dickestel.com/images/expo1099.jpg

(Note that they have not been hooked up yet and that they both have to share a the single 1702 monitor.)

FCUG celebrating 33 years,
Robert Bernardo
Fresno Commodore User Group
http://www.dickestel.com/fcug.htm
July 18-19 Commodore Vegas Expo v11 2015 -
http://www.portcommodore.com/commvex

 

[jltursan]

Also, it's a bitch to program in ML and the BASIC is horribly slow - being crippled by running at 1mhz, the banking scheme and ugly kludges in the kernal that write to the VIC-II registers multiple times.

Weird!, in the Von Bassewitz page I've found this piece of code about VIC writing:

wrtvic: sta     saver
@L1:   	lda     saver
    	sta     vic,y
    	eor     vic,y
    	beq     @L3
    	cpy     #$20
    	bcs     @L2
    	cpy     #$11
    	bcc     @L1
    	and     wrttab-$11,y
    	bne     @L1
@L2:	and     #$0F
    	bne     @L1
@L3:	lda     saver
    	rts

wrttab: .byte   $7F,$00,$00,$00,$FF,$3F,$FF,$FE
    	.byte   $00,$0F,$FF,$FF,$FF,$FF,$FF

Indeed it looks a bit awkward. I can't read 6502/6509 code but seems that it waits for several VIC states.
I'm pretty curious about a simple benchmarking against a C64. A BASIC loop with some arithmetics and some screen fill loops.

but I failed to take a photo of the latter working. All I have is a photo of both, taken during the Friday set-up time.

Hahaha, thanks!. I'm sure Pet rescue will provide a bunch of interesting pics in the future

 

[carlsson]

Bitch to program in machine code due to the mapping and lack of RAM in the same page where the VIC-II registers are located?

(and yes, I'm aware of the MultiMax which is very attractively priced, but as far as I can tell doesn't contain any modern homebrew software except the menu system itself)

 

[Pet Rescue]

Hahaha, thanks!. I'm sure Pet rescue will provide a bunch of interesting pics in the future

Are they still not working, I uploaded them from my computer?

Regarding programming I used PETDISK to load up the demo software but It would not work properly on the bload parts I think.
I got a neat hires graphics one work that drew dots in a x,y style graph with loops to look like a petal formation.
MEGA slow on the screen though!!

 

[Pet Rescue]

Sorry but I can't seem to get my head around the P500's memory BANK's.

It's a 128K machine so 2 banks of 64K ram (assumed to be the 16 4164 chips!) BANKS 0 & 1.

What makes up Bank 15, is it the kernal and basic roms and the 2k static (is that zero page) RAM's ? (if so does that add up to 64k?)

 

[Pet Rescue]

Here's a video hopefully of a demo run using PETDISK.

[video]http://vid984.photobucket.com/albums/ae322/SX-64_USER/P500/2015-02-27_13-17-12_379.mp4[/video]

 

[crock]

Sorry but I can't seem to get my head around the P500's memory BANK's.

It's a 128K machine so 2 banks of 64K ram (assumed to be the 16 4164 chips!) BANKS 0 & 1.

What makes up Bank 15, is it the kernal and basic roms and the 2k static (is that zero page) RAM's ? (if so does that add up to 64k?)

Bank 15 has a 64k of addressable space, but not all of which is populated, and maybe not even mapped - I'm not sure. It consists of the 2k static RAM, screen and colour RAM, I/O space and the ROMS. Some of the addressable space in bank15 is mapped to the cartridge ports and some is reserved for internal expansion.

Here's a memory map of Bank 15, hosted on Steve's site and scanned from The Transactor magazine.

http://www.6502.org/users/sjgray/computer/cbm2/b-memmap.jpg

Although this is for the B series machines, I assume it's basically the same. I would guess at the following differences:

Only 1k of screen ram from $D000 - $D3FF
1k of colour nibbles at $D400 - $D7FF
The VIC-II is at $D800 instead of the CRTC controller.

cheers, Rob

 

[Pet Rescue]

Bank 15 has a 64k of addressable space, but not all of which is populated, and maybe not even mapped - I'm not sure. It consists of the 2k static RAM, screen and colour RAM, I/O space and the ROMS. Some of the addressable space in bank15 is mapped to the cartridge ports and some is reserved for internal expansion.

Here's a memory map of Bank 15, hosted on Steve's site and scanned from The Transactor magazine.

http://www.6502.org/users/sjgray/computer/cbm2/b-memmap.jpg

Although this is for the B series machines, I assume it's basically the same. I would guess at the following differences:

Only 1k of screen ram from $D000 - $D3FF
1k of colour nibbles at $D400 - $D7FF
The VIC-II is at $D800 instead of the CRTC controller.

cheers, Rob

Thanks for the info Rob, I was looking at the program for the demo and it was loading sprite data into bank 0 and into bank 15 screen ram area 54272.

It was using bload command to load in the binaries into that location on both bank 0 and bank 15.

It was getting a bit confusing, it looks a bit different than setting up sprites on a C64.

 

[sjgray]

Weird!, in the Von Bassewitz page I've found this piece of code about VIC writing:

wrtvic: sta     saver
@L1:   	lda     saver
    	sta     vic,y
    	eor     vic,y
    	beq     @L3
    	cpy     #$20
    	bcs     @L2
    	cpy     #$11
    	bcc     @L1
    	and     wrttab-$11,y
    	bne     @L1
@L2:	and     #$0F
    	bne     @L1
@L3:	lda     saver
    	rts

wrttab: .byte   $7F,$00,$00,$00,$FF,$3F,$FF,$FE
    	.byte   $00,$0F,$FF,$FF,$FF,$FF,$FF

Indeed it looks a bit awkward. I can't read 6502/6509 code but seems that it waits for several VIC states.
I'm pretty curious about a simple benchmarking against a C64. A BASIC loop with some arithmetics and some screen fill loops.

On my site I have a "fast boot" kernal that I created for the P500. Basically I patched the startup memory test routine to only test 1 byte of each memory page. This makes the bootup almost instant. I also patched a few of those ugly printing loops etc but it didn't seem to make much difference in speed. I'm pretty sure a lot of that code was written for early hardware which was unstable and commodore just never removed that code.

Steve

 

[sjgray]

Here is the P-series memory map also from my page:
http://www.6502.org/users/sjgray/computer/cbm2/p-memorymap.jpg

This comes from the FIRST revision of the user guide which DID include information on the C128-40 aka P128 aka P500 machine.

http://www.6502.org/users/sjgray/computer/cbm2/CBMII-Guide.pdf

Bank 15 memory is completely mapped, but some of the areas were reserved for future expansion. A CBM-II cartridge can contain up to 24K of ram or rom. There was a planned DMA disk drive option which had ram and rom space allocated to it, but sadly was never completed AFAIK.

Steve

 

[Pet Rescue]

Here is the P-series memory map also from my page:
http://www.6502.org/users/sjgray/computer/cbm2/p-memorymap.jpg

This comes from the FIRST revision of the user guide which DID include information on the C128-40 aka P128 aka P500 machine.

http://www.6502.org/users/sjgray/computer/cbm2/CBMII-Guide.pdf

Bank 15 memory is completely mapped, but some of the areas were reserved for future expansion. A CBM-II cartridge can contain up to 24K of ram or rom. There was a planned DMA disk drive option which had ram and rom space allocated to it, but sadly was never completed AFAIK.

Steve

Thanks for the info Steve, I've been trying to get the sprites to work on the p500 but I'm having trouble finding the sprite memory locations and sprite pointers.
I have tailored the POKE commands based on the C64 and can get the sprites to turn on and move but I can't seem to get the data for the sprites to be seen.
On the Demo's they aren't much help as they are using machine code routines to set up sys Q commands but as I say I've managed to POKE the sprites like the
C64 but without useable sprite data, they just get displayed as corrupt data.

 

[sjgray]

Thanks for the info Steve, I've been trying to get the sprites to work on the p500 but I'm having trouble finding the sprite memory locations and sprite pointers.
I have tailored the POKE commands based on the C64 and can get the sprites to turn on and move but I can't seem to get the data for the sprites to be seen.
On the Demo's they aren't much help as they are using machine code routines to set up sys Q commands but as I say I've managed to POKE the sprites like the
C64 but without useable sprite data, they just get displayed as corrupt data.

Reading:

http://davidviner.com/cbm6.html?name=500+Hi-Res+Graphics

The routines divert the text screen to bank 0. Is that where you are putting your sprites? It looks like they need to be put to $DC00 in bank 0.
If you are not using David's routines then there's likely some special setup code to move everything to bank 0 that you would need to do. That's because there is only enough ram for the text screen in BANK15. You wouldn't be able to put sprites anywhere. You can't put them at $0400 in bank 15 because the VIC only see's 16K ram and the text ram and $0400 ram are too far away from each other to be in the same 16K range. There's no other ram in bank 15 that can be used.

Steve