[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help with confirmation on a small bit of assembly?
mdj wrote:
>
> Tristan Mumford wrote:
>
>> >> I was just after a little help. It's not 100% apple2 related, but it
>> >> is 6502 related.
>> >> It's for my uC based USB card. I finally nailed hopefully all the
>> >> hardware problems. But now I'm back at the problem of it getting stuck
>> >> during initialisation.
>
> Hey, it's 6502, and you're developing an Apple II card! It's hard to
> get more related than that!
Yeah. The current incartnation is running on a PIC micro but that doesn't
really matter. My language of choice for this project is C anyway. And the
micro makes a convenient, portable platform. I'm still tempted to leave the
uC and a bit more logic to make it work.
>
>> ...What's wrong with me.
>> You've pointed out yet another idiotic mistake I've made of late but
>> couldn't see. Somehow during my breakdown of it 0xF = 16. Last time I
>> checked 16 != 15.
>
> Relax Tristan, this is *the* most common mistake made by programmers,
> of all levels of experience. It's some kind of brain failure mode than
> causes humans to equate the number of digits in a number system with
> highest value digit. And it's not just in assembly, C programmers do it
> all the time, by reading one past the end of an array, or printing the
> NULL on the end of string. Eventually they made up a word - 'zeroth'
> which apparently helps you out by stopping you from referring to
> element zero as the 'first' element.
Yeah, I always had trouble with fencepost errors in arrays when my mind
isn't fully with the task.
>
> The really nasty part is, as your tendency to make this mistake goes
> down, the difficulty in finding it goes up, so in a way you're
> fortunate :-)
For sure. Sometimes it takes another set of eyes to spot a problem.
>
> And remember, just because nobody else around here piped up and
> admitted to it, it's not so much that they're dishonest. It's just
> that, like other social taboos, it's not the kind of thing people will
> admit to, let alone discuss freely
>
> ;-)
Meh. Late last year I wrote a C program for my apple. I can't say I remember
what it did anymore. But it had a nasty little error not unlike this one.
In the midst of its buggy loop it went berzerk and overwrote the floppy
with garbage and made some interesting other effects too. That was a big
oops.
For some reason my short reply last night ended up attached to the wrong
part of the thread. This newsreader doesn't update properly, so sorry about
that.
Something just occurred to me that I want to run by everyone.
IIRC the SSC can trigger interrupts when it receives data etc.
This has proved to be a bit of a nuisance for things like contiki etc.
However it _may_ be useful for utilising the serial connection on my current
experiment board. Ie use a simple Prodos driver that translates data over
RS232 to something useful like the prodos compatible block mode with the
name I forget.
The interrupt is important because it can halt the system while it's
translating etc so the OS gets the data when it wants it. I think the speed
would be sufficient if most of the processing is done on the external uC.
Just an idea anyway.
--
-----> http://members.dodo.com.au/~izabellion1/tristan/index.html <-----
===== It's not pretty, it's not great, but it is mine. =====