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.
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?
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.
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
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.
(...) 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.
(...) 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!
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.
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?
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!
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.
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.
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.
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.
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!
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!
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.
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]
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.
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
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.
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!
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...
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 :/..
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.