[Coco] Disto 512k upgrade board
Kip Koon
computerdoc at sc.rr.com
Fri Dec 13 05:29:17 EST 2013
Hi All!
I looked in the Color Basic Unraveled book in the Disassembled Listing for
the WARM START FLAG detection sequence at the beginning of the code and upon
detecting no warm start flag, control is transferred to BACDST or the Basic
Cold Start routine which is $A074, so I typed in a simple one command
statement using &H to precede the hexadecimal number A074 like this
EXEC &HA074
to see if the code would Cold Start DECB 2.1 on the Coco 3. I tried it in
VCC to make sure it would work and it did. Then I thought, what about those
individuals that prefer all decimal numbers, so I converted $A074 to 41076
and tried it expecting that to work also. I typed in
EXEC 41076
and guess what? It didn't work! VCC Coco 3 got lost! I thought that was
very strange. I tried it on a real Coco 3 and it didn't work there either.
Then I got to thinking. Could it be true that since &HA074 is already
hexadecimal, the Basic Interpreter may just be directly using that number as
an execution address? Could it also be true that since 41076 is decimal and
since Basic needs to convert that to a hexadecimal number to be able to use
it as a memory address to transfer control to, somehow during the conversion
process of changing 41076 decimal to $A074 Hexidecimal that a conversion
error took place and the end result is not exactly $A074? I would imagine
the floating point routine is not exactly perfect.
Years ago back in the early 1980s, I wrote a BASIC program on the Altair
8800B running a Microsoft Time Sharing Basic Interpreter computer system
there in the computer room in the Electronics Engineering Technology Wing of
Spartanburg Technical College to convert Decimal numbers to and from
Hexidecimal and Binary. "0.1" turned out to be a repeating binary number
according to the conversion process I learn back then.
Though I don't exactly know how Color Basic is converting a decimal number
to a hexadecimal number for the EXEC command, I'm thinking something is
wrong with the math routines. Can anyone who understands the math routines
implemented in 6809 assembler code better than me check to see if this is
true? It would be interesting to see if there are any other errors in the
math routines.
So, I guess I'm relegated back to the
POKE 113,0
and pressing the <RESET> button to cold start my little Cocos. At least
that will work on any Coco, a 1, 2 or 3. Take care my friends. Qaplah!
Starfleet Out!
Kip
-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of William Astle
Sent: Thursday, December 12, 2013 3:30 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] Disto 512k upgrade board
On 13-12-12 01:10 PM, Mark Marlette wrote:
> No 20 count......
>
> POKE 113,0:POKE 49152,0:EXEC40999
>
How does zeroing out the first byte of the DECB range help anything? All
that'll do is stop extended basic from initializing DECB.
For a proper cold start, better to EXEC&H8C1B (35867) on a coco3 - that will
actually trigger the internal boot rom. 40999 (A027) does not.
Triggering the internal rom will recopy the ROMs to RAM which may be helpful
if you messed something up.
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list