On 7/4/2014 5:18 AM, silverdr@wfmh.org.pl wrote: > YESSS!!! Oh, no one was more surprised than me. I was writing the first part of the original to Greg King on my lack of success before heading to sleep when I decided I just could not send such a downer of a note :-) Normally, by the time I get things set up for a test, someone else on the list has already set up a more elaborate test, maybe even created a custom PCB for it, written the code, tested it, found the information, written a paper up on it (typeset in troff or LaTex, no doubt), created a web site, and is implementing the feature in VICE. > I think I know what you mean ;-) Exactly the reason why I pushed to gain more clear information before trying anything. Thank you Jim for stepping in and getting this eventually done. Excellent job!! Hopefully this will also help VICE people and we may see a _full_ 1520 emulation at some point with e.g. SVG output... So, if anyone wants to send me an Amiga controller, I cna read it out, but I think I do need to reclaim my workbench at some point :-) > >> And ran the code 16 times to read out RAM/ROM. I got two different >> reading for page 2 and 3, so I need to determine which bytes are >> different and I can read them out by themselves, but it's 3AM here, and >> I've worked on this all night, so maybe someone else can help... > http://dl.dropboxusercontent.com/u/58002657/cbm/1520/page2_diffs.png > http://dl.dropboxusercontent.com/u/58002657/cbm/1520/page3_diffs.png > > Now the obvious question if this is just an idiosyncrasy of the chip we deal with or is it some kind of unreliability of the method? Were all other readings fully consistent? Those pages are supposedly "Unassigned" so it shouldn't be much of a problem if it is just inner life of the chip bit We have to verify now the remaining parts. I'll make a binary of the ROM part in a moment and have a look at it. > The code in the AVR is brittle, I'll be honest, so I have reasonable but not complete confidence in the dumps. YMMV. The code could be stabilized quite a bit, it is a true hack job of code. I tried to recreate a true "startup" sequence through every loop (stop clock, pull reset low for some time, start clock, release RESET, etc.), but the CPU does *NOT* like the clock domain changing speeds (or stopping) while power was applied. I'd probably need to switch opcode port on AVR to input, put a transistor on the Vcc to the CPU, disconnect power while bringing RESET low, and then truly power the CPU up. But, I can read individual bytes with high confidence, so I'll check the diffs. 0x0201 = 0x65 0x0215 = 0xf5 0x021b = 0x57 0x0228 = 0x82 0x022e = 0x01 0x022f = 0x12 0x0234 = 0x00 0x0235 = 0xff 0x0236 = 0x03 0x023c = 0x0a 0x023f = 0x44 0x0301 = 0x65 0x0315 = 0xf5 0x031b = 0x57 0x0328 = 0x82 0x032e = 0x01 0x032f = 0x8c <- hmmm 0x0334 = 0x00 0x0335 = 0x00 <- hmmm 0x0336 = 0x03 0x033c = 0x0a 0x033f = 0x44 0x382 = 0x01 ... = 0x01 I did another few page 3 runs: 0365AED700D5BA2BAA05A865AA5C2AE4AA75AA308EF5AA542ED7AA57BB5028D1A2BDAA062AC400DF8255A8F00001008C00CC0000FF0003128954BA100A5CAA4400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780 and page 2... 0365AED700D5BA2BAA05A865AA5C2AE4AA75AA308EF5AA542ED7AA57BB5028D1A2BDAA062AC400DF8255A8F00001FF8C00CC0000FF0003128954BA100A5CAA4400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780 I checked out zpage again: 0365AED700D5BA2BAA05A865AA5C2AE4AA75AA308EF5AA542ED7AA57BB5028D1A2BDAA062AC400DF8255A8F00001FF8C00CC0000FF0003128954BA100A5CAA4400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780FFFF01FF070700000707070707070780 and page 1: 0065AED700D5BA2BAA05A865AA5C2AE4AA75AA308EF5AA542ED7AA57BB5028D1A2BDAA062AC400DF8255A8F00001008C00CC0000FF0003128954BA100A5CAA4400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780FFFF00FF070700000707070707070780 They look identical except for byte 0. But, some bytes have changed from the runs last night. Not sure what it means... I did check page 8 through page f, all show the same today... So, I think, brittle though the test harness is, I am confident the ROM is correct. On the RAM, I assume the discrepencies are due to other factors... Jim -- Jim Brain brain@jbrain.com www.jbrain.com Message was sent through the cbm-hackers mailing listReceived on 2014-07-04 21:00:02
Archive generated by hypermail 2.2.0.
