That's the real CBM hacking ! ;) Jim... you are THE BOSS :) Of course all of the guys involved in this are the _hackers_ ;) Now let's put this back to a new 6500/1 and see if it works in 1520. How ? I also have a few R6500/1EAB MCUs - the "piggyback" ones, with a socket for an EPROM :) 2014-07-04 13:28 GMT+02:00 <email@example.com>: > > On 2014-07-04 at 13:16:39, firstname.lastname@example.org (email@example.com) wrote: > > > The differences in the unassigned pages can be disregarded. It's like > > reading from the unassigned address space in the C64, since there are no > > drivers active, you get what the input stages see. That could be > leftovers > > from the last command or noise from other parts of the chip that is > 'loud' > > enough to be seen as '1' instead of '0' and combinations of both. > > > > In the C64 you usually get the last byte read by VIC since the traces > have > > enough capacitance to hold the voltage long enough. In the 6500/1 we're > > talking about traces on the die itself. > > > > So, as long as the ROM part reads stable, we can disregard the rest. > > Yes, that was my question. If the remaining - chiefly ROM pages read all > reliably. > > > According to the datasheet, the ROM is only 2 KB, so only pages 8 to F > are > > interesting, everything else is RAM, I/O or empty space. > > > > From looking at the last page, it looks like as if all 3 vectors > > (IRQ,RESET,NMI) point to the same address $0A95, suggesting that IRQs are > > not used in this implementation. That might help with the disassembly. > > Binary: > https://dl.dropboxusercontent.com/u/58002657/cbm/1520/p8-pf.bin > > Infofile (pretty basic): > https://dl.dropboxusercontent.com/u/58002657/cbm/1520/p8-pf.infofile > > Raw disassembly (infofile still crude): > https://dl.dropboxusercontent.com/u/58002657/cbm/1520/p8-pf.s > > -- > SD! > > > Message was sent through the cbm-hackers mailing list > Message was sent through the cbm-hackers mailing listReceived on 2014-07-04 14:00:40
Archive generated by hypermail 2.2.0.