On 06/26/2014 01:31 PM, email@example.com wrote: > As before, I still don't have a clear picture of how exactly is this > supposed to work. Either this or the (presumably simpler) approach with > an EPROM and a 4040. I think I am not alone in this and that is one of > the reasons nobody (including myself) haven't done it yet. Well, the way I see it is as follows: First you put the 6500/1 through the normal reset. It will then start to run its internal program. Then you pull RESET to +10V. From that moment on, all memory fetches will be made from the data register of Port C. This will of course interrupt the internal program, possibly in the middle of an instruction fetch. Means you will have to make sure you use a few single byte instructions at the beginning to 'sync' up. 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 LDA #$xx ; first byte of ROM dumper STA $00 LDA #$yy ; second byte of ROM dumper STA $01 [...] ; continue until last byte... JMP $0000 The idea I have is to unroll the program into the byte sequence the CPU expects. This will not necessarily be the sequence produced by an assembler from your program so there is work by hand involved. The simplest way would be use a 4040 (12Bit counter) as an address counter for an EPROM containing this sequence. Since the external clock is divided by 2, it would either mean to double up the byte sequence or ignore the first output of the 4040 and hook up the second one to A0 of the EPROM. Some extra logic keeps the 4040 in RESET until the +10V are applied to the CPU RESET pin. 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 and this will cause some extra logic to return the RESET to +5V just in time for the CPU to realise it needs to fetch the next byte to execute from $0000. Now the CPU is running your program. Best might be to have it wait for an external clock and then supply the next byte from the ROM until done. That way you could grab it via an AVR at your leisure which then transfers it by RS232 to your PC. The pitfalls are the start and end of the program load. You need to hit the exact point in time when taking over with RESET=+10V and when handing back with RESET=+5V. This is something that will probably have to be tested the hard way with a simple program that just writes a bit pattern to one of the other ports after setting it to be output and then halts the CPU with one of the killer opcodes. Gerrit Message was sent through the cbm-hackers mailing listReceived on 2014-06-26 19:01:01
Archive generated by hypermail 2.2.0.