Programming challenge

[Gazoo]

I have added some edits to post #48 mentioned above which should help clarify things. These are highlighted in blue. Basically follow the recipe in that post. Since you are making a BASIC program it should work fine without modifying VEP ram that you care about. The CF7 should take care of the extra 5 bytes automatically. Naturally, if the loader is a different length than the one in post #48 then you have to modify the programs to embed a buffer that is the right length and move the right number of bytes into the buffer.

 

I've been testing by using the original Basic program, which was quite a bit longer because it contained character set data, and just patching in a new program image with a hex editor where the original one was. I make sure the length of the original Basic program is maintained by padding it. It loads the program and a bunch of zeros after it, but what's the harm.

 

It's a much quicker process as I only have to assemble one program instead of 2.

 

Gazoo

[Gazoo]

Would BASICLOAD load any EA5 file as long as the length byte and pathname were correct?

 

Yes, it was originally tested by loading Disk Manager 1000, which is a 2 segment program. It currently sits at memory location >3000, so it won't load anything that overwrites it. But as the universal EA5 loader that was developed a few years ago overcame that problem by using scratchpad, this can too.

 

Gazoo

[Gazoo]

 

Woohoo! BASICLOAD works with my nanoPEB!

 

I still get the red FCTN+6 screen; but, everything I have checked so far works. The only extra step for me was to copy the files from 060715.DSK to a 1600-sector, CF7+ image of the same name via TI99Dir. I would not think that should matter.

 

...lee

 

There's a test that should answer a few questions.

 

Flash a cart on a standard TI system. I would assume that the cart verifies ok here. Try the verification of that same cart on a CF7/Nano system. I'm betting it doesn't verify.

 

Flash a cart on a CF7/Nano system. Does it verify? Try the verification of that same cart on a standard TI system. Does it verify?

 

Gazoo

[+InsaneMultitasker]

 

Yep. Maybe limit this to a quick search of VDP from 0x37D0 to 0x37D8. Take the address of the first ">AA" found, subtract one, and stuff into 0x8370. Compare to known values for extra protection if desired.

 

Without going into full details that Lee and I were discussing here are the basic findings so far:

 

1. Lee verified that his BwG controller reserves 2 bytes of VDP at 0xfffe-0xffff. The ">AA" is at location 0x37d6.

2. The CF7/nanopeb devices reserve 8 bytes of VDP from 0xfff8-0xffff. ">AA03" is located at 0x37d0. (This usage doesn't conform to the full 5-byte validation header normally constructed by the floppy controllers.)

3. CorComp FDC, Myarc FDC, Myarc HFDC (at 1100 only), and TI controller locate ">AA" at 0x37d8.

4. The Myarc HFDC does NOT construct a VDP header nor change 0x8370 if it is configured to any CRU besides 0x1100.

5. WHT SCSI controllers do not manipulate the pointer.

6. Horizon RAMdisk ROS expects a floppy DSR to reserve VDP RAM, as it stuffs some things there. This leads to interesting problems in XB and BASIC since the programs grow downward in VDP from the highest available point. Using a Horizon RAMdisk without a floppy controller will lead to corruption in memory and during save operations.

 

While doing some further digging into DSRs, Lee and I revisited the BwG disk controller. We determined the BwG disk controller does -not- reserve 2 bytes of VDP RAM. In fact, it reserves the same amount of RAM as the TI disk controller.

 

What we didn't consider back then was a non-disk peripheral reserving VDP via 8370. The AVPC and EVPC reserve VDP ram during powerup!

 

A summary of what is "known" so far:

1. TI, CorComp, and BwG disk controllers reserve VDP RAM during powerup. 0x8370 is set to 0x37D7.
2. Myarc disk controllers set 0x8370 to 0x37D7 for compatibility with the above cards. However, actual VDP usage is minimal. For example, disk # boot tracking does not work in the same manner as the TI and CorComp.
3. Myarc Hard/floppy controllers set 0x8370 to 0x37D7 for compatibility when used at CRU 0x1100; otherwise, the pointer is left untouched. VDP usage is minimal.
4. SCSI cards do not manipulate 0x8370.
5. IDE cards do not manipulate 0x8370.
6. Horizon Ramdisk ROS 8.32 and earlier use VDP memory to save the filename and last disk number. ROS 8.14F and ROS 8.32 place this data in a location unused by the disk controller, thus rendering irrelevant. The next version of ROS is expected to remove the last VDP dependencies.
7. The AVPC video card reserves 16 bytes from 0x3FF0 to 0x3FFF, setting 0x8370 to 0x37C7 (confirmation required) based on a review of the OPA 3.0 DSR. Disk buffers are pushed down as a result.
8. The EVPC video card reserves 2 bytes at 0x3FFE-0x3FFF, setting 0x8370 2 bytes lower. With a standard floppy controller, 0x8370 will be set to 0x37D5. Disk buffers are pushed down as a result.
9. EVPC2 usage is untested/unknown at this time.
10. The NanoPEB/CF7 devices reserve 8 bytes of video RAM from 0x3FF8-0x3FFF to store pointers and information related to the mounted diskettes. 0x8370 is set to 0x37CF. Disk buffers are pushed down as a result.

Edited January 19, 2016 by InsaneMultitasker

[+Ksarul]

Nice analysis there, o insane one!