6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Mar 28, 2024 10:50 am

All times are UTC




Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Wed Feb 12, 2014 9:57 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
(and I'd like to see where the PIC is hiding on the circuit board!)
Welcome, boxerbomb!


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 12, 2014 10:33 pm 
Offline
User avatar

Joined: Thu Jun 23, 2011 2:12 am
Posts: 229
Location: Rancho Cucamonga, California
BigEd wrote:
(and I'd like to see where the PIC is hiding on the circuit board!)
Welcome, boxerbomb!


The PIC isn't really hiding, it's "the other big chip".

The chip that's hiding is the SRAM chip, underneath one of the other chips.

And this would look awesome if there would be a Propeller next to it, of course (it's 40 pins as well) with its EEPROM hidden underneath it. :-)

===Jac


Top
 Profile  
Reply with quote  
PostPosted: Wed Feb 12, 2014 10:35 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Oh, of course, not the PIC - but someone was hiding... is it on the back side? A side view might give me the clue I'm lacking.


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 13, 2014 12:49 pm 
Offline

Joined: Thu Feb 13, 2014 12:47 pm
Posts: 1
I thought it could be nice to replicate this computer.
Are the sources for PIC available somewhere? I can't find it.r


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 13, 2014 9:41 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1918
Location: Sacramento, CA, USA
BigEd wrote:
Oh, of course, not the PIC - but someone was hiding... is it on the back side? A side view might give me the clue I'm lacking.


You completely missed the clue, Ed!
Quote:
... That was a donation from a Ham radio friend. I think he got them on ebay. He actually offered me a choice of that 64K chip or a 128K Alliance chip like the one you're using. I snatched up the 64K chip because it was 15 nanoseconds and because it would fit within the open frame of a 40-pin machined pin socket ...


Mike


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 13, 2014 10:04 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Ah, so the PIC is unsocketed...


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 2:05 pm 
Offline

Joined: Sun Feb 16, 2014 10:39 am
Posts: 4
Would you be able to explain a little about how you can upload a program to RAM with the PIC without the 6502's control of the address bus getting in the way?
I am assuming that this happens at power up, before the 6502 starts executing.


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 2:27 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
The PIC keeps the 65C02 in reset state while loading programs to RAM.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 5:53 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 585
Location: Michigan, USA
Pukuhaha wrote:
Would you be able to explain a little about how you can upload a program to RAM with the PIC without the 6502's control of the address bus getting in the way? I am assuming that this happens at power up, before the 6502 starts executing.
Hi Pukuhaha. Welcome to 6502.org.

Thank you for a very thoughtful question. Unlike the WDC65C02, there's nothing in the Rockwell R65C02 Datasheet to suggest I can tri-state the buss lines so I assumed that the R65C02 is always driving the address lines after it's powered up.

In order to load RAM during start-up, the PIC puts the R65C02 through the 'reset' process, then pushes the $FFFC and $FFFD reset vector bytes to the R65C02, then pushes instruction and operand bytes that make up a simple three instruction LDA/STA/JMP loop which guides the R65C02 through the process of filling RAM memory. It's a slow process (~80-msecs for 8192 bytes) but it seems to work well. I should mention that you need to disable the address decoder when pushing $FFFC and $FFFD bytes during the reset process to avoid contention since these locations are normally mapped to RAM or ROM. In the PIC, that's just a matter of specifying "decoder on" or "decoder off" for the push() routine. After the reset process, the address decoder is always on since the loader loop is running at an address in the page assigned to PIC I/O in the decoder map. After the ROM image has been loaded into RAM the PIC pushes the JMP ($FFFC) instruction and the R65C02 is running entirely on its own.

Does this brief explanation help? I plan to explain this in much more detail when I post the completed project into the SBC Forum in a few weeks.

Cheerful regards, Mike


Last edited by Michael on Sun Feb 16, 2014 6:06 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 5:59 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 585
Location: Michigan, USA
Klaus2m5 wrote:
The PIC keeps the 65C02 in reset state while loading programs to RAM.

Hi Klaus,

Does the Rockwell R65C02 tri-state the buss lines when held in reset? If so, that would really help to speed up my PIC code.

Cheerful regards, Mike


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 6:11 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Hi Mike, do you need the JMP in your force-fed loader? LDA immediate, STA absolute and never mind where the PC has got to - until the final JMP. Perhaps that's what you meant...


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 6:33 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 585
Location: Michigan, USA
BigEd wrote:
Hi Mike, do you need the JMP in your force-fed loader? LDA immediate, STA absolute and never mind where the PC has got to - until the final JMP. Perhaps that's what you meant...

Hi BigEd,

That would work to a certain extent. The loader loop is running from a single 256 byte PIC I/O page in the 6502 address space with "decoder on" for access to RAM so I really need to stay within that page. Still, shaving 3 cycles off every 120 or so bytes moved would save about 23-24 msecs which is pretty significant.

I'll definitely put this on my ever growing "to do" list (grin).

Thanks, Ed...


Last edited by Michael on Sun Feb 16, 2014 6:47 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 6:35 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
(Ah, yes, I suppose you have to fiddle your decoding so that all reads come from your two-instruction loader and all writes are directed to RAM)


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 6:43 pm 
Offline
User avatar

Joined: Thu Jun 23, 2011 2:12 am
Posts: 229
Location: Rancho Cucamonga, California
Michael wrote:
In order to load RAM during start-up, the PIC puts the R65C02 through the 'reset' process, then pushes the $FFFC and $FFFD reset vector bytes to the R65C02, then pushes instruction and operand bytes that make up a simple three instruction LDA/STA/JMP loop which guides the R65C02 through the process of filling RAM memory.


It would probably be a lot more efficient if you would use the same process as my Propeddle project: After giving the 6502 the reset vector (which is the start of memory), just write the data to memory from the PIC during the first half of the clock cycle when the 6502 doesn't use the databus, and feed the 6502 a fake instruction during the second half of the clock cycle.

I actually use NMI to load data to RAM, so I can do it anytime while the system is running too. I feed a fake address for the NMI vector, and access the RAM from my Propeller while the 6502 clock is low and it doesn't use the databus. Then I take the RAM off the data bus and feed the 6502 with $C9 bytes.

Unlike the NOP instruction which is 2 clocks and one byte (so the address bus advances only once every OTHER clock cycle), $C9 is CMP Immediate which is 2 clocks, 2 bytes (the 6502 sees it as CMP #$C9) so the address bus increases on EVERY clock cycle. That means that I can store one byte of memory on every clock cycle!

The CMP Immediate instruction changes the flags register but the flags got saved on the stack by the NMI interrupt handling anyway. I'm planning on intercepting the saving of the flags too, so that the NMI leaves no trace in memory at all, and so there's no chance of a stack overflow either. At the end of the memory area, I feed a $40 (RTI) so the 6502 reads the flags back and continues where it left off. My Propeller then resumes "normal" operation where the 6502 has access to the RAM.

And of course, the same process can be used to let the Propeller READ data from the RAM chip.

===Jac


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 16, 2014 6:57 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Michael wrote:
Klaus2m5 wrote:
The PIC keeps the 65C02 in reset state while loading programs to RAM.

Hi Klaus,

Does the Rockwell R65C02 tri-state the buss lines when held in reset? If so, that would really help to speed up my PIC code.

Cheerful regards, Mike

Maybe that was too much of an assumption as I don´t know, wether older 65C02 behave that way. The ones with a bus enable pin will have the logic for it. However the Rockwell cores may have the logic for it too, as other variants do have the BE input and chipmakers are lazy not to modify chip designs more than necessary. As I said in another thread, it could easily be tested for, if one tries to use a weak pullup or pulldown during reset and see, if the address bus would follow.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: