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

[bytestorm]

Hey!

Since the document titled "Self-Programming the MC68701 and the MC68701U4" Motorola. Part: AN906A seems to have become Unobtainium, I thought Id ask here..
(I have even emailed Motorola directly about it)

I need to program a couple of MC68701U4 with a supplied bin file, but I cant find any programmer that handles them.. or they do, but need some unobtainable adapters.
Programming is however described in the datasheet but I would rather avoid constructing a programmer for it, if there is a simpler way.. (would love learn how to make one with the help of maybe a ARM or AVR but aint got time now.. )

Anyone have any idea where I could find this document? Or perhaps knows how to program these ones?

Datasheet:
http://matthieu.benoit.free.fr/cross/data_sheets/MC68701U4.pdf

Thanks in advance!

[amyk]

Note that Motorola is now NXP so perhaps asking them might yield better result.

[bytestorm]

Note that Motorola is now NXP so perhaps asking them might yield better result.

Yeah, already tried. they even started a case for it but didnt find anything ;(

[joeqsmith]

I suspect I have everything you would ever want to know about the 01.  If no one else turns it up, I'll post that section of the document later.   

I designed a bit of test gear around one for the fun of it.  Scan down, you can see one of the programmers I made for it.
https://www.eevblog.com/forum/testgear/hear-kitty-kitty-kitty-nope-not-that-kind-of-cat/350/

[joeqsmith]

Hitachi did make a few CMOS clones of the Motorola parts for a short time.  Their databooks are on-line.  I suspect they will show the basics how to program them but maybe not for your specific part.  It will at least give you some idea what is required while I find the original notes.


https://www.jaapsch.net/psion/pdffiles/hd6301-3_handbook.pdf

[Circlotron]

I remember seeing that technique with HC705 series. Have a look at some of those data sheets or other notes. Might be similar enough in principle to get you going.

[joeqsmith]

Enjoy

[amyk]

These MCUs are programmed basically by running a program from external memory, which then manipulates the internal registers so as to write to the EPROM. This means they can only be "self-programmed".

Here's a (newer?) datasheet on the MC68701 with a more detailed description of the programming algorithm (including source code) as well as the elusive test mode 4: http://pdf.dzsc.com/autoupload/4cbea484-a30f-4eab-a2e8-224414b2d8b3.pdf

This is the "PRObug" ROM monitor that also implements the programming algorithm along with other useful commands:
 http://www.chookfest.net/computers/files/probug.s19

[bytestorm]

Wow thousand thanks for all replies! I will dig into all this later today! The PRObug rom will most certainly help since I could not find it and the manual stated that it was needed.. phew!
Thank you all!!

[bytestorm]

oh my.. that was alot of info . Lots of it is concerning the regular 68701, and not the 68701U4 that I have, but that might be since they are very similar?
I found some more info about this whole programming board and schematics for the APB board for 68701, and I hope that its possible to modify it for the 4Kb eprom in the "U4" compared to the 2k in the regular 68701.

I wonder why they made it so darn complicated to program? .. or maybe its not that difficult, but the instructions are a bit vague.. like the part that you need an external program (probug) to program the internal eprom... but where do I put the code I have that is supposed to be programmed? the 4kb bin file that I am hoping to program into the 68701u4.. ??

I will check the book with the schematics tonight for some clarification. If some one is interested, it starts from page 204 in this book!
https://ia800205.us.archive.org/0/items/Motorola-SeminarsandApplicationBooksMCUandMPUApplicationsManualOCR/Motorola-SeminarsandApplicationBooksMCUandMPUApplicationsManualOCR.pdf

would love to find a newer copy since there is a possibility that newer versions would cover the 68701u4 specifics maybe.

Thanks again all!! and please give your comments if any.

[amyk]

The U4 is very similar to the non-U4, just with more memory.

It is up to you how you get the code to it, the point is that the MCU will run code from external RAM/ROM, and you can make it run code that programs its EPROM. It could accept bytes from the serial port, one of the parallel ports, or even just read from some other memory mapped into the external address space (including the code to do the programming itself!)

[bytestorm]

The U4 is very similar to the non-U4, just with more memory.

It is up to you how you get the code to it, the point is that the MCU will run code from external RAM/ROM, and you can make it run code that programs its EPROM. It could accept bytes from the serial port, one of the parallel ports, or even just read from some other memory mapped into the external address space (including the code to do the programming itself!)

I was hoping to find some clear info about when it actually starts programming itself. There are lots of info about putting it into different modes and such, but its unclear to me when it actually starts to read the data and program its own eprom section with it.. I just cant seem to understand how the data will be sent to it.

Perhapps i will have options in the PRObug terminal window when its actually running?

The best would be if it was able to program itself from a set memory space in a external eprom, into its own eprom area.. but I cant see how that process would be "started"

is it me or is the process explained vaguely in the book?

Thanks!

[grantb5]

I've used the 68705P3 before and it's pretty well documented on the web. Maybe there are some ideas or hints there? I don't know your part but it sounds like an EPROM version of the 6801, is that right? I think I have some old databooks that cover this era somewhere. And there were always pretty much second sources back then so a "competitor" databook might help as well. I haven't been able to find my MC68705P3 hardware ... hmmm...

[joeqsmith]

The U4 is very similar to the non-U4, just with more memory.

It is up to you how you get the code to it, the point is that the MCU will run code from external RAM/ROM, and you can make it run code that programs its EPROM. It could accept bytes from the serial port, one of the parallel ports, or even just read from some other memory mapped into the external address space (including the code to do the programming itself!)

I was hoping to find some clear info about when it actually starts programming itself. There are lots of info about putting it into different modes and such, but its unclear to me when it actually starts to read the data and program its own eprom section with it.. I just cant seem to understand how the data will be sent to it.

Perhapps i will have options in the PRObug terminal window when its actually running?

The best would be if it was able to program itself from a set memory space in a external eprom, into its own eprom area.. but I cant see how that process would be "started"

is it me or is the process explained vaguely in the book?

Thanks!

What you are suggesting with the external EPROM is basically how it's normally done.   I thought the source code was fairly simple to follow.  Mine is a bit more fancy with an LCD display.   I started with that and modified it.  The software resides in an external EPROM in my case.  I am using a dual ported memory to emulate a PROM which gets plugged into my standard EPROM programmer.  Once the dual port memory is programmed with the image, I load it into the 01.   Still the idea is the same.   I assume you read those pages I collected for you. 

Why do you need to program these old devices?  Just curious what would even be using them today.   

[bytestorm]

Thanks!
[/quote]
What you are suggesting with the external EPROM is basically how it's normally done.   I thought the source code was fairly simple to follow.  Mine is a bit more fancy with an LCD display.   I started with that and modified it.  The software resides in an external EPROM in my case.  I am using a dual ported memory to emulate a PROM which gets plugged into my standard EPROM programmer.  Once the dual port memory is programmed with the image, I load it into the 01.   Still the idea is the same.   I assume you read those pages I collected for you. 

Why do you need to program these old devices?  Just curious what would even be using them today.
[/quote]

Yes I have read the source you sent me several times but I cant seem to get it :/. I have never worked with this types before..
I understand how to make reads and writes to simple sram and flash/eproms, but I cant get my head around this one .

In which external memory space would I put the PRObug? And if I could have my 4k code in a area at the same time, which would that be?

Sorry for all these noob questions that probably are really simple once you understand, but right now its a bit messy for me.

I want to replace a MCU in an arcade game

Thanks for your time

[joeqsmith]

Yes I have read the source you sent me several times but I cant seem to get it :/. I have never worked with this types before..
I understand how to make reads and writes to simple sram and flash/eproms, but I cant get my head around this one .

In which external memory space would I put the PRObug? And if I could have my 4k code in a area at the same time, which would that be?

Sorry for all these noob questions that probably are really simple once you understand, but right now its a bit messy for me.

I want to replace a MCU in an arcade game

Thanks for your time

You know, if you have a micro you like, you could perhaps make an adapter to drive the game with a new micro.   The 01 was a workhorse of the industry in it's time but doesn't have much going for it compared with the lowest end modern micros.  Ditch the assembler code.   

Figure E-4 shows the memory map.   Section E.4 explains the process.   Looking at the assembler listing, 00078A  ORG $3000  where is states "EPROM STARTS HERE"  is where they have mapped this code.  From Fig E-4, we can see $3000 fall between $00FF and $BFF0 which marked "External Memory Space".    Of course, we can see in E.2.2 that the vectors are remapped for Mode 0.  Obviously they need to be or we wouldn't have access to set them.  If it's not clear, the external EPROM will contain these vectors.  Reset for example will need to point to your main section of code.   

Something like:
INTVEC    EQU  $BFF0          VECTOR TABLE

INVALID_IRQ    RTI            EXIT

          ORG  INTVEC
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  RESET           
          END

Where RESET is the pointer to your startup code.

The routine in the listing is called from your main program.   The header in the listing explains what you need to pass to it when making the call.   Figure E-4 shows the internal EPROM residing at $F800.  This is obviously for the 2K device and you would need to change this for the 4K device to $4000.   

It's not too difficult really.  6800 has a fair number of instructions.  Do you have the tools needed to build the code?  Assembler, linker and such? 

[bytestorm]

You know, if you have a micro you like, you could perhaps make an adapter to drive the game with a new micro.   The 01 was a workhorse of the industry in it's time but doesn't have much going for it compared with the lowest end modern micros.  Ditch the assembler code.   

Figure E-4 shows the memory map.   Section E.4 explains the process.   Looking at the assembler listing, 00078A  ORG $3000  where is states "EPROM STARTS HERE"  is where they have mapped this code.  From Fig E-4, we can see $3000 fall between $00FF and $BFF0 which marked "External Memory Space".    Of course, we can see in E.2.2 that the vectors are remapped for Mode 0.  Obviously they need to be or we wouldn't have access to set them.  If it's not clear, the external EPROM will contain these vectors.  Reset for example will need to point to your main section of code.   

Something like:
INTVEC    EQU  $BFF0          VECTOR TABLE

INVALID_IRQ    RTI            EXIT

          ORG  INTVEC
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  INVALID_IRQ
          FDB  RESET           
          END

Where RESET is the pointer to your startup code.

The routine in the listing is called from your main program.   The header in the listing explains what you need to pass to it when making the call.   Figure E-4 shows the internal EPROM residing at $F800.  This is obviously for the 2K device and you would need to change this for the 4K device to $4000.   

It's not too difficult really.  6800 has a fair number of instructions.  Do you have the tools needed to build the code?  Assembler, linker and such?

mm.. best would be to implement it into verilog and us a fpga (or micro).. would be awesome but skillwise I am faaar from that.. I have some dev boards but to make a 6801u4 in verilog would be way over my head. To use a micro on the other hand would require me to dissassemble the 4k binary I have and somehow implement that into a micro..

since I dont have the source, only the compiled 4k bin for the 68701u4, I might be in bigger trouble than I anticipated

So the 68701 is actually not programmed like I originally thought.. It actually needs the source asm code, and not the actual compiled binary? then I would need to somehow dissassemble the 4k binary and put that into the codesnippet..

aaah... I need to re-read the manuals and docs. Its quite frustrating reading the text that abviously explains it in detail, and dont "getting" how it works

[amyk]

I think you're very confused about how the programming process works.

These MCUs can run code from external or internal memory.

Programming the EPROM is accomplished by running code that manipulates registers on the MCU which control the EPROM.

If you boot it from an external memory, then you can make it run the code you want, code which programs the EPROM.

[joeqsmith]

If you are writing the code to perform the programming of the internal memory, you will need the tools.   

You don't need to disassemble the arcade game's binary and rebuild it just to program the part.   

My comment about replacing the 01 was suggesting you write your own software from scratch for the arcade game using a different micro.  I am not suggesting that you would disassemble the binary you have and port it.  That's a bit too boring. 

If you have the full schematics and assembled code, you would be all set.  Obviously, that's not what I sent you.   I haven't looked through any of the other posts but maybe they have what you need.  In my case, I just went with the notes, wrote my own code and built the hardware.

Another option as I showed in that link is to try and find an old Hitachi part.  Maybe you could find another game with the micro preloaded with what you want.

[bytestorm]

I think you're very confused about how the programming process works.

Yes, that is absolutely correct

These MCUs can run code from external or internal memory.

Yes I know.

Programming the EPROM is accomplished by running code that manipulates registers on the MCU which control the EPROM.

Yes, I know this too..

If you boot it from an external memory, then you can make it run the code you want, code which programs the EPROM.

This is where I am lost.. I dont understand HOW to run "my code" or where to put it and how to make it start the programming process so that my 4k binary actually gets into the eprom.

This is where I fail to follow somehow ..

I need my 68701u4, set to mode 0, make it start run the code in the PRObug eprom, which needs to contain "my code" somehow, or if PRObug needs to direct yet another eprom containing "my code" to get that 3rd one to somehow get the code into the epromarea................. or something. I havent had time to reread the docs again, but I will asap.

the more I try to understand to further away from actually understanding it I get :/.

To make a micro behave exactly like this MCU then I would need a full understanding of what the compiled program actually do? (which I dont, since I only have the binary.)

Sigh.. maybe this was a bad idea from the start.. aint got no linker or assembler tool either. Was just hoping it would be easy to get that darn 4k bin file into the eprom area

[grantb5]

I think the manufacturer information is out there. This datasheet explains self programming at the end:

http://pdf.datasheetcatalog.com/datasheets2/46/4637908_1.pdf

Here is another snippet.

https://www.edaboard.com/showthread.php?258453-how-to-copy-motorola-s-MC68701-mcu

Apologies if this is known already.

[joeqsmith]

It may help to know what level of education do you have?  Do you have any formal education with embedded designs?  Background?   If this is your first look at assembler and you have never built anything with a microcontroller, it would make sense what you are describing and perhaps we can try to simplify things for you. 

I am sure I could supply you with the tools you would need to assemble the code if you decide to write your own programming software.   I have never used the canned tool that was linked but you may be able to find a manual for it that would explain how it needs to be mapped.   

This is where I am lost.. I dont understand HOW to run "my code" or where to put it and how to make it start the programming process so that my 4k binary actually gets into the eprom.

This is where I fail to follow somehow ..

As I mentioned, your code is pointed to by the reset vector.  When you reset the micro, it will start to run your program.   Once the device is programmed, the mode is changed and the reset vector will now point to the arcade game's code.  The mode pins are the key....   

[bytestorm]

It may help to know what level of education do you have?  Do you have any formal education with embedded designs?  Background?   If this is your first look at assembler and you have never built anything with a microcontroller, it would make sense what you are describing and perhaps we can try to simplify things for you. 

I am sure I could supply you with the tools you would need to assemble the code if you decide to write your own programming software.   I have never used the canned tool that was linked but you may be able to find a manual for it that would explain how it needs to be mapped.   

As I mentioned, your code is pointed to by the reset vector.  When you reset the micro, it will start to run your program.   Once the device is programmed, the mode is changed and the reset vector will now point to the arcade game's code.  The mode pins are the key....

I have no formal education with embedded designs, just used some smaller avr for simple projects, for example to read and write to/from memories and sram, and displaying the data at the given adress on a small display. (in C++). I had hoped to get away with some similar simple bitbanging.
No experience with assembler, apart from the lessons described here: http://www.z80.info/lesson1.htm but never really worked with it.

From the schematics in the book on the other hand I can design the PCB and make it, no problem.

[joeqsmith]

This helps.  I wonder in your case if there is a company who offers programming them as a service.  It sounds like it's a one time deal anyway and to be honest, I really don't see where learning about the 01 is going to help you going forward.  It's just such old technology. 

Do you ow understand the mode selection, vector tables and how they are used to run the programs?

[bytestorm]

This helps.  I wonder in your case if there is a company who offers programming them as a service.  It sounds like it's a one time deal anyway and to be honest, I really don't see where learning about the 01 is going to help you going forward.  It's just such old technology. 

Do you ow understand the mode selection, vector tables and how they are used to run the programs?

I hoped to be able to solve this since its 10 units I want to program.. but in worst case. (probably would cost more than I am willing to spend thou..)

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?

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)

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?

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?

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

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?

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

e. Repeat steps b through d for each byte to be programmed.
- Will the counter increment automatically?

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

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

[bytestorm]

Ever think about just posting the raw S records?

of course, here it is, full raw PRObug S records. Its not that big actually.. Or I could try and learn assembly for the 680x but seems to be difficult to find usable software in win10 to compile it for the 6801..

S11BB8007EB8CD7EB8667EB8927EBAA87EBA7C7EBA790442BB390444FE
S11BB818BC660447BB64044CBD49044DB9FB054D56BF2F044FBA530433
S11BB83050BD1B0452BABF054849B8C0054859B8C80454BB870456BD20
S11BB8485A074348434BBE120750524F47BE800756455246BF4707587E
S11BB86054414CBF73FE378D1224FC847F27F8817F27F4D6FF26028DFE
S11BB878193339961148250348240396120D3937D611C52027FA9713ED
S11BB8903339378DF2D6FF2602D6E6810D2708811027EDC40320025422
S11BB8A8545A2BE4364F8DD73220F6CEBFA3BDBAA8CE411B0926FD39B8
S11BB8C0CC4F0697E6D71039CC000520F68E00C69FF5CE00F76F0008A3
S11BB8D88C010026F8CC10078DE1860A97118DCBCEBFADBDBAAF86D012
S11BB8F097F4CEEFEADFDB7C00088E00DA7F00FFBDBAB3862BBDB89204
S11BB908BDB9A925ED270ABDB99C25E6CEB9FF206CCEBB82812E27654C
S11BB920CEBA48812F275E9FE27F00E18D5D27137C00E136308C009022
S11BB9382F23BDB9A92524261C20E997E7CEB812DFE4DEE43CE6003AF7
S11BB950DFE4C003D1E1270D38C1FB26EDCEBFABBDBAAF2095DEE2DFB6
S11BB968EA3808A6003CDEEAA10027033820D309DFEA5A26EC38089EDD
S11BB980E2EE0096E7AD0025D420D8812C270A81202706810D270281DC
S11BB9982D398D11230AC1042F397D00ED27340D39C6F020015FCE0026
S11BB9B000DFEADFECCE00EA8D252517C6046801690024037C00ED5ABB
S11BB9C826F4AA01A7017C00EC20E5811826020D39DEEAD6EC0C39BDF6
S11BB9E0B86681302BF181392F0D5D2BEA81412BE681462EE280078443
S11BB9F80F5F398D9D2F52DEEA812F2704812026488D77DFE83C5F8D3C
S11BBA109C38253E2707D6EBBDBA982535810D2731812C26030820E3C4
S11BBA28812026030820DA810A260608BDBAB7200D815E2603092004E7
S11BBA40812F260D8D6DDFE8CE00E88D2CDEE820B80D39BDBD0325F958
S11BBA58DCEA83000193E8C17F22054D270620E981FF26E5D7EC8D4305
S11BBA70CE00EC8D078D3C20CF8D07088D048620203AA600368D0332E9
S11BBA88200444444444840F8B90198940192024E700E10027B4CEBF51
S11BBAA0B88D0C20AC8D1508A600810426F7398D0220F5860A8D0586F6
S11BBAB80D8D014F7EB8928D668DF0CE00EE5F3CCEBFD23AA6008D62CB
S11BBAD0A601387D00E1270B4D27038DA5088D9C082004378D0833CB1B
S11BBAE802C10C26DA39363CBDB9AD3833251B271DBDB98B26145D27F7
S11BBB000936DCEAED0032082004D6EBE700810D261338334F398120D6
S11BBB1826F85D2605BDBA7C2003BDBA7908398D8A7C00E18D957F000F
S11BBB30E1398D02862D7EB892810D270F812D2716BDB99A230F810D56
S11BBB48260BDFF7BDBAB3CE00F77EBA790D39BDB866810D26F74F5FC0
S11BBB60DDF720E8810D270EBDB99A23E8810D26E47F00FDDFEEBDBAB7
S11BBB78B396FD2603BDBC2A2015CE00012009810D27F7BDB9AD2FC5AF
S11BBB90DFFB27C17C00FD2048C618DE093ADF0B397C00088DF3308E12
S11BBBA800DA8D56BDBC1ADEFB26097F00FD8D72251D202509DFFB261E
S11BBBC0037F00FDCE0000BDBCEE27F1CEBFCEBDBAAFDEEABDBA7CBDA4
S11BBBD8BB2996FD26037EB8FA9EF5DEEE3CDEF03CDCF2363796F436E1
S11BBBF096FD270DDEEEDFEA860297017A00088D983BA60097F4EC01BD
S11BBC0897F3D7F2EC03DDF0EC05DDEEC6063ADFF53996FA270B96F9F1
S11BBC20DEF72702A7007F00FA3996FA265CDEF7270DA600C63FBDBA74
S11BBC3898250497F997FA39308E00DA8DBCDEEE09DFEEDFEA96FA27D2
S11BBC50098DC79CEA26034C20044F5FDDFB97FDBDBB277EB8FADEE8AD
S11BBC683C810D270A8D7C2316DFE8810D2615DCE8C4F0830010DDE823
S11BBC80C30020DDEA201938DFE80D398D5D23F7DCE8C4F0D7E993EAC7
S11BBC9822ED96EB84F097EBBDBAB38D49260538DFE84F39BDBAB3CE60
S11BBCB000E8BDBA79DEE8C610BDBA7C085A26F9BDBA7EC610DEE8A659
S11BBCC800847F81202D0481612D02862EBDB892085A26EBDCEA93E80B
S11BBCE027C5DFE87D00E926BA20B57EB99A36BDB87B847F81172607BB
S11BBCF8BDB87B24FB847F81183239810D27128DE2230EDFE8810D2737
S11BBD10088DD82304810D27010D397F00E78DE325F8BDBAB38610973D
S11BBD28FF4CD6E726014CBDB892BDBD5E4636CEBFA8BDB8B6BDBCEE62
S11BBD40BDBCEE7F00FF324939C601D7E7CE0000DFEA810D27CC8DB96B
S11BBD5820C8C6FF20ED5D2758DCEADDE8BDB866815326F9BDB8668184
S11BBD70392731813126F17F00E18D29C002D7EC8D23378D2032D3E841
S11BBD883736388D187A00EC270E7D00E72B02E700E10026060820EB22
S11BBDA04C27C20D395FBDB9DFC6103D375FBDB9DF331B169BE197E102
S11BBDB839C6194FBDB8925A26F9DCEAD0E992E82604C1182502C61788
S11BBDD0CB04D7E7C003D7ECCEBFBFBDBAAF5FCE00E78D29CE00E88DC5
S11BBDE824088D21DEE88D1D087A00EC26F8DFE85337308D1033DEE852
S11BBE00099CEA26BDCEBFC2BDBAAF4F39EB007EBA82810D2773BDBD70
S11BBE18039CE8256CCCFF869714D7ECDEE80908E60027054F8D0F273C
S11BBE30089CEA26F27F00FE397F00FE0D3936373CD6EC2A08CEBFEAC3
S11BBE48BDBAAFC40F2605C606BDBAB330BDBA7908BDBA82862FBDB879
S11BBE609208BDBA7CBDBA7E5A38D7EC3332BDBCEE39CEBFE43CBDBAC6
S11BBE78AFBDB86638815939810D2705BDBF0624020D39BDBE1DD6ECD7
S11BBE902B07CEBFDE8DDE26F08DD726EC86FE9714DEE83CDEDD093CD1
S11BBEA8389CDF26137D00FE2B8338DFE88DBB27FC814E26F87EBF4F86
S11BBEC008A6003CDEE87D00FE2B1AA70086FC97149608DCDBD309DD14
S11BBED80B9608844027FA86FE9714200DE600112708BDBE3E26033824
S11BBEF020BB08DFE820B1BDB99A2F8DDFDD810D2787BDBD03398DEFC5
S11BBF08250EDCE8DDDF81F82406DFE893DD24037EBE89D3E825F9DDEE
S11BBF20EADCDD81F824F196E881F825EB0C398DC625E5DEDD0908A6B9
S11BBF38003CDEEAA70008DFEA389CE826F039810D27528DB9254ECCDA
S11BBF50FF869714D7ECD7FE7EBEA4302920322E3435202031292034FD
S11BBF682E39310D0A5854414C3D04CEBF5BBDBAAF8630D6DBC17727C0
S11BBF80014CBDB892BDBA7EBDB866810D2712CE77EA80302709CEEFEE
S11BBF98EA810127020D39DFDB0C39103A1039041413043F0450524FBD
S11BBFB042554720312E30044E4F20434847045331045339303330307A
S11BBFC8303046430D044F502D04500158014100420043005301434844
S11BBFE0473F20045057523F2004414452204550522F56414C0D0A0434
S10BBFF8009ABC40BBA1B80093
S9030000FC

[bytestorm]

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.

Yeah I realised that after a while... haha  . I was so busy to try and understand it that it didnt occur to me that they could actually be 2 different programs.. and they were.. lol

But nevertheless I thought that I atleast should be able to find the adresses since they are fixed... but that didnt turn out so well.

[Circlotron]

Or I could try and learn assembly for the 680x but seems to be difficult to find usable software in win10 to compile it for the 6801..

I think any 8 bit 68xx assembler would do the job. The assembly language listing contains absolute addresses and so as long as you know where your config and IO registers are, where ram starts, where eprom starts, where the vector table is, you should be right. It's all in the data sheet. Only the list file that is optionally produced will be wrong because it may not show the correct amount of cycles for each instruction. The S19 file should be just fine.

ICS08JLZ from P&E Micro is free and should do the trick

http://www.pemicro.com/support/download_processor.cfm?type=2

[bytestorm]

Or I could try and learn assembly for the 680x but seems to be difficult to find usable software in win10 to compile it for the 6801..

I think any 8 bit 68xx assembler would do the job. The assembly language listing contains absolute addresses and so as long as you know where your config and IO registers are, where ram starts, where eprom starts, where the vector table is, you should be right. It's all in the data sheet. Only the list file that is optionally produced will be wrong because it may not show the correct amount of cycles for each instruction. The S19 file should be just fine.

ICS08JLZ from P&E Micro is free and should do the trick

http://www.pemicro.com/support/download_processor.cfm?type=2

Ah, so the compiler itself doesnt need to support the cpu, only if I try to dissassemble a made file? hmm.. cant run the software, just crashes with an error saying need to set %FILE% ?
Well, I might find something else, as long as it doesnt need to be a specific 6801 asm compiler?

[Circlotron]

You might have to run the programming (and installation) software in WinNT or Win98 compatibility mode. It’s pretty old.

[grantb5]

There are lots of assemblers available. And disassemblers too, but I think doing it by hand, at least for a while is good experience.

The JMP's you see are probably a jump table for various commands or some condition. No doubt the address of the first JMP will appear later in the program.  The bytes after the JMP table look like they may be something other than just executable code. It could be parameters for the JMP commands you typed. If you look it seems there might be a pattern:

04 42 BB 39
04 44 BC 66
04 47 BB 64
04 4C BD 49
04 4D B9 FB
05 4D 56 BF 2F
04 4F BA 53
04 ...

Hard to say what's going on here, but isn't the source code available?  These could be addresses of strings that go with the JMPs or something?  One nice thing about loading the S19 file into an EPROM programmer is that the ASCII text becomes obvious.

[joeqsmith]

Sorry, I wasn't following along close enough.  I assumed you would have built the programmer shown in Byte and used that code they provided to program your parts.   I wasn't thinking you were still looking at the debugger.   

If the goal is still just to program a few parts, what do you need the debugger for? 

[bytestorm]

There are lots of assemblers available. And disassemblers too, but I think doing it by hand, at least for a while is good experience.

The JMP's you see are probably a jump table for various commands or some condition. No doubt the address of the first JMP will appear later in the program.  The bytes after the JMP table look like they may be something other than just executable code. It could be parameters for the JMP commands you typed. If you look it seems there might be a pattern:

04 42 BB 39
04 44 BC 66
04 47 BB 64
04 4C BD 49
04 4D B9 FB
05 4D 56 BF 2F
04 4F BA 53
04 ...

Hard to say what's going on here, but isn't the source code available?  These could be addresses of strings that go with the JMPs or something?  One nice thing about loading the S19 file into an EPROM programmer is that the ASCII text becomes obvious.

ah thats true... I need to read some more about JMP and following bytes. See what they could be..
No, the source code for the PRObug.s19 is nowhere to be found.. the best I got so far was a article from a magazine that have the listing for a "similar" program.

[bytestorm]

Sorry, I wasn't following along close enough.  I assumed you would have built the programmer shown in Byte and used that code they provided to program your parts.   I wasn't thinking you were still looking at the debugger.   

If the goal is still just to program a few parts, what do you need the debugger for?

No I didnt build it yet in case I never find a suitable way of actually programming it... I am still stuck at how to modify the PRObug or that other program to actually work with the 68701u4.. the only availible one only works with the regular 68701.. but the U4 part has double the eprom area, and I need to somehow modify the PRObug code OR the code in Byte to program the 68701U4 instead of the 68701.

It was more difficult than I ever imagined hahaha... just to modify 3 places in the PRObug code... but I cant for the life of me find the known ones in the program as it is now.

I dont need any debugger, just program some parts

[joeqsmith]

Sorry, I wasn't following along close enough.  I assumed you would have built the programmer shown in Byte and used that code they provided to program your parts.   I wasn't thinking you were still looking at the debugger.   

If the goal is still just to program a few parts, what do you need the debugger for?

No I didnt build it yet in case I never find a suitable way of actually programming it... I am still stuck at how to modify the PRObug or that other program to actually work with the 68701u4.. the only availible one only works with the regular 68701.. but the U4 part has double the eprom area, and I need to somehow modify the PRObug code OR the code in Byte to program the 68701U4 instead of the 68701.

It was more difficult than I ever imagined hahaha... just to modify 3 places in the PRObug code... but I cant for the life of me find the known ones in the program as it is now.

I dont need any debugger, just program some parts

I figured you would just change the couple of pointers in the Byte source and assemble it.   If I had a couple of U4 parts, I would give it a try for you.

[bytestorm]

Sorry, I wasn't following along close enough.  I assumed you would have built the programmer shown in Byte and used that code they provided to program your parts.   I wasn't thinking you were still looking at the debugger.   

If the goal is still just to program a few parts, what do you need the debugger for?

No I didnt build it yet in case I never find a suitable way of actually programming it... I am still stuck at how to modify the PRObug or that other program to actually work with the 68701u4.. the only availible one only works with the regular 68701.. but the U4 part has double the eprom area, and I need to somehow modify the PRObug code OR the code in Byte to program the 68701U4 instead of the 68701.

It was more difficult than I ever imagined hahaha... just to modify 3 places in the PRObug code... but I cant for the life of me find the known ones in the program as it is now.

I dont need any debugger, just program some parts

I figured you would just change the couple of pointers in the Byte source and assemble it.   If I had a couple of U4 parts, I would give it a try for you.

Thats what I am hoping to find... I know what I need to change, and I know what is should be written there now... but as I said, I cant see it in the file.. I can not find the places to change the external and internal eprom areas. external eprom is fixed at 7800-7FFF för example as mentioned before. But I can not find any references to that in the s19 file. And thats the only source I have..

I dont know if you mean that I could copy the LIST file in the byte magazine? thats not the source asm, if I understand correct.. I dont even have any software that is working in win 10 to compile at the moment even if I had the asm

[bytestorm]

the text in the byte magazine looks like this:

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

can I just copy the raw code part and compile that?

B850   8E   00FF

or would I write like this?

LDS   #$FF

[joeqsmith]

Sorry, I wasn't following along close enough.  I assumed you would have built the programmer shown in Byte and used that code they provided to program your parts.   I wasn't thinking you were still looking at the debugger.   

If the goal is still just to program a few parts, what do you need the debugger for?

No I didnt build it yet in case I never find a suitable way of actually programming it... I am still stuck at how to modify the PRObug or that other program to actually work with the 68701u4.. the only availible one only works with the regular 68701.. but the U4 part has double the eprom area, and I need to somehow modify the PRObug code OR the code in Byte to program the 68701U4 instead of the 68701.

It was more difficult than I ever imagined hahaha... just to modify 3 places in the PRObug code... but I cant for the life of me find the known ones in the program as it is now.

I dont need any debugger, just program some parts

I figured you would just change the couple of pointers in the Byte source and assemble it.   If I had a couple of U4 parts, I would give it a try for you.

Thats what I am hoping to find... I know what I need to change, and I know what is should be written there now... but as I said, I cant see it in the file.. I can not find the places to change the external and internal eprom areas. external eprom is fixed at 7800-7FFF för example as mentioned before. But I can not find any references to that in the s19 file. And thats the only source I have..

I dont know if you mean that I could copy the LIST file in the byte magazine? thats not the source asm, if I understand correct.. I dont even have any software that is working in win 10 to compile at the moment even if I had the asm

The list is pretty much the source.  It just includes more data as it's been assembled.   Yes, I am saying type that back in, change the pointers and reassemble it.  You will need to setup DOSBOX to get the tools working.   

the text in the byte magazine looks like this:

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

can I just copy the raw code part and compile that?

B850   8E   00FF

or would I write like this?

LDS   #$FF

You would use:

START   LDS   #$FF   INITIALIZE STACK

Maybe feed it to an OCR. 

[bytestorm]

Sorry, I wasn't following along close enough.  I assumed you would have built the programmer shown in Byte and used that code they provided to program your parts.   I wasn't thinking you were still looking at the debugger.   

If the goal is still just to program a few parts, what do you need the debugger for?

No I didnt build it yet in case I never find a suitable way of actually programming it... I am still stuck at how to modify the PRObug or that other program to actually work with the 68701u4.. the only availible one only works with the regular 68701.. but the U4 part has double the eprom area, and I need to somehow modify the PRObug code OR the code in Byte to program the 68701U4 instead of the 68701.

It was more difficult than I ever imagined hahaha... just to modify 3 places in the PRObug code... but I cant for the life of me find the known ones in the program as it is now.

I dont need any debugger, just program some parts

I figured you would just change the couple of pointers in the Byte source and assemble it.   If I had a couple of U4 parts, I would give it a try for you.

Thats what I am hoping to find... I know what I need to change, and I know what is should be written there now... but as I said, I cant see it in the file.. I can not find the places to change the external and internal eprom areas. external eprom is fixed at 7800-7FFF för example as mentioned before. But I can not find any references to that in the s19 file. And thats the only source I have..

I dont know if you mean that I could copy the LIST file in the byte magazine? thats not the source asm, if I understand correct.. I dont even have any software that is working in win 10 to compile at the moment even if I had the asm

The list is pretty much the source.  It just includes more data as it's been assembled.   Yes, I am saying type that back in, change the pointers and reassemble it.  You will need to setup DOSBOX to get the tools working.   

the text in the byte magazine looks like this:

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

can I just copy the raw code part and compile that?

B850   8E   00FF

or would I write like this?

LDS   #$FF

You would use:

START   LDS   #$FF   INITIALIZE STACK

Maybe feed it to an OCR.

OH sweet! I somehow thought that the "listing" is something else than source.. but today when I converted it back from s19 it felt very similar

I will get dosbox going and try to find a suitable compiler!

[joeqsmith]

Start by entering the code and then we can get the assembler and other tools working.   I tried an on-line OCR but it was very poor.  You may have to type it.  We want everything from the * and to the right as follows:

OPT Z01,LLEM=80
* THIS PROGRAM WILL CHECK, PROGRAM AND VERIFY
* THE MC68701'S EPROM
*
* EQUATES
P1DDR   EQU     $00     PORT 1 DATA DIR. REGISTER
P1DR    EQU     $02     PORT 1 DATA REGISTER
TCSR    EQU     $08     TIMER CONTROL/STAT REGISTER
TIMER   EQU     $09     COUNTER REGISTER
OUTCMP  EQU     $0B     OUTPUT COMPARE REGISTER
EPMCNT  EQU     $14     RAM/EROM CONTROL REGISTER
*
*  LOCAL VARIABLES
*
        ORG     $80
IMBEG   RMB     2       START OF MEMORY BLOCK
IMEND   RMB     2       LAST BYTE OF MEMORY BLOCK
PNTR    RMB     2       FIRST BYTE OF EPROM TO BE PGM'D
WAIT    RMB     2       COUNTER VALUE
*
        ORG     $B850
START   LDS     #$FF    INITIALIZE STACK

[bytestorm]

Start by entering the code and then we can get the assembler and other tools working.   I tried an on-line OCR but it was very poor.  You may have to type it.  We want everything from the * and to the right as follows:

OPT Z01,LLEM=80
* THIS PROGRAM WILL CHECK, PROGRAM AND VERIFY
* THE MC68701'S EPROM
*
* EQUATES
P1DDR   EQU     $00     PORT 1 DATA DIR. REGISTER
P1DR    EQU     $02     PORT 1 DATA REGISTER
TCSR    EQU     $08     TIMER CONTROL/STAT REGISTER
TIMER   EQU     $09     COUNTER REGISTER
OUTCMP  EQU     $0B     OUTPUT COMPARE REGISTER
EPMCNT  EQU     $14     RAM/EROM CONTROL REGISTER
*
*  LOCAL VARIABLES
*
        ORG     $80
IMBEG   RMB     2       START OF MEMORY BLOCK
IMEND   RMB     2       LAST BYTE OF MEMORY BLOCK
PNTR    RMB     2       FIRST BYTE OF EPROM TO BE PGM'D
WAIT    RMB     2       COUNTER VALUE
*
        ORG     $B850
START   LDS     #$FF    INITIALIZE STACK

Do I need the same spacing? looks like a "tab" between every typed word? or is a regular space enough? It looks formatted almost..

[joeqsmith]

Space or tab should be fine.    I tried running the tools under DOSBOX and it seems fine.  Once you have the source code entered, just upload it here and I will make sure it assembles.  We can then get you setup with the tools. 





M6801 Portable Cross Assembler  0.05   MS-DOS/PC-DOS  Page 1
 Fri May 17 14:30:42 2019
Command line:
 C:\6801\PASM01.EXE -dxs -l byte_pgm.lst byte_pgm.asm
Options list:
ON  - b - Printing of macro definitions
ON  - c - Printing of macro calls
ON  - d - Placing of symbolic debugging information in COFF  (changed)
OFF - e - Printing of macro expansions
ON  - f - Printing of conditional directives
OFF - g - Printing of generated constants list
OFF - q - Expanding and printing of structured syntax
ON  - s - Printing of symbol table  (changed)
OFF - u - Printing of conditional unassembled source
ON  - x - Printing of cross reference table  (changed)
OFF - m - Suppress printing of error messages
ON  - w - Printing of warning messages
OFF - v - Suppress printing of updated status
OFF - y - Enabling of sgs extensions
ON  - o - Create object code
ON  -   - Formatting of source line listing
Create listing file - l - byte_pgm.lst
 
Xdefs:
  NONE
 
Xrefs:
  NONE

Input file(s): byte_pgm.asm (27 lines)
 
Output file: byte_pgm.o 
Listing file: byte_pgm.lst

M6801 Portable Cross Assembler  0.05  byte_pgm.asm  Page 2
 Fri May 17 14:30:42 2019 
Options - MD,MC,NOG,NOU,W,NOMEX,CL,FMT,O
 
LINE   S PC   OPCO OPERANDS S LABEL    MNEMO OPERANDS COMMENT
00001                         * THIS PROGRAM WILL CHECK, PROGRAM AND VERIFY
00002                         * THE MC68701'S EPROM
00003                         *
00004                         * EQUATES
00005  P 0000      0000     A P1DDR    EQU   $00      PORT 1 DATA DIR. REGISTER
00006  P 0000      0002     A P1DR     EQU   $02      PORT 1 DATA REGISTER
00007  P 0000      0008     A TCSR     EQU   $08      TIMER CONTROL/STAT REGISTER
00008  P 0000      0009     A TIMER    EQU   $09      COUNTER REGISTER
00009  P 0000      000b     A OUTCMP   EQU   $0B      OUTPUT COMPARE REGISTER
00010  P 0000      0014     A EPMCNT   EQU   $14      RAM/EROM CONTROL REGISTER
00011                         *
00012                         *  LOCAL VARIABLES
00013                         *
00014  A 0080                          ORG   $80     
00015  A 0080      02       A IMBEG    RMB   2        START OF MEMORY BLOCK
00016  A 0082      02       A IMEND    RMB   2        LAST BYTE OF MEMORY BLOCK
00017  A 0084      02       A PNTR     RMB   2        FIRST BYTE OF EPROM TO BE PGM'D
00018  A 0086      02       A WAIT     RMB   2        COUNTER VALUE
00019                         *
00020  A b850                          ORG   $B850   
00021  A b850 8e   00ff     A START    LDS   #$FF     INITIALIZE STACK
00022  A b853 86   07       A          LDAA  #$07     INIT. PORT 1
00023  A b855 97   00       A          STAA  P1DDR    DDR
00024  A b857 97   02       A          STAA  P1DR     DATA REGISTER (ALL LED'S OFF)
00025                         *  *
00026  A b859 ce   f800     A          LDX   #$F800   CHECK IF EPROM ERASED
00027                                  END           



Total number of errors: 0
Total number of warnings: 0
Total number of lines: 27
 
 
Number of bytes in section ASCT: 20

Number of bytes in program: 20
 
           CROSS REFERENCE TABLE
NAME    ATTRB S VALUE P:LINE LINE1....N
 
EPMCNT   EQU  A 0014  2:10       
IMBEG         A 0080  2:15       
IMEND         A 0082  2:16       
OUTCMP   EQU  A 000b  2:9         
P1DDR    EQU  A 0000  2:5           23
P1DR     EQU  A 0002  2:6           24
PNTR          A 0084  2:17       
START         A b850  2:21       
TCSR     EQU  A 0008  2:7         
TIMER    EQU  A 0009  2:8         

M6801 Portable Cross Assembler  0.05     Page 3
 Fri May 17 14:30:42 2019 
 
           CROSS REFERENCE TABLE
NAME    ATTRB S VALUE P:LINE LINE1....N
 
WAIT          A 0086  2:18       

[grantb5]

M6801 Portable Cross Assembler  0.05   MS-DOS/PC-DOS  Page 1
 Fri May 17 14:30:42 2019
Command line:
 C:\6801\PASM01.EXE -dxs -l byte_pgm.lst byte_pgm.asm
 

Which assembler is this?  I thought I'd seen them all. 

[bytestorm]

M6801 Portable Cross Assembler  0.05   MS-DOS/PC-DOS  Page 1
 Fri May 17 14:30:42 2019
Command line:
 C:\6801\PASM01.EXE -dxs -l byte_pgm.lst byte_pgm.asm
 

Which assembler is this?  I thought I'd seen them all. 

haha actually lookin for this one too.. couldnt find it thou

[joeqsmith]

This was Motorola's. 

Back in the early days of the 01, we had an Exormax, Exorsizer (Motorola) and several HP 64000 I think stations.  I couldn't afford such tools for my hobby so I designed and built my own ICE for the 01.  I think it handles the U4.  I rolled my own assembler and disassembler for it.  These were built into the DOS based front end.  You could do breakpoints, single step and such.   It even had a couple of trigger outputs to drive a scope.   It may be fun to make a video of it someday. Should be good for a few laughs.   

[grantb5]

Oh that's nice.  Some of us are still working at the trailing edge of technology.   

I just started working on a 6303 ROM Monitor for an expanded bus system. It also has breakpoints and single-stepping but I'd much prefer an ICE that can get-out-of-the-way versus a ROM monitor.

[joeqsmith]

Interesting.  If you have a blog, I would like to read more about it.

I went as far as designing a clone of the 01 on an FPGA.  It then grew to an 11, then to some crazy thing with some custom op-codes.   I think the last thing I was attempting to do was add a hardware multiply but it seems the FPGAs of the time were just too limited.


You can see some of my homemade development boards here:
https://youtu.be/C8txvmXUIJQ?t=493

[bytestorm]

There.. I think its done. Will double check it when I get home, but I think its correct..

Things that have changed is the internal eprom size and external eprom area..

68701 have 7800-7FFF
68701u4 have 7000-7FFF

also ät the area in the bytebug "START NEW CODE" there was a reference to 7800.. I am not sure what that does but changed it to 7000. (is it for verifying?)      
LDX   #$7000 SET UP POINTER

anyway, please have a look in the attachment if you like

[joeqsmith]

Double check your work.   I plan to do the same. 


00134                         **
00135                         * R E S T A R T   A N D   I N T R. V E C.
00136                         *
00137                         
00138  A bff0                          ORG   $BFF0   
00139  A bff0      b8f1     A          FDB   SELF     
00140  A bff2      b8f1     A          FDB   SELF     
00141  A bff4      b8f1     A          FDB   SELF     
00142                           FDR SELF
***** --------------------------^
***** error  40: Unrecognized mnemonic or undefined macro 'FDR     '

[joeqsmith]

I corrected the error, rechecked your work and changed the index back.   I reformatted things just so they line up to make it easier to read.    I ran it through if you want to check the listing file below.   I also included the S record.  Do you have a PROM programmer and part to load this code into?   If so, I think it's time to build up the circuit.   If you need help understanding how to build it, let me know.  You could do this on some white board for the small number of parts you want to program. 



S00A000042595445425547E3
S10B0080000000000000000074
S123B8508E00FF860797009702CEF800DF84C600A6001126298CFFFF27030820F3860697A3
S123B87002DF86CE004609CCC350D3097F0008DD0B8640950827FC8C000026EA20068683B5
S123B8909702205DCE7000DF80CE7FFFDF82CEC350DF86DE843CDE803C86FE9714A600DE03
S123B8B084A70008DF8486FC9714DC86D3097F0008DD0B8640950827FC38089C8223D9869E
S123B8D0FF971438DF84CE70003CA600DE84E60011261008DF8438088C800026EC868497F6
S10CB8F00220FE8682970220F872
S113BFF0B8F1B8F1B8F1B8F1B8F1B8F1B8F1B85096
S9030000FC

 

M6801 Portable Cross Assembler  0.05   MS-DOS/PC-DOS  Page 1
 Sat May 18 20:37:13 2019
Command line:
 C:\6801\PASM01.EXE -dxs -l BYTEBUG.lst BYTEBUG.asm
Options list:
ON  - b - Printing of macro definitions
ON  - c - Printing of macro calls
ON  - d - Placing of symbolic debugging information in COFF  (changed)
OFF - e - Printing of macro expansions
ON  - f - Printing of conditional directives
OFF - g - Printing of generated constants list
OFF - q - Expanding and printing of structured syntax
ON  - s - Printing of symbol table  (changed)
OFF - u - Printing of conditional unassembled source
ON  - x - Printing of cross reference table  (changed)
OFF - m - Suppress printing of error messages
ON  - w - Printing of warning messages
OFF - v - Suppress printing of updated status
OFF - y - Enabling of sgs extensions
ON  - o - Create object code
ON  -   - Formatting of source line listing
Create listing file - l - BYTEBUG.lst
 
Xdefs:
  NONE
 
Xrefs:
  NONE

Input file(s): BYTEBUG.asm (142 lines)
 
Output file: BYTEBUG.o 
Listing file: BYTEBUG.lst

M6801 Portable Cross Assembler  0.05  BYTEBUG.asm  Page 2
 Sat May 18 20:37:13 2019 
Options - MD,MC,NOG,NOU,W,NOMEX,CL,FMT,O
 
LINE   S PC   OPCO OPERANDS S LABEL    MNEMO OPERANDS COMMENT
00001                         *
00002                         *
00003                         * THIS PROGRAM WILL CHECK, PROGRAM AND VERIFY
00004                         * THE MC68701U4 ' S EPROM.
00005                         *
00006                         *
00007                         *         E Q U A T E S
00008  P 0000      0000     A P1DDR    EQU   $00      PORT 1 DATA DIR. REGISTER
00009  P 0000      0002     A P1DR     EQU   $02      PORT 1 DATA REGISTER
00010  P 0000      0008     A TCSR     EQU   $08      TIMER CONTROL/STAT REGISTER
00011  P 0000      0009     A TIMER    EQU   $09      COUNTER REGISTER
00012  P 0000      000b     A OUTCMP   EQU   $0B      OUTPUT COMPARE REGISTER
00013  P 0000      0014     A EPMCNT   EQU   $14      RAM/EROM CONTROL REGISTER
00014                         *
00015                         *         L O C A L       V A R I A B L E S
00016                         *
00017  A 0080                          ORG   $80     
00018  A 0080      02       A IMBEG    RMB   2        START OF MEMORY BLOCK
00019  A 0082      02       A IMEND    RMB   2        LAST BYTE OF MEMORY BLOCK
00020  A 0084      02       A PNTR     RMB   2        FIRST BYTE OF EPROM TO RE PGM'D
00021  A 0086      02       A WAIT     RMB   2        COUNTER VALUE
00022                         *
00023  A b850                          ORG   $B850   
00024  A b850 8e   00ff     A START    LDS   #$FF     INITIALIZE STACK
00025  A b853 86   07       A          LDAA  #$07     INIT. PORT 1
00026  A b855 97   00       A          STAA  P1DDR    DDR
00027  A b857 97   02       A          STAA  P1DR     DATA REGISTER (ALL LED'S OFF)
00028                         **
00029  A b859 ce   f800     A          LDX   #$F800   CHECK IF EPROM ERASED
00030  A b85c df   84       A          STX   PNTR     INIT. PNTR WHILE CONVENIENT
00031  A b85e c6   00       A          LDAB  #$00     GET READY FOR CMPR.
00032  A b860 a6   00       A ERASE    LDAA  0,X      LOAD EPROM CONTENTS
00033  A b862 11                       CBA            COMPARE TO ZERO
00034  A b863 26   29    b88e          BNE   ERROR1   BRANCH IF NOT ZERO
00035  A b865 8c   ffff     A          CPX   #$FFFF   
00036  A b868 27   03    b86d          BEQ   NEXT     IF SO BRANCH
00037  A b86a 08                       INX            GO AGAIN
00038  A b86b 20   f3    b860          BRA   ERASE   
00039                         **
00040  A b86d 86   06       A NEXT     LDAA  #$06     TURN ON ERASED LED
00041  A b86f 97   02       A          STAA  P1DR     
00042                         **
00043                         * WAIT FOR VPP TO REACH 21V (3.5 SEC.)
00044                         *
00045  A b871 df   86       A          STX   WAIT     
00046  A b873 ce   0046     A          LDX   #$0046   
00047  A b876 09              STALL1   DEX           
00048  A b877 cc   c350     A          LDD   #$C350   INIT. 50MS LOOP
00049  A b87a d3   09       A          ADDD  TIMER    BUMP CURRENT VALUE
00050  A b87c 7f   0008     A          CLR   TCSR     CLEAR OCF
00051  A b87f dd   0b       A          STD   OUTCMP   SET OUTPUT COMPARE
00052  A b881 86   40       A          LDAA  #$40     NOW WAIT FOR OFC

M6801 Portable Cross Assembler  0.05  BYTEBUG.asm  Page 3
 Sat May 18 20:37:13 2019 
Options - MD,MC,NOG,NOU,W,NOMEX,CL,FMT,O
 
LINE   S PC   OPCO OPERANDS S LABEL    MNEMO OPERANDS COMMENT
00053  A b883 95   08       A STALL2   BITA  TCSR     
00054  A b885 27   fc    b883          BEQ   STALL2   NOT YET
00055  A b887 8c   0000     A          CPX   #$0000   70 TIMES YET?
00056  A b88a 26   ea    b876          BNE   STALL1   NOPE
00057  A b88c 20   06    b894          BRA   PGINT   
00058                         **
00059  A b88e 86   83       A ERROR1   LDAA  #$83     LIGHT ERROR LED ONLY
00060  A b890 97   02       A          STAA  P1DR     
00061  A b892 20   5d    b8f1          BRA   SELF     
00062                         **
00063  A b894 ce   7000     A PGINT    LDX   #$7000   INIT. IMBEG
00064  A b897 df   80       A          STX   IMBEG   
00065  A b899 ce   7fff     A          LDX   #$7FFF   INIT. IMEND
00066  A b89c df   82       A          STX   IMEND   
00067  A b89e ce   c350     A          LDX   #$C350   INIT. WAIT (4.0 MHZ)
00068  A b8a1 df   86       A          STX   WAIT     
00069                         *
00070                         * THIS PART FROM 68701U4 DATA SHEET
00071                         *
00072  A b8a3 de   84       A EPROM    LDX   PNTR     SAVE CALLING ARGUMENT
00073  A b8a5 3c                       PSHX           RESTORE WHEN DONE
00074  A b8a6 de   80       A          LDX   IMBEG    USE STACK
00075                         *
00076  A b8a8 3c              EPRO02   PSHX           SAVE POINTER ON STACK
00077  A b8a9 86   fe       A          LDAA  #$FE     REMOVE VPP, SET LATCH
00078  A b8ab 97   14       A          STAA  EPMCNT   PPC=1,PLC=0
00079  A b8ad a6   00       A          LDAA  0,X      MOVE DATA MEMORY-TO-LATCH
00080  A b8af de   84       A          LDX   PNTR     GET WHERE TO PUT IT
00081  A b8b1 a7   00       A          STAA  0,X      STASH AND LATCH
00082  A b8b3 08                       INX            NEXT ADDR.
00083  A b8b4 df   84       A          STX   PNTR     ALL SET FOR NEXT
00084  A b8b6 86   fc       A          LDAA  #$FC     ENABLE EPROM POWER (VPP)
00085  A b8b8 97   14       A          STAA  EPMCNT   PPC=0,PLC=0
00086                         *
00087                         * NOW WAIT 50 MSEC TIMEOUT USING COMPARE
00088                         *
00089  A b8ba dc   86       A          LDD   WAIT     GET CYCLE COUNTER
00090  A b8bc d3   09       A          ADDD  TIMER    BUMP CURRENT VALUE
00091  A b8be 7f   0008     A          CLR   TCSR     CLEAR OCF
00092  A b8c1 dd   0b       A          STD   OUTCMP   SET OUTPUT COMPARE
00093  A b8c3 86   40       A          LDAA  #$40     NOW WAIT FOR OCF
00094  A b8c5 95   08       A EPRO04   BITA  TCSR     
00095  A b8c7 27   fc    b8c5          BEQ   EPRO04   NOT YET
00096                         *
00097  A b8c9 38                       PULX           SET UP FOR NEXT ONE
00098  A b8ca 08                       INX            NEXT
00099  A b8cb 9c   82       A          CPX   IMEND    MAYBE DONE
00100  A b8cd 23   d9    b8a8          BLS   EPRO02   NOT YET
00101  A b8cf 86   ff       A          LDAA  #$FF     REMOVE VPP, INHIBIT LATCH
00102  A b8d1 97   14       A          STAA  EPMCNT   EPROM CAN NOW RE READ
00103  A b8d3 38                       PULX           RESTORE PNTR
00104  A b8d4 df   84       A          STX   PNTR     

M6801 Portable Cross Assembler  0.05  BYTEBUG.asm  Page 4
 Sat May 18 20:37:13 2019 
Options - MD,MC,NOG,NOU,W,NOMEX,CL,FMT,O
 
LINE   S PC   OPCO OPERANDS S LABEL    MNEMO OPERANDS COMMENT
00105                         * *
00106                         * START NEW CODE
00107                         *
00108  A b8d6 ce   7000     A          LDX   #$7000   SET UP POINTER
00109  A b8d9 3c              VERF2    PSHX           SAVE POINTER ON STACK
00110  A b8da a6   00       A          LDAA  0,X      GET DESIRED DATA
00111  A b8dc de   84       A          LDX   PNTR     GET EPROM ADDR.
00112  A b8de e6   00       A          LDAB  0,X      GET DATA TO BE CHECKED
00113  A b8e0 11                       CBA            CHECK IF SAME
00114  A b8e1 26   10    b8f3          BNE   ERROR2   BRANCH IF ERROR(LIGHT LED)
00115  A b8e3 08                       INX            NEXT ADDR
00116  A b8e4 df   84       A          STX   PNTR     ALL SET FOR NEXT
00117  A b8e6 38                       PULX           SETUP FOR NEXT ONE
00118  A b8e7 08                       INX            NEXT
00119  A b8e8 8c   8000     A          CPX   #$8000   MAYBE DONE
00120  A b8eb 26   ec    b8d9          BNE   VERF2    NOT YET
00121                         **
00122  A b8ed 86   84       A          LDAA  #$84     
00123  A b8ef 97   02       A          STAA  P1DR     LIGHT VERIFY LED
00124                         **
00125  A b8f1 20   fe    b8f1 SELF     BRA   SELF     WAIT FOREVER
00126                         **
00127  A b8f3 86   82       A ERROR2   LDAA  #$82     LIGHT ERROR & ERASED LED'S
00128  A b8f5 97   02       A          STAA  P1DR     
00129  A b8f7 20   f8    b8f1          BRA   SELF     
00130                         **
00131                         * R E S T A R T   A N D   I N T R. V E C.
00132                         *
00133  A bff0                          ORG   $BFF0   
00134  A bff0      b8f1     A          FDB   SELF     
00135  A bff2      b8f1     A          FDB   SELF     
00136  A bff4      b8f1     A          FDB   SELF     
00137  A bff6      b8f1     A          FDB   SELF     
00138  A bff8      b8f1     A          FDB   SELF     
00139  A bffa      b8f1     A          FDB   SELF     
00140  A bffc      b8f1     A          FDB   SELF     
00141  A bffe      b850     A          FDB   START   
00142                                  END           



Total number of errors: 0
Total number of warnings: 0
Total number of lines: 142
 
 
Number of bytes in section ASCT: 193

Number of bytes in program: 193

M6801 Portable Cross Assembler  0.05     Page 5
 Sat May 18 20:37:13 2019 
 
           CROSS REFERENCE TABLE
NAME    ATTRB S VALUE P:LINE LINE1....N
 
EPMCNT   EQU  A 0014  2:13          78   85  102
EPRO02        A b8a8  3:76         100
EPRO04        A b8c5  3:94          95
EPROM         A b8a3  3:72       
ERASE         A b860  2:32          38
ERROR1        A b88e  3:59          34
ERROR2        A b8f3  4:127        114
IMBEG         A 0080  2:18          64   74
IMEND         A 0082  2:19          66   99
NEXT          A b86d  2:40          36
OUTCMP   EQU  A 000b  2:12          51   92
P1DDR    EQU  A 0000  2:8           26
P1DR     EQU  A 0002  2:9           27   41   60  123  128
PGINT         A b894  3:63          57
PNTR          A 0084  2:20          30   72   80   83  104  111  116
SELF          A b8f1  4:125         61  125  129  134  135  136  137  138  139  140
STALL1        A b876  2:47          56
STALL2        A b883  3:53          54
START         A b850  2:24         141
TCSR     EQU  A 0008  2:10          50   53   91   94
TIMER    EQU  A 0009  2:11          49   90
VERF2         A b8d9  4:109        120
WAIT          A 0086  2:21          45   68   89

[joeqsmith]

Looking at the schematics, they may have had a bug.   The datasheet for the MCM2716 shows the Read Enable (G) being active low.  They route this to address A13 and talk about the two ROMs being at 0xB8nn and 0x78nn.  So double check their work as well. 

You can't use a 2K part anyway.  I would just follow their decoding but expand it to A11 and make sure you get the polarity of the chip select correct. 

On the power supply, you could consider running the board from the VPP and using a DC-DC to get the 5.  Or, you could just run two supplies.   These were the only things I saw with my quick once over.     

[bytestorm]

Awesome! Thanks alot man!

I will start planning the build and get the components that I might be missing. I was planning to use a AM2732B for the code. (I have a programmer that supports it)
I remember seeing 2 different schematics actually. One with terminal output and one automated. The latter one is from byte mag so will roll with that one.
will check my power supplies and see if I might have some suitable ones.. need +5,+21VDC.. think i have a 2port with +5,+24VDC..

This really got me interested in diving deeper into assembler..

I have a question about line 55, whats the reason for 70 times? does this need to be increased?

00055  A b887 8c   0000     A          CPX   #$0000   70 TIMES YET?

Is there any chance that you could share the software you are using, or is it private/commercial?

[joeqsmith]

Awesome! Thanks alot man!

I will start planning the build and get the components that I might be missing. I was planning to use a AM2732B for the code. (I have a programmer that supports it)
I remember seeing 2 different schematics actually. One with terminal output and one automated. The latter one is from byte mag so will roll with that one.
will check my power supplies and see if I might have some suitable ones.. need +5,+21VDC.. think i have a 2port with +5,+24VDC..

Glad to help.   Keep in mind, you could use a larger EPROM if they are easier to source and less expensive.   See what you can find and then design around that.

This really got me interested in diving deeper into assembler..

I have a question about line 55, whats the reason for 70 times? does this need to be increased?

00055  A b887 8c   0000     A          CPX   #$0000   70 TIMES YET?

It looks like they have a 50ms timer that uses the hardware timer, based on the 4MHz xtal.  This is called in an outside loop 70 times.  0.05ms * 70 = 3.5 seconds.  If you read the comment for this section:
*     WAIT FOR VPP TO REACH 21V (3.5 SEC.).

I would suggest you sketch out new schematics, by hand or what ever so you can post them here.  Let me and others review them.  Then build it.  I will make the changes to the code for you and give you what ever sort of image your programmer requires. 

Is there any chance that you could share the software you are using, or is it private/commercial?

The assembler and other tools were all public domain and available to anyone who wanted to download them.   Once you are able to program a device, my plan is to then wrap all the tools into a ZIP file along with a batch file to automate the build.  I will make one for the original programmer and one for yours.    I will upload the tools here for others who may come across your post in the future.   

[bytestorm]

Awesome! Thanks alot man!

I will start planning the build and get the components that I might be missing. I was planning to use a AM2732B for the code. (I have a programmer that supports it)
I remember seeing 2 different schematics actually. One with terminal output and one automated. The latter one is from byte mag so will roll with that one.
will check my power supplies and see if I might have some suitable ones.. need +5,+21VDC.. think i have a 2port with +5,+24VDC..

Glad to help.   Keep in mind, you could use a larger EPROM if they are easier to source and less expensive.   See what you can find and then design around that.

This really got me interested in diving deeper into assembler..

I have a question about line 55, whats the reason for 70 times? does this need to be increased?

00055  A b887 8c   0000     A          CPX   #$0000   70 TIMES YET?

It looks like they have a 50ms timer that uses the hardware timer, based on the 4MHz xtal.  This is called in an outside loop 70 times.  0.05ms * 70 = 3.5 seconds.  If you read the comment for this section:
*     WAIT FOR VPP TO REACH 21V (3.5 SEC.).

I would suggest you sketch out new schematics, by hand or what ever so you can post them here.  Let me and others review them.  Then build it.  I will make the changes to the code for you and give you what ever sort of image your programmer requires. 

Is there any chance that you could share the software you are using, or is it private/commercial?

The assembler and other tools were all public domain and available to anyone who wanted to download them.   Once you are able to program a device, my plan is to then wrap all the tools into a ZIP file along with a batch file to automate the build.  I will make one for the original programmer and one for yours.    I will upload the tools here for others who may come across your post in the future.   

Yeah now when you mention it.. I do have a bunch of Winbond W27C512-45Z which is supercheap and flash. Sure they are way to big but more easy to work with.. might design around them instead.
And about the chip enable "bug" it was actually mentioned in the byte magazine that only the specified motorola eproms had this function .

Lets take newer ones instead so its more accessible for all. W27C512 are really good and cheap

[joeqsmith]

Yeah now when you mention it.. I do have a bunch of Winbond W27C512-45Z which is supercheap and flash. Sure they are way to big but more easy to work with.. might design around them instead.
And about the chip enable "bug" it was actually mentioned in the byte magazine that only the specified motorola eproms had this function .

Lets take newer ones instead so its more accessible for all. W27C512 are really good and cheap

Sure enough. I read the document and then the data sheet I linked.  It's not a bug in their design but rather a problem with the lazy human. 

I think using the E^2 parts is a good idea.   I assume your programmer supports them, binary and S record formats.   If so, we should be all set. 

If you want to upload your binary image that you plan to load into these parts, I can have a look and at least make sure that it looks like a valid file. 

[Mrozkey]

(...)  The datasheet for the MCM2716 shows the Read Enable (G) being active low.  (...)

The MCM2716s are unique... They allow standard "active low" output enable with Vpgm=+5V, as well as "active high" with Vpgm tied low.

A.

[joeqsmith]

(...)  The datasheet for the MCM2716 shows the Read Enable (G) being active low.  (...)

The MCM2716s are unique... They allow standard "active low" output enable with Vpgm=+5V, as well as "active high" with Vpgm tied low.

A.

Odd.  I thought the last two posts made it pretty clear that the active level was programmable.  But thanks for jumping in and adding that bit of useful data.      

I have to add, also very insightful for that second post!   

[grantb5]

The MCM2716s are unique... They allow standard "active low" output enable with Vpgm=+5V, as well as "active high" with Vpgm tied low.

A.

I've just been looking at an old mask ROM that has a "programmable" CE*/CE input so I guess there were a few instances where active high signals appeared on ROMs.

[bytestorm]

I corrected the error, rechecked your work and changed the index back.   I reformatted things just so they line up to make it easier to read.    I ran it through if you want to check the listing file below.   I also included the S record.  Do you have a PROM programmer and part to load this code into?   If so, I think it's time to build up the circuit.   If you need help understanding how to build it, let me know.  You could do this on some white board for the small number of parts you want to program. 



S00A000042595445425547E3
S10B0080000000000000000074
S123B8508E00FF860797009702CEF800DF84C600A6001126298CFFFF27030820F3860697A3
S123B87002DF86CE004609CCC350D3097F0008DD0B8640950827FC8C000026EA20068683B5
S123B8909702205DCE7000DF80CE7FFFDF82CEC350DF86DE843CDE803C86FE9714A600DE03
S123B8B084A70008DF8486FC9714DC86D3097F0008DD0B8640950827FC38089C8223D9869E
S123B8D0FF971438DF84CE70003CA600DE84E60011261008DF8438088C800026EC868497F6
S10CB8F00220FE8682970220F872
S113BFF0B8F1B8F1B8F1B8F1B8F1B8F1B8F1B85096
S9030000FC

 

Hmm.. when I convert this s19 to bin it actually gets 64k big.. that was unexpected. What am I missing? 

[bytestorm]

ill try the miniprog program for loading the s19 when my circuits arrive.. I am not sure how they translate into binary size wize when programming thou?

Ordering the missing components  in the weekend!

[joeqsmith]

Hmm.. when I convert this s19 to bin it actually gets 64k big.. that was unexpected. What am I missing? 

In your very first post, you attached a datasheet for this part.  You will notice it has 16 address lines.  2^16=?   Or, if you look on page 3-793 Table 2, Expanded Multiplexed, what is the total amount of memory it states the part can address?   

Some programmers are not able to remap.  Maybe this is why you are asking.  If this is the case, don't worry.   Normally, the programmers will read a binary image.  Once you have the hardware design, I run this S-Record through a remap utility that can then be programmed into your PROM.   

You have yet to post the image of what you plan on loading into these parts.  I assume that what ever the format is, that your programmer (not the one you are building but the one that will load this image into your PROM) will support it.   

Post your schematic and we can go over it.  Post your image file and I can make sure it seems valid.

[bytestorm]

Hmm.. when I convert this s19 to bin it actually gets 64k big.. that was unexpected. What am I missing? 

In your very first post, you attached a datasheet for this part.  You will notice it has 16 address lines.  2^16=?   Or, if you look on page 3-793 Table 2, Expanded Multiplexed, what is the total amount of memory it states the part can address?   

Some programmers are not able to remap.  Maybe this is why you are asking.  If this is the case, don't worry.   Normally, the programmers will read a binary image.  Once you have the hardware design, I run this S-Record through a remap utility that can then be programmed into your PROM.   

You have yet to post the image of what you plan on loading into these parts.  I assume that what ever the format is, that your programmer (not the one you are building but the one that will load this image into your PROM) will support it.   

Post your schematic and we can go over it.  Post your image file and I can make sure it seems valid.

ah, no I mean the bytebug file.. the byte magazine shows the bytebug file is programmed into a 2716.. which can only hold 2k not 64k. Thats why I wondered what happened when I converted s19 into bin.

the image that I am supposed to load into the internal eprom of the 68701u4 is 4k BIN file, so a 2732 will suffice, and my programmer supports is. (I can post it tonight, dont have it at work)

About the schematics I thought Id use the one in the Byte magazine, althou some modification will be needed for the bigger size eprom and such.


But as I said before, it might be better to adapt the circuit for 27c512 eeproms since they are dirt cheap and easy to find, and erases electronically instead of uv.. sizewize its a tremendous overkill but.

[grantb5]

One of the things about embedded programming is dealing with "locating" data in code space and also the various tools for programming these 8-bitters.  In your case whatever program you used to read and/or write with probably has 62K of $FF's in the codespace and then 2K of what you expected. The S19 file has a starting address in it so that's a consideration too. At some point it's likely that the 2k in question will be located down to $0000 for the base address of the eprom device that you program.  Your mentor there seems well aware of all the steps so you are in good hands.

[joeqsmith]

ah, no I mean the bytebug file.. the byte magazine shows the bytebug file is programmed into a 2716.. which can only hold 2k not 64k. Thats why I wondered what happened when I converted s19 into bin.

the image that I am supposed to load into the internal eprom of the 68701u4 is 4k BIN file, so a 2732 will suffice, and my programmer supports is. (I can post it tonight, dont have it at work)

Regardless of source code, the tools will create a 64K S-record because that is was the part uses.   Again, this would then be remapped, or moved to some other location and size depending what you come up with for hardware and what your programmer requires.   All things that you really don't need to worry about.  Let just say what ever you come up with for decoding, I can change support it.   For example, the following should target a 2716. 

S32500000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA
S32500000020FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDA
S32500000040FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8E00FF860797009702CEF800DF84C60071
S32500000060A6001126298CFFFF27030820F386069702DF86CE004609CCC350D3097F0008DDDF
S325000000800B8640950827FC8C000026EA200686839702205DCE7000DF80CE7FFFDF82CEC30D
S325000000A050DF86DE843CDE803C86FE9714A600DE84A70008DF8486FC9714DC86D3097F001A
S325000000C008DD0B8640950827FC38089C8223D986FF971438DF84CE70003CA600DE84E60017
S325000000E011261008DF8438088C800026EC8684970220FE8682970220F8FFFFFFFFFFFFFF77
S32500000100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9
S32500000120FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD9
S32500000140FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB9
S32500000160FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF99
S32500000180FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF79
S325000001A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF59
S325000001C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF39
S325000001E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF19
S32500000200FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8
S32500000220FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD8
S32500000240FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB8
S32500000260FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF98
S32500000280FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF78
S325000002A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF58
S325000002C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF38
S325000002E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF18
S32500000300FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7
S32500000320FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD7
S32500000340FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB7
S32500000360FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF97
S32500000380FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF77
S325000003A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF57
S325000003C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF37
S325000003E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF17
S32500000400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6
S32500000420FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD6
S32500000440FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB6
S32500000460FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF96
S32500000480FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF76
S325000004A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF56
S325000004C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF36
S325000004E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF16
S32500000500FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5
S32500000520FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD5
S32500000540FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB5
S32500000560FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF95
S32500000580FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF75
S325000005A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF55
S325000005C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF35
S325000005E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF15
S32500000600FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4
S32500000620FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD4
S32500000640FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB4
S32500000660FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF94
S32500000680FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF74
S325000006A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF54
S325000006C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF34
S325000006E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF14
S32500000700FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
S32500000720FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD3
S32500000740FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB3
S32500000760FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF93
S32500000780FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF73
S325000007A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF53
S325000007C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF33
S325000007E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB8F1B8F1B8F1B8F1B8F1B8F1B8F1B8505C

About the schematics I thought Id use the one in the Byte magazine, althou some modification will be needed for the bigger size eprom and such.

But as I said before, it might be better to adapt the circuit for 27c512 eeproms since they are dirt cheap and easy to find, and erases electronically instead of uv.. sizewize its a tremendous overkill but.

I suggest you markup that schematic the way to plan to build it and post that here.  Even a hand marking is fine. Until we have that sorted out, there is no point moving forward. 

[bytestorm]

Great to hear.. man I have lots of things to learn..

Here is the file for the internal eprom of the 68701u4 as promised. (rename TXT to bin)

I will start working on the schematics!

[bytestorm]

One of the things about embedded programming is dealing with "locating" data in code space and also the various tools for programming these 8-bitters.  In your case whatever program you used to read and/or write with probably has 62K of $FF's in the codespace and then 2K of what you expected. The S19 file has a starting address in it so that's a consideration too. At some point it's likely that the 2k in question will be located down to $0000 for the base address of the eprom device that you program.  Your mentor there seems well aware of all the steps so you are in good hands.

mm yeah.. I got a bit confused when it had so much FFs but actual data in some places.. was wondering how that would endup in the 2716.
I am sure it will become clearer the more I work with it!

[joeqsmith]

If you would rather work with the binary files, rename the attached to .bin.  Again, this would target a 2716 (2KB file as you would expect).   You can try both the this and the last S record with your programmer and make sure it can read them. 

Looking at the image you uploaded, it does indeed appear to be in the correct format and for the 6801.   The vectors appear correct for a U4.    It's packed full.  They would have spent a lot to time trying to fit this into a 2K part.   

Parts are erased to FFs.  Your programmer may have a way to initialize the buffer before loading the files.  However, if you use one of the last two files, all of the unused bytes are already cleared for you.   This is why you would see so many FF.   

Hardware next. 

[joeqsmith]

Just doing a quick search, Wiki comes through:

The arcade version of Bubble Bobble was widely bootlegged in its day, but due to a security chip installed by Taito (known as the PS4, based on a Motorola 6800) none of the bootlegs played exactly like the original. Through a technique called "decapping", the MAMEDEV team has been able to reverse engineer the workings of the chip and emulate it perfectly.[29] Following that, project Bubble Bobble REDUX has been able to implement an exact version of Bubble Bobble on bootleg boards.[30]

[grantb5]

How did you know that's what the objective was? I didn't see much in the BIN file of any help, aside from the date.

[bytestorm]

Just doing a quick search, Wiki comes through:

The arcade version of Bubble Bobble was widely bootlegged in its day, but due to a security chip installed by Taito (known as the PS4, based on a Motorola 6800) none of the bootlegs played exactly like the original. Through a technique called "decapping", the MAMEDEV team has been able to reverse engineer the workings of the chip and emulate it perfectly.[29] Following that, project Bubble Bobble REDUX has been able to implement an exact version of Bubble Bobble on bootleg boards.[30]

Yeah the redux version is very good, but not perfect, and not working exactly the same gameplay wize in terms of slowdowns. My goal is to be able to reproduce the ps4 mcu for original boards in case that chip dies or is missing/damaged. As it is now, there is no replacement for it. I guess you googled the CRC to find it?

Its a extremely fun game and I used to own it back in the day. Now days I play it in emulator untill I find the PCB for a reasonable price again. A group of people is actively working of making reproductions of various custom chips to help people with damaged/faulty ones get their game running again. I wanted to try and chip in with something nobody did before... not knowing it would be this hard haha

The optimal goal would be to implement this into a new MCU and have that one handle it the same way the original 68701u4 does, but that might be impossible... or it certainly is for me. But its a stretchgoal... if I actually try and learn some assembler and learn to understand how this 4k bin works, then it could actually be possible maybe, but yeah.

A some of my friends still have the original board so I can verify it when it's done

[grantb5]

Sounds like a fun adventure.  Would this have been the CCITT CRC16 or some other algorithm? I see some people referring to a Fluke 9010 checksum or some such thing.

[bytestorm]

Sounds like a fun adventure.  Would this have been the CCITT CRC16 or some other algorithm? I see some people referring to a Fluke 9010 checksum or some such thing.

The CRC32 directly from the ZIP will get hits on google. Yes its been very challenging (for me).. I have spent much more time than I want to admit trying to figure out how this works.. and I would probably newer find out, if it werent for ALL THE GREAT TIPS & SUPPORT from all you guys on this very forum!

I am impressed that you guys even stuck with me for so long hahaha . I have been at this before like a year ago or so but failed..

Ill try and get the schematics done asap and start breadbordin!

[joeqsmith]

I was able to disassemble the binary, reassemble it, run a diff on the two binaries and get a match.   The code does appear valid.    It's a bit interesting in that it appears that how ever the code had been created, they had forced the use of extended addressing in certain cases.   To get the source to build the exact image, I had to manually compare the listing and force these same conditions. 
Of course the assembler tells me how stupid I am for wasting space.    I guess with 4K, you have space to burn with poor coding... 

[bytestorm]

I was able to disassemble the binary, reassemble it, run a diff on the two binaries and get a match.   The code does appear valid.    It's a bit interesting in that it appears that how ever the code had been created, they had forced the use of extended addressing in certain cases.   To get the source to build the exact image, I had to manually compare the listing and force these same conditions. 
Of course the assembler tells me how stupid I am for wasting space.    I guess with 4K, you have space to burn with poor coding... 

Wow thats awesome! Was it using your own tools? I couldnt find any online with 6801u4 support :/
Could I please have the dissassembled file?

I thought that if I went throu it and commented all whats happening then I might actually learn a thing or two when looking up all instructions and operands.
I think I would have lots of use of learning assembler in my hobby actually.. then it would allow me to write own test code for certain games to test out memory and such on the pcbs I am repairing

Got about 100 game pcbs and 8 arcade machines.. althou only 4 of them are working and in my house :/..

[grantb5]

Take the TXT, rename to BIN then ZIP it and look at the CRC. This I would not have thought of. Maybe the CRC of the BIN, but I don't really have a handy utility for getting the CRC or anything.

My ventures into 6303 land have taken me on a few paths through Yamaha synthesizers and such. I've seen in their code where they used (forced?) extended where direct would do. And for no good reason as far as I could discern. The timing was not important for the stuff I was looking at.

[bytestorm]

I have lots of z80, 68k, 68x09, 63c09 etc that I would love to understand more deeply how they actually works in the boards that they are used .

[bytestorm]

I need to get me a proper DosBox setup so I can run all these old softwares. I dont have any old PCs left at home really so I guess dosbox is the best (only) choice

Ideally thou would be win software with gui for ease of use when handling assembler (as a total newb).... but might not exist for 6801u4 and such?

[grantb5]

That's a tall order. I'm sure there are GUI's or editors that could be massaged into doing this, but you'd end up having to figure out all the command lines needed anyway. I think it's better to just use an editor you like (I use Notepad++) and create some batch files for the build process. I'd be happy to learn of a better way though. I use PlatformIO and Visual Studio Code for a few things but that's just more stuff to learn. For assembler my method is fine.  I used Win7 and newer exclusively but I have access to XP and older ... but I can't really recall needing them in a long time.\

[joeqsmith]

Could I please have the dissassembled file?

I thought that if I went throu it and commented all whats happening then I might actually learn a thing or two when looking up all instructions and operands.
I think I would have lots of use of learning assembler in my hobby actually.. then it would allow me to write own test code for certain games to test out memory and such on the pcbs I am repairing

I did look for a schematic for this game.  There was one for a Z80, but nothing for the 01.   I have no problem giving you the disassembled code but would be doing you a disservice at this stage.   If I can locate the schematics, I could possibly start to comment some of it for you.   To be honest, even with my skills and knowledge of the 01, without an understanding of the hardware, trying to understand this code would not be trivial. 

***
Found it.  Still even with this, the project would be a significant amount of effort. 

https://wiki.arcadeotaku.com/images/f/f7/Bubble_Bobble_-_Schematics_-_English.pdf

I need to get me a proper DosBox setup so I can run all these old softwares. I dont have any old PCs left at home really so I guess dosbox is the best (only) choice

Ideally thou would be win software with gui for ease of use when handling assembler (as a total newb).... but might not exist for 6801u4 and such?

I suggest you focus on marking up the schematics and getting them posted.   Then get the hardware built.  Once that is working, you can worry about things like DOSBOX and tools. 

I am not aware of any GUI based tools for the 01. 

[joeqsmith]

Thinking ahead, there are two books Motorola put out that I recommend you try and find.   The first is M68HASLK/D1.   This is the book for the tool set.  It's fairly thick.  It doesn't cover the instructions or how to code in assembler.  It's strictly for the tools (command line options, coding syntax, ...  ).   

The other is MC6801RM(AD2) which is specific to the 6801.  It contains a fair bit of detail about the hardware and how to program the device.   

I have a few other books but these two are really the only ones I used. 

[bytestorm]

Thinking ahead, there are two books Motorola put out that I recommend you try and find.   The first is M68HASLK/D1.   This is the book for the tool set.  It's fairly thick.  It doesn't cover the instructions or how to code in assembler.  It's strictly for the tools (command line options, coding syntax, ...  ).   

The other is MC6801RM(AD2) which is specific to the 6801.  It contains a fair bit of detail about the hardware and how to program the device.   

I have a few other books but these two are really the only ones I used.

Phew, back in the game.. my main HDD died on me and since it was quite old pc overall I decided to build myself a new. Fortunately I had backups of everything but its allways a hassle with reinstalls and upgraded to win10 this time.

Anyway, I cant for the life of me find the systems book (the M68HASLK/D1). Any ISBN number printed on the back of that book?
 The other I have found so far..

[joeqsmith]

There is no ISBN number.  Like databooks, these were distributed by the reps.   Maybe eBay, Amazon or used book stores.   There is another booklet they published on how to use their BBS.  In there you will find a directory of all the files they had available.  This is where I pulled the tools from.  They may have had this document on-line in some plain text format.   

 

[grantb5]

That book does seem rather rare, however there are other books on the same topic (like, ISBN books incl text books) as well as the data books and applications books from that era.  Lots of assemblers too. I like the Baldwin AS68xx stuff. Main problem with assembly language is that various assemblers have slightly different syntax so sometimes you need to tweak things as you go from one to another.

Here is the Baldwin as68xx stuff. He's been keeping it up since who knows when :

http://shop-pdp.net/ashtml/asxxxx.php

There may be others that are closer to the original, ... I bet there are dozens out there.

[Les]

I realise that this is a very late reply but I have a copy of the Motorola application note AN906A "Self-Programming the MC68701 and the MC68701U4"
As this doesn't seem to be available elsewhere I have attached a scanned copy.
bytestorm if you are still checking this thread I hope this is useful for you.

[bytestorm]

I realise that this is a very late reply but I have a copy of the Motorola application note AN906A "Self-Programming the MC68701 and the MC68701U4"
As this doesn't seem to be available elsewhere I have attached a scanned copy.
bytestorm if you are still checking this thread I hope this is useful for you.

Wow, you really had this and scanned it for me? THANK YOU!
I am still checking this thread.. I have since last time finally gotten the chips programmed by a guy in france, since I just couldnt seem to ever get it done myself
Too many hurdles and I just lost the patience..

That said, now I have the new schematics, thanks to you, so lets build this thing!
Ill keep you posted! (If enyone else checks this anymore)

[bytestorm]

Here is the schematic. I had to make some changes to the 21VDC supply since I couldnt find that typical module.

I also choose bigger eproms since the old ones are getting more expensive and harder to find..

Please let me know your thoughts!

[Les]

The changes look fine. The switching regulator is more than capable and the larger eproms are not an issue.
It is hard to tell from your schematic but are you aware that the +5V to the left of SW1 is the input and all the other+5V on the circuit should
connect to the right hand side of SW1?

Excuse me if this is a dumb question.

[bytestorm]

The changes look fine. The switching regulator is more than capable and the larger eproms are not an issue.
It is hard to tell from your schematic but are you aware that the +5V to the left of SW1 is the input and all the other+5V on the circuit should
connect to the right hand side of SW1?

Excuse me if this is a dumb question.

Well spotted. I didnt see that actually . Now, of course the MT3806 is nowhere to be found so I might need to take some other part instead for the step-up :/.. onsemi.com might have some..
MT3806 is actually availible on some kind of module already assembled on ebay.. but I am not a fan of having to rely on another module to fit the pcb :S

[Les]

You could try the MC34063. It is available from a number of manufacturers and is quite common.
Most car chargers for mobile phones will contain one or an equivalent.

[bytestorm]

You could try the MC34063. It is available from a number of manufacturers and is quite common.
Most car chargers for mobile phones will contain one or an equivalent.

Yeah that one seems better. And has some tutorials also on how to calculate all the correct parameters for choosing the components! I will rewamp the schematic for that one . Thanks!