Re: A86: Hi! It's Bubbaloo13 (grayscale)
[Prev][Next][Index][Thread]
Re: A86: Hi! It's Bubbaloo13 (grayscale)
> uh, well, yeah... still, if you use any complex rom calls, you have to
> make sure you know whether or not they may trigger errors. i realize in
> most games that's not an issue, but i wanna be picky!! :)
Heh...I don't think I've ever used a ROM call that triggers an error in any
program.
> >> just another reason why i like having the second plane at $f000.
> >along
> >> with the fact that i'd rather not go to all the work of copying the
> >> stack.
> >
> >I like to have a contiguous buffer, because it makes scrolling and
> >other
> >effects much simpler.
>
> does it? one loop instead of two??
> hmm, do you use a back buffer, or draw directly to the screen?
> if you use a back buffer, you can still have it contiguous and split it
> when you copy to the display. (i should talk, i couldn't even get the
> stupid level scroll to work properly)
> the link routine, as i was working on it, was gonna work in a sorta
> "multitasking" kind of way. the link routine had an entire seperate
> register set and was set up to count time while it waited for link
> transitions. after a specified number of times through the loop, it
> switched back and returned from the interrupt. it might be better to
> occasionally steal the time in between interrupts, like every 10th time
> or something.
That sounds kind of interesting. Does it use the "standard" method of
transmitting bytes, or did you come up with your own protocal for calc to
calc?
> oookaaay... how odd.
Yep :)
I think Matthew Shepcar is the first person to find this bug, although it
probably exists on the 85. The only mention of it I've seen is in the
Repton source, which is how I finally figured out why weird things would
happen to the keyboard when interrupts were disabled, but only on the real
calc.
References: