Lol.... we had literally hundreds of bugs that got whittled down with surprising efficiency given that there was one guy on the Kernel and one guy on Basic. (Also some assists on things that sucked lots of time like the cassette code). The bugs that exist today are literally a frozen slice of time when we had to commit to MOS masks. I don’t even think management knew what a monitor was and I remember smiling when I asked if they were going to back out the monitor at the end as it was originally our main troubleshooting tool for us.... shipping a computer with the ability to debug seemed novel in a way where you knew an engineer/programmer had made a decision and not management. -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Hársfalvi Levente Sent: Wednesday, August 31, 2011 5:27 PM To: firstname.lastname@example.org Subject: Re: 264 kernals, bugs, ntsc hack, etc. Hi!, On 2011-08-31 20:08, Gerrit Heitsch wrote: >> I did meet the infamous "28 ff" bug, though (which is IMHO present in >> all revisions). > > Oh? Never heard of that one. Can you describe it? Had to recall how that one exactly happens. In short, if you code in monitor, from time to time, you'll notice that some bytes around $3000 get overwritten. To be precise: most of the time, if it happens, $3058 and $3059 are overwritten by $28 and $ff respectively. ...Most people who developed in monitor, met that one and its consequences sooner or later. As it turns out, the problem is the assembler function of the built-in monitor, interfering with Basic disc routines. "A" would copy some bytes to $0077 and on. Basic disc routines usually call the "clear ds$" routine ($CD57), which first checks if ds$ was empty (by checking whether $79 is 0). If not, it writes $28, and $ff to ($7a),y where y is $28 and $29 respectively. When using the built-in assembler, and exiting from monitor (to get a directory, or something like that), the zeropage addresses assigned to ds$ are almost 100% to be invalid. Now request directory, or do any other Basic disk I/O operations, and your stuff is most probably shot. (Whether it'll fail then is another matter - it all depends whether you're using these locations... sometimes it meant long hours of debugging mysterious problems, wondering why the hell it all failed to work once it already did work, sometimes reloading some previous saved state to start over with, etc. ) > To give you can idea, go to www.reichelt.de and search for 'V 5619' > (Search field, upper left corner). I used the one for 28pin on the CPU > and the one for 40 pin on TED. A _small_ drop of heatsink compound in > the middle, place on chip, move a bit to spread the compound around. > Then just a drop of generic adhesive (not epoxy) on each end of the > heatsink so it connects the exposed part of the chip with the end of > the heatsink. Let dry for a few days. Done. Okay, thanks! Levente Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2011-09-03 08:00:13
Archive generated by hypermail 2.2.0.