Re: ROM Dump of Amiga Keyboard controller

From: Jim Brain <>
Date: Fri, 04 Jul 2014 15:28:22 -0500
Message-ID: <>
On 7/4/2014 5:18 AM, 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...
> 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 

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:
and page 2...
I checked out zpage again:
and page 1:
They look identical except for byte 0.

But, some bytes have changed from the runs last night.  Not sure what it 

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 


Jim Brain

       Message was sent through the cbm-hackers mailing list
Received on 2014-07-04 21:00:02

Archive generated by hypermail 2.2.0.