On 2012-09-16, at 13:05, Gerrit Heitsch wrote: >>> The test mode is described briefly on page 8. >> >> "... Applying +10V signal to the _RES line places 6500/1 in the test mode. While in this mode all memory fetches are made from Port PC. [...] A program can be loaded into RAM allowing the contents of the instruction ROM to be dumped to any port for external verification." >> >> Now, how do we understand this? >> >> "Port PC" is probably Port C (Pins PC0-PC7) /me guesses. Eight bits of data (guessing again) but what about addresses? There is not much of a program to be loaded into the whopping 64 bytes of RAM but should be enough for dumping the ROM. Still /how/ can this be loaded into RAM? And executed? > > I wouldn't be surprised it means that no matter what the PC or commands say, every memory access (command and data fetch) will redirected to Port C. > > So you have to expect what it wants to load and then supply the Byte starting from the RESET vector. Sounds like a very painful job to get a program into the thing, but it could be done and 64 Bytes RAM are enough for a simple copy routine that will just dump the ROM onto another port. Even if it is so, then few more questions come to mind: 1. What about the timing? Since I notice no form of handshaking mentioned, I guess one would need to put proper bits on the port according to cycle-exact fetch/execution times? 2. If it is as you write and [1.] above is solved, then what do I need [to load program into] RAM for? I could supply commands and data until I am done with ROM dump or anything, effectively simulating RAM on the port, couldn't I? I see some contradiction here. Or we understand it wrong. 3. If I need to load PRG into RAM, how do I switch execution to it when all accesses go to port anyway? Maybe a precisely timed disconnect of the _RES voltage combined with appropriate data preceding it.. Yes, in any case sounds like a painful process. Might Bill for example remember something about this stuff and shed some light? -- SD! Message was sent through the cbm-hackers mailing listReceived on 2012-09-16 22:00:32
Archive generated by hypermail 2.2.0.