[Coco] CoCoNet bug in BASIC

[Arthur Flexser]

I can only take a wild guess, but....

Sounds like you might have, in your Drive Pak accessing, corrupted one of
Basic's variables that is used for line insertion, making Basic think the
to-be-inserted line is empty.  Are you using any low-memory scratch
locations, perhaps in the $Dx or $Fx range?  Another possibility:  could the
DP register have somehow been left set to something other than zero on
return from one of your routines, causing Basic to look in the wrong place
for the contents of one of these low-memory locations?
Art
On Mon, Nov 30, 2009 at 1:22 AM, Roger Taylor <operator at coco3.com> wrote:

> I need help here guys... put your thinking caps on so the CoCoNet client
> ROM can be released sooner?
>
> This is getting crazy.  For two weeks I've seen the bug come and go.  I've
> looked at the BASIC source code (Unravelled Series) and can't figure out why
> it's happening or what I'm doing to make it happen.
>
> Only when the Drive Pak is accessed (the MicroSD card is read or written
> to) does this seem to happen.  Yet, when I issue the command DRIVE#? to see
> a listing of the partitions, the bug goes away until the next time I type
> DIR or load a program, etc.  Both commands access the pak, but DRIVE#? uses
> the raw sector reader, bypassing the track/sector computer to get the LSN
> offsets.  It jumps over that part and uses registers A and X for the 24-bit
> LSN and uses the SAME sector read/write routines to do the transfer.
>
> What's happening is that when you go to EDIT or insert a BASIC program
> line, the line and following lines of the program VANISH from the listing.
>  Peeking into memory shows that NULL bytes were inserted, as if the program
> was opened up for the insertion, but nothing was inserted!  The space is
> there, though.
>
> This has caused me a Lot of lost sleep and is the reason the CoCoNet ROM
> hasn't been released yet.  Other than that, the Drive Pak is functioning
> like it should at 230400 bps, boots into DOS or OS-9 in any partition you
> like.  The Wirless Pak, bitbanger drives, etc. don't cause the bug to
> happen.
>
> I feel that this is related to me switching to the ROM map temporarily to
> access routines in the upper 8K of the 16K CoCoNet ROM. I always mask
> interrupts and restore after I've returned back to the bottom 8K of my ROM.
>
> The CoCo 3 patch guys really gave us a nightmare once you have to work with
> the ROMs more in a project like this. They butchered the crap out of BASIC
> and did things that make little sense.  They were under pressure and just
> got it done, apparently.  They made it work and left bugs and made it hard
> to use a 16K DOS, that's for sure.
>
> So, what on Earth is in the BASIC code that would open up an area in a
> BASIC program in prep for the insertion of a new line or the replacement of
> an edited line, but doesn't actually insert those characters?  What would be
> stopping the second action from happening?  The input buffer looks empty or
> returns NULL characters perhaps?  A corrupt pointer?  I don't mess with any
> of that, so what's the problem?
>
> Btw, the partitioning commands have been added to Disk BASIC and more to be
> added tomorrow... you can list the partitions, set the auto-boot partition
> by name or direct LSN, and set the current temporary DOS partition (256
> drives)... which gets overridden by the auto-boot partition the next time
> you boot.
>
> DRIVE# is the prefix for the MicroDrive (Drive Pak) commands.
>
> DRIVE#="MYDISKS",DOS    make pak boot to the MYDISKS partition of 256 disks
> on each boot, and sets the current partition to the same
> DRIVE#="MYGAMES"  change to partition temporarily until changed again
> DRIVE#=#0,0,0   point to LSN-based area of 256 disks (for surgery mode)
> DRIVE#=#0,0,0,DOS  auto-boot to any LSN (treated as 256 virtual disks like
> the above partitions) (unusual need to do this, but it's there)
> *.BAS is the auto-boot program looked for on DRIVE 0 of any auto-boot
> partition.
> DRIVE#+"MYGAMES"   add a partition (size and starting LSN optional) (180mb
> is the default size so OS-9 can use 720K disks without worries)
> DRIVE# KILL "DATALOG"  remove 256 disks partition called "DATALOG" (180mb)
> DRIVE# SET 0,0,1   (the default already) set partition table to LSN1
> (shouldn't be changed once partitions are added to the table)
> DRIVE#?  list partitions  (name, starting LSN, size, type)  The Type
> doesn't really matter
> DRIVE    show currently mounted disks (wireless, real, bitbanger, drive
> pak, ram disk, etc.)
> I might have left some stuff out here, but you get the idea.
>
> The defaults are LSN0 system use, LSN1 partition table start, LSN $002000
> 'DOSFD0' 256 disks, and NitrOS-9 is 180mb past that, with 782 megs to go on
> my 2gb card.
>
> Until partition moving and advanced logic is added when deleting/inserting
> partitions, it's better to start with a clear partition table and add the
> partitions in sequence.  If the power goes out when you're working with the
> partition table entries, the data isn't lost, btw.  In tests and goofups,
> I've repeatedly cleared my table and gone back and inserted the standard
> partitions in sequence and got my drive pak restored, all data intact.
>
> It's pretty fun doing this from the command prompt, but I've got a PART.BAS
> program that attempts to simplify the adding of partitions, showing you the
> types, sizes in MB, starting LSN, etc. all computed automatically.
>
> --
> ~ Roger Taylor
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>