8MGb CP/M

[Wmaalouli]

So I tested the 8MGb CP/M and it works great, but I noticed a couple of things:
- The file copying process seems slower than standard CP/M
- When copying files using the * wildcard, the first file's name appears twice on the screen. It's a very minor issue with no real consequence, but I thought I'd mention it.

Overall very nice work indeed!

[Milli]

So I tested the 8MGb CP/M and it works great, but I noticed a couple of things:
- The file copying process seems slower than standard CP/M
- When copying files using the * wildcard, the first file's name appears twice on the screen. It's a very minor issue with no real consequence, but I thought I'd mention it.

Overall very nice work indeed!

The slow down could be because of the larger record sizes.

[Wmaalouli]

I thought it might be...

[Wmaalouli]

One other thing: the file size is incorrectly reported by the STAT command.
I have made your 8meg CP/M image my main work image as it simplifies my life quite a bit by keeping all my development files in one place.

[Milli]

I’m glad you’re making use of it

[Wmaalouli]

I’m glad you’re making use of it

Do you think you're going to fix the file size reporting issue?

[Milli]

To tell the truth I’m not sure how - I really don’t understand the parameter blocks. I’m tempted to post all the source code so others ( you? ) can play with it.

[Wmaalouli]

To tell the truth I’m not sure how - I really don’t understand the parameter blocks. I’m tempted to post all the source code so others ( you? ) can play with it.

Normally the OS takes care of the size calculations like the extant number etc... so I have never messed with that.
The extant and number of records for the files appears to be correct, but the reported size is a little over double what it should be. Each record is 128 bytes, so its easy to manually calculate the real file size. I have no idea where in BDOS that calculation takes place...