RE: 264 kernals, bugs, ntsc hack, etc.

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: owner-cbm-hackers@musoftware.de
[mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Hársfalvi Levente
Sent: Wednesday, August 31, 2011 5:27 PM
To: cbm-hackers@musoftware.de
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 list