My 3-Chip Design Is Working...

[BigEd]

(and I'd like to see where the PIC is hiding on the circuit board!)
Welcome, boxerbomb!

[jac_goudsmit]

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

[BigEd]

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.

[jaromir]

I thought it could be nice to replicate this computer.
Are the sources for PIC available somewhere? I can't find it.r

[barrym95838]

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

[BigEd]

Ah, so the PIC is unsocketed...

[Pukuhaha]

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.

[Klaus2m5]

The PIC keeps the 65C02 in reset state while loading programs to RAM.

[Michael]

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

[Michael]

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

[BigEd]

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...

[Michael]

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...

[BigEd]

(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)

[jac_goudsmit]

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

[Klaus2m5]

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.