Corvette

[litwr2]

I have added the support of a boot disc format for the Corvette. For instance zcc +cpm -subtype corvetteBOOT -lm -o adventure -create-app adv_a.c creates a boot disc. However I am not sure that I use the best way to implement this support. Boot formats are typical for the Corvette, almost all (just all?) known discs for the Corvette use a bootable format.

[suborb]

The auto-boot code looks like it's actually CP/M?

Normally our autoboot discs use their own bootstrap code (see pc88 for example) take over the entire machine, switching to all-ram mode and the libraries tend to drive the hardware directly rather than relying on ROMs.

[litwr2]

The auto-boot code looks like it's actually CP/M?

Normally our autoboot discs use their own bootstrap code (see pc88 for example) take over the entire machine, switching to all-ram mode and the libraries tend to drive the hardware directly rather than relying on ROMs.

Yes, it is just CP/M generated for the Corvette. Almost all the Corvette software uses CP/M or its enhanced version called Micro DOS. So, sorry, I haven't still understood what is the proper way to make a boot disc for the Corvette. It seems It implies the format which is not CP/M compatible but almost all (99.99%) the Corvette software is CP/M compatible.

[litwr2]

What is exactly wrong with this commit? Why is not it merged? CP /M is now free software, its code is perfectly legal to use in this project.

[feilipu]

What is exactly wrong with this commit? Why is not it merged?

IMHO, the issue is that you're including a blob of code into a project where that is not the norm.

Usually, if there's some assembly to be included (such as the DAI 32-bit math library, or Microsoft Floating Point mbf32) the assembly and its entry points will be adjusted to suit the use of two compilers in use, and then included as a maintainable assembly file.

However, specifically to the solution for the corvette, the way to build the PR is to disassemble the blob, and then identify where the CP/M BIOS entry points are for the ROM serial and disk access mechanisms. These are pretty easy to find in the table referenced from the BIOS entry point. If there is no ROM, but the CP/M BIOS actually directly accesses the hardware, then so much the better as you can then describe the complete hardware interface, including graphics and sound.

Once you've got these hardware access routines then you can use these to build the appropriate serial / disk / graphics and other drivers that you want to have in the ROM for the corvette.

For the example provided by @suborb the pc88 you can see how the stdio is implemented, how the display raster interrupt is implemented, and how graphics and other items are implemented.

So the idea is to build direct interfaces to the hardware in the best case or otherwise to ROM, if the ROM doesn't contain errors that prevent it being used. If you're interested to build a boot ROM, then you'll be writing the drivers for the hardware.

CP/M is now free software, its code is perfectly legal to use in this project.

Yes, but a CP/M blob is not particularly maintainable, and having the blob is actually just like making a CP/M target for the corvette.

Just to clarify, I've got no idea how the corvette works, but I'm trying to answer the questions that you posed in the PR to help it progress. :+1:

[zx70]

I'd like to add that your effort is MUCH appreciated, please do not stop. The z88dk needs contributions and fresh ideas, otherwise it'd be yet another compiler. It is not critical for us to add a (reasonably coherent) stub for a new target, even if not fully working. When it is clean and properly explained we will able to help/contribute.

[suborb]

Slowly finding the time to do more...

I've added the disc geometry into appmake (corvboot is the name), the boot file can be added with -Cz--bootfile=xxxxx

I've spotted that we've got a binary blob for +sam (from the source code here: https://github.com/stefandrissen/samdos) so there is a precedent for blobs

[litwr2]

Slowly finding the time to do more...

I've added the disc geometry into appmake (corvboot is the name), the boot file can be added with -Cz--bootfile=xxxxx

I've spotted that we've got a binary blob for +sam (from the source code here: https://github.com/stefandrissen/samdos) so there is a precedent for blobs

Thank you! Your code should definitely make the required things better than mine. But there is something wrong in the update. :( It causes wrong code to be written on the boot sectors. A disk created with -Cz--bootfile=xxxxx is not bootable. :( I have checked this issue and found out that dd if=xxxxx of=diskimage conv=notrunc fixed the disk. So the code needs to write the same way as dd does. It seems that /lib/config/cpm.cfg should be fixed too, it must contain something like SUBTYPE corvboot -Cz+cpmdisk -Cz-f -Czcorvboot -Cz--container=raw -D__CORVETTE__ -Cz--extension=.kdi -pragma-define:CLIB_FPUTC_CLS_CODE=0x1f -clib=8080 I am not sure about the value for the D-option. EDIT. I have just checked, with the updated cpm.cfg all works fine. Should I create a pull request for this tiny change? EDITEDIT. IMHO I should create a new pull request and close this one, right?

[litwr2]

It seems, I have just made my small fix for the boot-disk commit.

[litwr2]

Is it something wrong with my tiny commit which fixes the commit from @suborb ?