From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2004-07-16 09:20:49
Hallo allemaal,
The initial subject was "Three days of frustration....".
My problems started Monday evening when testing CBM-HD, a PC emulating a
IEEE-floppy drive, and specificly testing GET#. I simply asked to display
the first two bytes of the BAM-sector of a 4040-disk. Instead of the
expected '18 1' I got '13 13'. It was late so I called it a day.
The next day my program simply refused to run, worse, the computer blocked
up completely. The program that worked the day before, would do that anymore
the next day, although I hadn't changed even one character. At the end I had
to fall back to a back-up of Sunday. Only Wednesday evening I discovered why
the computer froose: a wrong use of memory. But only to discover that my
INPUT# didn't work anymore as it should:
.....
10 print#1, a$, m
.....
30 input#1, a$, m
.....
50 input#1, a$
55 input#1, m
.....
Line 30 worked fine, both a$ and m were filled. 50 executed fine as well but
55 didn't. The stupid thing was that after receiving '$29 $69' for line 50,
my PC started to transfer the needed data and was interupted after sending
the data for 'a$' as expected. But when sending the data for 'm', it was
interrupted by an ATN while transmitting the first byte. Something that was
strangely enough also the case with GET#. Having no idea at all where to
look for, I again fall back on the back-up of last sunday :(
I started to add all needed changes to make GET# work and finally arrived at
the procedure that actually transmits the data and.... BINGO! But the
weirdest thing was that REMOVING a debug statement caused the fault with the
INPUT#: with the statement line 55 worked fine, without the statement it
didn't.
I'm using some records inside a record and accessing them in the 'Watches'
window is a bit tough so I copy them to some reserved variables which are
more easy to access. But the debug statement also contained a section were I
read the BAM-directory as this was changed form time to time by an earlier
bug. Not needing it anymore and being afraid of unnecessary time delays I
'remarked' it. Suprise, my line 55 problem was back!
The next step was replacing this debug statement with 'for w1 := 0 to 1000
do by := port[$278];'. Knowing that accessing the LPT-port would take about
1 uSec, I wanted to generate a delay of 100 uSec. But I made a typo as you
see above. But nevertheless things worked fine. Seeing that typo, I replaced
the statement with 'delay(1);' meaning: delay one milisecond. This worked
fine as well. But the biggest suprise was that GET# now worked fine as well
!!!
Now the big question: why this delay ???
I even can hardly accept that GET# doesn't work because of being to fast
trying to transmit the data. The only interrupt driven line is ATN AFAIK so
a reaction on a too early interrupt is out of the question IMO. What I
certainly don't understand is that line 50 works but a GET# does not: the
circumstances are the same IMHO, the CBM just sent a 69 and has nothing to
do except waiting for data. A possible reason for the error with line 55
could be that the CBM still is processing the received data but then tell me
why it tells the drive to send the next batch?
Quite puzzling, any ideas?
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
=====DISCLAIMER=================================================================
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.