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 BIT $EA NOP NOP 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. Gerrit Message was sent through the cbm-hackers mailing listReceived on 2014-06-28 18:00:03
Archive generated by hypermail 2.2.0.