On 09/16/2012 11:30 PM, silverdr@wfmh.org.pl wrote: > > 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? That's what I think too... > 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. No you can't since in that mode all data fetches would be from the I/O-port, you wouldn't be able to access the ROM for reading. Since loading a program into RAM is mentioned, I assume writing will go to RAM. > 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.. That's what I figure... Have the CPU fetch a JMP to the beginning of your code in RAM, that let go of _RESET and it should start to run your program. > Yes, in any case sounds like a painful process. Might Bill for example remember something about this stuff and shed some light? I think it would only be a painful process until you fully understand it. Then you should be able to hook up a 2716 or 2732 EPROM plus a 4040 as the address counter and just supply the Bytes needed one after the other. Plus some extra logic to stop the counter, deselect the EPROM and free the _RESET line once you're done. If you're the maker of this CPU, you only write this EPROM once and then you're able to dump the ROM of all the 6500 you'll ever make. I wonder if that could be used to dump the ROM code from the 6570-036 used in the Amiga keyboards? Gerrit Message was sent through the cbm-hackers mailing listReceived on 2012-09-17 17:00:32
Archive generated by hypermail 2.2.0.