[Coco] Disto 512k upgrade board

[Kip Koon]

Hi Art!
That is true, Super Basic does patch many things after Color Basic and
Extended Basic completes their initialization routines.  I will have to
check that out.  I'll let ya'll know the results of my findings which should
prove to be interesting.  It will be later on tonight though at the
earliest, because this evening I'm going to a dinner theater a local middle
school is putting on this Christmas Season.  Take care my friends.
Kip

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Arthur Flexser
Sent: Friday, December 13, 2013 9:04 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Disto 512k upgrade board

Kip, I'm reasonably sure that this strange behavior isn't due to any
inaccuracies in  the floating point-to-hex conversion routines.

There were changes made to the Color Basic startup sequence for the CoCo 3,
and I strongly suspect that the code at $A074 in a CoCo 3 is not what you're
looking at in the Unraveled book.  I suspect you're doing something like
jumping into the middle of an instruction and knocking a hole into the
floating point evaluation routines.  Also, Super Extended Basic may be
further patching into the code around there.  Try disassembling what is at
$A074, and I think you'll find it is not what you were expecting.

Art

On Fri, Dec 13, 2013 at 5:29 AM, Kip Koon <computerdoc at sc.rr.com> wrote:
> 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
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco