[Coco] CoCoNet bug in BASIC

[Roger Taylor]

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