[Coco] Disto 512k upgrade board

[Arthur Flexser]

I think even if you knock out Super Extended Basic by going to ROM
mode (POKE&HFFDE,0), you may still find the code in that region is
different from the original Color Basic version that is in the
Unraveled book.

A lot of the startup changes were put into the area originally
occupied by the DLOAD command, which on the CoCo 3 does the equivalent
of pressing reset.  (So POKE113,0:DLOAD is yet another method of cold
starting.)

Art

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