Self-Programming the MC68701 and the MC68701U4? (motorola)

[grantb5]

The example on the last few pages of the first PDF I linked (a few posts above) shows how the register is written and comments are included.

Apparently some Needhams programmers can program these, so there must also be a parallel programming method. You might want to research that as well just in case. This is hearsay, so keep that in mind.

[bytestorm]

The example on the last few pages of the first PDF I linked (a few posts above) shows how the register is written and comments are included.

Apparently some Needhams programmers can program these, so there must also be a parallel programming method. You might want to research that as well just in case. This is hearsay, so keep that in mind.

I have found some programmers that can and even have a friend who owns some really good, old ones, that support this MCU, but all needs a special adapter.
This adapter includes the circuitry with probug and rams etc baked into the adapter.. :/

the docs you posted are the same datasheet I just wrote the process from. The other "snippet" just led me to a oscilloscope leaflet :S

Thanks nevertheless!

[joeqsmith]

Back when I was starting out, I designed and built my own EPROM programmer that had an ISA card that plugged into my IBM AT.  I had support for the 01 with this as well.   The problem was it was built for old hardware and years later after I could afford a real programmer, I decided to make that adapter I showed in my link that works with it.   Even that programmer is really old now, using the PC's printer port.      I keep thinking I will get a new one some day but I just don't use it very often.

10 parts is not very many.  I wonder what someone would charge you.  Maybe a half hour of time assuming you are supplying known good virgin parts.  Old parts, maybe double to erase them.   

I understand the mode selection, but when it fetches a "vector table" I am not so sure what that means.

This below is the instructions straight from the datasheet

When the MC68701U4 is released from reset in mode 0, a
vector is fetched from location $BFFE:$BFFF.
- So it fetches a vector (instruction?) from those 2 adresses? or all inside that area?

Each vector is a 16-bit address pointing to different parts of your program.   Reset points to the start.

This provides
a method for an external program to obtain control of the
microcomputer with access to every location in the EPROM.
- Ok, so here it must mean that now PRObug can somehow interact with the MCU? (or viceversa)
I have never used PRObug and don't know anything about it.  Consult the manual if you can find one.


To program the EPROM, it is necessary to operate the
MC68701 U4 in mode 0 under the control of a program resident
in external memory which can facilitate loading and programming
of the EPROM.
- Allright, this must be PRObug? But how can the external memory controll the MCU?
I assume it could be PRObug but really could be anything.  The MCU is in control of the memory, internal or external.

After the pattern has been loaded
into external memory, the EPROM can be programmed as
follows:
- Ok.. what pattern is getting loaded into what external memory? (sram i suppose)
- Is it here "my code" would get loaded into a external sram? If so, from where does it get loaded into external sram?
External memory contains the software used to program the part (PRObug??) and also the image of what you want to program into the device (your arcade software).   Both could be in any type of memory.  It really doesn't matter.  Normally the software doing the programming is in ROM.   The image or pattern in my case has always been RAM but it could have been ROM.

a. Apply programming power (VPP) to the RESET/Vpp
pin.
- ok (haha jeez, well atleast I can probably get this one right).


b. Clear the PLC control bit and set the PPC bit by writing
$FE to the RAM/EPROM control register.
- ok, how would I do that? (cant possibly mean manually right? since its for every single byte..)

It's a micro and can do a lot of things, like program the PPC bit.  I would assume PRObug does everything for you.  In my case, I just release the reset button and watch the LCD to tell me what is going on.


c. Write data to the next EPROM location to be programmed.
Triggered by an MPU write to the EPROM, internal
latches capture both the EPROM address and the
data byte.
- Now here I dont see what I am supposed to do. How am I supposed to write data?
- Or does it simply mean that it WILL write the data if I trigger a MPU write manually somehow?
Again, this is all done in software by the routine I posted.


d. Clear the PPC bit for programming time, tpp, by writing
$FC to the RAM/EPROM control register and waiting
for time, tpp. This step gates the programming power
(Vpp) from the RESETlVpp pin to the EPROM which
programs the location.
- ok, how would I do that? (cant possibly mean manually right? since its for every single byte..)
Again, this is all done in software by the routine I posted.

e. Repeat steps b through d for each byte to be programmed.
- Will the counter increment automatically?
I would need to look at the routine and am guessing you need to keep track of that.  But again, PRObug should do all of this for you.


f. Set the PLC and PPC bits by writing $FF to the
RAM/EPROM control register.
- How would I do that?

g. Remove the programming power (Vpp) from the
RESET IVpp pin. The EPROM can now be read and
verified.
- ok

As you can see there are many points where I cant see how its suposed to be done. :/

If PROBug is anygood and well documented, I doubt it's a big deal.  If you want to write your own from scratch, sounds like you are going to learn embedded programming an assembler.   Not a bad thing if you want to learn it. 

[amyk]

I understand the mode selection, but when it fetches a "vector table" I am not so sure what that means.

This below is the instructions straight from the datasheet

When the MC68701U4 is released from reset in mode 0, a
vector is fetched from location $BFFE:$BFFF.
- So it fetches a vector (instruction?) from those 2 adresses? or all inside that area?

It will read 2 bytes, interpret those as a memory address, then begin execution at that address (i.e. Program Counter register will be initialised to that value.) You should probably familiarise yourself with 6800 architecture in general (there's plenty of other documentation on that) because the 68701 is basically a 6800 with some peripherals attached.

To program the EPROM, it is necessary to operate the
MC68701 U4 in mode 0 under the control of a program resident
in external memory which can facilitate loading and programming
of the EPROM.
- Allright, this must be PRObug? But how can the external memory controll the MCU?

It could be PRObug, it could be any other program (including code you write yourself).

After the pattern has been loaded
into external memory, the EPROM can be programmed as
follows:
- Ok.. what pattern is getting loaded into what external memory? (sram i suppose)
- Is it here "my code" would get loaded into a external sram? If so, from where does it get loaded into external sram?

It could be SRAM, it could be EPROM, it could even be the FPGA in a programmer simulating a memory. The important point of that line is to say that you need to have a way to get the data you want to write into the EPROM accessible by a program running on the MCU itself. That program then follows the steps outlined in the datasheet and shown in the example source code listing to write each byte into the EPROM.

Apparently some Needhams programmers can program these, so there must also be a parallel programming method. You might want to research that as well just in case. This is hearsay, so keep that in mind.

I'm pretty sure the "parallel programming method" involves the programmer feeding the chip instructions and data to "self-program". If there was a simpler "EPROM-ish" mode then Motorola would've likely documented that.

[bytestorm]

I am super grateful that I have gotten so much response and tips in this thread.. I would love to learn how to do this so I really dont mind spending time trying to understand it, so I will carry on.

Tonight when the kid is asleep I will try to consolidate all the great info I have gotten from you all and I must be able to get how its working!
I am suprised no one used probug, since I thought it was mandatory from reading the docs, but they prolly just put it that way so ppl should use it

Anyway, a big thank you to all who took Their time to help me.. Thanks!!

[Mrozkey]

Hello,

the complete MC68701 programmer was described (along with proper firmware) in the old Byte Magazine (Vol. 7, No. 8, 1982)

https://archive.org/details/byte-magazine-1982-08

Authors are from Motorla company.

Hope it helps,
Adam

[grantb5]

I attempted to extract, PDF and OCR the article in question. Not sure if it will attach or not, but the file is 8 pages and 5MB rather than the original 513 pages and 479MB.

Rats. Too large 5MB > 2MB allowed.

[bytestorm]

Hello,

the complete MC68701 programmer was described (along with proper firmware) in the old Byte Magazine (Vol. 7, No. 8, 1982)

https://archive.org/details/byte-magazine-1982-08

Authors are from Motorla company.

Hope it helps,
Adam

Wow that was a big one . Will check it tonight! Thanks

[bytestorm]

Strange I didnt get any email that there were new posts in the thread 

[bytestorm]

Hello,

the complete MC68701 programmer was described (along with proper firmware) in the old Byte Magazine (Vol. 7, No. 8, 1982)

https://archive.org/details/byte-magazine-1982-08

Authors are from Motorla company.

Hope it helps,
Adam

It really made it much more clear now when I revisited this. Especially since this example needs no external computer "monitor" connected.
My only gripe is how can I change the adress for these 4 values in the compiled PROBUG.s19 (or any of the examples) to make the full 4k file to be burned instead of just 2k that this program is designed for?

There are some adresses that needs to be changed to adopt the program for the 68701U4, since the areas inside differs.

IMBEG - start of memory block
IMEND - last byte of memory block
PNTR - first byte to be programmed
WAIT - counter value

I found a *.s19 editor but it only gives me all bytes in long rows. Its difficult to see where to change.

The other option is to copy the program found in the mega pdf linked which seems awesome . But I have no clue how to write the code in that way or compile it.
Code is structured in such way that it looks like its been printed in excel almost..

And if someone would be so kind to explain how the code is built up in this? what is what in a row like this for example? Will it all be included in the compiled file or can i just ignore some of the text as comments?

00027A   B850   8E   00FF   A   START   LDS   #$FF   INITIALIZE STACK

what here is actual code? and what can be ignored?

Thanks in advance .

I havent given up on this, just took a break and renovated my house some more to come back with fresh eyes.. I must succeed

[grantb5]

You are looking at a .LST (list) file. The .SRC (source file, more likely .ASM) is what you input. The assembler takes the source files and creates the list file for the author and the .S19 file for the programmer hardware device.

.ASM/.SRC are the same as every assembler, although the syntax can vary:

Label    Opcode Operand Comment
START   LDS   #$FF        INITIALIZE STACK

You need to do some home work here. But in any event Labels are used as decided by the programmer, "Opcodes" are the instruction mnemonics, the Operands is the argument for the "Opcode" and the Comment is just that.  The Operand could be a number expressed as hex, binary, decimal, etc or it may be a label representing said number or it may be an address (like in BASIC). Comments are often preceeded by a semi-colon for most assemblers.

The stuff you see before that on the line are generated by the assembler and represent usually Line Number, Address (AKA location counter), actual opcodes that go in the .S19 "hex" file and then the source line from your input ifle.

[bytestorm]

You are looking at a .LST (list) file. The .SRC (source file, more likely .ASM) is what you input. The assembler takes the source files and creates the list file for the author and the .S19 file for the programmer hardware device.

.ASM/.SRC are the same as every assembler, although the syntax can vary:

Label    Opcode Operand Comment
START   LDS   #$FF        INITIALIZE STACK

You need to do some home work here. But in any event Labels are used as decided by the programmer, "Opcodes" are the instruction mnemonics, the Operands is the argument for the "Opcode" and the Comment is just that.  The Operand could be a number expressed as hex, binary, decimal, etc or it may be a label representing said number or it may be an address (like in BASIC). Comments are often preceeded by a semi-colon for most assemblers.

The stuff you see before that on the line are generated by the assembler and represent usually Line Number, Address (AKA location counter), actual opcodes that go in the .S19 "hex" file and then the source line from your input ifle.

wow this keeps kicking me in the n*ts.. that basically means that I cant change the probug.s19 file to use the memory areas of the 68701U4 instead of the regular 68701? just when I thought it couldnt get any more complicated...

[grantb5]

You can modify bytes in an S19 file, but you need to be careful and recalculate the line checksums (assuming the programming method you use does anything with them).

The .S19 file is pretty well documented.

Not sure what you are proposing will actually work though.

[bytestorm]

You can modify bytes in an S19 file, but you need to be careful and recalculate the line checksums (assuming the programming method you use does anything with them).

The .S19 file is pretty well documented.

Not sure what you are proposing will actually work though.

Yeah I found out that its quite well documented but I have yet to understand how the actual breakdown works to try ans "see" where the values are that I need to change.
I have no idea If what I am trying to do will actually work, but its fun to try and learn and I think it should work... as I am only changing the adress area of the internal eprom.. *should work*
If only i could find it in the s19 file that is

[bytestorm]

Well, after weeks of searching and trying to modify the s19 format, I must say that I am getting close to give up. 
Since the PRObug software isnt made the same as the LST example i have in one of the books, then I cant find where to edit the adresses.

If I could just find and edit the places in the s19 file (probug) then I am sure it would work... but I just keep finding hurdle after hurdle.
Trying to rewrite the "programming" program myself is way out of my league. Dont know which programs to use or even get them to run on my pc, not to mention i dont know assembly programming at all.

Man this was frustratingly difficult !! just because the only examples is for 68701 and they will not work unless modified grrrrr 

Since I must use a edited probug OR write the whole programming program myself and compile it somehow, this seems impossible.
I was hoping to find a way but since these 2 options are the only ones availible, then I dont know.. all programmers supporting this chip is obsolete and not to mention even the adapter needed for the 68701u4 is unobtainium.

Data I/O company could probably help me according to the staff but the cost started at 75.000$.... without the adapter......

I have attached the LST file decoded from Codewarrior, and in that one I can see all s19 data... BUT the given areas where the programming is supposed to happen, cant be found.. so I have no clue where to edit in the new adress arean for external and internal eprom

[grantb5]

One thing you can do for one of those steps is to download *any* EPROM programmer software, load the S19 file into it, edit the file in the binary and then save it back as an S19 file. These problems you face are typical of dealing with 30 or 40 year old technology.

[bytestorm]

One thing you can do for one of those steps is to download *any* EPROM programmer software, load the S19 file into it, edit the file in the binary and then save it back as an S19 file. These problems you face are typical of dealing with 30 or 40 year old technology.

Yeah thats what I thought, since I know which need to be changed.. but when I search for them using a hexeditor och *.s19 decoder, I cant find them... :/. I was sure that I would find the adress areas for the external eprom for example.. since they are known, but nope . hence my confusion

[amyk]

If I could just find and edit the places in the s19 file (probug) then I am sure it would work... but I just keep finding hurdle after hurdle.
Trying to rewrite the "programming" program myself is way out of my league. Dont know which programs to use or even get them to run on my pc, not to mention i dont know assembly programming at all.

Now would be a good time to learn... given that you actually have a goal you can work towards.

I recommend reading the PRObug listing or source code, and see if you can understand what the program is doing. As I mentioned previously, other 6800-family documentation will be very useful for this. Once you understand how it works, only then will you be able to successfully modify it.

[bytestorm]

If I could just find and edit the places in the s19 file (probug) then I am sure it would work... but I just keep finding hurdle after hurdle.
Trying to rewrite the "programming" program myself is way out of my league. Dont know which programs to use or even get them to run on my pc, not to mention i dont know assembly programming at all.

Now would be a good time to learn... given that you actually have a goal you can work towards.

I recommend reading the PRObug listing or source code, and see if you can understand what the program is doing. As I mentioned previously, other 6800-family documentation will be very useful for this. Once you understand how it works, only then will you be able to successfully modify it.

Problem is that I dont have the PRObug listing/source code.. I thought that the actual code was in one of the books linked here, but that is just an example of how it can be done in listing format only (I also thought this was sourcecode). Hence why I never could follow the code when I sat the s19 listing and the example side by side to try and see where to change.

for example the external eprom area is 7800-7FFF, so I was sure that I would find these somewhere in the decoded s19 file, but no .

The PRObug.s19 file was decoded by me using the decoderfunction in Codewarrior 5.2 by NXP, but since the 6801 is not a supported CPU then I only get the decode, no dissassembly. And can I even trust that this decoding is correct?

I mean shouldnt I be able to see the reference to the external eprom in the code? It must be included to work.. I was so sure that I would find those so I had somewhere to start digging from. 

[bytestorm]

Here is a photo to show how I thought I would find some similarities, and maybe find the hard coded memory areas to change.

I know now that the decoded probug and the pdf is not the exact same program, but they should be doing the same things according to the documents.
Or am I totally wrong to compare them like this? (please see the picture)

[bytestorm]

Oh well, I decided to sit down and check the CPU Instructions set for the 6801u4 (and 6800). Thought that if I break it down or reverse it from decoded s19 to assembler it might be easier.

Am I correct so far?

B800   JMP      (7E)   0xB8CD   (Jumps to this adress and do something, then return here and go to next?)
B803   JMP      (7E)   0xB866   (Jumps to this adress and do something, then return here and go to next?)
B806   JMP      (7E)   0xB892   (Jumps to this adress and do something, then return here and go to next?)
B809   JMP      (7E)   0xBAA8   (Jumps to this adress and do something, then return here and go to next?)
B80C   JMP      (7E)   0xBA7C   (Jumps to this adress and do something, then return here and go to next?)
B80F   JMP      (7E)   0xBA79   (Jumps to this adress and do something, then return here and go to next?)
B812   LSRD   (04)         (Shifts all bits of the 16-Bit Double Accumulator D one place to the right.)
B813   *      (42)   ??      (Unassigned Instruction, should not be executed according to manual?)
B814   ADDA   (BB)   39 04   (Add Memory contents from adress 0x3904 into Accumulator A.)
B817   LSRA   (44)         (Shifts all bits of the 8-Bit Accumulator A one place to the right.)

its taken from the very first row in the probug s19

S11BB8007EB8CD7EB8667EB8927EBAA87EBA7C7EBA790442BB390444FE
Type:     S1 (A record containing the 2-bytes address at which the code/data is to reside)
Length:   0x1B
Address:  0xB800
Data:  0xB800   7E B8 CD 7E B8 66 7E B8  - ~??~?f~?
          0xB808   92 7E BA A8 7E BA 7C 7E  - ?~??~?|~
          0xB810   BA 79 04 42 BB 39 04 44  - ?y?B?9?D
CheckSum: 0xFE


that was actually quite fun .. to see how it translates into asm.. considering its not a big file, it wouldnt be an impossible task to translate all... IF I am doing it correct that is.

[Circlotron]

B800   JMP      (7E)   0xB8CD   (Jumps to this adress and do something, then return here and go to next?)

If it were to return and continue, that would be JSR, not JMP.

[bytestorm]

B800   JMP      (7E)   0xB8CD   (Jumps to this adress and do something, then return here and go to next?)

If it were to return and continue, that would be JSR, not JMP.

oh, I see.. hmm lots of jmps in the start of a program? But what do I know, might be perfectly ordinary
I need to do the rest to be able to see how it all connects, but before I do the whole file I would like to just verify that I am doing it the right way?

If an instruction says that it takes for example 3 bytes, like a JMP.. That means including the JMP right? (7E in this case) or is it 7E + 3 bytes? (total 4?)

[joeqsmith]

Ever think about just posting the raw S records? 

[amyk]

If an instruction says that it takes for example 3 bytes, like a JMP.. That means including the JMP right? (7E in this case)

Yes. 1 byte for the opcode, 2 bytes for the operand (in this case, destination address). The instruction format summary tables will show you this.

I posted a link to the probug.s19 on the first page of this thread, but it's not necessarily the same version as in that PDF.