Re: ROM Dump of Amiga Keyboard controller

From: Gerrit Heitsch <>
Date: Sat, 28 Jun 2014 19:04:57 +0200
Message-ID: <>
On 06/27/2014 11:52 AM, Marko Mäkelä wrote:
> On Thu, Jun 26, 2014 at 08:42:21PM +0200, Gerrit Heitsch wrote:
>> To write a program for that, you need to supply the next byte the CPU
>> expects to Port C. This means you don't have to care about the program
>> counter, but you will need the exact timing for every 6502 instruction
>> you plan on using and remember the rudimentary pipelining. So better
>> stick to simple commands and forget about branches and stack
>> operations in the loader. To get a ROM dumper into the RAM, you'll
>> mostly need
>> NOP
>> NOP
>> NOP
>> SEI
> Well, keep in mind that the current instruction length is between 2 and
> something like 9 cycles.

Yes, this was only an example, the real program would use a lot more 
NOPs at the beginning.

> I pointed out earlier that NOP is not a sufficient choice, because you
> will still have uncertainty which cycle you are executing. You do not
> know if the 0xea was a dummy fetch, or if it was fetched for the
> instruction decode.
> Because of this, you need a final synchronization with a 3-cycle
> instruction followed by a 2-cycle instruction. The start could indeed
> look like what you suggested:
> 0xea 0xea (two bytes emitted for one NOP; it is 2 cycles)
> 0xea 0xea
> ...
> 0xea 0xea
> 0x68 0xea 0xea 3-cycle PHA, or 2-cycle NOP if the 0x68 was a dummy fetch
> 0x78 0x78 (SEI)

An idea might be the BIT instruction. Like


should sync things up nicely. Either you execute the BIT or the NOP that 
follows either way, then you should then be in sync.

> Right, you will have to supply some dummy data also while the write
> cycle of STA is executing. So, you could obtain the byte sequence with
> an assembler by just appending some single-byte instruction such as NOP
> after each STA above.

Or just repeat the last byte since the dummy data will not be used by 
the CPU.

>> Now, how to hand the control to the program just loaded into RAM?
>> Easiest idea would be to make sure the last byte of JMP $0000 is
>> located on a page border so that an address bit that was 0 all the
>> time before switches to 1
> Could we use this idea for synchronizing the instruction fetch when we
> are in the +10V mode? For example, wait for A15 to be 0, and to get back
> to 1 while you are in the "ea 68" mode.

You forget that you don't see any of the address and control lines on 
the 6500/1. You have no way of knowing the current state unless you 
manage to get some code to change the state of an I/O-port.


       Message was sent through the cbm-hackers mailing list
Received on 2014-06-28 18:00:03

Archive generated by hypermail 2.2.0.