6500/1 ROM Archival

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

6500/1 ROM Archival

Jim Brain

I realize it's been a while since this happened:

http://e4aws.silverdr.com/hacks/6500_1/

But, I have pulled my hacked reader out from mothballs to read a CPU someone is sending, so I thought I would inquire if others have 6500/1 units they want archived.

Jim
-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

Francesco Messineo
Great one!
Where's the archive of the dumped firmwares?
If nobody has done it, I would (not *soon* probably) make a dump of
the 6500 inside the Olivetti PL10 plotter (which is a parallel port
clone of the Commodore 1520).
I'm not sure the MCU is socketed, but I own the right tools to do a
safe operation.

On Wed, Jul 4, 2018 at 7:02 PM, Jim Brain <[hidden email]> wrote:

> I realize it's been a while since this happened:
>
> http://e4aws.silverdr.com/hacks/6500_1/
>
> But, I have pulled my hacked reader out from mothballs to read a CPU someone
> is sending, so I thought I would inquire if others have 6500/1 units they
> want archived.
>
> Jim
>
> --
> Jim Brain
> [hidden email]
> www.jbrain.com

Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

silverdr@wfmh.org.pl


> On 2018-07-04, at 19:50, Francesco Messineo <[hidden email]> wrote:
>
> Great one!
> Where's the archive of the dumped firmwares?

On github. Linked from the article there ;-)

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

Francesco Messineo
On Wed, Jul 4, 2018 at 8:16 PM,  <[hidden email]> wrote:
>
>
>> On 2018-07-04, at 19:50, Francesco Messineo <[hidden email]> wrote:
>>
>> Great one!
>> Where's the archive of the dumped firmwares?
>
> On github. Linked from the article there ;-)

oh... the very last link :)
So the only dumped one so  far is the 1520?

smf
Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

smf
In reply to this post by Jim Brain
I don't know if it's worth posting on here, in case he still wants one
dumped.

https://www.vintage-radio.net/forum/showthread.php?t=107080

On 04/07/2018 18:02, Jim Brain wrote:

> I realize it's been a while since this happened:
>
> http://e4aws.silverdr.com/hacks/6500_1/
>
> But, I have pulled my hacked reader out from mothballs to read a CPU
> someone is sending, so I thought I would inquire if others have 6500/1
> units they want archived.
>
> Jim
>

Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

David Wood-2
In reply to this post by Francesco Messineo
I have a 64k printer buffer that uses one- The MicroStuffer from Supra.  Dumping it would be a purely educational exercise since there's doesn't seem to be much interest in printer buffers these days.

On Wed, Jul 4, 2018 at 2:21 PM, Francesco Messineo <[hidden email]> wrote:
On Wed, Jul 4, 2018 at 8:16 PM,  <[hidden email]> wrote:
>
>
>> On 2018-07-04, at 19:50, Francesco Messineo <[hidden email]> wrote:
>>
>> Great one!
>> Where's the archive of the dumped firmwares?
>
> On github. Linked from the article there ;-)

oh... the very last link :)
So the only dumped one so  far is the 1520?


Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

Jim Brain
On 7/4/2018 1:58 PM, David Wood wrote:
> I have a 64k printer buffer that uses one- The MicroStuffer from
> Supra.  Dumping it would be a purely educational exercise since
> there's doesn't seem to be much interest in printer buffers these days.
Well, I have refined the code a bit so it's basically just a plug and
read action.  Not a whole lot of work on this end.  If you want to, send
it over.

Jim


Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

Rhialto
In reply to this post by Jim Brain
On Wed 04 Jul 2018 at 12:02:45 -0500, Jim Brain wrote:
> I realize it's been a while since this happened:
>
> http://e4aws.silverdr.com/hacks/6500_1/

Regarding that blog post: near the end there is this:

    There is still one uncleared thing about the loop in point (5). It
    seems that additional toggling between the normal and TEST mode
    inside this loop is required. We don't know why at the moment but
    you can find it in the C program file...

which must refer to this:

https://github.com/Project-64/reloaded/blob/master/1520/extraction/main.c#L169

    for(i = 0; i< sizeof(code);i++) {
        send_data(0xA9);
        send_data(code[i]);
        send_data(0x85);
        send_data(0x00 + i);
        TEST_OFF();
        send_data(0);  // extra cycle
        TEST_ON();
    }

Now, I didn't re-read the threads, so it is possible it was mentioned in
there, and isn't an unclear thing at all, but isn't that clearly the
cycle in which the STA (85) opcode must access the zero page to store
the value there?

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl      -- are condemned to reinvent it. Poorly.

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

Jim Brain
On 7/4/2018 2:39 PM, Rhialto wrote:

>
> https://github.com/Project-64/reloaded/blob/master/1520/extraction/main.c#L169
>
>      for(i = 0; i< sizeof(code);i++) {
> send_data(0xA9);
> send_data(code[i]);
> send_data(0x85);
> send_data(0x00 + i);
> TEST_OFF();
> send_data(0);  // extra cycle
> TEST_ON();
>      }
>
> Now, I didn't re-read the threads, so it is possible it was mentioned in
> there, and isn't an unclear thing at all, but isn't that clearly the
> cycle in which the STA (85) opcode must access the zero page to store
> the value there?
It is.  I reread the posting and mentally made a note to update
SIlverDream, but have not done so.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

silverdr@wfmh.org.pl

> On 2018-07-04, at 23:40, Jim Brain <[hidden email]> wrote:
>
>> https://github.com/Project-64/reloaded/blob/master/1520/extraction/main.c#L169
>>
>>     for(i = 0; i< sizeof(code);i++) {
>> send_data(0xA9);
>> send_data(code[i]);
>> send_data(0x85);
>> send_data(0x00 + i);
>> TEST_OFF();
>> send_data(0);  // extra cycle
>> TEST_ON();
>>     }
>>
>> Now, I didn't re-read the threads, so it is possible it was mentioned in
>> there, and isn't an unclear thing at all, but isn't that clearly the
>> cycle in which the STA (85) opcode must access the zero page to store
>> the value there?
> It is.  I reread the posting and mentally made a note to update SIlverDream, but have not done so.

Please do :-) Or should we just drop that paragraph and maybe add some comment in the extraction source?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: 6500/1 ROM Archival

Jim Brain
On 7/8/2018 7:10 AM, [hidden email] wrote:

      
On 2018-07-04, at 23:40, Jim Brain [hidden email] wrote:

https://github.com/Project-64/reloaded/blob/master/1520/extraction/main.c#L169

    for(i = 0; i< sizeof(code);i++) {
	send_data(0xA9);
	send_data(code[i]);
	send_data(0x85);
	send_data(0x00 + i);
	TEST_OFF();
	send_data(0);  // extra cycle
	TEST_ON();
    }

Now, I didn't re-read the threads, so it is possible it was mentioned in
there, and isn't an unclear thing at all, but isn't that clearly the
cycle in which the STA (85) opcode must access the zero page to store
the value there?
It is.  I reread the posting and mentally made a note to update SIlverDream, but have not done so.
Please do :-) Or should we just drop that paragraph and maybe add some comment in the extraction source?

I am working to add comments in the code, but here's some description:

WIth TEST_ON(), you are feeding opcodes into the 6500/1 from the AVR, and in the code above, you are sending the ML:

lda #code[i]

sta zp:i

after the sta and the i is sent, you have to drop out of TEST mode so that CPU can access on board memory.  The same is true when we try to load the specific memory location in the "brute force" mode of reading a byte and then resetting the machine.

Jim


-- 
Jim Brain
[hidden email] 
www.jbrain.com