#RGB Encoder
9 messages in this thread
GreG,
BTW, I just received a glowing review of SportsText via Easyplex (along
with some suggestions for improvement, of course 8} ), so it must work OK,
GOMF notwithstanding. —Mike
Mike,
Great! It's a nifty little program. I never said there was anything
wrong wit it, only that GOMF 2.0 traps a lowmem error. Not to worry though,
not all low-mem trashing causes a problem. It still would be nice to have it
remedied though. Keep up the good work Mike.
GreG
Excuse my ignorance, but how does GOMF distinguish lo-mem trashing from
lo-mem use? I've written enough programs that guru eventually (but not
released them, of course), and this one seems solid after running 50 times.
—Mike
Mike, I don't know. Maybe trashing was a wrong choice of words. This was
the message that GOMF2.0 came up with up running SPTEXT.
Trap or Exception table was trashed.
68000 vector at loaction – $00000034
was corrupted with value – $00C01F70
Other than that, I can offer nothing. As I said, this may mean nothing. But
should it be happening at all?
GreG
Beats me. The only standard memory location is $0004. I'll investigate.
Thanx! —Mike
Mike,
The Amiga reserves a lot of low memory. You should not be writing into it
with your program.
Regards, Larry.
Actually, a lot of that low memory is "reserved" by the 68000 itself rather
than the Amiga. The vectors for traps and interrupts are stored in the low 1K
of memory because that's where the 68000 wants to see them. I believe the 010
and 020 are more flexible about where those tables can be put, but with the
68000 there's no choice. So, although 4 is the only fixed location as far as
the Amiga OS is concerned, that whole stretch of memory is also fixed by the
CPU. Many programs do accidentally write more or less benignly into that
space. The 3.4a Aztec assembler frequently writes a $62 to location 12; since
that's the high byte of a pointer it does no damage (at least with a 68000).
The first release of Professional Page writes twelve successive bytes of
garbage starting at $30 or so, but that's a reserved, unused slot in the
vector table so it gets away with it. It would be nice if developers would
check to make sure that their programs don't write to low mem before
releasing a product, though; even when those writes don't crash the machine,
they do point to something unintended happening in the program, and of course
may be disastrous on some future Amiga where things are arranged a bit
differently.
Nick
If another program, like, oh, ieee math libraries decided to patch the 68000
vectors so to emulate the 68881 better your memwatch type program would
probably go off, too.
andy
Right. One of the more annoying things about developing with Aztec and db is
that the assembler itself can set off db's low memory checksum alarm. Unlike
memwatch, unfortunately, db doesn't provide a way to undo the damage
automatically.
Nick